Dax Raad on Building OpenCode: Fast Growth, Slow Thinking, and Why AI Hasn't Made the Hard Parts Easier
The Pragmatic Engineer
Dax Raad is a co-founder of OpenCode, an open source AI coding harness that, by the numbers given in this conversation, grew from about 650,000 monthly active users in December to somewhere near 8 million within a few months. In this episode of The Pragmatic Engineer, Raad also argues that the tool he builds, and AI coding tools in general, have not made building good software meaningfully easier. The conversation covers that tension, along with how OpenCode was positioned, how the company turned Anthropic's block of Claude subscriptions into a growth moment, where its revenue comes from, why Raad thinks inference is highly profitable, and why they are tired of confident predictions about the future of engineering.
"Objectively, stuff has become easier, but then why am I thinking as hard as I ever have?"
The host starts with the apparent contradiction. Raad builds one of the most widely used AI coding tools, yet says it is not enough on its own to produce better software. Raad's answer starts with dogfooding. OpenCode's team built the product for themselves, uses it heavily every day, and treats it as a critical part of their workflow. Still, "all the old problems" are there. Raad says they are working and struggling as hard as ever, even though much of the job has objectively become easier, and describes holding both of those facts at once as a strange feeling.
Raad separates companies by stage. Before product-market fit, AI helps little, in their view, because the main task is figuring out what to build. It might help a team "swing a lot," but Raad has always preferred thinking a lot to swinging a lot. Many ideas can be eliminated by thinking and talking with the team, and AI does not speed that up.
OpenCode is at the next stage: it has product-market fit and now has to live up to its potential. The problem is that there are a million possible directions: obvious improvements, things users ask for, things competitors ship. It is easy to respond to each one directly. A problem comes in, you prompt the agent. A competitor ships a feature, you prompt the agent. Raad says a thousand features added this way do not sum to a good product. They sum to "a horrible product" in which nothing is cohesive. Every shipped feature has to be supported indefinitely, and every future feature will interact with it, so the ability to ship ten times more does not mean a team has ten times as many good ideas.
As a result, Raad says a lot of their job now is figuring out how to slow everyone down. Over the past six months the team operated very differently than it ever had, "a lot of stuff went wrong," and they are now pulling back to work out what from the old way of working still makes sense. Raad also notes that no competitor is crushing OpenCode either. In a market where every competitor is deeply invested in AI, you might expect a large gap between those who use it well and those who don't. Raad says that gap doesn't exist.
From Minecraft mods to startups
Raad grew up programming. Their father was a software engineer, which Raad says made it easier to get started. They began working straight out of high school, founded a company they now say they didn't really understand how to run, and were eventually acqui-hired into what they call the "real tech industry." After that came consulting, several more startups, and about six years of full-time open source work.
One formative experience was the Minecraft modding scene. Raad worked on a modding framework and built mods with it. What interested them was less playing the game than building sandboxes: they ran a server with about 100 players and used mods to set up situations for observing how people behaved. The community lived on IRC and included very senior programmers who, as Raad describes them, weren't career-driven. They seemed comfortable, perhaps working a couple of hours a day, and put their talent into Minecraft instead. Raad says they learned a lot from those people in just a few months.
Later, Raad was head of engineering at Ride Health, a transportation and healthcare startup that grew to about 20 people. It went further than their previous attempts but "ended up in a disaster." Raad also met their wife there; she was head of product, which Raad jokes was better than a startup exit. Their main takeaway was skepticism about the "team of very young founders" stereotype. Everyone at Ride Health was in their twenties, and Raad says people's insecurities showed up as politics and drama. Startups are intense and personal, so anything unresolved in a person shows up at work. Raad feels their own brain didn't finish developing until around 26 and says that if they ever invest, they wouldn't back companies made up entirely of very young people. They describe the young-team success story as the exception.
Asked whether they considered big tech back then, Raad says the mid-2010s pressure was real: joining a big tech company or a hot unicorn seemed like the only path to success. But they couldn't bring themselves to do the structured interview preparation that path required. Raad considered themselves a good programmer and did well in some interviews, but didn't think they could compete with people who studied specifically for them. They were drawn to building practical things.
Into open source: SST and OpenNext
After Ride Health, Raad joined a Series B startup, the largest company they had worked at, and became a director with no programming duties. With three or four hours of manager meetings a day, they explored open source on the side and found SST, which Frank and Jay had launched only a couple of months earlier. Raad started contributing, invested in the round the founders were raising after Y Combinator, and joined the team a month later. The founders then returned the investment as salary, which Raad had to pay taxes on. Their joking advice: don't invest in a company you might join.
OpenNext is the project Raad says first made the team well known, and it was something they didn't want to build. SST served AWS users, and for about a year people kept asking for help deploying Next.js on AWS. Nobody on the team used Next.js, and recreating the right infrastructure meant digging into JavaScript bundling and Next.js internals, which Raad calls tedious. Frank ended up doing most of it.
From the start, Raad says, the goal was for OpenNext to eventually become unnecessary. They saw it as filling a gap left because the Next.js team's attention naturally went to Vercel, which Raad says wasn't malicious. The project annoyed Vercel, but it helped people deploying elsewhere. Other providers with similar problems joined in: Cloudflare, Netlify, and later Microsoft and Google built OpenNext adapters. Eventually the Next.js team created an official adapters API, and Raad says that over the past year or two things have become more collaborative and the need for OpenNext is fading. This pattern of rallying several companies against a shared gap comes up again later in the OpenCode story.
Why OpenCode: claiming the open source position
In February of the previous year, the company was pushing toward profitability. For three or four months it had been running low on money while revenue climbed, and in February it had about one month of runway left but also broke even. Raad says the team was oddly calm, feeling that something would work out. Breaking even gave them room to step back and decide what they wanted to work on.
Raad describes their general view of hype cycles. Anything with real potential attracts a lot of investment, and most of that investment doesn't make sense, so it's easy to dismiss the whole area. But usually a few things in it make a lot of sense, and sitting out means missing them. The team tried several AI ideas, many of which they dropped before launch after realizing they didn't make sense.
The turning point was using Claude Code as a team. It was the first AI coding tool that stuck for them because it directly solved annoyances in their workflow. Raad asked why they hadn't built it themselves and whether their open source experience gave them an opening. Their reasoning was about positioning. There were many coding agents, but none had claimed to be "the open source option," and Raad argues that in every category of dev tool, whether databases or compilers, the open source option eventually becomes the default. They also expected model competition to stay fierce: with billions invested, OpenAI and the open source world weren't going to let Anthropic win uncontested. A neutral, open source agent that worked with all models seemed valuable in that environment, so the initial push was to ignore everything else and secure that spot.
Growth: from 650,000 to nearly 8 million
OpenCode launched in June 2025 with three people, the co-founders. A friend joined to help build the first version, and a designer the team had long wanted to work with joined in the fall after launch. Growth was immediately better than anything they had done before. By December, OpenCode had 650,000 monthly active users. In the fall the team had said publicly that they aimed for 1 million by early the next year, and people thought that was unrealistic.
In January they reached 2.5 million monthly actives. Raad reports 6.5 million the previous month and, halfway through the current month, perhaps close to 8 million. The next milestone is 10 million.
Raad offers two explanations for the December-to-January jump. From their dev tools experience, usage usually dips over the holidays and spikes in the first week of January as people return with new things they've learned. This time, OpenCode grew through the holidays, which Raad says they had never seen with any product. Then in January, Anthropic blocked the use of Claude subscriptions in OpenCode.
Anthropic's block and the OpenAI partnership
Raad believes Anthropic is relatively new to working with developers. They say it's fine for a company to do what it needs to stay sustainable, but dropping a block suddenly around 9 p.m. sets you up for developer anger. A phased, communicated rollout over a month would still have upset people, Raad says, but wouldn't have created a single concentrated moment of outrage. Raad also says the backlash accidentally put OpenCode and Anthropic in the same sentence, which Raad says OpenCode didn't deserve given how much larger Anthropic is. That week's attention sent OpenCode's numbers up sharply.
Asked whether this was a case of AI making it too easy to act quickly, Raad attributes it instead to fast growth in general: a small action suddenly affects millions of people. They give an example from OpenCode itself. The team recently shipped a bug that opened OpenCode in light mode when almost everyone uses a dark terminal. In the past that might have affected 100 people; this time it "flashbanged" roughly a million.
The team had expected the block for a while, and Raad says they felt excited when it happened. Two things made them confident. First, they knew the "everyone has a $200 Claude Max subscription" view was a Twitter bubble; there was no way most of their 650,000 users paid $200 a month for anything. Second, they had already been negotiating official subscription support with other companies. Microsoft had agreed to officially support GitHub Copilot in OpenCode, and other deals were in progress but unannounced. They hadn't yet approached OpenAI.
The night of the block, Raad got around a hundred tags on X, decided "it's go time," and messaged OpenAI: when everyone woke up angry at Anthropic, OpenAI could win good press by taking the opposite position and officially supporting OpenCode. OpenAI agreed the next morning. While people online were saying OpenCode was finished, the team built the integration and announced official OpenAI support by the end of the day.
Raad ties this to the same pattern as OpenNext: "pick one temporary bad guy and then galvanize all their competitors to push something forward against them." Everyone competing with Anthropic had a reason to support access to their models in OpenCode. The host compares this to Linux, where the open core is advanced by competing commercial vendors. Raad agrees, saying good positioning keeps producing wins you didn't predict: if a neutral party exists, well-funded companies will use it to advance their own interests. Raad acknowledges OpenAI might one day become the "bad guy" if it dominates, and that is part of how competition works. They've heard criticism that OpenCode is too hard on Anthropic, but Raad argues that a small company only has influence over billion-dollar companies by applying pressure in the right places. Even someone who plans to use Claude Code forever, they say, should want other people to be able to use the tools they prefer.
Treating a dev tool as a consumer product
Asked why the gap existed, Raad says programmers building dev tools are bad at consumer products and don't realize that widely adopted dev tools are consumer products. Top-down enterprise sales can work, but the tools that become standards spread bottom-up: individual developers adopt them, and they spread into companies. To succeed that way you have to think like a consumer company, even as if you were launching Instagram.
For OpenCode, that meant the first launch had to feel different and better. The team built its own terminal rendering framework from scratch instead of using Ink like other terminal agents. Some users might find the interface overwhelming, Raad says, but they still leave thinking the builders are competent. The second priority was getting people prompting with as little friction as possible, including cases like a locked-down enterprise laptop.
Raad says OpenCode's harness, its core agent logic, was not very good for about the first five months. It was "good enough" that most people couldn't tell. Competitors assumed the smartest harness would win. OpenCode did the reverse: it won usage share first with a mid-level harness, then went back to improve it. Raad says it is now improving toward having the best harness while already being the most used.
Desktop app mistakes and declining a growth hack
The host asks about Tauri. Raad says it was used for the desktop app and calls it mostly a mistake. Raad does all their own work in the terminal but doesn't think 8 million people should be, and believes many OpenCode users would be better served by a GUI. The team saw early on that things would move toward web and desktop apps and was right, but didn't take the project seriously enough or think hard enough about technical choices. They are now moving back to Electron.
The host also mentions that Claude Code and GitHub Copilot tag commits and PRs with the name of the tool that produced them, which works as free marketing. OpenCode originally did this too because, Raad says, it was essentially a Claude Code clone at first. When users asked for a way to turn it off, Raad decided the feature felt "lame," like a casino using every trick to keep people in. It was too obvious a growth hack, so instead of making it optional, they turned it off by default.
Business model: OpenCode Zen and the enterprise control plane
OpenCode has two lines of business. The first came from reducing onboarding friction. Early users had to connect an Anthropic or OpenAI account, and new Anthropic accounts didn't initially get enough rate limit to use OpenCode. The team built an inference service, OpenCode Zen, so users could sign up and get access to all models with enough capacity. It started as an onboarding aid and grew quickly. As open source models became popular, the team found that hosting them properly is difficult, so Zen became a place for good inference on the best open source models alongside frontier models. Raad says Zen reached a $50 million run rate within about five or six months, and that margins can be good because open source models can be hosted profitably.
The second line is what Raad calls "extremely boring": a control plane for companies. A company with a thousand engineers can't just tell everyone to download OpenCode and add an API key. It needs central management for providers, permissions, budgets, and rate limits. That product is open source and has been deployed for enterprises; most customers pay for the hosted version, and Raad says it will be made publicly available soon.
Raad sees the timing as good. Companies are starting to look at their LLM spending and ask whether they're getting results. Open source models are now competitive and about ten times cheaper, according to Raad, so the enterprises OpenCode serves naturally start using inference for them. If that becomes the main business, OpenCode may stop charging for the control plane and charge only for inference.
Why Raad believes inference is profitable
Raad's case that inference is very profitable starts with cost structure. Once hardware is paid for, the lower limit on the cost of producing a token is the electricity to run it, plus operations and staff. OpenCode rents GPUs at scale, still through intermediaries, and Raad says that for some models, the difference between list price and OpenCode's cost is about 80% margin.
Raad also argues prices have effectively risen. People used to default to Sonnet because Opus was too expensive; Opus then got cheaper and became the default, but it still costs much more than Sonnet did, while hosting costs haven't changed. Raad speculates that with the largest GPU deals, Anthropic and OpenAI might see margins around 90% at current prices, though they don't think that's sustainable long term. Raad acknowledges that training and R&D costs are enormous, but says inference as a business makes sense and will continue to.
The host connects this to Bryan Cantrill's earlier appearance on the podcast: Cantrill said AWS hid its financials while cloud computing was widely seen as a poor business, and running a cloud turned out to be very profitable. Raad adds that any hyped business attracts negative sentiment, and companies have no reason to correct it.
GPU shortages
Raad has posted that there are not enough GPUs, and that even a company OpenCode's size is constrained by this. They describe the whole supply chain, from chip production to supporting hardware to labor, as tight. Raad thinks demand for inference may be growing exponentially while GPU production grows more linearly, and where those curves meet, supply tightens. OpenCode has to reserve GPUs and pay a lot upfront, and everyone is hoarding because they expect the shortage to continue.
Raad also points to scale: startups raising a couple of billion dollars seem huge, but Amazon, Meta, and others spend tens of billions a year, and suppliers are too busy with them to talk to smaller buyers. Based on their career so far, Raad expects shortages to end in oversupply, though they note it might be different this time.
Motivation: where productivity gains actually go
The host brings up a widely quoted post in which Raad argued that people talk about their teams as if they were already at peak efficiency and limited only by how fast they could produce code. Raad expands on it. Software engineers work at nearly every company in the world, and most of those workplaces aren't especially motivating. Most people want to do their job and go home to their families. Give them a button that makes work faster, and the rational thing is to do the same amount of work and keep the extra time. Raad says leaders should be realistic about where their employees will take those gains.
There's a second-order effect. In such organizations there are often a few people who are, in Raad's words, "irrationally motivated" because they love the work and push for quality. Those people are now overwhelmed by "slop PRs." Raad says OpenCode has hired people who were in exactly that role at previous companies and were burning out and leaving. Motivation, people, and emotions still matter a great deal.
Asked how companies should rethink motivation and pay, Raad says startups have it easier. OpenCode is in an exciting market, its hires are competitive and want to win, and everyone has equity that could be meaningful. Even before AI, Raad questioned why startups advertised two engineering roles at modest salaries instead of combining them into one salary that attracts someone who can change the company's direction. OpenCode needs about 20 good people, not a thousand. For large organizations, Raad says they have no good answer: at a certain size, there's no strong reason for anyone to do more than their job requires.
Raad sums up the startup situation with a joke. Before AI, they spent 95% of their energy deciding what to do and 5% doing it. Now it's 96% and 4%. That's a 20% improvement, but day to day it feels just as hard.
Costs, and whether the spending will last
On CFOs asking why each engineer now costs an extra $2,000 a month, Raad describes a "flexing" phase that comes with every new technology: companies want to look future-facing and brag about spending, say, $10,000 per engineer per month. Raad considers that narrative fake and expects it to fade. The real issue is that for a company with thousands of engineers, an extra $1,000 per engineer per month can break the budget, especially without clear results to show. Raad frames this as a temporary experimental period and doubts it will last in its current form.
Raad then describes a possibility, explicitly not a claim about what is happening: the net result of AI coding tools might be the same amount of work with happier engineers because their jobs are easier. For many companies that won't be enough, and they'll tell people to go back to typing code.
The host raises a counterpoint: some CTOs say they can't restrict tools because their best engineers would leave. Raad agrees this happens, comparing it to strong engineers leaving because they hate using Jira every day. But Raad sees that as the top of the market. At most companies, the policy is simply to use Copilot, possibly plugged into OpenCode, within set limits. Raad doesn't find the story that such companies will die from falling behind convincing.
The memo: too many features, too many hacks, not enough cleanup
The host quotes a memo Raad sent to the OpenCode team listing three challenges that Raad called old problems "turbocharged by LLMs": shipping features that weren't worth shipping; accepting hacks when a feature doesn't fit the original design, because the LLM can work around the hack; and not spending enough time cleaning up.
On the first, the team is trying to be more restrained and to define more clearly what they will ship now and what should wait until things are clearer.
Raad considers the second the biggest challenge. When a system doesn't support a new feature, you either rethink the system from first principles or accept a temporary hack, and that choice depends on how bad the hack is and how valuable the feature is. Raad says that judgment is now "so distorted" because the agent will write the hack and deal with its downstream problems, making "it's a temporary fix" too easy to accept. The team has shipped hacks in places where it should have redesigned or refactored.
The host describes the uncomfortable feeling of writing a hack by hand, the "prickle" that gets worse with each new hack and that comes from having been burned before. Raad agrees: that feeling is now muted because someone else is dealing with the problem. The landmines are still there and will still go off, but without that discomfort, judgment gets worse. Raad says all of life is about keeping the right feedback loops, and they disappear easily. The host compares it to a CEO who delegates everything and loses touch with how bad conditions are, and mentions that Stripe's CTO periodically spends a week coding in the company's environment. Raad agrees that you need to feel what users feel, including in your own codebase.
On cleanup, Raad admits it's hard to justify when a thousand people are demanding features every day, a thousand more say you're doing everything wrong, and new competitors appear constantly. Letting those pressures steer won't lead anywhere good, Raad says. The upside is that cleanup has never been easier: where a new pattern once only applied to new code, an agent can now apply it across the whole codebase and remove old patterns. Raad concedes there's no direct payoff and that companies can succeed without doing this. Their reason is that there are many ways to succeed and most successful companies are places you wouldn't want to work. Raad wants OpenCode to be a place people still enjoy in five years, not one where good people won't join because the work is mostly wading through legacy code.
The memo's most striking line, which the host quotes, is that the team wasn't trading these compromises for speed: "I think we're moving at a normal pace." Raad explains that it feels fast, but looking back they aren't sure it was, and they don't see OpenCode moving faster or slower than competitors. It's easy to fool yourself about productivity. Raad believes in laying groundwork first so that when you do sprint, you do it with much more force.
Tired of predictions
The host reads a viral post claiming that engineers aged 24 to 29 will become the most valuable people in tech because they have "pre-AI principles and post-AI speed." Raad pushed back on it publicly. Raad says they're tired of waking up to endless predictions and that this one follows a familiar pattern: people like me have every advantage, and people unlike me have every disadvantage. Raad reads this as a defense mechanism. Everyone is anxious about their place in a period of big change, so they confidently describe a future where they win. Traced back, most predictions reduce to "my company will succeed and others will fail" or "my job won't be replaced by AI, but everyone else's will."
Raad says young people have always had the advantage of energy and the disadvantage of less experience, and that the specific age range just happened to include the author. Instead of predicting, Raad focuses on what makes sense today and tomorrow. They didn't know a year earlier that they'd be working on this and don't know what they'll be working on a year from now. The host mentions that veterans like Kent Beck, Martin Fowler, and Grady Booch say they've seen shifts like this before, such as mainframes to microprocessors, but over a decade instead of a couple of years. Raad adds that what actually happens is almost always counterintuitive, the obvious predictions rarely come true, and the outcome will look strange now but obvious in hindsight.
Product principles that haven't changed
Raad describes OpenCode's product principle simply: a product probably has only one good idea, so get the user to experience it as quickly as possible. It's hard because accidental steps keep creeping in. Every two weeks or so, Raad runs a command that starts a fresh Docker container with OpenCode to go through the first-run experience, and they always find something the team has broken without noticing.
Raad argues that product work isn't about shipping a direct fix for each problem. It's about taking in many problems and finding one solution that addresses fifty of them. That takes experience, thought, conversations with users and the team, and understanding the codebase. Raad says they used to be terrible at it, are "okay" now, and expect to keep improving for decades, and that AI hasn't helped with this at all.
What has helped, Raad says, is years of good feedback loops: users yelling when Raad gets something wrong, and slogging through the codebase when a poor design makes a simple change hard. OpenCode tries to make sure nobody on the team is shielded from that. Raad thinks this becomes nearly impossible to maintain as companies grow, and gives an example from a past job: a product team cut corners to ship sooner, the support team absorbed the angry customers and manual fixes, and the product and engineering teams celebrated shipping without seeing the cost. Raad also values trying to build for the whole market. So many environments and constraints must be handled that outsiders often think you're focusing on the wrong things, but it changes how you think.
How the OpenCode team works
OpenCode now has more than 20 people, most of whom joined in the last three months or so. Raad says they're in the uncomfortable phase of having more people than ever while moving slower than ever as everyone gets up to speed.
As an open source company with public code, OpenCode builds in public as much as possible. Raad describes two phases for a project. First comes pushing it up the hill, the painful stretch from nothing to something that exists. Then comes filling in details once the main questions are settled. The team tries to get through the first phase quickly, aiming for a demo they want to show people. After that, vocal users provide direction: what's missing, where else it needs to work, what's bad. The engineer who built a feature handles the full cycle, reading GitHub issues and replies on Twitter and deciding the roadmap. Nobody summarizes feedback for them.
The founders try to give everyone context about the market, competitors, and OpenCode's position, expecting that people with that context will choose good priorities themselves. Raad treats motivation as central because this is a long game, and the way to stay in it is to work on things that excite you. So people pick what they think is the biggest problem. Raad says some team members have insisted on projects Raad argued against, and a few weeks later Raad realized they had been right.
Taste, quality, and doing irrational things
Raad thinks the idea of "taste" is fundamentally right, and that like most good ideas it is simple to say and hard to live by. Taste can be learned, but it takes a lifetime. The real question, Raad says, is whether people actually believe their product has to be good. There's a common view that code and product quality don't matter because companies with poor products and poor engineering still make money. Once that idea takes hold, Raad believes, you won't ship good products. Many great products could be 50% worse without an obvious effect, but quality shows up in ways that are hard to trace, and laziness in one place spreads everywhere, "like an infection." Raad says they're far from meeting their own standard and still find other products inspiring.
Raad names Mitchell Hashimoto as a hero: all his products were open source and widely adopted, Terraform became a default, the business model was well executed, and Ghostty's architecture reflects care for every detail. Raad points to a clip in which Hashimoto says a feature's value lies in how it interacts with every existing feature, and calls him one of the best at combining product thinking with programming.
Asked whether quality is one of the last advantages a small company has against giants, Raad agrees, adding that it's now easier than ever to let a product decay. Raad says big companies' products are decaying faster than ever and that even a year-old startup product is probably already degrading, which they attribute to agent-driven workflows. Quality comes from doing irrational things, about half of which you didn't strictly need to do, and few people are willing to work that way given the prevailing "cold logic" that equates good business with doing only hyper-rational things. OpenCode's own terminal framework is Raad's example. Building your own framework is what engineering teams are told never to do. But the team, as users of tools like Neovim and aware of what Hashimoto had shown terminals could do, couldn't get the experience they wanted otherwise. Raad says much of OpenCode's early appeal next to Claude Code came from Claude Code's jankiness and flickering, which didn't stop it from being very successful, but OpenCode's "irrational" focus on quality helped it compete with a much bigger, better-funded company.
Raad's setup
Raad uses a Framework Desktop running Arch Linux, a single 5K display, and a tiling window manager they've used for ten years, plus an SM7B microphone and an iPhone as a camera. Actual work happens over SSH on a more powerful remote machine, with one tmux session per project, usually split with Neovim on the left and OpenCode on the right.
Engineering leadership: old patterns return
Raad describes an idea they've heard from other leaders and are partly skeptical of. If engineers aren't writing code, their job becomes making it safe for anyone to ship with an agent, whether another engineer or the marketing team editing the website. That means guardrails, strong testing, and clear conventions agents can follow. Raad's objection is that this isn't new. It's what teams have always tried to do to help junior engineers ship safely and make less experienced people punch above their weight. Some companies managed it and some didn't.
OpenCode has long used domain-driven design lightly and now uses it much more heavily. Raad says these "boring enterprisey" patterns have become useful because "you have a bunch of idiots on your team now": coding agents that work 24/7 and ship a lot. You need more guardrails than before, and the old downside, the verbosity of typing it all out, mostly disappears when you no longer type the code. The host wonders whether 2000s-era design patterns will return. Raad says good programmers never needed those training wheels, but agents do.
Advice for engineers and a reading recommendation
Raad hesitates to give general advice because a startup doing open source is an unusual place to work. Their longstanding belief, which predates AI, is that software engineering is a skill applied to an industry, and that combining it with deep expertise in one industry is very powerful. A decent engineer who understands farming well might be among the ten most sought-after people in that niche. Engineers also don't have to commit to one field: you can spend ten years in medical software, decide you don't like it, and move to something else. Raad thinks a year in almost any industry puts you ahead of most people there, but warns that it's easy to ignore the domain and just finish UI tickets. Being able to learn any industry from the inside, they say, is both one of the fun parts of the job and a sound career strategy.
Raad says they barely read books. Their wife is an avid reader and passes along the best ideas, which Raad admits to repeating as their own. From an earlier reading phase, Raad recommends Nassim Taleb's work, including Skin in the Game and The Black Swan. Raad thinks a book is often "one good idea inflated into a book," but says Taleb's ideas describe basic truths you see everywhere. The idea that influenced Raad most is emergence: much of what's great in the world comes from many small entities interacting rather than from top-down design, whether in robust software, walkable neighborhoods, great cities, or organisms that resist disease. Raad says that once you understand the contrast between bottom-up and top-down system design, you see it everywhere, which fits how Raad talked about OpenCode's growth throughout the conversation: good positioning and the right feedback loops, rather than a detailed plan or a confident prediction.
Objectively, stuff has become easier, but then why am I thinking as hard as I ever have? None of our competitors are crushing us either. And we're in the coding agent space. All our competitors are super into AI. So, you would think in our space there would be a huge gap, but there just isn't. The 24 to 29-year-old engineer will soon become the most valuable asset in technology because they have pre-AI principles and post-AI speed.
Person like me has all the advantages. Person not like me has all the disadvantages. Everyone is just saying mantras to themselves. A defense mechanism is to confidently assert a future in which you're a winner. And that's almost what every single prediction that you see is happening.
That past 10ish years of building dev tools and understanding dynamics is really helping. The strategy that we know how to play really well is to pick one temporary bad guy and then galvanize all their competitors, push something forward against them. There is a world where the net result of all these AI coding tools is the same amount of work gets done, but all the engineers are happier cuz their job is easier. That's not good enough for a lot of companies. So they're just going to say
Dax Raad is a co-founder of OpenCode, the most popular open source coding harness. He's also a very downsource when it comes to AI, which can be a bit surprising when you consider that he built such a widely used AI tool. Today we talk about the rapid growth of OpenCode to closer to 10 million active users in less than a year. The memo Dax sent to his team admitting they were shipping too many features, taking on too many hacks, and AI usage not helping them move faster. Why inference is one of the most profitable businesses in tech right now and why even OpenCode is bottlenecked by GPU supply and many more. If you'd like to ignore the hype on social media around AI and instead talk about where it helps or hinders productive engineering teams, this episode is for you.
This episode is presented by Antithesis. Verify your system's correctness without human review or traditional integration tests and avoid bugs or outages.
I'd also like to mention our season sponsor, turbopuffer. You probably heard someone say RAG is dead these days, but it's not. It just doesn't mean what it meant in 2023. Back then, retrieval was pretty straightforward. The human asks a question, your code embeds it, you hit a vector database, top K results come back, those get stuffed into context, and the LLM answers.
Now, look at what's actually happening inside something like OpenCode or any serious agent product. In 2026, a human sends one prompt to an orchestrator agent. That agent fans out to sub agents. Each sub agent is hitting separate systems. A vector index, a full text index, grabbing the file system, running CLI commands and SQL against OLTP and OLAP stores, reading and writing a memory system, reranking results, looping, and calling more tools. One human prompt turns into dozens or even hundreds of searches across totally different shapes of data.
In practice, this means a lot more complexity, a lot more cost, and a lot more potential performance issues, especially when you need to scale up the system. This is exactly what turbopuffer is built for. It's a ridiculously scalable, fast, and cheap search engine. It's built on top of object storage for reliability and scale with smart caching on NVMe SSDs, so it's very fast. It's priced so you can let agents loose with proper in 2026 without seeing your bill explode. Check it out at turbopuffer.com/pragmatic.
Dax, welcome to the podcast.
Yeah, thanks for having me and thanks for coming all the way to Miami.
I wanted to jump in something really interesting about you. You're building one of the most popular AI engineering harnesses, OpenCode, which is speeding up how people write code and just like turn out software. And yet you're claiming that this itself is not enough. Like this itself will not get us to better software.
I've always said the easiest products to build are ones that you can use yourself. And obviously we built OpenCode so that our team can use it and it's like we are the customers of the product. So we use it aggressively as much as anyone else can. And of course it is like we build it so we think it's useful and we use it every day and it's a critical part of our workflows, but all the old problems that I've always struggled with are still there. I'm working as hard as I ever have. I'm struggling as much as I ever have. So a lot of the job has become easier. But yeah, it's a weird feeling because objectively stuff has become easier. But then why am I like thinking as hard as I ever have? You know, it's a weird feeling to have both those things be true.
And it's interesting because a lot of the people who are decision makers, CEOs, often hands-on people like hands-on CEOs, CTOs, founders at companies, they kind of think, oh, look, we've got these tools. Coding used to be the hard part, right? Like objectively, it took us so much time. It still takes, you know, to get into the zone if you're going back to coding by hand. So if that's faster, cuz that's where we used to spend most of our time, it should be faster. Like everything should be faster. But why do you think this is not the case? Or like what is getting in the way of just shipping high quality software faster, better, right?
Yeah. I mean, there's different life cycles, different companies. There's like pre-product market fit, there's achieved product market fit, which is kind of where we are. And there's companies that have had product market fit for like a decade. And I imagine that things look very different across these three. For us, pre-product market fit, to me it doesn't really help that much cuz you're trying to figure out what you should be doing. And yeah, like maybe it helps you swing a lot. But I've always thought it's better to think a lot instead of swinging a lot. I think you can eliminate a lot of ideas or directions just by, you know, spending a lot of time in your head and with your team talking. Obviously AI doesn't speed that part up.
We're at the phase where we've achieved product market fit. Now our task is to kind of hit the potential that we have. And the issue for us is there's a million different directions we can go in. There's all the obvious stuff we can do. There's all the stuff that our users are telling us that we have to do. There's stuff that our competitors are doing. And it's very easy to just one to one do each one of those things because we have a problem, prompt the agent. Competitor has a feature, prompt the agent. User has a problem, prompt the agent. If you add that up, you think, "Oh, we shipped a thousand features. Now that adds up to a good product." It actually adds up to a horrible product.
Like a Frankenstein.
Yeah. Nothing's cohesive. You look in there, you're like, "We shouldn't have shipped this." The moment you ship something, you're stuck supporting it forever. And by supporting, it means any future feature you build is going to like interact with it. So you still have to be very conservative with what you put out there. It's hard to undo anything. Just cuz we can ship 10 times more doesn't mean we have 10 times as many good ideas to ship out there. So, in a lot of ways, my struggle has now been how do I like slow everyone down? And like understanding that yes, our process can look very different, but should it look very different?
Like we, you know, in the past 6 months, we've kind of operated very differently than we ever have. A lot of stuff went wrong because of that. So now we're pulling back and figuring out, okay, what from the old world still makes sense. So yeah, we're like figuring out what we should be doing. And I definitely don't feel like, oh yeah, we're like killing all our competitors, we're using AI so much better than everyone else. And by the way, none of our competitors are crushing us either. Like no one out there is using AI so well that we just can't even compete, right? And we're in the coding agent space. All our competitors are super into AI. So you would think in our space there would be like a huge gap, but there just isn't.
Yeah. So I want to rewind back to the very beginning of how, you know, before AI, before a lot of these things. How did you get into tech and software engineering?
Yeah. So I grew up, kind of cliche story, I grew up programming as a kid. My dad was a software engineer, so a little bit easier for me to get into than for other people. Then just started working out of high school. Founded a company. Thought it was cool. Thought I knew what I was doing. Looking back in hindsight, like wow, I didn't know what I was doing at all. That eventually got acqui-hired as a small acqui-hire. And I ended up in like the real tech industry. Bounced around as a consultant, founded a few companies, and then ended up doing open source pretty much the past six years full-time.
But going back to the very beginning, I found or saw some references to you working on Minecraft, Minecraft servers.
Yeah. Yeah.
Back in the beginning, can you take us back a little bit?
Yeah. So, Minecraft, obviously everyone knows what Minecraft is. And again, this is another cliche story. You talk to a bunch of people in tech, they have a similar backstory. There was a modding framework for Minecraft that came out. I ended up working on the framework itself. I ended up making a bunch of mods with it. I found that I liked creating like interesting sandboxes. I played the game a little bit, but I didn't play the game that much. I like had a server that like a 100 people would play on and I would just use these mods to create like interesting situations to try to understand how people would behave under certain scenarios. And I found that fascinating. But yeah, that required a lot of programming Java stuff.
What's interesting is that community, obviously I was very new to programming. It was all done over IRC, or the community existed on IRC, but there were some very senior, very good programmers in there. The people there I felt like were people that weren't particularly career motivated. They were probably in a comfortable enough situation where they worked like two hours a day. And they were talented but they just didn't have any desire to career chase at all. So they funneled it into the Minecraft stuff and I got to talk to them and learn from them. So I feel like in the couple months I was doing that I learned a lot.
And then you went to the startups, you founded a startup, and then after being the founder at Iron Bay, I saw looking back your history, you became a head of engineering at Ride Health.
Yeah.
Can you tell me a little bit about what was that like? That was in 2017 or so, like pre-COVID.
Yeah. Yeah. So that was a company in the transportation and healthcare space. It was just me and the co-founder originally. And that company grew to like 20 people or so. That was my second swing at doing a startup, I would say. And it got further than my previous attempts. But it kind of ended up in a disaster. I did end up meeting my wife there. She was head of product. I was head of engineering. We got together after a year. So, better than a startup exit, I would say. Definitely learned a lot.
But, yeah, it was one of the situations where everyone was super young in their 20s. And I think there's this stereotype of startups that oh yeah, it's a bunch of super young people, you know, building stuff. After that experience, if I ever end up investing in companies, I'm not going to invest in companies with a bunch of young people cuz we were all just like, our brains weren't fully developed. We're all insecure about various things still and that played out with like company politics and dramatics and stuff. So, yeah, that cliche of like, oh yeah, just a bunch of young people, I think that's like the exception, I would say, looking back.
So like a bunch of young people succeeding is probably the exception.
Yeah. Yeah. And of course we have famous stories of that. But you know, on average, for me I felt like my brain didn't finish developing until I was like 26, I think. So prior to that, you know, I don't know if I really should have been running a startup.
And when you say like stop developing, is it just kind of like getting enough experience to understand how a business actually works, or like professional relationships? In what sense?
Yeah, I think for me it's like startups are so intimate because it's just you and a few people and it's very intense. Like this is the thing you're doing, this is your hobby, it's your job, it's kind of everything. If you're not like fully developed as a person, if you're just trying to prove something to the world, if you're still insecure about certain things, all of that shows up at work. Especially in such an intimate situation like that. So fighting, conflict, all that stuff. The way I perceived the situation, even my own understanding of what was going on, just basic like how to be a person and live in the world. I think for guys it takes a while for their brain to fully settle, and when it did it felt like day and night, like I was a different person. But it definitely took a bit.
And now you can look back at that time and just kind of be like, oh gosh, what was I doing? What was I thinking?
Yeah. Everything was just so magnified and way more intense and way more emotional than it needed to be, I think.
Okay. So the people who knew the Dax back then might be a little bit surprised.
Yeah. Yeah. I think so. But again, that's when my wife met me. So something was right there.
In your first few years, so you founded a startup, then you kept going at very early stage startups either as a founder or an early founding engineer or so. Did you ever consider larger companies at that time?
Yeah, I think that was always there because, you know, for me this era was like the early 2010s or mid-2010s. The big tech companies were very prestigious at that point. Like everyone you met was trying to get a job at either one of the big top tech companies or one of the hot unicorn startups at the time. That was like the thing to try to do. If you weren't doing that, you basically were going to fail in tech. So I felt some kind of pull from that point of view. But I also just couldn't get my together to do that. Like I knew what it takes. There's a set of things you have to do to kind of be successful there. I just couldn't even do that. So, yeah, I could say like, oh yeah, I chose not to do it, but really I just don't think I was
What do you think the things were back then?
I mean, you know, there was a very structured interview process for these things. You know, you have to do certain programming problems, whatever. And I think I was a good programmer. And I think I'd done some interviews that were like that. And some of them I even did well in. But the level of competition, and like people study for it, people focus on it, just randomly swinging at it, I don't think I would have landed anything. So yeah, I was into building stuff. I was into more practical things. And I just struggled to do anything outside of that.
And then how did you transition into open source? Well, Serverless Stack was a big project of yours. It was a toolkit for building full stack applications, I think.
Yeah, that was kind of where our initial focus was. And how we got into open source. So after Ride Health kind of ended up in disaster,
I took a job at a Series B stage startup, which at that time for me was the biggest company I'd ever worked at. And I eventually got put in a director role. First time being a full-time manager with no active programming tasks. And I still wanted to program a lot. So I ended up exploring a bunch of open source things at the time. You know, I had three or four hours of manager meetings every day, but outside of that, you know, I had time to explore open source things like that. And I started to build my own kind of crappy stuff, and I came across SST, which had just launched. It was maybe a couple months old. That was Frank and Jay. They both had created this thing originally. I started contributing to it. They were raising a round when they were kind of getting out of YC. I invested in that round, and then a month later I ended up joining the team, and they gave me the money back as salary, but now I had to pay taxes on it. So if you're going to invest in a company, make sure you're not going to join them. It's a bad use of money.
And then you did SST and then you did some other stuff as well on the side, right? OpenNext.
So OpenNext I think was probably the thing that blew us up initially. This wasn't even a thing that we wanted to build. We were serving people in the AWS space. Every single day someone would come to us and be like, we like what you guys are doing, but we really need help deploying Next.js on AWS. And over and over, for a year, people were just nagging us about this, and we didn't want to do it cuz we weren't Next.js users. Very tedious. It actually is a very complex framework; trying to recreate the right infrastructure for all that in AWS is a lot of work. Digging into JavaScript bundling, Next.js internals, not very fun, not very exciting work. So we made Frank do all of it. He basically slogged through that and figured out how to get it all working on AWS. Our goal from the beginning was that this project shouldn't exist. It's just a weird gap because the Next.js team is focused more on Vercel, and it wasn't a malicious thing or anything. It's just where the attention would naturally go. So we're like, let's fill this gap. The end ideal state should be that, you know, Vercel eventually just manages all this and there's no need for this. So we built that. It annoyed Vercel a bunch. But yeah, it was very useful for the people that, you know, were trying to deploy in other places. Eventually we kind of rallied some other providers that had problems with Next.js as well: Cloudflare, Netlify, I think Microsoft got in there eventually too, Google got in there eventually, and they kind of built adapters for OpenNext. And eventually the Next.js team had time to be like, okay, let's make an official adapters API. And in the past year or two it became a much more collaborative thing, and I think the need for OpenNext is slowly going away.
And then how did OpenCode come about? Because that's a pretty recent story. It started sometime in summer of last year, summer 2025.
In less than a year, yeah. Back in February, our company, we were basically doing a push to hit profitability. So with SST we had a monetization path for that. Basically for 3 or 4 months we were running out of money, but then our revenue was going up, and then in February we had one month of money left, but we also broke even at the same time. Weirdly though, we were all really calm about it. It just felt like something would work out, and it did. So that gave us time to kind of take a step back and think about, okay, we can technically do whatever we want now, what do we want to be doing? And for a while we're like, obviously AI is the thing to work on this decade, especially if you're working in dev tools. We've been through waves before where there's just a thing that happens, and whenever a thing is happening it seems like it's not making a lot of sense, because whenever something has a lot of potential, it attracts a lot of investment. By its innate nature, most of that investment doesn't make sense. So it's very easy to look at anything exciting that's happening and think none of that makes sense, I'm not going to participate in it. But usually what happens is a few things in there make a lot of sense, and if you just completely sit out, you just miss out on that. I think we've been through a few waves of kind of doing that, where we saw the AI thing and we're like, okay, a lot of this stuff is stupid, but there's definitely real value here. We need to be doing something in it. And we took a few swings at a few ideas, and a lot of them we didn't even fully launch, cuz we just discovered they didn't make sense while we were working on them.
And then eventually we started to use Claude Code as a team. It was the first AI coding tool that stuck for us. It directly solved some of the workflow annoyances that we had. This is great, obviously this should exist. At some point I asked, why weren't we the ones that built this? We should feel bad about that. And then we realized, okay, maybe there is still an opportunity to do something given our experience in open source. As we were saying earlier, you don't have to just ship a million products to figure out something that works. If you sit and think, you can figure something out. And we kind of looked at it from a positioning point of view: there's a market, there's a bunch of coding agents out there. For some reason no one has grabbed the open source territory. There was no coding agent that was like, we are the open source option, and that obviously is a super valuable territory. Every single dev tool we use, whether it's databases, compilers, whatever, eventually the open source option becomes the default option, right? That, combined with the fact that there's heavy, heavy competition for models. Sure, Claude was popular, but there's billions and billions and billions of dollars invested. They're not just going to let Anthropic win. There's going to be push from OpenAI, there's going to be push from the open source side. So given that, we saw that chaos, we saw that it's really valuable to have the open source positioning that tries to work with all the models. So the initial push for us was to kind of ignore whatever was going on in the market and just make sure that we claimed that open source spot, which we were able to do. And then yeah, our numbers have been pretty crazy since then.
Can you tell me about the growth? You launched in June 2025. How was the growth, both for usage but also for the team? When you started, how big was the team even? Was it most of the existing smelly labs working on this, or just a small...
Yeah. No, so we were just three people at the time. So it was just the co-founders. And then we hired one of my friends who was also interested in working with us, and he helped us build the initial thing. So he joined, so that was four, and then we convinced a really good designer that we had always wanted to work with to join us as well. But that was after we launched, so that was more in the fall. But yeah, we launched and the growth was really good immediately. It was better than anything that we'd ever done. By December we hit 650,000 monthly actives. And at that point we're like, wow, this is great. Back in the fall we were kind of telling people our goal was to hit 1 million by early next year. Everyone thought we were crazy. Like, oh, okay, sure. Then in January we did 2.5 million monthly actives. So we went from 650 to 2.5. Last month we were at 6.5. This month, we're still halfway into the month so I'm not sure, maybe close to eight. Our next goal milestone was 10.
There was a massive jump. So you went from 650 in December to 2.5 in January. What was that jump? Is that the winter break jump, where everyone started to realize that these models are really great?
Yeah. So, having been in DevTools for a while, we knew that in January there's always a bump, cuz I think people take time to learn new things in December with the time off, and they have time to try new stuff. So what we typically see is a dip into the holidays and a giant spike in the first week back. For this, we saw growth into the holidays, which we've never seen with any other product before. So despite the fact that people were off, it was higher usage than ever. And then January came around, and Anthropic helped us a lot by, you know, they wanted to ban Anthropic subscriptions in OpenCode. That blew up into a huge thing. We barely even commented on that, but the user base was just so upset. Anthropic accidentally put us and them in the same sentence, which we don't deserve, cuz they're a much bigger, more successful company. But that week that kind of happened by accident, and that spiked our numbers like crazy.
So I guess in hindsight, because what happened is Anthropic silently banned being able to use Claude Code subscriptions inside of OpenCode, which every tool including OpenCode did, cuz there were a bunch of other third parties, but they didn't allow OpenCode to do this, and then this led to this outrage.
The thing with them is I think that they're kind of new to working with developers. It's okay to do things like... of course you need to do what you need to do to make your business sustainable. It's totally fine. But randomly dropping a block at 9:00 p.m. at night, that just sets you up for people to hate you. Doing a phased, communicated rollout over a month, I think they would have...
Giving a heads up.
Yeah. I think people would have been upset. Of course, everyone's going to be upset no matter what, but it wouldn't have been this concentrated moment of everyone being really annoyed.
This reminds me of what we were talking about, how AI allows you to do things really quickly and fast. Do you think in this case Anthropic might be, you know, stepping into this trap of: they can do things really fast and they do things really fast, but for example in this case they can just implement a block like this. The PR probably took, what, a few seconds or a few minutes. Whoever did that might have not thought through the implications.
I think it's just a consequence of any kind of fast-growing company. You forget the amount of leverage you now suddenly have. You do one small action and it ripples through millions of people. We're dealing with this ourselves. We've never worked at this scale before. We put out a bug the other day where, almost everyone has a terminal in dark mode, and OpenCode opened up in light mode. So we flashbanged a bunch of people, and I'm like, in the past that would have been like 100 people we hit, but I did this to like a million people this week. So...
Yeah, but with this block, obviously we know it worked out well in hindsight, but when it happened, at the time Opus 4.5 or 4.6 was the most powerful model out there, best for coding, and you saw that Anthropic just blocked, you know, Claude. Before you knew that this press would happen, what was the team's reaction? Was it just stay calm, keep going?
Yeah, what's weird is we knew this day would happen at some point, and for some reason when it happened we all just felt excited, because I think we had been thinking about this for a while and we knew this would happen. We also knew that we live in this crazy bubble, especially on Twitter, where everyone has a $200 Claude Max subscription. At that point, we were at 650,000 monthly actives. There's no way 650,000 of them have Claude Max subscriptions. It's crazy for the average person to spend $200 a month on anything. So we knew it was a smaller subset.
And also at the time, we had been working on deals with pretty much every other company to officially support their subscription in OpenCode. So in the weeks leading up to that, we got Microsoft to agree for GitHub Copilot to be officially blessed by OpenCode. We had a bunch of different companies in the works. We hadn't announced any of them yet. And the big one we hadn't gotten, or hadn't even approached, was OpenAI. So when this happened that night, I forget if it was Thursday night, I don't remember exactly when, I got like a hundred tags on X being like, "Oh, they banned it. They banned it." And I was like, "All right, it's go time." So I messaged OpenAI being like, "Hey, tomorrow everyone's going to wake up. Everyone's going to be really angry at Anthropic. You guys have a chance to score a PR win by taking the opposite stance and officially supporting OpenCode." The next morning, they confirmed, like, "Yeah, let's do it." So in the morning, everybody was like, "Oh, Anthropic blocked OpenCode. They're screwed." I saw a bunch of people being like, "They're worth nothing now. They're going to go to zero," whatever. I was laughing to myself. I'm like, "Okay, just wait till the end of the day." And then we figured out the integration, we implemented it, and at the end of the day we announced OpenAI is officially supported in OpenCode.
We knew what was going to happen, and going all the way back to the OpenNext thing, right? The strategy that we know how to play really well is to pick one temporary bad guy and then galvanize all their competitors to push something forward against them. So Anthropic was unfortunately in that position. So we kind of got the rest of the industry to, you know, support OpenCode, support access to these models in different places, because they were all competing with Anthropic. So these are nice strategies that you can run in these situations even as a small company.
I'm starting to get a sense that the past 10-ish years of building dev tools, or at least five of open source, and understanding the dynamics is really helping you. Because even when you told me about how you were thinking of OpenCode, you were talking about strategy, about how there was this gap, and there's all these competing model providers, and with an open alternative, over time, in a lot of ecosystems, the open one wins and the vendors compete. For example with Linux, you know, Linux is open source, but the distributions are for-profit companies: Red Hat, Ubuntu or Canonical, and so on, and they all compete and they make it better. So even in this case, it sounds like it all goes back to you actually having a strategy where you expected that if the vendors play as they play, it will make sense.
Yeah, exactly. If you get your positioning right, the world just keeps handing you wins that you didn't even expect. So we never predicted this exact scenario, but our fundamental understanding of the position was right. If there is a neutral party, all these companies with billions of dollars will kind of use a neutral party to advance their own company's interests. So it's beneficial to be that thing in the middle.
Yeah. And then right now, Codex came forward. They saw it as a way to increase brand awareness, usage, et cetera, how much it's growing. And I'm sure logically at some point they might turn around. Let's say they win the market or they become market leaders, they might do the same, saying, "Okay, we no longer want to support this thing." But at that point there might be other players, as long as there are multiple interested parties.
Yeah, exactly. So at some point maybe OpenAI becomes a bad guy that we have to kind of galvanize everyone around. I mean, it's why competition is good. This is kind of exactly how competition plays out.
Think the thing that people maybe underestimate is we're a small company. We're not a huge company at all. If you apply pressure in the right places, you can actually make things happen. We get a lot of criticism and anger from people being like, "Oh, you guys are being so mean to Anthropic." They criticize the way we approach things, but these are billion-dollar, huge companies. Us being able to apply any amount of pressure to get something to happen is very difficult, and this is what it looks like. People might think that they're above it or whatever, but having more access to these things, having more people be able to use the tools they want, is a good thing. You can love Claude Code and be like, I'm never switching off Claude Code. That's great. You should probably still be into the fact that people can use other tools that they like, right?
And going back to why OpenCode is so successful and that there was a gap: using what you've learned about dev tools in general, why was there a gap? What do you think was a difference that you did, outside of just writing the tool to start with?
The biggest advantage in DevTools is the fact that everyone working at DevTools is a programmer, and programmers are horrible at B2C products. They don't realize DevTools are B2C products. You basically treat
B2C as in business to consumer.
Yeah, exactly. So the most extreme mindset to have is you treat them as though you're launching Instagram or a social media app, something like that. You can do a top-down process, and there's plenty of companies that do an intense top-down enterprise process, and that works and that's great. But the dev tool products that are massively adopted, to the point where they're basically a standard, they're all bottom-up. Individual developers start to use them, start to like them, and they kind of creep into companies and they grow in that direction. And to do bottom-up, you have to basically think like a consumer company, and programmers generally are very, very bad at thinking this way.
So we very much focused on: the moment you open OpenCode, it should feel very different and better than some of the other options. And to do that, we had to build a ground-up terminal rendering framework. That's not what Claude Code did. That's not what any of these other terminal coding agents did. They just used Ink or whatever and they made it work for what they need. But we invested in it upfront because from the moment you use it, it feels like something different. It might not be for you. Maybe you don't like the overwhelming experience, maybe it feels like too much, but you still walk away thinking the people that did this are probably competent. So immediately getting people a good feeling, and then immediately getting them prompting without any layers of friction. We focused on just reducing that friction as much as possible, and focusing on things like: I'm on a locked-down enterprise laptop, can I use OpenCode? Optimizing for all of those things.
And our harness wasn't very good for the first five months of OpenCode. But it was good enough. It was good enough that most people couldn't really tell a difference. And once we won enough share, then we went back and tried to make our harness good and smart and optimized and all those things. But it was inverted from what everybody else was doing. Everybody else was like, you have to build the smartest harness and that's how you win. We had a mid-level harness, but we are the most used. And now we're able to creep up and actually have the best harness and also be the most used. So I think it was an inverted strategy that we did that other people didn't fully understand.
And to get into the inverse strategies at the technical level, you launched with a framework called Tauri, right?
Oh, that was for a desktop app. I would say that was mostly a mistake on our part. I love terminal stuff. I do all my work in the terminal. Our numbers say we're going to hit 8 million monthly active users. I don't think 8 million people should be using the terminal. I think we have too many users for what the product is. I think a lot of them would probably have a better experience on a GUI, and we understood that very early, so we were experimenting with a web app, with a desktop app, and we were like, this is probably going to be the direction things go. Unfortunately, we were right, that is where things are going, but we should have treated that project a lot more seriously and tried to get it out there way faster and thought a little bit harder on the technical stuff. We just kind of picked stuff and didn't think too hard about it, and it ultimately was a mistake, and we're moving back to Electron now.
But OpenCode is growing amazingly fast. Interestingly enough, there's this growth hack that some harnesses are doing, I would say a growth hack, where in the PR on GitHub, they actually put which harness did it. Claude Code is doing it. GitHub Copilot is doing it. Some others are not doing it. And in OpenCode, you are not doing it, even though this could be almost like free marketing.
Yeah. So initially we had that, because initially we were effectively a Claude Code clone. If Claude Code did it, we did it. So we had that with the commit, it would say committed with OpenCode or whatever in GitHub, and then we got a bunch of people being like, hey, can I have an option to disable this? And I thought about it, and it just felt lame to me. You can be like a casino, right? A casino just tries to trap you in there with every little trick to get you to stay. That's the extreme of doing a consumer product. I felt like we didn't have to go to that extreme. It felt a little bit lame, it's too obvious of a growth hack, right? Everyone sees it, everyone knows why that's there. So I just wasn't a big fan, and instead of having the option, we just turned it off by default.
You're still running a company that is a for-profit company in the end, or you need to make bankroll. What is the business model behind OpenCode?
So we have two lines of business, basically. Initially, when we first launched OpenCode, a big problem that we had, again thinking about reducing friction, was people had to connect something. They had to connect their Anthropic account, they had to connect their OpenAI account. At that time, when you signed up for Anthropic, you couldn't even get enough rate limits to use something like OpenCode. So a lot of our users couldn't even use it. So we were like, okay, we have to at least build some kind of inference service that you can sign up for and get access to all the models with the rate limits you need. So we built that and we called it OpenCode Zen. We initially just built it as an onboarding thing to smooth out onboarding, but that grew a ton. And with the amount of open source models that are becoming popular, we also found there's a ton of difficulty in hosting open source models correctly. So Zen has become a place to aggregate the best models. Of course frontier models are easy, but then the best inference for all the open source models. All that became really popular. That business is growing a ton. I think a couple months ago we announced that it hit a 50 million run rate within five or six months.
Wow.
And the margins there can be pretty good, because open source models you can host at a decent margin. That is growing like crazy. We didn't really expect that, but that's a big part of it. The other side of it is extremely boring. If you are a company that's using OpenCode and you have a thousand engineers, you can't just tell them all to go download OpenCode and add an OpenAI API key. You need some kind of control plane to set up all the providers, permissions, budget controls, rate limits. So we have a product there. We're going to make that publicly available soon, but right now it's just been enterprise deployed. If you're a company that's using OpenCode at scale, you need some administrative software to run it. You can't practically use OpenCode at scale without something like that. That's also open source, but most people just pay for our hosted version.
The other thing is, I think the time has finally come where people are looking at how much they're spending on LLMs and they're like, what are we doing? Are we actually getting anything more done? So companies are now looking at their cost and trying to figure out how to optimize it a little bit. It's great timing, because open source models are now very competitive. They are 10x cheaper. Blending that in and having good inference for open source models is becoming a part of our business as well. So these big companies need the control plane, but then we kind of just give them inference access as well to these other models, and they end up just naturally starting to use it. If that ends up being a main part of our business, we might stop charging for the control plane itself and just charge for the inference.
Dax was just talking about the boring but essential work to get enterprises onboarded: SSO, permissions, control planes, all the stuff every serious company eventually needs, which is where I need to mention our season sponsor, WorkOS. Sooner rather than later, you'll need to get around to building these enterprise features. Not just control planes, but things like auth for apps and agents. WorkOS handles it: SSO, SCIM, fine-grained authorization built for how agents actually operate. The fastest growing AI companies, Anthropic, OpenAI, Cursor, Perplexity, already trust WorkOS to solve these problems. Check it out at workos.com.
I'd also like to talk about our presenting sponsor. We just talked about slowing down to speed up, thinking hard about what to build so you're not sprinting to the wrong destination. But quality is part of the destination, too. You don't want your product to flashbang a million people like the team at OpenCode did that one time. Antithesis is a property-based testing platform that enables you to express the properties your system should have, then verify that those properties will hold in the chaos of production. With Antithesis, specification and thorough verification becomes a seamless workflow, giving you clarity so you can deliver quality. Check out antithesis.com/pragmatic to learn more. And with this, let's get back to Dax and OpenCode.
We had a recent tweet about how inference is actually really, really profitable. You were quoting someone who was saying these AI model providers might be having financial difficulties. Can you explain to those of us software engineers who don't do inference, we use these models and we just assume that this must be their business, how can it be profitable? Why is it profitable? What are you seeing?
Yeah. So there are different parts of a business. If you look at the pure inference part of a business, if you think about what's the floor on the cost, the floor is the cost of electricity. There's a capital cost to acquire the hardware. Once you have it, to deliver a token, the cheapest it can get is the electricity to power it. And obviously there's other infrastructure, there's operations staff, there's stuff like that. But we have seen models where we look at the sticker price, because we rent GPUs at scale to run the models, and we still use middlemen, by the way, so we're not going all the way down to the floor. Even for us, there are some models where between the sticker price and the cost to us, there's an 80% margin in there.
And I think the other thing that people don't notice is prices have gone up. It's confusing because it seems like they haven't. But they've gone up from the point of view that we used to all use Sonnet as our default because Opus was too expensive. Then they made Opus cheaper so that we started to use Opus as our default, but it was still way more expensive than Sonnet. So the prices have gone up, and the cost to host these models hasn't changed. So that's one aspect of it being really profitable. And Anthropic and OpenAI, of course, have crazy scale. They have the biggest GPU deals. So I wouldn't be surprised if they're looking at like 90% margin at current prices. I don't think that's a defensible margin long term. It's crazy to be able to make that much with this amount of money going through as well.
It's interesting, because when Bryan Cantrill was on the podcast, he used to work at building a cloud service that would compete with AWS, and he said that back then it was the same thing. AWS back then hid their financials, and they told everyone that cloud is a terrible business and it's red blood everywhere. And then he started to do it and he said, actually, it's a really freaking profitable business to run a cloud, but it's kind of a well-kept secret, because why would Amazon or any other provider advertise that the business is printing money?
There's always negative sentiment that exists for any business that's getting hyped. They have no incentive to correct it. Again, it's complicated, because I know the training costs are a big part of it. The R&D department is hugely expensive, but long-term, inference makes sense as a business, and I think it always will. Yeah.
This being said, you also said something in public about GPUs. I'm quoting you: "There just aren't enough GPUs. It's crazy that even a company our size is being bottlenecked by this." What does that mean?
Yeah. So across the whole stack of GPUs, everything from producing the GPU to supporting hardware to labor, everything is super tight right now. The demand for inference is growing. I don't think it's linearly growing, I think it might even be exponentially growing. But we haven't made our production of GPUs grow exponentially. That's kind of a linear process. So as those lines intersect, there's going to be tightening. For us, we have GPUs that we need to reserve. We have to pay a lot up front. Everyone is now hoarding because everyone's expecting this crunch to continue. It's very hard to get capacity for inference.
And the other thing that's crazy, I think I posted about this: we see things like, oh, a company has raised $2 billion or whatever to do something in AI, and that feels like a crazy amount, like wow, that's huge, you have to be a crazy startup to do that. The big tech companies are spending tens of billions in a year, like Amazon, Meta, whatever. They dwarf anything that's happening in the startup space, so they are just vacuuming up all the demand. Any company that is in the supply chain doesn't want to talk to you, because they're busy trying to get something with Amazon or Microsoft or Google. So yeah, it's very tight times. I think it'll get resolved. My whole career, anytime I've seen any kind of shortage, there was a tense period and it was met with crazy oversupply. It might be different this time, but generally that's how I see things go. But right now, it's tight.
I want to talk about the hype of what productivity gains these AI tools, specifically AI agents, are giving to engineering teams, and the reality. And you wrote a
now very heavily quoted tweet which I'll quote just some parts of it: "Everyone's talking about their teams like they were at peak of efficiency and bottlenecked by the ability to produce code, but the way things actually look like is," and you listed a few things like, "your org has good ideas. People are now using AI to be 10x more productive. They're using it to churn out their tasks with less energy to spend," and so on. So this was a few months ago, I think two or three months ago, when you wrote it.
Yeah. I think there's so many dimensions to this. So the thing I was talking about in that post is the majority, again, we forget how big the software engineering industry is. Every company in the world employs software engineers to some degree, right? The majority of these environments aren't like the most motivating, exciting environments. Most people there are trying to do their job, go home to their kids, have a reasonable life.
You give them a button that lets them do their work faster. The natural place for them to go is hit that button as much as possible, do the same amount of work, and just cash in that extra time, right? Which makes total sense. If you have no reason to be above and beyond motivated, you're not going to really use that to, you know, push your organization harder. Yeah, these tools maybe make you more productive, but be really realistic about your employees. Where are they going to cash in those gains?
Obviously, some companies are not like that. The employees are motivated. They have good reason to be. They're compensated in a way that makes sense. But most places aren't like that. And the problem with that is usually in those environments, there will be a couple people that are irrationally motivated because, you know, they love the work they do, etc. Even though the rest of the company isn't as motivated, they're usually the ones that are trying to make sure everything is good quality, kind of push everyone to try harder. They're all now overwhelmed by slop PRs. And we've had a few people on our team that have joined and their previous company was like this. They were the person that still cared, the rest of the organization just hits the button and gets their task done, and they're drowning in just garbage and they're getting burnt out and they're leaving. So motivation and team and people and humans and emotions, all that stuff is still a big factor in all this.
How do you think companies, let's say a midsize company or even a small company, might have to rethink motivation, compensation, thinking about work now that, you know, I was talking with Steve Yegge about this, on how an engineer, if they're super motivated and they put in the task and energy, they can produce a lot more output, and if it's well directed that could be better business results, but it does come at a huge cost in energy. And again, if you're just being paid the same paycheck, it doesn't necessarily make as much sense to do so. So I'm wondering what kind of early thoughts you have so far. And of course, for you guys in a startup, I guess it might be a bit easier.
I mean, obviously for us, you're right, it's easier for us. We are in a very exciting space. The people that join our company are very competitive. They want to get in there and they want to win. So that's a big driver. Everyone has equity that, if we do our jobs right, it'll be pretty meaningful for them at some point.
Even pre-AI, I feel like, again, I can only speak for startups as that's where my experience is, I'd always see startups post jobs where they're like, "We're hiring two engineers," and they post two salaries, and these are okay salaries. I always thought, why not just hire one person and combine the salary? You'll get someone that'll meaningfully change the direction of your whole life. People will start showing up at that level. So we've always been willing to pay quite a lot. We don't need to hire a thousand people. We need to hire like 20 good people. So generally I think good salaries still go a long way. But yeah, at bigger scales I think it's just hard. When your company hits a certain size, there is just no good reason for someone to do much more than what their job strictly asks them for. So I don't have any good ideas here.
And I wonder if it's a thing where it is hard to retrofit this technology and the way of working to existing structures. And I guess the question goes back to how much will the AI-native startups like yours, or ones that are starting today, change? How will their workflows change, the type of work, even the roles, right? What does a software engineer even do? Okay, of course they prompt AI to write code, but what about product, what about all these other things?
Yeah. I mean, yeah, I think the bottlenecks are still there. You're still figuring out what you should be doing. You can spend a year just figuring out the right thing to do. And then once you figure it out, maybe it's fast to actually build it. But yeah, I think the joke I made was pre-AI, I would spend 95% of my energy thinking about what to do and 5% of my energy doing it. Now I spend 96% of my time thinking about what to do and 4% of my time actually doing it. So yeah, it's like a 20% improvement, but day-to-day it feels as hard as ever.
Another observation you made is at a lot of companies, and I guess you will see this secondhand from OpenCode being used at companies, that the CFO is now going, "What do you mean each engineer costs an extra $2,000 per month?" What are things you're hearing about in that area, because this is happening.
Yeah. So I think with every technology there's a phase of flexing, where there's so many companies now that want to be seen as, "We're so future facing, our process is ahead of everyone else's, you have no chance, you're never going to catch up," and they're all bragging about how much they're spending. So right now there's a push to be like, each engineer is spending like 10,000 a month and that's so worth it, our business is so successful and so useful and so efficient that any amount of money is worth it. And there's a lot of that narrative. And that's fake, that'll go away.
Then there's a real narrative of, yeah, these companies hire thousands of engineers. If they literally cost $1,000 extra a month, that breaks your whole budget. That's not a thing you can kind of casually do. We're in a temporary period of we're experimenting to see what's possible and everyone's learning. I doubt this is going to be a sustainable thing. These companies were already pretty tight on what they could afford, especially if they can't directly point to clear results. Here's the issue, right? I'm not saying this is the case, but there is a world where the net result of all these AI coding tools is the same amount of work gets done, but all the engineers are happier because their job is easier. That's not good enough for a lot of companies. So they're just going to say, go back to typing out the code.
It's also an interesting dynamic where there's also the pressure of, well, when everyone else is doing it, even if we just stick with the happier analogy, and again, let's assume that the quality of the output overall wouldn't change, if everyone else is doing it and you're like, "Okay, well, it's not worth it, let's stop it," then your best engineers will leave. So I'm also hearing some CTOs saying, well, we're giving access to better tools because we're one of the best companies. It would look silly if we said, "Oh, you can only use, I don't know, GitHub Copilot anymore, we're not allowing you to get OpenCode or Claude Code or whatever else that is," because our best people would leave.
Yeah. No, that is a real thing. It's kind of like, I mean, again, it depends. If you have someone that's really good that has infinite opportunities, using Jira is a risk, because they're going to be like, "I hate using Jira every day," and they're going to leave. And I know people that literally have done that. So that's always a dynamic. So
But that will be at the top of the market, right?
Yeah. So again, I think at the scale we're at, we're just so exposed to how big the world truly is, and the world we typically play in is so small compared to everything else that exists. And at most of these companies it is just, use Copilot, just plug Copilot into OpenCode and that's all you get, and your limits are your limits, and that's what's there. And there's some narrative being pushed that these companies are going to die because they're going to fall behind, etc. But I don't know, I just don't think it's that straightforward.
Another longer post that I paid a lot of attention to is the one that you sent out to your team, to the OpenCode team, which was on the topic of saying, all right, we should do three changes. I'll quote you: "Basically, we have the following challenges. None of them are new, but I think they're turbocharged by LLMs. Number one is shipping features not worth shipping. Number two, when iterating on features, sometimes the original design is off and it forces you into something hacky, but the LLM cannot deal with the hacking. And number three is we need to spend more time cleaning things up." How did you get to these observations, and what's changed since, and how did the team respond?
So the first thing, right, features that we shouldn't have shipped. It's so easy just to respond to a problem by shipping a feature. So having more restraint. So we try to flesh that out a little bit more: here's the type of stuff that we want to ship, here's the type of stuff that we'll wait on until we have more clarity. There's having more restraint there.
The thing about shipping hacky stuff, that one is I think probably the biggest challenge, because forever this has been a problem where you have a system that's doing a bunch of stuff, you need to add a feature to it, and the system doesn't exactly support the feature. So your options are rethink the system from first principles, redesign it so it supports that feature, or just absorb the hack temporarily. And you can make a judgment call on which one you do, depending on how bad the hack is, depending on how valuable to the company it is to get this feature out. You make the judgment call.
That judgment, that ability to have that judgment, is so distorted right now because the agent will just do the hacky thing for you. The agent will kind of deal with the hacky problems that come down the road. And it's way easier just to be like, "Oh yeah, it's a temporary fix." So we're shipping way more hacks in places where we should have just rethought the whole system from the ground up, or redesigned it and refactored it to make it more flexible. So I think our judgment is just off.
Does this have to do with that when I, as an engineer, you know, pre-AI, I'm making a hack, I know I'm making a hack, I'm thinking about it, I feel bad about it, I feel bad.
Yeah, exactly.
But I do it anyway. But you know, I spend time thinking about it and there's kind of a little bit of prickle there. And then when I do a second hack, I remember the first one and I feel even worse about it, and I can still justify it, right? After a while, there's feelings, especially when you're someone who cares, and the reason you care is you have experience, you've been burnt. You know you're placing landmines for someone else, maybe even for yourself. And is it just that the agents, I mean, they just do it, they don't have feelings, and they also suppress the effort, suppress the thinking. They don't even tell you "I'm doing a hack." It doesn't even know it's doing a hack. It's just following whatever the training data is, which is pretty low-quality code on the internet, right?
Yeah. Exactly. I think that's exactly right. That prickle, that feeling that you get, it's muted now, because it's kind of like you've made someone else deal with the problem. The problem is still there and the landmines are still going to blow up on you eventually, but you don't feel that bad feeling as much anymore. So your judgment is skewed. You're not getting that feedback loop.
I guess it's like, you know, there's always this very relatable story of the CEO who just delegates stuff and then doesn't understand why things are terrible on the floor, and then one day goes down and gets into doing the actual work and realizes, "Oh my gosh, these conditions are terrible."
Exactly.
Versus the CEOs who were hands-on and they tried to stay in touch and do, I don't know, simple stuff, or CTOs doing coding in the environment. I think the Stripe CTO did this, like once for a week every few months, and then felt like, "Oh, this is painful, let me do that."
Yeah, exactly. I mean, just like you need to be using your own product, you need to feel the pain that the users are feeling. Same thing with your codebase, same thing everywhere. So yeah, I think all of life is about having the proper feedback loops in place, and it's very easy for those to go away.
And then the third thing that you said in this memo, related to this one, is we need to spend more time cleaning things up. How do you deal with that? And I mean, because you're also a founder, how do you justify it? Because you know there's this thing, especially when you're a startup, okay, you've just found product-market fit, but there is this pressure to move quickly, and cleaning things up will not get you more customer love or revenue or any of the stuff that you care about as a business.
Yeah, it's really hard because every single day we wake up, there are a thousand people yelling at us, telling us to do XYZ things. There's a thousand people telling us we're doing everything wrong. Every single day there is a competitive new product that shows up. Very overstimulating. If we let ourselves just get pulled by those forces, I don't think it results in anything good.
And I think what's also cool is cleaning stuff up is easier than ever. In the past, I would realize, oh, there's a new pattern that we should be using, and we would just start to use that for stuff going forward, but it was too much work to clean up all the old stuff. But now you can clean up all the old stuff. You can ask the agent to go implement the new pattern everywhere. It's very easy to clean up tech debt. It's very easy to find new patterns and implement them across a codebase. Very easy to clean up dead old patterns.
And yeah, you're right that there's no direct result of doing that. I think you can be a successful company without ever doing that. The way I think about it is there's a million ways to be a successful company. There's all these different companies that are successful out there. If you had your pick of any company you could work for, you probably wouldn't pick 99% of them. So I want to make sure we build a place that we're happy to work at 5 years from now. Our day-to-day is happy, we feel good working there every single day. It's not this thing where it becomes miserable to work there and we can't get anyone good to join us because it's mostly about slogging through legacy stuff.
And in this memo, after you listed all of these things, and you're basically saying, all right, we're shipping a bunch of stuff that we don't need, we're not cleaning it up, we're not thinking, you actually said something really interesting, and I'm quoting you again: "The worst part about all of this is I don't think we're trading this off to move faster. I think
we're moving at a normal pace.
Right. Yeah. It feels like we're going fast, but then I look back and I'm like, I don't know if we actually are going that fast. And I don't think we're going any slower than our competitors. We're certainly not going any faster than them. So if you're trying to look at productivity, it's so easy to trick yourself into thinking you're being more productive. And when you sit down and really look at it, oftentimes it's not as crazy as you expect.
I guess what you're saying is, you know, don't be complacent and accept, but just be critical and look at: is this working? Should we slow down to speed up? Should we focus on the invisible stuff? Those kind of things.
I really believe in just preparing a lot and setting the foundations, right? And then when you spring, you spring with so much more force than you would if you just forced it earlier on.
One thing I like about you is you do call out BS when it's BS, especially when it's really trending on social media. Again, you're a lot on X. This happens a lot specifically. And here's a tweet that I'll read to you that you'll remember. It went very viral. So many people, you know, VC folks, all said like, "Yeah, this is the future." And this is what it said: "The 24 to 29 year old engineer will soon become the most valuable asset in technology because they have pre-AI principles and post-AI speed, and it's an undefeated combo." And people are saying like, yeah, this is the future, like this generation who is not too old to have the old things, they will be killing it. Again, they have no preconceptions of what used to be possible. And you did call BS. Honestly, can you tell me your thinking?
Well, it's funny cuz I'm just so tired. Every single day I wake up and I open the feed and just prediction after prediction. The future's going to be like this. If you're just going to be like that, if you're just going to be that, everyone's just making stuff up, right? That one's funny because that's a very classic post where it's like person like me has all the advantages, person not like me has all the disadvantages. It's like everyone is just saying mantras to themselves, cuz the root thing that's going on here is we are experiencing a moment of great change. Everyone is very nervous about what that means for their own position in it. A defense mechanism is to confidently assert a future in which you're a winner. And that's almost what every single prediction that you see is. You almost always trace it down to: companies like mine will be successful, other companies will fail. My job won't be replaced by AI, but everyone else's job will be replaced by AI. And everyone has some rationalizations for this, but the root thing that's happening here is everyone is scared and worried and not sure about where things are going. And we are just bombarded with predictions and people protecting their own psyche.
I'm just tired of predictions. Like, yes, we're going to have a time of great change. I just focus on the next day. Like, what can we do today? What can we do tomorrow? I didn't know I was going to be working on this a year ago. I don't know what I'm going to be working on a year from now. I'm just trying to do the thing that makes sense right away.
This thing about, oh, young people have that, that's always been a thing. Young people have a lot of advantages. They have the classic disadvantage of not having a lot of experience, but having a lot of energy. I have a lot of experience, but not as much energy as a 20-year-old. So, it's just the same thing that's always been. And that one's particularly funny cuz he said 24 to 29. Why not 18 to 25? You know, it's clearly he falls in that age range, which is why he's saying that. It's just made up. And I think everyone's just nervous and worried.
I think it's good to just be honest about it because it's true. I mean, I'm nervous and worried as well just because the change is faster than before. And this is talking with the greats of the industry who have lived through it, Kent Beck, Martin Fowler, Grady Booch, and they're all saying that they have seen change like this. For example, when they went from mainframes to microprocessors, but it was throughout more like a decade, not a matter of a year or so, or maybe we're now at this point two or three years. And they're all saying the same thing, that the change is faster. But yeah, as you say, it's very easy to rewrite history and say it was always obvious, but it's just hard to tell.
No, it's not. Yeah, it's so unobvious. Everything that ends up happening is always counterintuitive. There's always people that see it correctly and line themselves up properly for it, but none of the obvious things ever happen. The end state we're going to end up at is going to be so weird from our point of view now. It's going to make total sense in hindsight. So yeah, predicting is a lot harder than people think it is.
So far with OpenCode, especially with OpenCode, you and the team have reached really good success. What are the things, when it comes to building products and your engineering principles, that have not really changed from the early days, or the ones that you've learned and you've stuck to, and it helped make OpenCode successful as well?
Yeah, I think for us on the product side, like I said, it's very simple. You probably only have one good idea in your whole product. Get the user to experience that as fast as possible. It sounds so easy, but if you go try every single product out there, you will see a million accidental steps they introduced from the user hearing about your product to seeing the value in it. Very hard to keep that minimal. Very hard to not let that creep back in. It's a constant thing. So, I do this thing where I have a command that spins up a new Docker container and runs OpenCode, which lets me experience the first-time experience. I do that once every two weeks and I'm always catching stuff that we've messed up in that process by accident.
The job of product isn't to just receive a problem and ship the immediate solution. It's to absorb all the problems and understand that there's one solution you can ship to fix 50 different problems. Right? That is hard. That is difficult. That takes experience. That takes thinking. That takes talking to users. That takes talking to your team. That takes understanding your codebase. A product is a way to abstract a solution for many different issues, right? That's always going to be hard, and that is a skill that you can infinitely get better at. I used to be horrible at it. I'm okay at it now. I probably got another few decades of getting better at it. Yeah, that's what I'm focused on, like how to build stuff that solves problems well, and AI has not helped me even a little bit.
What has helped you there? What has helped you to get this product sense better, or figuring out... cuz it sounds like we talked a lot about thinking, about reflecting, about having one elegant solution that can solve multiple seemingly unrelated problems.
I mean, it's just years of experience in situations with the right feedback loop, right? When I mess something up, I get a literal human yelling at me and saying horrible things about me. When I design something poorly, I have to slog through the codebase and do something that should have been easy that's a lot harder now. Yeah. So, for us, it's all about making sure everyone on the team has those feedback loops. No one is insulated. When you're in that type of environment, even for just a couple months, you just get so much better. And I think a lot of organizations, it's hard to keep that type of situation as your company grows. I think it's probably impossible. So if you mostly worked at larger companies, this is probably the thing that you've never fully experienced.
I've been at companies where the product team would want to ship something faster, so they'll cut stuff to get it out sooner. The pain is not felt by them. It's felt by their support team. The support team deals with the angry people, and the support team fixes things manually for them. And the engineering and product team are like, you know, hey, we did it, we shipped the feature, and they don't realize that there's a side effect that they created. So, yeah, really being in that feedback loop just makes you better.
I think caring a lot about building something for a lot of people is another thing. You don't have to try to build stuff for millions of people. I'm not saying you have to do that, but it is very interesting to have that perspective of, hey, make something that works for the whole market. It's so hard to do that. There's so many different environments, people, workflows, preferences, constraints. If you adopt that mindset, the stuff you work on makes no sense to anyone else observing things. They think that everything you're doing is wrong. They think you're focusing on the wrong stuff. But if you really are going for the whole market, you just start to think very differently.
Can you let us in a little bit on how the OpenCode team today works? Tell us how many people there are, what kind of setup, and maybe we can walk through a recent feature that you or someone else launched, or the team, and then how you also get this immediate feedback.
Yeah. So, we're still figuring this out because we've grown a lot recently. We're at 20-something people now, and it's happened in the last...
Congrats.
Thank you. Yeah, it's happened in the last couple months, like 3 months or so. So, we're still very much in the phase of getting everyone settled. We're in that horrible feeling phase where we have more people than ever, but we're going slower than ever because everyone is still kind of getting situated and getting up to speed, etc. So, we're trying to make it through that phase as fast as possible.
I think for us, we're an open source company, which means all of our code is already public, so we kind of build in public as much as we can. We've been trying to figure out a good terminology for this, but if we have a thing we're trying to ship or make happen, there's a phase where we're trying to push it up the hill, and that's a painful phase cuz you're going from zero to making it exist. And there's a point where it's definitely not done, there's definitely a lot of work to do, but at that point most of the stuff is figured out and it's mostly just fleshing out the details. So our team really tries to focus on getting it out of that first phase into the second phase as fast as possible. We kind of put a milestone of, this is a demo that we want to show people, let's try to get it there as fast as possible. And from there, again, because we're so public, because our users are so vocal, people tell us exactly what to do after that. Once the foundation is there and people roughly get what a feature is, they'll tell us what else they need. They'll tell us where else we need to make it work. They'll tell us what sucks about it. And it gets very easy from there on. And whoever worked on it, they do that full cycle. There's no one that's receiving the feedback and summarizing it for the engineer. They're receiving the feedback. They're getting the GitHub issues. They're getting the replies on Twitter, and they're figuring out the roadmap and the cycle for it. So that first phase is the hardest, but from there, again, the feedback loop kicks in. Things get better over time.
One of the things that we try to do as the founders is make sure that the whole team has perspective on everything that we care about: the market, our competitors, what we're trying to do, our position in it. If they properly understand that, they naturally land on their own priorities. For us, motivation is a huge thing. I said it earlier. We know this is a long game. If it's a long game, your strategy should be, how can I stay in it the longest? The only way to do that is to work on stuff that is exciting every single day. We kind of let the whole team grab stuff that they're excited about. Whatever they think is the biggest problem, the worst thing that's hurting us, they're just going to grab that and work on it. They roughly end up having good judgment if we're doing a good job providing them the right context about what's going on. So, typically people will just grab stuff.
There's been times where someone on our team really wanted to work on something and I vocally disagreed with it. I was like, I don't think we should work on that. And they've been right. A few weeks later I realized, oh, they were actually correct about it and I was wrong. So, it's really exciting to see our team be able to start to do that kind of thing.
One thing that comes up, we didn't mention it a single time in this conversation, but elsewhere it often comes up, is taste. There's this notion or idea that one thing that AI is just very bad at, and probably will stay bad at, is having taste, and how as engineers taste, product sense, they're I think synonyms to some extent. In fact, I even heard that Microsoft internally has a training for taste, to get better at taste, which I'd love to see. What is your take on taste as a whole, as a concept?
So, I think fundamentally it's a good idea. There's something that makes sense there. I think with good ideas, they're very simple, and so everyone kind of repeats the idea, but good ideas are simple but very, very difficult to actually live. So, it's very difficult to actually have good taste. One, it can be learned. It's a lifelong thing that you're going to work on forever. I think the root issue is a lot of people will say the whole taste thing, but do you actually believe it? Do you actually believe that your product has to be good? There's so much out there now that's like, the code doesn't have to be good, the product doesn't have to be good, nothing has to be good, it's just this other thing, you can still be successful. They point to companies that have crappy products, that have crappy engineering, but still make a lot of money, right? So, there's a thing in the air about maybe all that stuff doesn't matter. The moment that gets in your head, you're just not going to ship good products, cuz fundamentally you don't believe in it. And I feel like the number of people that vocally believe that craft is really important, making an irrationally good product is still something that you're going to do. Because most great products, they could probably be 50% less good and have no material impact on it. But it shows up in other ways that are really hard to directly draw that line to. If you start to be lazy in one place, you start to become lazy everywhere. It's like an infection.
So my thing with the whole taste thing is like, yeah, you're saying taste matters, but do you really believe it? It's a very, very high bar to be someone that says I really care about good products. For me personally, I care a lot about it, and I am nowhere near achieving my own bar. I'm so missing my own bar and what I believe. So when you hear me talk about body and stuff and use my products, you're like, "Oh, he's kind of ahead of what he's saying." That's cuz I'm still trying to get better at it, you know? So I look at products that are really good. I'm still very inspired
by them. I still have heroes that I think just kind of do a great job at certain things. I know I have a long way to go to get there.
Can we talk about these heroes, the products and the engineering teams that you look up to and why?
Yeah. So, I think in my space in dev tools, I think Mitchell Hashimoto is an obvious one. Our company is very similar or trying to be similar to theirs in that all their products were open source. They became mass adopted. Things like Terraform became the default. You know, it's very hard to do something like that. And it's well executed across the board in the microscopic, in the macro, the business model. His work with Ghostty has been really great. The architecture of it cares about every little detail and it shows up when you use the product. And he's very good at product, and he made a clip that's a very similar thing to what we were just talking about, where every feature you ship, it's not about the features, it's about how it interacts with every existing feature, and his work as a product person is to make sense of all that. And he's very good at doing that. I think he's probably one of the best for being also a good programmer. So, I think he's someone that I admire a lot and I hope that we can kind of be as good as that one day.
I sensed as we're talking about taste, we started to talk a lot about quality. Could it be that quality is one of the last few things that these days a startup, a small company going up against Goliaths, has left to hang on to?
Yeah. And I think the flip side of it is it's easier than ever to rot your product, with these agents and everything. So you see with big companies, big companies' products are rotting faster than ever. Even startups' products, I was saying this the other day, now if a product is a year old, it's probably already kind of going to... And I think it's because of these agent workflows. So yeah, I still believe quality is a huge differentiator. It's not just something you can decide to do. I think it needs to show up in every single aspect of your company. You have to do things that are irrational. I think that's kind of where quality comes from. You do a bunch of things and 50% of those things you didn't have to do, and I think very few people are willing to operate that way. There's a cold logic these days to programming and to software and to products. It's like, I'm a business guy and I care about business, which means I only do things that are hyper-rational, and a lot of people think that's what being good at business looks like. And of course that can work, but yeah, I think quality is a huge differentiator.
I mean, even if you look at our story, when we first launched OpenCode, Claude Code was the only other real thing we were going up against. A big initial differentiator was that our terminal experience just felt better. We spent a lot more time on it; we built our own terminal framework. Building your own framework is the first thing they tell you not to do, right? It's the thing that no engineering team should do.
It's irrational.
Yeah. Exactly. It's irrational. But we looked at it and we couldn't achieve the experience we wanted. We're people that use terminal tools. We look at tools like Neovim and enjoy them and know what is possible. I mean, again going back to Mitchell, he worked on making terminal stuff as good as possible. He knows what's possible with it. Once we know what's possible, how are we going to ship something that's not pushing those capabilities to the max, right? And very initially, a lot of the reason people were using us, when people were talking about us compared to Claude Code, was how janky Claude Code was or how much it flickered or whatever. And it didn't matter, they're still a hugely successful product, but we irrationally focused on some of the quality stuff, and that helped us go up against a much larger product company with much more funding.
What's your work setup?
My work setup: I've now switched to a Framework Desktop.
Nice, the one where you can replace...
Yeah, the little tiles in the front and stuff. So, that, running Arch Linux, on a, not an ultra, I guess it's a 5K display. Just one 5K display. I use a tiling window manager, which I've been using for 10 years, and that's roughly it. Got my SM7B as well, the mic. And I use my iPhone as my camera. That's about it.
And then you use mostly terminals, of course. OpenCode terminal, right?
Yeah. Oh, I guess my setup is actually a little bit more complicated. So that is my physical machine, but I do all my work on a remote machine. So I SSH into a much bigger, beefier computer that has many tmux sessions going, one for each project, Neovim as my editor, and then OpenCode. It's usually split half, so Neovim on the left, OpenCode on the right, and I'm going between the two. So yeah, Arch, Neovim, OpenCode.
I wanted to ask you how you think engineering leadership has changed with AI, because you've been an engineer, founding engineer, then you've led teams before, you're technically leading a team now as well. And also when you talk with, you know, you're now talking with a lot more CTOs and like-minded folks, what's different? Are people being more hands-on? Is that even a good thing?
Yeah, I think I'll tell you something that I've heard, and on one hand this makes sense, on the other hand I'm not too sure about it. I think these teams are now looking at themselves as, okay, what's the role of an engineer now, right? If you're not going to write the code, what do you do? Your role maybe is to figure out how to make it easy to ship code, that is, to safely ship code, right? Set up guardrails so that when someone prompts an agent to do something, it's not introducing a bug. Make sure your testing story is good. Make sure there's proper conventions and patterns in your codebase that agents can follow so they're not adding something that's really crazy. So your role ends up being more like, how do I set up the right guardrails to make it so someone that is using an agent can kind of blindly ship something that works well. Whether it's another engineer, it could be your marketing team that is trying to ship a change to your website. How do you make it safer to make changes? And this is the novel way that everyone is kind of looking at engineering teams.
The thing that I find interesting is that's not novel. This has been the thing we've always been trying to do forever. How do we get a junior engineer to ship code safely without breaking stuff, right? How do we make patterns in the codebase? How do we make tests? It's all the old stuff that we've always wanted to do. I would love to be able to hire 100 junior engineers and have them be effective, but you know there's limits to that. We never really figured that out, and some companies did to some degree, some companies kind of didn't. So it's kind of the same problem as always, which is how do I make a less experienced person punch above their weight, right? And now it's using coding agents, or maybe it's how does a designer ship stuff, like that. So in a lot of ways I think it's the same problem as always, which is how do you make codebases that are easy to work in, scalable, flex to new requirements.
I think a lot of the old patterns for me are coming back. We've always been a big domain-driven design company. We did it in a very light way. We're now doing it in a much heavier way, because we find that these kind of boring, enterprisey patterns end up being pretty useful, because you have a bunch of idiots on your team now. The coding agents are a bunch of idiots, and they are going to work 24/7 and they're going to ship a lot of stuff. So you need way more guardrails than you used to. And I think what's nice is some of these old patterns we hated because they were very verbose. They produced reliable code that was modular and safe, but they were very verbose and annoying to type out, but you're not typing it out anymore. So now you can kind of get the benefits of these patterns without the downsides. So we're starting to explore that more and kind of enjoy that.
Yeah. I wonder if design patterns might make their way back. Remember in the 2000s, or mid-2000s, they were a huge thing, again for structure. It helped junior engineers not mess things up.
Yeah.
And it was very verbose. So eventually people just hated them and got rid of them.
Yeah. And if you're a good programmer, you didn't have to do those patterns. You didn't need the training wheels in a lot of ways. But now, you know, the agents don't have training wheels, so you've got to put them back on.
Yeah. And what advice would you have for more experienced engineers who, again, had been pretty good engineers until now, and they're like, all right, I just want to stay with it, keep my game high, and have the skills and build up the experience, so I could work at a place like OpenCode?
I have a tough time giving advice to people because I feel like I work in such a weird place. My company, one, it's a startup, so it's innately, automatically a little bit weird. Two, we do open source, and there's like five companies that are open source companies really. So everything we do and the type of people we try to bring in, I don't know if it generally applies to everyone. I think the most I could say, and I've always believed this, even pre-AI, is software engineering is a skill that can be applied to an industry, and you can just be a great software engineer and that's totally fine. You'll probably make a good career doing that. But if you also become an expert in a specific industry, that's a deadly combo.
Just pick any industry, let's say farming. Let's say you understand the farming industry really well and you're also a decent software engineer, you're probably in the top 10 people in the world for that combination that the whole industry will want to hire. And I guess what's great about being a software engineer is you don't have to pick an industry. Everyone else has to be like, I'm going to be in medicine for the rest of my life. You can choose to do medicine for 10 years of your life and do tech in the medical field and become an expert in that, and realize you don't like that industry, and pick a completely different industry and just go become an expert in that. That's so exciting. I think software engineers are curious people, and it's just so fun to be able to deeply learn an industry in that way. And eventually you'll find something that clicks that you can stick with, and being a good engineer and also being an industry expert, it's very easy to become a unicorn of a person in that way.
And when we started, we were talking about how software is everywhere. Software engineers are everywhere. And I guess every industry will lack software engineers who are really curious about their industry.
Yeah. It doesn't take long, right? You spend a year in any industry and you now know it more than 99% of people. But I think the trick here is it's very easy to turn your brain off to that side of things and just focus on, I'm given a task to add something to the UI. Your opportunity as a software engineer is you get to be in any company in the world and learn about anything, and you should kind of take advantage of that, and I think there's a rational career reason to do that as well.
As a close, do you have any book recommendations, things that you've enjoyed or that changed how you think?
Yeah, it's funny because I do not read books at all.
Or reading recommendations.
Well, can I expand on that? My wife is an avid reader and I get to benefit from that, because she reads all the books and then she tells me all the good ideas in them, and I restate them like they're my own idea, like I've read the book. I did have a reading phase earlier on. I think it kind of helped me understand a lot of how the world works. These are boring recommendations, but I'm a big fan of a bunch of Taleb's work. I think he's basically got a couple good ideas, and it's maybe hard to read a whole book because a book is just one good idea inflated into a book, but these are just fundamental true things about the universe that you can just see play out everywhere. So, huge fan of stuff like Skin in the Game. Obviously Black Swan is super popular.
A lot of the stuff that I found to be very influential on myself is the idea of emergent properties. Almost everything great in the world came not through top-down design. It came through a bunch of smaller entities operating together randomly, and then something kind of great comes out of that. And you see that whether it's in robust software, or what makes a city great, what makes a neighborhood walkable, what makes an organism capable of surviving disease. So this whole bottom-up versus top-down in terms of designing systems, there's a few books that talk about that. Taleb's is one of them. And I feel like I see that everywhere. Once you kind of understand his ideas, you realize they kind of underpin the whole world.
Dax, thanks so much for this conversation. This was fun.
Yeah, it was good. Thanks for having me.
I hope you enjoyed this conversation with Dax as much as I did. Dax is in a rare position. He's building one of the fastest-growing AI coding tools out there, going from 650,000 to nearly 8 million monthly active users in just a few months. And yet, he's the one telling us to slow down.
One thing I really liked is what Dax called the muted prickle. Pre-AI, when you wrote a hack, you knew you were writing a hack. You felt a little bad about it. You'd remember it the next time. And that feeling kept your judgment sharp. With AI agents, that feeling is gone. Now someone else is dealing with the consequences. The landmines are still there. They just won't blow up on you today. And we don't even pay attention to a lot of these landmines being placed by AI agents.
Finally, I really appreciated Dax's memo to his team. He basically admitted, "We're shipping features we shouldn't. We're absorbing too many hacks, and the worst part is we're not even moving faster. We just feel like we are." That's a pretty brave thing for a founder of a hot AI-native startup to say out loud, and I think it's a reality check that a lot of engineering teams need right now.
If you enjoyed the episode, be sure to subscribe on your favorite podcast platform or on YouTube. And if you'd like to support the show, leaving a rating or review really helps.
Thanks for listening and see you in the next
Article published