The Pragmatic Engineer — selected conversations
Building OpenCode with Dax Raad
Eighteen curated conversations on agent workflows, design, harnesses, and software quality
A manually reviewed selection of Pragmatic Engineer conversations with Maggie Appleton, Matt Pocock, Tibo Sottiaux, Martin Fowler, Dex Horthy, Boris Cherny, Mario Zechner and Armin Ronacher, Laura Tacho, Hillel Wayne, Mitchell Hashimoto, Kent Beck, Peter Steinberger, Grady Booch, Steve Yegge, DHH, Dax Raad, Charity Majors, and Addy Osmani. Topics include design prototyping, reusable skills, agent workflows, context and harness design, TDD and verification, architecture, measurement, accountability, and open-source governance. Practitioner observations, product-team claims, and forecasts are not controlled findings.
In this collection Browse 18 summaries 16 of 18
Faster code generation does not decide which features are worth shipping. In Gergely Orosz's Pragmatic Engineer interview, OpenCode co-founder Dax Raad explains why product judgment remains the bottleneck 03:33–06:27(opens in a new tab).
He also describes OpenCode's open-source, provider-neutral strategy 17:46–20:38(opens in a new tab), and warns that agents can make weak features and architectural hacks cheaper to ship 49:05–54:35(opens in a new tab).
Key points
- Product judgment remains scarce: Shipping every user request or competitor feature creates an incoherent product and an expanding support burden, even when implementation is cheap 03:33–06:27(opens in a new tab).
- Neutrality is a competitive strategy: OpenCode claimed the open-source harness position so rival model providers would have reasons to support it; continued neutrality still depends on provider competition 17:46–19:51(opens in a new tab), 25:16–27:12(opens in a new tab).
- Initial UX came before harness superiority: The team invested in terminal rendering and a fast first prompt, while Raad says the early harness itself was only good enough 28:15–30:21(opens in a new tab).
- Provider access is not permanent: Anthropic's subscription restriction showed how vendor incentives can change; OpenCode responded by adding official support from competitors 20:38–27:12(opens in a new tab).
- Agents hide the felt cost of hacks: Easy implementation mutes the discomfort that once encouraged an engineer to reconsider a poor design, while leaving future maintenance risk intact 49:05–51:52(opens in a new tab).
- Cheap generation can fund cleanup too: Raad advocates migrating improved patterns across old code to keep the repository workable, while acknowledging that cleanup has no immediate revenue line 52:46–54:35(opens in a new tab).
- Builders receive feedback directly: OpenCode moves work to a demonstrable foundation, then has the implementing engineer process GitHub and social feedback without a summarizing intermediary 1:02:39–1:04:47(opens in a new tab).
- Guardrails are familiar engineering work: Tests, conventions, and stronger domain structure help fallible agents make safer changes; the episode does not measure their comparative defect impact 1:12:40–1:15:27(opens in a new tab).
- Speed and business claims need qualification: Raad says aggressive AI use did not obviously make OpenCode faster 54:35(opens in a new tab). User and run-rate figures are company-reported, while margin claims include estimates about other providers; none is independently verified here 19:51–20:38(opens in a new tab), 33:26–38:55(opens in a new tab).
Full video: https://www.youtube.com/watch?v=1VqKUrxR2C8(opens in a new tab)