Paul Asjes is a Developer Experience Engineer at ElevenLabs, building developer tools and writing about the web. His career spans product engineering, developer relations at Stripe, and developer-experience work at WorkOS. Across that work, he examines how APIs can help their users understand what to do next—a question that now includes the coding agents integrating those APIs.
From product engineering to developer relations
Asjes began as a Flash developer, then worked in frontend and full-stack engineering at Tumblr and startups before moving into developer advocacy. His professional background connects his developer-experience work to more than a decade of building products.
By 2021, he was a developer advocate at Stripe, where he later ran developer relations. In his account of the transition, he describes listening to developers as practical engineering work: frustrations need to become actionable changes for product teams. Helping someone get unstuck also reveals what the product needs to do better.
At Stripe, Asjes developed a sustained argument for human-centered API design. An API is part of the product; a confusing interface can prevent developers from discovering the underlying service’s value. His writing on API design patterns examines the tradeoff between a simple, opinionated integration path and the flexibility more demanding applications require. The design depends on the audience and which decisions developers should have to make themselves.
His work on error messages makes that argument concrete. A useful error identifies the failed input, explains the likely cause, and suggests a remedy. When a customer lookup uses test credentials against a live-mode object, naming the mismatch saves the developer from guessing. He also sets limits on disclosure: helpful errors should not expose sensitive internals or reveal whether an authentication identity exists.
Making application infrastructure easier to use
At WorkOS, Asjes brought these concerns into authentication and enterprise application development. His 2024 writing explained several complementary parts of that infrastructure:
Session management: His explanation of sessions connects simple integration with server-side revocation and graceful handling of expiring sessions—behavior developers need to get right even when authentication is not their product’s main purpose.
Roles and permissions: His introduction to roles explains permission-based access levels, helping developers distinguish what a signed-in user is allowed to do.
At ElevenLabs, Asjes’s work extends API usability to coding agents whose knowledge may lag behind a changing product. His proposals and projects address different parts of that problem:
Self-healing API integrations: In 2025, Asjes proposed a natural-language integration layer that could consult an OpenAPI specification, cache successful request patterns, and regenerate them when a schema changes. He treats this as an exploratory design: repairing a schema mismatch cannot necessarily resolve a change in meaning, and automatic retries can mistake bad input for an API change. His preferred direction uses predefined MCP tools to constrain the operations a model can perform.
Agent education and usable output: Asjes distinguishes skills from MCP tools: skills teach an agent how to approach a task, supplying current product knowledge and explicit warnings; tools execute defined actions. He also built the ElevenLabs MCP Player, which gives generated audio a playable interface instead of leaving the user with a file path. This work addresses both the agent performing the integration and the person receiving its results.
Agents-as-code: Asjes co-authored the August 2026 introduction of ElevenLabs CLI v1 with Min Kim and Tadas Petra. The workflow brings voice-agent configurations into local files so teams can edit them, review differences, and preview changes before applying them. Machine-readable command schemas and structured errors help coding agents construct requests without guessing. It carries his earlier API-design concerns into a workflow where developers and software agents both need clear guidance.
Follow a voice agent from speech recognition to language switching, tool calls and spoken replies, then examine what breaks with slow systems, mixed languages and domain vocabulary.
Which languages—and which accents—should the agent speak?
▶ Watch ↗