Building OpenCode with Dax Raad

The Pragmatic Engineer 1h21 8 min #88
Building OpenCode with Dax Raad
Watch on YouTube

Summary

  • Dax Raad is co-founder of OpenCode, the most popular open-source AI coding harness, which grew from 650,000 to nearly 8 million monthly active users in under a year. Despite building one of the fastest-growing AI dev tools, Dax is notably skeptical of the hype around AI-driven productivity gains. He argues that AI tools make individual tasks easier but haven’t fundamentally accelerated the pace of building good software — the hard part is still thinking clearly about what to build, not typing code faster.

Dax’s path into tech and dev tools

  • Grew up programming as a kid, influenced by his father who was a software engineer.
  • Got his start in the Minecraft modding community, where he learned from senior programmers who were talented but not career-driven — they funneled their skills into open-source hobby projects.
  • Founded early startups, including a transportation/healthcare company that grew to ~20 people but ended in disaster. He reflects that running a startup in your early 20s is risky because “your brain isn’t fully developed” — insecurity and immaturity magnify conflict in intimate, high-pressure startup environments.
  • Worked at a Series B startup as his first director-level management role, which gave him time to explore open-source projects on the side.
  • Got involved with SST (a full-stack serverless toolkit created by Frank and Jay from YC), invested in their round, then joined the team — a move he jokes was a “bad use of money” since he had to pay taxes on the returned investment.
  • Built OpenNext to fill a gap in deploying Next.js on AWS, which annoyed Vercell but rallied other providers (Cloudflare, Netlify, Microsoft, Google) to collaborate. The project is slowly becoming unnecessary as Next.js builds official adapter support.

How OpenCode was born

  • In early 2025, SST reached profitability, giving the team space to think about what to build next.
  • They recognized AI was the defining technology of the decade, especially for dev tools, but had taken several failed swings at AI ideas before finding product-market-fit.
  • The team started using Claude Code, which was the first AI coding tool that genuinely solved their workflow annoyances. Dax asked: “Why weren’t we the ones who built this?”
  • They identified a positioning gap: no coding agent had claimed the open-source territory. In dev tools, the open-source option eventually becomes the default (databases, compilers, etc.).
  • They also saw that billions in investment meant no single model provider would dominate — so a neutral, open-source harness that works with all models would be strategically valuable.
  • Launched in June 2025 with just 3 co-founders, growing to 4, then adding a designer in the fall. The team is now ~20 people.

The Anthropic ban and strategic positioning

  • In January 2026, Anthropic silently blocked Claude Code subscriptions from being used in OpenCode (as they had with other third parties, but OpenCode was uniquely targeted).
  • Dax anticipated this would happen. In the weeks prior, he had already been securing deals with other providers to officially support their subscriptions in OpenCode.
  • When the ban hit, Dax immediately contacted OpenAI, framing it as a PR opportunity: “Everyone’s going to wake up angry at Anthropic — you can score a win by taking the opposite stance.” OpenAI agreed within hours.
  • By the end of the same day, OpenCode announced official OpenAI support, turning a crisis into a massive growth moment.
  • Dax describes this as a repeatable strategy: “Pick one temporary bad guy, galvanize all their competitors, and push something forward.” This is the same playbook they used with OpenNext against Vercell.
  • The growth spike was enormous: from 650,000 monthly actives in December to 2.5 million in January.

Why AI tools haven’t accelerated software development

  • Dax’s core thesis: AI makes tasks easier but doesn’t reduce the cognitive load of figuring out what to build.
    • Pre-AI: 95% thinking, 5% doing. Now: 96% thinking, 4% doing. The ratio barely changed.
    • The bottleneck was never typing code — it was making good decisions about direction, priorities, and tradeoffs.
  • At companies that have achieved product-market fit (like OpenCode), the problem is having too many directions to pursue. AI makes it easy to one-one every competitor feature and user request, resulting in a Frankenstein product.
  • The “muted prickle” problem: When engineers write hacks, they feel a prickle of guilt that serves as a feedback loop. With AI agents writing the hacks, that feeling is suppressed. The landmines are still there, but the engineer doesn’t feel them being placed.
  • Dax sent a memo to his team identifying three AI-turbocharged problems:
    1. Shipping features that shouldn’t be shipped (responding to every prompt without restraint)
    2. Absorbing hacks instead of redesigning systems (the agent will always take the shortcut)
    3. Not spending enough time cleaning up (tech debt accumulates faster when you don’t feel the pain)
  • The worst part: “I don’t think we’re trading this off to move faster. I think we’re moving at a normal pace.” The feeling of speed is an illusion.

AI productivity hype vs. reality

  • Most software engineers work in environments that aren’t highly motivated or exciting. Give them a button to do work faster, and they’ll do the same amount of work and cash in the extra time — which is rational.
  • The people who were irrationally motivated (who cared about quality and pushed teams harder) are now drowning in AI-generated PRs and burning out.
  • Companies are bragging about spending $10,000/month per engineer on AI tools, but Dax expects this to be unsustainable. CFOs are already questioning the spend.
  • There’s a real risk that the net result of AI coding tools is “the same amount of work gets done, but engineers are happier because their job is easier” — which isn’t enough ROI for many companies.
  • There’s also a retention pressure: even if a company thinks AI tools aren’t worth the cost, they can’t pull them away without losing their best engineers.

OpenCode’s business model

  • OpenCode Zen: An inference service that aggregates models (both frontier and open-source) with proper rate limits. Originally built to smooth onboarding, it hit $50M run rate within 5-6 months. Margins are strong because open-source models can be hosted at good margins, and inference pricing has crept up while hosting costs haven’t changed.
  • Enterprise control plane: Companies with thousands of engineers need SSO, permissions, budget controls, and rate limiting. This is open-source, but most companies pay for the hosted version. Dax may eventually stop charging for the control plane and just monetize inference.
  • Why inference is hugely profitable: The floor on cost is electricity. Even renting GPUs through middlemen (not at the floor), OpenCode sees ~80% margins on some models. Anthropic and OpenAI, with their massive GPU deals, likely see 90%+ margins. This is similar to how AWS hid how profitable cloud was for years.
  • GPU bottleneck: Even a company OpenCode’s size is bottlenecked by GPU supply. Demand for inference is growing exponentially while GPU production grows linearly. Big tech companies (Amazon, Meta, Google) are vacuuming up all the capacity, making it hard for smaller companies to get deals.

Building OpenCode: product philosophy and quality

  • Inverted strategy: Everyone else focused on building the smartest harness first. OpenCode launched with a “mid-level” harness but invested heavily in the terminal experience — building a ground-up terminal rendering framework so the product felt different and competent from the first moment. Once they won market share, they went back and improved the harness.
  • Bottom-up adoption: Dev tools that become standards are always bottom-up — individual developers start using them, then they creep into companies. This requires thinking like a consumer company, which most programmers are bad at.
  • Quality as a differentiator: Dax believes quality is one of the few things smaller companies can still compete on. Products are rotting faster than ever because of AI-accelerated feature shipping. OpenCode’s initial differentiator against Claude Code was that their terminal experience didn’t flicker or feel janky — an irrational investment that paid off.
  • Taste and craft: Dax is skeptical of people who say taste matters but don’t actually believe it. “Do you actually believe your product has to be good? There’s so much out there now where nothing has to be good.” He holds himself to a high bar and feels he’s still far from it.
  • Heroes: Mitchell Hashimoto (HashiCorp, Ghostty) is Dax’s model — someone who builds open-source products that become defaults, with quality showing up at every level from architecture to business model.

Engineering culture and how the team works

  • The team builds in public (all code is open-source) and focuses on getting features through the “painful phase” (zero to demo-able) as fast as possible. Once users can see what a feature is, they provide precise feedback on what’s missing or broken.
  • Engineers own the full cycle: they receive GitHub issues, Twitter replies, and figure out the roadmap themselves. No one insulates them from feedback.
  • The founders provide context about the market, competitors, and positioning, then let team members grab problems they’re excited about. Sometimes they’ve been right when Dax disagreed.
  • Feedback loops are everything: Dax regularly spins up a fresh Docker container to experience OpenCode as a new user would, catching onboarding friction. He believes organizations lose these feedback loops as they grow, and that’s where quality dies.
  • Domain-driven design is back: Patterns that were previously rejected for being too verbose (because humans had to type them) are now valuable because agents don’t mind verbosity. These patterns produce modular, reliable code that agents can work with safely. “You have a bunch of idiots on your team now — the coding agents — so you need way more guardrails.”

The role of engineers and engineering managers

  • The novel framing — “if engineers aren’t writing code, their job is to set up guardrails for safe AI-assisted shipping” — is actually the old problem of making junior engineers effective, just applied more broadly.
  • Old patterns (testing, conventions, modular design) are becoming more important, not less, because agents need clear structure to produce good output.
  • Dax’s advice for experienced engineers: combine software engineering skill with deep industry expertise. Software engineers have a unique advantage — they can learn any industry. Spend a year deeply learning an industry (farming, medicine, logistics) and you become one of the top people in the world at that combination. And unlike other professions, you can switch industries when you get bored.

Dax’s skepticism of predictions

  • He’s tired of the constant stream of AI predictions on social media, which he sees as people asserting futures where they’re winners — a defense mechanism driven by anxiety about rapid change.
  • The viral tweet claiming “24-29 year olds will be the most valuable asset because they have pre-AI principles and post-AI speed” is a classic example: “Person like me has all the advantages. Person not like me has all the disadvantages.”
  • Dax focuses on what can be done today and tomorrow. He didn’t know he’d be working on OpenCode a year ago and doesn’t claim to know what he’ll be doing a year from now.
  • Every major technological shift ends up being counterintuitive in hindsight. The obvious predictions never come true.

Personal work setup

  • Uses a Framework laptop running Arch Linux with a tiling window manager (i3), connected to a remote beefier machine for actual work.
  • Workflow: Neovim on the left, OpenCode on the right, switching between the two. Uses an SM7B microphone and iPhone as camera for recordings.

Book recommendations

  • Dax doesn’t read books himself (his wife reads and summarizes for him), but he’s heavily influenced by Nassim Nicholas Taleb — particularly Skin in the Game and The Black Swan.
  • Core idea that shaped his thinking: emergent properties. Almost everything great in the world comes from bottom-up interactions of smaller entities, not top-down design. This applies to software architecture, cities, neighborhoods, and biological systems.
Back to The Pragmatic Engineer