Intel / article

Building OpenCode with Dax Raad

Source: newsletter.pragmaticengineer.com
Author: Gergely Orosz
Date: Published May 27, 2026

Context

Cheaper code generation leaves teams with decisions about which features deserve to exist. That is a central argument from Dax Raad, cofounder of the AI coding tool OpenCode, as summarized by Gergely Orosz in an episode of The Pragmatic Engineer Podcast. In the summary, Raad says that before a product finds its market, AI helps little because the problem is deciding what to build, not how fast to build it.

The summary adds a cost that follows release: it is tempting to prompt an for every user complaint or competitor feature, but a product with many more features tends to get worse, and every shipped feature must be supported for as long as it stays. This is a builder's argument for deliberate feature selection, presented in a host summary rather than a transcript, and not a measured estimate of how much AI changes team productivity.

Key takeaways · AI-distilled

Agents mute the guilt that used to force cleanup. Writing the same hack a third time by hand felt bad enough to trigger a refactor; when the agent writes it, nobody feels anything and the debt just accrues.
The flip side: cross-codebase refactors are now cheap — tell an agent to apply a new pattern everywhere — so teams should be paying down far more debt than they currently do.
Domain-driven design and verbose patterns fell out of fashion mostly because they were tedious to type. Agents removed the tedium and need the , so the old enterprise patterns are worth reviving.
Dax's own thinking-to-doing ratio barely moved: 95/5 before AI, 96/4 after. What got automated was never the expensive part, which is why the job still feels just as hard.
OpenCode shipped a mediocre for its first five months and only went back to make it good after winning share. Owning the category was the scarce thing; harness quality was catch-up work.

Terms in this piece · Glossary

AI agent — An AI system that doesn't just answer once but works toward a goal in a loop — taking actions, reading the results, and deciding what to do next.
guardrails — The checks around a model that block bad inputs and outputs — filters, validators, and permission rules the model itself can't override.
agent harness — The scaffolding around a model that turns it into a working agent — the loop, the tools it can call, and the rules for when to stop.

Key quotes

“Once we won enough market share, we went back and tried to make our harness good and smart.”
Dax Raad

Read the source newsletter.pragmaticengineer.com