APIs are the cornerstone of communication between services, yet we still treat the design of them as an afterthought. We spend huge amounts of time considering UIs and how users interact with them, why don't we do the same for APIs?
In this talk, Paul leverages 5 years of API experience at Stripe to discuss why we should start designing our APIs for the humans behind them. He'll show examples, share some horror stories and hopefully convince you on some best practises when designing and implementing your API.

Each component property in your design system serves as an entry point to your component library and its developer experience is largely influenced by their structure and implementation. In this talk, we'll explore multiple ideas to refine your thought process when working on components and make your libraries more user-friendly for other developers.

We want our software to be easy for people to use. That means building a great UI. Now that people work with AI agents, we need our software to be easy for agents to use. That means building a great MCP. Model Context Protocol servers give AI agents fingers to feel around and act in the world, one tool at a time.

In this session, I’ll share design considerations from the Honeycomb.io MCP. I’ll contrast MCP design with human UX and software APIs, then discuss ways to tell whether the MCP is effective in production.

GraphQL error handling sucks. There, I said it.

Ever hunted through the errors list to figure out if a null was legit or caused by an error? If you're like me, you gave up and now treat nulls as "maybe errored, maybe absent, maybe both."

And nullability. Schema designers make anything that might fail nullable, producing partial responses when errors occur. But since anything can fail, now everything is nullable— and we're drowning in null checks. We recklessly cast to non-null or fall back to the empty string out of desperation. And we still don't know what's truly nullable.

No more.

This talk introduces a new, pragmatic approach, born from years of work by the Nullability WG. We propose a future where schemas reflect the true nullability of business entities, and error handling is where it belongs: in your code, not your data. Use your language's built-in tools to handle errors ergonomically; and drop the unnecessary null checks. When you read a null, it should mean one thing: the absence of data.

This isn't some distant ideal on the horizon of GraphQL's future; with just 512 bytes added to your GraphQL client, you can start adopting this today. Come see how.