DHH on Going Agent-First: Taste, Tiny Teams, and the End of the Programmer as Bottleneck
The Pragmatic Engineer
Six months before this conversation, David Heinemeier Hansson (DHH), creator of Ruby on Rails and co-founder and CTO of 37signals, was on Lex Fridman's podcast criticizing AI coding tools. Over the winter break he reversed course and now starts nearly all of his work with AI agents. He insists his opinions haven't changed; what changed, he says, is the facts. In this conversation he explains what made the difference and how he works now. He also covers what agents are doing at 37signals, why he thinks senior engineers benefit most while junior developers face a harder road, and why he believes taste, design, and craft matter more than before. Much of the discussion also covers how 37signals builds products: tiny teams, designers who act as product managers, and a long, deliberate path to launching HEY.
Omarchy and scratching your own itch
DHH says he has been building things on the internet since around 1994. His latest large project is Omarchy, a Linux distribution. He switched to Linux a little over two years ago and spent some time on Ubuntu. He then decided he wanted to build his own system from scratch on top of Arch and Hyprland. Omarchy started as a summer project during the downtime around the 24 Hours of Le Mans, where he races, and he says it took off quickly.
He finds it encouraging that a new distribution could find an audience in a market of roughly 7,000 existing ones, many with long histories and similar sensibilities. His takeaway is that all the ideas in the world may be taken, but that doesn't matter, because your spin on them isn't. He says he has seen the same pattern with Rails, Kamal, and leaving the cloud: when he builds something that exactly suits him, thousands of people with similar tastes turn up. By his count, Omarchy has about 400 code contributors after a little over six months, and tens of thousands of people use it as their daily driver. He likes that Linux, though it dates to 1991, is a new discovery for many people who have never run it on a personal computer. He sees his job as flattening that learning curve with a default install that looks good without 100 hours of tweaking.
Rails had the same origin. DHH picked up Ruby in the early 2000s and put it to real use in 2003, when 37signals began building Basecamp. On earlier client work he had been told which language to use. With Basecamp he was free to choose, and Ruby had little web tooling at the time, so he built what he needed, and that became Rails. He says Rails is having a renaissance because it is "one of the most token efficient ways of building web apps," which suits agent workflows. He adds that this may not last: agents might end up writing machine code, and humans might eventually stop needing to read and verify agent output. For now, he argues, token efficiency and human-readable code both still matter.
He also brings his hobby projects into the business. 37signals has run on Rails for more than 20 years. Most of its developer machines now run Omarchy. At first Linux was optional. Once Omarchy became serious, he asked everyone on the technical side to switch: web developers, Ruby developers, and DevOps staff, but not iOS developers. He compares it to not letting someone at a Rails shop write a project in Django. His reasons are that 37signals has always deployed to Linux, and being close to the production environment is "a material advantage." He also wants as many people as possible helping with the distribution, and as CTO, he says, he sets the technical direction.
From consultancy to Basecamp
37signals was founded in 1999 as a web design firm. DHH joined in 2001 and spent a couple of years working with Jason Fried on consulting projects. Work on Basecamp began in 2003, and it launched in 2004, a day before or after Facebook, by his recollection. Within about a year it was clearly taking off, and the company switched from consulting to software.
Basecamp is still the company's largest and most important product. DHH points out the irony: you might expect ideas to improve with experience, but for many people the first idea is the best one. He says without embarrassment that Basecamp is "objectively" the best business idea they have had, and he is proud that it has kept growing for more than 20 years.
HEY: taking on Gmail and fighting Apple
The company's other big bet was HEY, an email service launched in 2020. DHH calls it a crazy mission, because email is dominated by Gmail. He describes Gmail as a solid product that "hasn't really changed in 17 years," with an estimated 80–85% share of U.S. email traffic, though he qualifies the figure himself. He finds it curious that people say they hate email without connecting that to the fact that they use Gmail. He had used Gmail since receiving an early invite code and had built up many opinions about what didn't work. Those opinions went into HEY, which took almost two years and millions of dollars in cumulative R&D.
The launch coincided with a fight with Apple, which wouldn't approve the app unless 37signals paid the 30% fee. DHH says being kept out of the App Store would have killed the product, because most paying HEY customers are iPhone users. After about two weeks of public back-and-forth, which happened to coincide with WWDC, when Apple presumably didn't want to look like Goliath crushing a small developer, HEY was allowed in and Apple adjusted its rules after the fact. He calls it a small victory rather than a final one. The irony, he says, is that the fight gave them wall-to-wall media coverage worth millions. He says he would never have deliberately made that gamble, because the downside was zero: a rejected app with 200 signups. Instead, tens of thousands of people signed up in the first weeks.
DHH uses HEY every day. On many days it is his most-used app, because he does so much communication and writing in email. The central feature is the Screener: nobody reaches your inbox until you approve them. He finds it strange that under Gmail's model "total strangers around the world can just make your pocket buzz." In HEY, he screens people himself, with no AI involved, and says it takes little effort because not that many new people write to you. The host mentions reaching DHH by cold email for this interview and passing the Screener.
DHH contrasts this with sales tactics in Gmail. A polite "no thank you" can pull you into a sense of obligation to keep replying, and an outreach campaign can mean seven emails, or 52 if you show any sign of life. In HEY, one thumbs down means you never hear from that sender again. He compares it to pulling weeds until only flowers are left. The original email protocol, he argues, was designed for scientists with good manners and then released into a world full of salespeople. HEY is meant to be a defense against that, "a way to love email again." He connects this to Viktor Frankl's idea that a strong "why" helps you get through the cold, uncomfortable, annoying parts of building with computers, even if that why is as modest as helping people love email.
Why HEY took two years, and why teams start tiny
The host asks why HEY took two years when 37signals is small, nimble, and staffed with strong developers. DHH recognizes the "I could have built that in a weekend" instinct from Hacker News's reaction to Dropbox and the original iPod. He calls it developer hubris and admits he has it too. A prototype can be built in hours, and these days an agent can start one for you. The slow part is figuring out what you actually want to build, and getting to something worth publishing takes longer still.
On the technical side, HEY started with DHH alone, alongside Jason Fried and one or two designers. He says most of the company's major products started that way, with one programmer and one or two designers, and Basecamp too was just him on the technical side. He believes you go slower if you put a lot of people on an uncertain direction: "If you don't know what you want a million people is not going to build it for you." With Gmail as the competitor, HEY couldn't be "Gmail in blue." It had to solve problems people hadn't articulated, because the complaint they did articulate, "I hate email," was, in his view, a misdirection. The small team keeps working until something clicks. Then they add a few people, and for roughly the last 20%, when the terrain is known, everyone joins in. He notes that recent AI progress is changing this: working out what you want has become faster.
Designers as product managers and implementers
The host contrasts this with VC-backed startups and large companies such as Uber and Facebook, where a product manager, perhaps with half a designer, writes a spec before developers get involved. DHH agrees that 37signals is unusual. Designers there don't make a spec pretty; "they're here to find what the spec should be." They act as product managers, working from customer feedback or intuition to decide what to build and how it should work. They also implement: they write the HTML and CSS and often work in JavaScript and Ruby. With agent acceleration, he says, designers now produce the whole thing in its final shape, though not necessarily in the form that gets merged.
He says the company has struggled to hire designers because many are not used to wearing the product manager hat and the implementation hat at the same time. When one person wears all three, "you have an individual who know the materials they're working with," someone who works with the grain of the web. His analogies are a jewelry designer who knows how gold bends and an architect who understands load-bearing structures, while still relying on engineers.
He applies the same idea to Apple. He thinks longtime fans such as John Gruber of Daring Fireball are disappointed because the finely designed native Mac app is essentially dead. Native feel, in his view, has its own grain: button placement and behavior feel either authentic or synthetic, and "today, it's all synthetic." He also defends Electron, saying it gets too much hate and is "just a web in a box," even if some implementations are poor. He expects agents to give designers more implementation power, which will move the industry toward 37signals' position. He sees the same happening with team size: he says people long called a one-programmer Basecamp unambitious, wrong, or even a lie, and he always attributed it to better tools like Rails. Now, with agents, the industry is recognizing that one person can build something valuable and that smaller teams reduce communication overhead.
"Aesthetics is truth"
Asked whether he values design as a craft alongside engineering, DHH says: "I think aesthetics is truth. When something is beautiful, it's likely to be correct." He believes this holds in mathematics, physics, and many other fields, and that our intuition toward beauty points toward correctness. He also argues that beauty makes people happy. Put negatively, a major source of anxiety is when everything is bad: laggy interfaces, touchscreens that don't register, a travel agent blocked by an old COBOL system. He calls this a "serious source of malaise for civilization" and says human happiness could be raised by surrounding people with more beautiful objects and systems, beautiful on the outside and the inside.
He believes the inner and outer qualities usually go together. Steve Jobs, he says, cared about the inside of the box because the kind of person who cares about circuit board layout also sweats the interface and the ergonomics of opening the case. For DHH, Ruby is the language that produces the most beautiful code, "there's barely even competition." He finds Smalltalk beautiful in its minimalism but "not the house I want to live in." Ruby is, because it combines that aesthetic quality with a lack of ideological rigidity. People obsessed with beauty tend to be narrow-minded, he says, and Ruby has avoided that. Craftspeople, in his view, should keep polishing "until there are no splinters left."
"My opinions haven't changed. The facts did."
When the host brings up his AI skepticism on Lex Fridman's show, DHH calls it "a nuanced point and maybe it's self-serving," and says his opinions haven't changed, only the circumstances. He says he recognized ChatGPT's launch about three years earlier as a landmark in computing history. He found the models "freaking smart, smarter than me in many ways," and says he sees no use in debating whether that intelligence is "real," since we barely understand human intelligence either.
His objection was to the form factor. Autocomplete-style tools such as early Copilot and Cursor "won't let me finish a sentence," he says, and they were wrong so often that any acceleration felt like a nuisance. For him it wasn't net positive, though he allows he may have given up too soon. He became briefly pessimistic that the industry's future was "tap tap tap." The host mentions receiving a Cursor swag keycap with only a Tab key, which both agree felt dystopian. DHH compares it to the Simpsons episode where Homer puts a drinking bird on the keyboard to keep pressing Enter while the reactor overheats.
During that period he used ChatGPT and similar models as a tutor, or as a pair programmer who doesn't drive. He would paste code and ask why it works or what's wrong, much as he had used Google and Stack Overflow, and he often got good explanations. The host mentions game developer Jonas Tyroller, who turned off autocomplete in his IDE and went to ChatGPT only when he needed help, which let him stay in the zone. DHH agrees and jokes that he worried everyone would become the drinking bird and he would have to take up potato farming.
The inflection point: agent harnesses plus Opus 4.5
Two things changed his mind. First, Claude Code, which DHH says started in the spring and gained traction by the fall, established agent harnesses in the terminal, where the AI can use bash, the tools in your terminal, and the internet. "This is really where we transition from AI to agents," he says. Second, Opus 4.5, which he recalls dropping around November 27, was the first model that "continuously and consistently would shock me" with the quality of its analysis from vague inputs and, more importantly, the quality of its code. It produced code he wanted to merge with little or no change, and when he corrected it, it remembered.
His bar is high. He wants agent-written Ruby to look as good as his own, and he wouldn't merge sloppy code from an agent any more than from a junior developer. Earlier models could sometimes produce working software. He recalls how magical it felt to have a snake game he had wanted to make since age six appear in about 30 seconds. But they couldn't match his standard.
He notes that others point to different turning points, but he sees a general consensus around late November and early December. The host adds that this coincided with the winter break, when people at big tech companies had time to try agents on side projects they never expected to finish and then found them finished. Many CTOs and engineering leaders came back in January and told their teams to use these tools because they had "seen the future." Both agree that words don't convince people; you have to try it. DHH recommends sitting down with OpenCode or another harness and starting with Opus, which he calls the best frontier model.
He dismisses the claim on X that anyone who hasn't absorbed everything about AI has been left behind. You could pick it all up in three weeks, he says. He notes that anyone who ignored last spring's MCP enthusiasm can now skip straight to CLIs and skills. He credits Tobi Lütke of Shopify with seeing this about two years earlier and repeatedly sending him examples. DHH says his own eyes tend to stay "close to the road," while some people look further ahead. "Toby saw exactly where we were going two years ago. And I finally saw it because the road came to me in December." He had always expected the tools to become good enough but thought it might take 18 months or five years, and he says even Silicon Valley couldn't predict when "the hockey stick starts hockeying."
The agent-first workflow
His main harness is OpenCode, and he also uses Claude Code. He is critical of Anthropic for revoking OpenCode's access to Max subscriptions, calling it a mistake that treats the game as a single match rather than many rounds. He still says he has no qualms about using Opus and turns to it for hard problems. He cites Anthropic's revenue growth as he recalls it (from about $9 billion to about $19 billion within the year) as fueling competition, which he welcomes. He tries to hold two views at once, as he does with Apple: he has serious grievances about Apple's gatekeeping, yet as someone who loves computers he likes the new Neo and might buy one.
His layout, built into Omarchy, runs in tmux. Neovim is on the left. On the right are two agent panes: OpenCode running Kimi K2.5 on top and Claude Code with Opus below, with a terminal strip at the bottom. He runs two models at different speeds. Almost everything starts with a prompt to an agent. He then reviews the diff in lazygit inside Neovim, commits if it looks right, and otherwise corrects it himself or asks the agent to. In early November he was still code-first and asked his "friendly clanker" only for second opinions. Now the agent writes the draft and he reviews it.
Once he was convinced, he wanted to see how far agents could go with no accommodations: no MCP, no CLI. He installed OpenClaw on a VM and, over Telegram, told it to sign up for Fizzy at fizzy.do. It needed an email address, so he told it to sign up for HEY, expecting it to fail. It reported that it had signed up for HEY, gave him the password, completed the Fizzy signup, and confirmed via email. He then sent an invitation to its new address and asked it to join the AI Labs project in Basecamp and introduce itself. It did, saying it had read back through the transcript and could see everyone was excited. It took about seven minutes, "an eternity" in agent terms, and he acknowledges this may have been possible with earlier models. He concluded that the end state is agents needing no accommodations at all, and that "they'll be coming on bionic legs."
For now, 37signals is building CLIs for Basecamp, then HEY and Fizzy, and probably some legacy products. What he likes most is that agents vindicate the Unix philosophy of small tools connected with pipes. The value isn't that Basecamp becomes easier to use, he says, but that it can be chained with GitHub's CLI and Sentry's MCP. His example: tell an agent to look at errors in Sentry, post a write-up to Basecamp, open a pull request on GitHub, and comment back in Basecamp when done, so the team can follow the work in one place. He urges people to try this with their own products and tasks. They will be excited, he predicts, and also a little anxious: if three months turned his understanding of computing upside down, what will the next 18 months bring?
The host says they are wary of extrapolation, noting that Moore's law broke. DHH replies that it broke for single cores and then found another route through many cores. The host mentions "The Bitter Lesson," which they describe as saying our hard-won specialist knowledge is less special than we want to believe.
Senior versus junior developers
DHH says that at this moment, experience still matters a lot, and the result is a split. At 37signals, the biggest gains from agents have gone to the most senior people, who can judge whether agent output is fit to ship to millions of users. He cites recent reporting on major Amazon outages, which he says Amazon's own internal analysis linked to letting junior programmers ship agent-generated code without review. He thinks most companies are reaching the same conclusion: in mission-critical systems you can't yet rely on agents, and junior programmers can't catch their mistakes.
Senior developers, in his account, can run many agents in parallel, check output quality with confidence, and redirect agents when needed. This is the role they used to play for juniors, and agents follow redirection faster. That lets a senior developer multiply their output five or ten times. The second-order effect is that the senior's hour is now worth far more, so spending it teaching a junior becomes expensive, and he says it is unclear how that will play out. One possibility is that agents become "senior" in their ability to ship working code. That would be his bet in the long run, by analogy with Tesla's self-driving, which he says now drives better than humans on average. If we can hand off life-or-death driving to AI, he reasons, agents can probably make code work too, though "who knows when, who knows how."
The host adds the limits of the analogy. At Uber, AI adoption depended on internal systems built to feed agent harnesses the context of monorepos, ticketing, Slack, and RFCs, and a staff engineer moving companies loses effectiveness until they learn the new systems. Waymo operates in mapped areas and good weather, and the host describes a ride where a human operator had to step in. Uber's self-driving predictions also took far longer than promised. DHH replies that Elon Musk's 2017 promise was made when Autopilot was, as he puts it, 500,000 lines of hand-coded C++ that could never have gotten there. The current AI-based FSD hasn't been running long, and over roughly 18 months, from version 13.1 through 14.2 as he recalls, it went from "better pay attention" to "why is there a steering wheel." He calls the Tesla "the best chauffeur in the world," smoother than he is. People look at that pace and wonder what happens when coding agents make the same leap. He also warns against getting lost in speculation. He tries to focus on what is possible and enjoyable today and leaves forecasting, like the interview with Leopold on Dwarkesh's podcast about 2030 and multi-gigawatt data centers, to people who are good at it.
"Twelve arms instead of two": the enjoyment and the exploding pie
DHH says his biggest surprise wasn't the agents' capability but how much he enjoys working with them. On Lex's show he had said he didn't want to become a project manager for agents. Running agents feels instead like "stepping into this super mech suit where suddenly I don't just have two arms. I have 12," watching seven screens and typing on five keyboards. He is still the programmer, just a different kind, with the same concern for aesthetics.
One moment that convinced him came before the Omarchy 3.4 release, with about 250 open pull requests. At 15 minutes each, the backlog looked daunting, so he began giving Claude a PR URL and asking for a review. In about 90 minutes he processed 100 PRs. Roughly 10% were merged as-is. About 20% identified a real problem but used code he didn't want, so he asked Claude to "clean room" a fix, which it produced in Omarchy's style. That is mostly bash, but he says bash still has a shape. About 25% he decided the project shouldn't have at all, and in the last 25% Claude found something worthwhile but no straight path to a good implementation. He estimates this would have taken days to a week. He also admits that for about half of the PRs, Claude's analysis covered areas he knew nothing about, where it was "undeniably a smarter, better reviewer." Those PRs had sat because he didn't want to research unfamiliar debugging territory, and he calls the session one of his top 20 programming moments.
The host suggests the underrated impact is work that would never have been done. DHH agrees: "the pie is just exploding." He says the number of internal projects 37signals has taken on that it would never have considered is "legion." His example is Jeremy, one of the company's most agent-accelerated developers. Instead of P50, P95, or P99, Jeremy targeted P1, the fastest 1% of requests. DHH remembers the floor as about 4 milliseconds and says Jeremy brought it below half a millisecond over a couple of days as a side project, in about a dozen PRs totaling roughly 2,500 changed lines, though he says he may be misremembering the details. Each PR made sense on its own, and DHH says he would never have approved such a project in advance. The host notes that P1 work usually looks like vanity with no business case, even though everything adds up.
DHH does the same now. He gives vague instructions to test a half-formed idea and reverts without regret, because 75 lines of code no longer represent two hours of his time. He compares it to being a king who asks servants for reports, except the answer comes back immediately and sometimes a "terrible idea" turns out to be good. His current example is dual boot for Omarchy, which users have requested from the start. He didn't need it personally, and he was wary of the risk of damaging boot records or partitions, plus the difficulty of LUKS encryption on a partition that doesn't own the whole drive. He had Opus write a plan, had Codex critique it, and let them trade it back and forth several times. He likes the result but hadn't yet started the implementation when this was recorded. He says he still hasn't fully absorbed the idea that you can start a long-postponed project "on a hunch while you go to lunch."
Even if models stopped improving tomorrow, he argues, we would spend a decade getting more out of them. He compares this to the Commodore 64, where games made decades after launch far exceeded early ones once developers learned the hardware's tricks, and to the gap between early and late PlayStation games. We won't get that experience with models, he notes, because a new one arrives every three months.
Team size, methodology, and "peak programmer"
DHH says that for 37signals the same people can now do far more, and that is enough. The company already had margin to hire more if it had enough good ideas. Extra productivity goes into projects like P1 and faster product improvements. The old idea that a major feature takes two months is gone, and Shape Up's two-month cycles no longer make the same sense. He says they haven't rewritten those scripts yet because things are changing so fast, and that no company really has.
He still thinks developers are "delusional" if they don't expect a shift. They used to be the constraint on output and were paid accordingly, and that constraint is loosening, especially once product managers can ship working changes themselves. "If I was going to bet we've seen peak programmer," he says, meaning the number of people who trained for years in programming as a skill. Jevons' paradox means demand for software will grow, but he argues that doesn't guarantee every programmer is rescued. More software is being produced than ever. The conversation touches on GitHub's reliability problems, including a chart reportedly showing 92% uptime, as a sign of the strain. OpenClaw's roughly 400,000 lines of code come up as something that once would have taken many people years. DHH compares Shopify's main monolith at about 3 million lines, built over 20 years by, in his rough estimate, around 20,000 contributors in total. He also says that outside the X bubble, most companies have barely adopted AI, despite ChatGPT's 800 million users, so much more change is ahead.
He distinguishes between companies like 37signals, which have unlimited scope and can put productivity into doing more, and companies where software is a cost center. He believes those are the majority, and they will simply want the same work at a tenth of the cost. That creates pricing pressure, so he thinks it is "correct for the average programmer to think maybe we've seen the best of the golden days."
The host outlines how developer hiring has shifted: the lone nerd of the 1990s, language-specific hiring in the 2000s, algorithm-focused hiring in the 2010s, and now "product engineer" roles that emphasize empathy and communication. DHH agrees that the constraint is now deciding what to build and for which customers, which is product management. He admits he used to think little of product management as a function, partly because product managers were idle while waiting weeks for expensive programmers. That dynamic "absolutely is going to switch." He believes implementation will be solved at some point but isn't claiming it is solved now. Having learned from last summer, he won't bet it won't happen by next summer. The host expects edge cases to take longer, as with trucks in self-driving. DHH says that to keep the privilege of "I just want to sit and code," you have to be at John Carmack's level and better than the agents available off the shelf. The host notes that Carmack is also enthusiastic about AI and has always had business sense or partners who did.
Hiring: what it takes to get in
37signals has about 60 employees. DHH estimates around 20 are programmers, about 10 are designers, 14 are in customer support, and about 10 are in operations managing servers, with the rest in HR, finance, and other support roles. By his rough estimate, about 100 to 150 programmers have worked there across the company's history, chosen from tens of thousands of applicants. He says their "batting average" is only slightly better than 50/50 in the long run. He cites a Google study that found no reliable predictors in education, GPA, or similar measures, and says that "no one has figured out" hiring.
He says he may have a skewed sense of the average programmer from working with excellent people in open source. Every hiring round, he is surprised by how weak most submissions are and how little effort goes into them. He rejects thinking about hiring as odds: with 1,000 applicants, a weak applicant's chance is zero, not 0.1%, while a strong applicant might have 10–30%. The company discards at least half, maybe two-thirds, of applications immediately for not addressing the job or not following instructions. From what remains, it historically narrows to about 20 candidates who get a take-home test. He dismisses the complaint that this is free labor, since the test is based on code already in the system, though he understands not wanting to spend six hours on a test that goes nowhere. He says the idea that you send a resume, have a 30-minute call, and get hired didn't exist in his career.
The "black pill," he says, is that the company's long-term hires have come more from warm referrals ("I've worked with this person for two years") than from open calls. That leads to his main advice: do your best even at a job you consider bad. Coasting and browsing Reddit is noticed by your coworkers, and those coworkers are where future referrals come from. He says he didn't like most of his former bosses but still worked hard for his own growth. The host notes that DHH's path to 37signals began as a contract job, and DHH recounts that Jason realized "this punk better get some equity," while cautioning that founder stories are exceptions.
DHH also says he may have contributed to a mistaken 2010s idea that you can be a great programmer without caring about programming outside work. He was pushing back on 100-hour weeks, and he says 37signals has averaged 40-hour weeks for 25 years. But he plays with computers in his free time. The belief that programmers were so scarce that companies would hire people who "barely gave a [damn]" is over, he says. He adds that high salaries attracting boot camp graduates was the economy working as it should. The host expects reference checks to become more rigorous and mentions Databricks' in-depth reference calls.
DHH notes that "peak programmer" doesn't apply to everyone. Really good programmers are "currently more valuable than ever," because they get the most from AI. He says he is enjoying programming more than at any time since discovering Ruby in the early 2000s, and that 37signals' most AI-forward programmers feel similarly, with their anxieties pushed aside by enjoyment. He understands the anxiety of someone worried about paying for their kids' college in seven years. But he argues the only productive response is to lean in: take an unfinished hobby project out of the closet and try it with an agent. The host mentions Kent Beck, who has programmed for 52 years and is using agents to build a Smalltalk server while taking long breaks to watch birds at his lake house. DHH calls Beck one of his heroes. He saw Beck speak in Denmark in 2001 and calls Smalltalk Best Practice Patterns his favorite book on tactical programming.
The risk of overwork
DHH sees a tension: most people he knows who are all-in on agents are working harder than ever, and he has noticed it in himself. When an hour of supervising agents can accomplish so much, the dopamine loop around shipping becomes "hyperactive." His reminder to himself is that "this is not like a limited sale." AI will still be here next month, and today's models are the worst they will ever be. The host mentions Steve Yegge, who has been candid about being pulled in and looks drained.
DHH doesn't use an alarm, though his wife now does for the kids' school schedule. He considers eight hours of sleep the best investment in cognitive capacity. Cutting to six hours to gain two means carrying a deficit through 18 waking hours, which he calls "such a bad piece of math." He admits the AI excitement has cost him sleep a few times, fewer than ten, which is unusual for him. His rules are: don't trade sleep, don't trade exercise for agent time, and don't neglect diet. Cutting two or three hours of sleep a night for three weeks leaves you "a hot mess," he says, so it doesn't work even in the short term.
Why he keeps building
Asked why he still works when he could have retired long ago, DHH says it comes down to a deep love of computers, which he has had since age five. He races cars, takes time off, and has three kids, but if he is going to fill eight hours a day, computers are his best option. Directing agents now feels a bit like a video game, like moving units in StarCraft. He calls it a misconception that wealth is a finish line after which leisure brings happiness. He says a century of psychology suggests purposeless leisure is misery, and points to founders who sell their companies and are back at work within weeks. The work, he says, is the goal itself and a confirmation that he is useful rather than "just a blob laying around."
For now he is focused on agent accessibility, especially the Basecamp CLI. That work has shown him "we're not quite at AGI yet": an agent can make a CLI, but getting it just right still requires his help, and he is happy to provide it. He expected it to be released soon, possibly before the episode aired, with CLIs for the other products to follow. His new morning ritual is resisting the urge to check X immediately, which he says takes real willpower because he is so curious about what has happened overnight. He doesn't expect that curiosity to fade: he says he likes computers more now than he did five years ago.
In closing, the host highlights three points. DHH's philosophy didn't change, but the tools became useful. His high quality bar suggests AI may make judgment more valuable. His "peak programmer" argument suggests developers may lose the leverage of being the bottleneck. The host's own view is that there will still be strong demand for engineers who can oversee complex systems and who have taste and business sense in addition to coding skill.
I feel that you very much value software engineering as a craft.
Hugely. I mean, I think aesthetics is truth. When something is beautiful, it's likely to be correct. I think this is true in mathematics. This is true in physics. This is true in a lot of different domains.
I wonder if there's a part of AI about the impact of doing work that we would have not done before.
The number of projects we have tackled internally that we would never even have contemplated starting on or Legion. Jeremy, one of our most agent-accelerated people, went like, "We're going to do P1. We're going to optimize P1." Literally the fastest 1% of requests, we're going to make them even faster.
There's a bit of tension right now is that most of the people I find who are all in, they're working harder than they ever have. And I've seen that with myself now, too. When you can be this effective and impactful on an hour of supervision of these agents, it's really intoxicating. And I need to go, do you know what? This is not like a limited sale.
On Lex Fridman's podcast, you were still, rightfully so, very skeptical of AI.
This is a nuanced point and maybe it's self-serving, but I don't actually think my opinions have changed. What have changed is
How has the creator of Ruby on Rails changed how he builds software now with AI agents? David Heinemeier Hansson, often referred to as DHH, created Ruby on Rails, Omarchy, and is a co-founder of 37signals. He bashed capabilities of AI coding tools on Lex Fridman's podcast 6 months ago. Then over the course of a few weeks over the winter break, he did a 180 turn and went AI first on everything.
In today's conversation, we cover how David and his team at 37signals build software today and how AI tools are making them more ambitious than ever before. Why Ruby on Rails and Linux could become even more popular than they are today, as they are both well suited to working with AI agents. Why taste and beautiful software are becoming more important, and why both standout designers and engineers who care about the craft could become more in demand, and many more.
If you're interested in what one of the most experienced builders in the tech industry thinks about the practical utility of AI tools and how these tools could impact software engineers who care about the craft, then this episode is for you.
This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Check out the show notes to learn more about them and our other season sponsors, Sonar and WorkOS.
David, it's awesome to have you here.
Thanks for having me. Thanks for coming. I should actually say you're in Copenhagen. That's my city of choice at the moment. It's a beautiful city. It's got so much going for it. And so, what have you been up to?
I'm always building stuff. I have been building stuff for a good damn three decades now on the internet. I got started back in '94, I think it was, when I first got exposed to it and basically just never stopped. And in the past six months, I've been building a variety of things. One of them is a new Linux distribution called Omarchy.
I switched to Linux a little over two years ago, I think, now. First spent some time on Ubuntu, having fun with that, and then realizing I actually wanted to make my own system from scratch, building it on top of Arch and Hyprland. So, put a lot of time into Omarchy. It got started as a summer project in between racing at the 24 Hours of Le Mans. There's a lot of downtime in that week. So, I just started hacking on it and it really took off very quickly thereafter.
It's been a truly inspiring ride to see that even in a market as crowded as Linux distributions, there's about 7,000 different distributions out there, some of them with long pedigrees and many of them even based on sort of kind of similar vibes to some extent, there's room for something new. And it's a great reminder that all the ideas in the world may be taken and it doesn't matter, because your spin on it isn't.
And I put my spin on Linux. Built Omarchy, built the perfect computer system for me, and saw exactly the same thing I've ever seen. Whenever I build something that really just hits the spot for me personally, there are thousands of others just like me, or close enough to what I like, that they find the same pleasure and joy in it. Whether it was Ruby on Rails, Kamal, getting out of the cloud, any of these things, it's the same syndrome.
Yeah. With Rails, you were literally scratching your own itch. You were just building your own components and then open sourcing them. Is that how it started?
Basically, I picked up Ruby in the early 2000s and really put it to the test in 2003 when we started building Basecamp, and I did not have a mandate of what to use to build it. Prior to that, I'd been working for a lot of client projects that would say, well, we're building this in PHP because we have someone who knows that. So, this is what you have to use. And then we were building our own system. We're building Basecamp. And I was free to choose. So I chose Ruby, and at the time Ruby didn't have any tooling, or not very much, when it came to web applications. So I had to build it all myself, and that turned into Ruby on Rails, which is still going strong. I'm still very heavily involved with that.
I think in some ways Ruby on Rails is having a little bit of a renaissance now that it is one of the most token-efficient ways of building web apps. It's ideally suited for the agent workflows we're dealing with now. We'll see how long that lasts. Maybe all the agents are going to be writing machine code or assembler in about five minutes. So maybe that comes to an end. But for the moment, token efficiency still matters. And it still matters whether the agents produce code that humans are able to read and verify. That may also come to an end at some point.
But as it is right now, it's been a fun ride to just see these kinds of projects where I'm scratching my own itch resonate with a much larger community of people who then show up and want to help. I mean, for Omarchy, which has only been around for what is that, just over 6 months now, we have, what, 400 contributors who've made code changes to the distribution, and on top of that we have tens of thousands of people who've installed it and use it as their daily driver.
So, I always love that discovery of something new, novel, and inspiring, like Ruby. Or, it sounds weird to talk about discovery of an operating system that's been around since, what, '91, but for a lot of people, Linux now is that discovery, because they have not been using it on their personal computer. So, they're seeing it for the first time. And for me to help a new cohort of Linux users, and hopefully even enthusiasts, come to be because I'm flattening the curve a little bit, I'm making it easier to get started, I'm making the default installation just look amazing so that they don't feel like they have to invest 100 hours into tweaking the system to get going, is really fun.
But what's also fun, of course, is that both of these things, both Ruby on Rails and Omarchy, were not just hobby projects. I love hobby projects and I will always do those, but I also like to apply them to business. So at 37signals, we built an entire business for 20-plus years on top of Ruby on Rails. We're now running Linux on the majority of developer machines because we now have our own distro.
So it's Omarchy? People can choose, right? Can they
Well, sort of kind of. We started with an open choice, and then at some point it just doesn't make sense anymore, in the same way it would not make sense for someone to be at 37signals and say, I want to write this thing in Django, we're going to use Python and this other framework, even if you have Ruby on Rails and you're doing that. So we pivoted from an early invitation to play around, that was when I first switched to Linux, just said like, hey, if you want to check it out, check it out. Then when things got a little more serious with Omarchy, I just said let's go all in for everyone who's on the technical side of things, not the iOS developers of course, but anyone who's working with the web, who's working with Ruby, who's doing DevOps. They should be on Linux.
Because first of all, that's closer to what we deploy. We've always deployed on Linux. We've been a Linux shop on the server side since day one. For developers and system operators, I actually think it is a material advantage to be closer to your production environment and just be more familiar with the tools. Then on top of that, of course, we are building this distribution and we should have as many hands help out as possible. And given the fact that I'm the CTO of this company, I get to set the technical direction, and this is the direction we're going.
Can you just do a very short recap of how you started, and right now where is the business as a whole? And you keep building, you keep launching new and exciting and just cool stuff. I think Fizzy was the latest one.
Yes. So 37signals was founded in 1999. It started as a web design firm, and then I joined up in 2001, two years after, and for a couple years collaborated with Jason on these consulting projects. And then it was in 2003 we started work on Basecamp, released it in 2004. Actually, either the day after or the day before Facebook went live, which is kind of a funny coincidence, that we were of that same time and cohort. And within about a year, we realized this thing was taking off and we went full-time and switched from being a consultancy to being a software company.
Awesome.
And that's now 22 years ago, a little more than that. And in that time, we've released a ton of products. Basecamp was the first. Remains the biggest and most important, which is also kind of funny, because you sometimes perhaps have this delusion that as you learn more and as you get more experience, you'll get smarter and you'll have better ideas. And like, no, there's tons of people for whom their first idea was the best idea. And I have no shame in saying that Basecamp was the best idea, objectively, in terms of a business that we've ever had. And I'm incredibly proud that we've been able to keep that going and growing and flourishing for over 20 years. Very few software companies, let alone software products, can boast of that longevity and legacy.
But we've tried a ton of things over those years and had some other great successes. We launched hey.com, our email service, back in 2020, which was a crazy mission when you think about it.
Here is a sector completely dominated by a single player, Google with Gmail. That's a good product.
It hasn't really changed in 17 years, but it was really solid and lots of people are perfectly content with it. They hold this duality in their head where at once they both hate email but somehow don't connect it to the fact that they're using Gmail, which I find curious. But either way, we launched this, that is not only a competitor to this very entrenched product that has probably a greater grasp on market share in any major category than any other product I can come to mind of in the US. I think Gmail is something like 85% of all email traffic, which sounds insane. Maybe it's 80%. It's incredibly high. It's basically Gmail, and then all the rest is in this tiny little part of the graph.
So, we thought that after using Gmail, I used it since, I don't know when I signed up, a few weeks into it, I got one of those invite codes. That was a really clever launch, and I used it ever since. So, that's literally 17 years or something of Gmail usage. And over that time, I built up a lot of opinions about things that didn't work quite like I would prefer it to work. And we put all those opinions into a new software product. Spent almost 2 years developing it. Millions of dollars in accumulative R&D funds. And launched it in the summer of 2020, which, by the way, time to launch a product. 2020 wasn't great for a whole host of different reasons. We were kind of trying to slot in a, can there just be a week where the whole world is not just insane?
Yeah.
We finally picked a week. We went live, and then we had the battle of our lives with Apple.
With Apple. I remember that.
And ultimately
They didn't want to approve your app.
They didn't want to approve our app unless we paid the toll fee, the 30%.
And they were basically willing to say you can't be in the App Store, which for an email product like that is a death sentence.
Yes. You have to be on not just mobile phones but specifically the iPhone. This is true today. The majority of HEY paying customers are iPhone users, because that's the largest, most affluent market in the US, and the US is the most affluent software market in the world. So for that business to work, we needed to be on the iPhone. After a two-week epic struggle back and forth, thankfully timed to perfection with WWDC, where Apple preferably didn't want to look like the Goliath squashing a
developer, tiny developer, we ended up being allowed in, and Apple sort of rewrote the rules after the fact to make it fit. It was a small victory, not the ultimate victory, but at least it allowed us to be there. And HEY ended up being an enormous success. In part, ironically, because Apple gave us wall-to-wall coverage for two weeks.
When I look back upon that, I think I wouldn't have gambled like that, because the outcome would have been zero, right? Like, Apple refuses our app. We sign up 200 people and the app is dead. What instead happened was they gave us a multi-million dollar launch campaign and coverage in all major media, and we signed up tens of thousands of people in those first weeks. That was an insane event, but also very satisfying.
And the other satisfying thing was I just love HEY. I use it every day. I basically use Basecamp in terms of web applications. That's where we do all our collaborative work. And then my number two app, and many days it's my number one app, is HEY, because I just do all my stuff in email. I am constantly communicating with people. I'm writing. I'm doing a lot of stuff in email, as many people do. And having that be a pleasurable experience and a nice environment, and my inbox being a little more sacred than what happens with Gmail, where total strangers around the world can just make your pocket buzz if you have notifications turned on, which they are by default. Just seems insane to me, right? This idea that there's direct access to one of my most important daily priority lists, like anyone can put something on that, insane.
Anyway, HEY doesn't do that. We have the Screener, and no one gets to reach your inbox before you've said I want to hear from this person. And most of the time I say no to most people, right? Like, things end up in the Screener and we have thumbs up, I will hear from this person, thumbs down, I'll never hear from that person again.
This is how I reached out. I mean, I'm not sure we were connected on X, but I sent an email, cuz your email is out there, and your Screener seems to have worked, cuz it gave me the thumbs up.
It did, because the Screener is me. So, there's not even AI trying to suss out whether I want to hear from you or not. Because what turns out to be true is it's actually not that onerous to once a day go through your Screener and say thumbs up or down, because there aren't that many people in the world. And if you say no to the annoying, pestering salespeople who within Gmail managed to reach your inbox seven times, then the workload is much less.
And it's very satisfying, I will say, too, because when I was using Gmail, I would get roped into this sales tactic that they of course rely on, which is that you write back and say like, "No, thank you. I'm not interested." And then they would respond again. And now you feel like, "Wait, am I now obligated to respond to this person? I kind of feel like I am." And occasionally I would end up writing, and even if I wouldn't write, they still have access to my inbox. So I would hear from them again next week. They have a whole drip campaign. They all [ __ ] do, right? That any outreach is seven
emails. It's not one email. It's seven emails. And if you show any sign of life, it's probably 52. That's just not how it works. And in HEY, I say thumbs down one time, never hear from that person again. It's actually amazing how quickly you can curate your garden from that weed. And then suddenly there's just beautiful flowers. Suddenly email is not a chore. So you want to go smell the roses. Suddenly the majority of things that end up in my email are things I want to read, from people I want to hear from.
And that was really the fundamental mission for us with HEY: can we make email lovable again? Email is so hated by so many people because the systems are so poor, because they're based on the original premise that email is just what universities use for scientists to talk to each other, and scientists have really good manners and will not pester you 52 times about some stupid app they want to sell you. No, they're respectful and beautiful, right? Beautiful ideal, beautiful thought, beautiful protocol designed for those norms and those people. Then you let it into the world at large and you realize, ah, not everyone is endowed with such norms and such politeness, and especially when salespeople get involved, you need better defenses. And for me and for us and for all our many customers, HEY is that defense. It is a way to love email again.
And I find that it's really important actually to have a grand why. This is all the way back to Viktor Frankl, the meaning of man: finding a why allows you to walk through the snow when it's cold and uncomfortable and annoying, which many things are when you're building with computers. They are cold and uncomfortable and annoying. Now, it shouldn't be that most of the time, but occasionally that will be there. And if you have a really strong why, why are we building this? Who is it for? What are we trying to do to improve the world? Even if that's not more grand than just letting people love email, it's a lot easier and it's a lot more enjoyable to then carry whatever burdens you got to pack if you can set it up that way.
This is a good time to talk about our season sponsor, WorkOS. Having a strong why is what gets you to building something great. But after you build it and start selling it to enterprise customers, they expect things like SAML, SSO, directory sync, audit logs, and fine-grained permissions. And those are not small features. They're systems. Systems that can take months to build and maintain. WorkOS gives you APIs, enterprise-ready auth, and user management in days instead of months. All designed to fit cleanly into your product. That's why companies like OpenAI and Anthropic and Cursor run on WorkOS. Focus on building your product. Let WorkOS handle the enterprise infrastructure. With this, let's get back to David and the old way of thinking versus the new way of thinking.
Putting your developer hat on, can you talk me through how you built it? You said it was two years, but was it just one or two people starting to build it? I'm sure as tech you obviously must have used Ruby on Rails a lot, and then probably some native stuff as well, but the two years seems a lot, especially because, you know, you're a small company. You're nimble. You're a great developer. You hire great developers. Suddenly it's been two years. What took so long? And of course it's a beautiful product. But right on the surface, I think as developers we might have this thing where I look at it as like two years with a talented team.
That's the Hacker News quip to basically everything, right? Like, I could have built that in a weekend. I mean, famously stated with Dropbox that I could have built that in a weekend. We could have at the original iPod when it launched. It was like 5 GB, no Wi-Fi, whatever, less space than a Nomad, lame. So I get that because I also have that same instinct. I think that is our hubris as developers. We think we are gods and we can make anything happen in no time at all. And you totally could. You can make a prototype happen these days faster than a weekend, right? Like in a few hours we should be able to have
Kick off an agent. Yeah.
But figuring out what you actually want to build takes a lot longer, and arriving at something that's worth publishing takes longer still. At least it does for us, and I think it does for anyone who arrives at anything good. And the original HEY construction was just me on the technical side. This is actually how we've started the majority of our major products: either it's just me, sometimes it's one additional developer, but it's a tiny, tiny team until we have a shape, until we have an architecture and we have a direction of where the product is going to go. I've found that you actually go slower if you pour a bunch of people into a direction that is uncertain. If you don't know what you want, a million people is not going to build it for you. You have to figure out what you want. We can talk about this later, but this is where AI's very recent progress is changing things dramatically. It is now quicker to arrive at what do I want.
But for HEY, it was me and then it was Jason and one designer, two designers, very, very small team trying to figure out the shape, trying to figure out, if you're taking on Gmail, you can't just do Gmail in blue. No one's going to buy that. No one's going to be interested in that. It's got to be novel, which means it's, well, not just novel, it's got to be good. It's got to solve problems that people haven't even articulated they have with Gmail, because the articulation people have of their problems with Gmail is "I hate email," which as we talked about is a bit of a misdirection. My contention is you hate Gmail. And not just Gmail, but most email systems built on the old way of anyone has access to your inbox and all that stuff. But figuring that out, figuring the shape out takes a while, and it's also fun to do in this way where you noodle with it and you don't have infinite capacity.
The original Basecamp was built the same way. It was just me on the technical side. Is this a Shape Up ideology? There's Shape Up thinking in trying to actually endow the designer with an intention of how should it work, not just how should it look. And figuring out how it should look too; products should be beautiful and they should be unique and appealing and so forth. So that also takes time. But figuring out how it should work is primary. Figuring out where's the epicenter, what's the most important part, and teasing all that apart. But with HEY, as with all the major products we've done, we start with an absolutely tiny team, often just one individual on the programming side and then one or two individuals on the design side. And then we go, we go, we go, we go. Suddenly something clicks and we go like, this is good. There's something here. And then there's a bit of a ramp. We take on a few more people, and then when we get within maybe the last 20%, we go, okay, now we know what the terrain looks like, we can go way faster if everyone piles in.
So one thing that is super interesting, and you might take it for granted, but it's very different to how most startups that raise VC money, which I'm very familiar with, and big companies, Uber, Facebook, you name it, the way projects would start there is you take the product manager
who works with maybe half a designer
and comes up with a spec, and then developers get involved later. And what I'm hearing, what is very novel to me, is you take one or two designers and a developer. How you think about designers, even, you recently hired a designer, Zultan actually, who I'm chatting with on the side. A great guy.
But my sense is you think of designers a little bit differently than potentially the rest of the industry does.
We very much do. Designers at 37signals are not just here to make a spec look pretty. They're here to find what the spec should be. They're product managers in many ways. They are the finders of the how and the why, in many cases deducing, in some cases, customer feedback, in other cases just pure intuition, and distilling that into what should we build and how should it work. And then on top of that, they're also responsible for building it. They're responsible for doing the CSS, they're responsible for doing the HTML, they're quite often responsible for at least dabbling in the JavaScript and the Ruby code to get to something functional. Now with agent acceleration, they do the whole thing, not necessarily as it will be merged, but the whole thing in terms of here's the final shape and design of what it should look like.
But I do think we are very peculiar in this sense. And we have found this when we've been trying to hire designers, that many designers working at other companies are not used to also wearing the product manager hat, figuring out what we should build, and wearing the implementation hat, shaping it into CSS and HTML. I found that when you combine these three hats into one, you have an individual who knows the materials they're working with, knows how they stretch, knows which way the seam is supposed to be cut, and therefore works natively with the fabric of the internet. When you're working directly in CSS, when you're working directly in HTML, you're just much more in tune with what this medium wants. And I find that that's probably quite similar if you're a jewelry designer. You should know the properties of gold. You should know how it bends and the strength. An architect should have some engineering understanding of load-bearing structures and so on. Not to the degree that the architect is just going to design the whole thing and then we start pouring concrete. You still have engineers helping you out, but the more you understand the materials you're working with, the more you're likely to come up with something that cuts along the grain and therefore ends up feeling correct, feeling good.
Just a quick hop to Apple. I think this is one of the reasons why some of the historic super fans like Daring Fireball and others, Gruber, have been disappointed by the new direction, is that Apple used to stand for these exquisitely designed native Mac applications, which is a dying breed. Like, they're essentially dead. Now we have Electron, which we can talk about that too, gets way too much hate in my book. There's crappy implementations of that, but it's just a web in a box. But the disappointment with losing that sense, and I think it's about the same thing, that the Mac, its native feel has a stretch to it. Like the button placements, everything you would call a native application either feels synthetic or it feels authentic. And today, it's all synthetic. There's nothing authentic about it left. And I think for the web it's the same thing. Now, the web is a much, much larger platform and therefore it's gotten much more attention. So there are way more people working on that quality of it. But at the large companies it's exceptionally rare to non-existent to have that kind of dynamic.
I think some of that is going to change. Agent acceleration is going to empower designers to be more capable in these ways. So the industry is coming a little towards our fundamental stance, which is funny too, because the same is true on the programming side. When I talked about Basecamp being a product of just me on the programming side for launch, that for so long sounded unambitious or even wrong or even to the point of lying, from some quarters of the internet, like, yeah, but you can't build anything real, anything meaningful, anything big, unless you have a team that's much larger, because it's just going to be a toy product, right? And my insight from the start was that's of course [ __ ] because you just haven't used Ruby on Rails. You just haven't used the acceleration that's possible if you use better tools. Now we're all realizing, oh, so if you use agent acceleration, a single individual actually can build something highly valuable team.
Yes.
And that's just fun to see, that the industry is coming towards, oh, smaller teams are better, because now the cost savings you have on the logarithmic curve on communication cost starts to be relevant. And this is one of the things, maybe we can talk about this, where agent acceleration is really changing the bargain between junior developers and senior developers.
Let's talk about this. But before we go into that, I feel that you very much value software engineering as a craft, which is very obvious, but what I'm sensing is you're valuing design, user experience design, design on software, like, you know, building stuff that feels good. May that be software, hardware, you also value that as a craft, and you look for these two things. Do I sense this correctly?
Hugely. I mean, I think aesthetics is truth. When something is beautiful, it's likely to be correct. I think this is true in mathematics. This is true in physics. This is true in a lot of different domains, that when you arrive at something that has the correct aesthetic quality, it's like we have an intuition that guides us towards that level of beauty because it also happens to be correct and noble and something to aspire to. I also happen to believe it's what makes people happy. Being surrounded by beautiful, well-functioning objects is a key part of happiness.
In fact, I'll put it in a negative way, too. One of the great sources of anxiety and frustration is when everything is [ __ ]. When everything is laggy, when that touch interface doesn't register, when you have to restart it, when you're calling a travel agent and they can't do something because their old shitty COBOL system won't let them, right? The world is full of not just enshittification, that is, things that went from being good to being bad, but just plain bad, just plain awful. And I think it is a serious source of malaise for civilization, that we could literally raise the bar of human happiness if we were surrounded by more beautiful items, more beautiful systems. Both in the sense of their aesthetic exterior qualities, but just as much in terms of their aesthetic interior qualities, because I find those two things are usually in perfect harmony. The reason why Steve Jobs cared about the inside of the box was because he intuitively knew that the kind of people who care about the layout of the print board will be the kind of people who sweat the details on the user interface, will be the kind of people who sweat the ergonomics of opening the case.
So I think there's essentially no choice, if you are a person who is attracted to these aesthetics, which I think is everyone, there's just varying levels of awareness about whether you are or not, but that you want to make it all beautiful. And for me, Ruby in particular has been this seminal language because it produces the most beautiful code in my book. There's barely even competition. Like, there are other things that can be beautiful in a way. Like, I find looking at Smalltalk, for example, very beautiful in its minimalism, but not the house I want to live in. Ruby is the house I want to live in because it's got that aesthetic quality while not being rigid about its ideology, which is a very rare aspect too. I more often find, now we can refer to Ive again, is that when someone is obsessed in this way, they are a little narrow-minded. Like, that's the trade-off, that's the price. And I find that Ruby has somehow managed to be both broad-scoped yet also intensely focused on this. But overall, we have to have beautiful things. We have to work with beautiful tools. We have to produce beautiful, fluid interactions. This is how we should see ourselves, as craftspeople, that we care about polishing it until there are no splinters left.
How is AI changing how you work, and how do you think it's changing your craft? Or let's just talk about the craft. Again, you're hiring people at 37signals who similarly care about design and software craft quality. How is it changing what you get out of the craft, or how is it making it better or worse in some ways? I just want to, you know, start with how has your view changed, because the last time you talked at length about this, that was on Lex Fridman's
...cast and you were still, rightfully so, very skeptical of AI. It was a different set of tools. It didn't work as well and I think you went there bashing it pretty hard, but things have changed since.
This is a nuance point and maybe it's self-serving, but I don't actually think my opinions have changed. What have changed is the circumstances and the facts, which is something I called out on that show and in many other writings. Right from the get-go I could see that we had something new and novel here that was going to change things. ChatGPT, its launch, what, three years ago, was clearly and obviously, even at the time, something you would mark on a timeline. You're like, here are all the important things that happened in the history of computer science or the world. Yoinks, there is the launch of ChatGPT, and interacting with computers in this way and seeing them reason, even if that's still a disputed term perhaps. But to me it seemed obvious that these things were freaking smart, smarter than me in many ways, whether those smarts came from parenting or weights and data.
So what? We don't know how human consciousness works. We don't know how human wisdom or intelligence works, barely. So, let's not be so categorical about what constitutes consciousness or intelligence. At least, I find no utility in that distinction, even if it's fun to ponder. But what I found with the early models and the early ergonomics, where it was autocomplete, where it was Copilot and Cursor in your editor trying to guess the next character,
It would be sometimes littering it. Right.
Yes. I found it infuriating. I found it as, we're trying to have a conversation. You won't let me finish a sentence. You're constantly trying, was this what you meant? Was this what you meant? You're like, shut the hell up. Can I just finish a thought? And I thought, even if it is capable of occasionally accelerating, it's also wrong so often that that acceleration feels like a nuisance, even if it's somehow net positive, which it wasn't for me. Or maybe I gave up too soon. But I just did not enjoy that. I didn't think the models were good enough. I thought the way of using the models with autocomplete versus agent harnesses was just dreadful, annoying. In fact, to the point that I got a little pessimistic about the direction of the industry for a hot second, because I thought this was what we were all going to do. We're all going to sit and do tap tap tap. No, thank you.
Well, Cursor even had, I even got one of these, one of their swags was a tap key.
Exactly.
Which felt very, and I got it from them. It's really cool, very well designed and all that, beautiful design, but
But dystopian.
Dystopian.
When I see that, and I remember that was a meme for a while, we only need three characters on the keyboard, right? I thought of that episode of The Simpsons where Homer puts a mechanical bird on the keyboard that just dips down and hits enter, because all he's been doing is hit enter. Except suddenly there's a warning about the nuclear core overloading, and the bird just hits enter and the whole thing burns down. I'm like, "Wow, that's quite a parallel." The Simpsons really does predict everything.
But I did not like that style of using it, as much as I retained my enthusiasm for the general direction of travel, because it truly is amazing. And the amazement, to me, I tried to embrace as a tutor model, as a pair programmer who doesn't drive. It was amazing to have ChatGPT and the other models just be there for, like, I don't understand this fully, here's a piece of code, here's a question, can you tell me why it works like that? Can you tell me what's wrong with it? Because that's how I've been using the internet since day one, right? That's what Google was for. Here's an error message. Here's a concept. Maybe I find something on Stack Overflow with some passive-aggressive nerd telling everyone why he's so smart, and then at the bottom there's the solution I'm looking for. Or I don't find it at all and that's just kind of frustrating. With the ChatGPT model, I very often got a really good explanation.
Yeah, this was actually, I talked with a game developer, Jonas Tyroller, who built this really cool bestselling game. I loved playing it. And this was during this time of the tab completion, and he said that the way he works is he just turned off all autocompletions in his IDE because he got annoyed by it, and then every now and then he went to ChatGPT to ask something or have a longer thing. And then he had the mode of, like, I'm thinking and I'm doing this stuff, oh, I need some help, okay, here's the specifics, and I'm taking it. And somehow it felt that, you know, he was in the zone the whole day by controlling it. And somehow those habits, it sounds like, you know, you're saying the same thing. It kind of took it away from you. Us.
Exactly. And I did get a little worried that that was going to be the direction, that we were all going to be the bird, and I didn't want to be the bird. Then I was like, well, what should I do instead? Maybe like farming potatoes. Like, that's a long tradition here in Denmark. Maybe I could take that up.
But then thankfully two things happened. A, Claude Code, in what is that, starts in the spring, gets going sort of over the summer, then by the fall has some traction on a new way of using agents to help you code with the agent harnesses, right? This is really where we transition from AI to agents. Suddenly the AI has tools. It can use bash. It can use everything you got on your terminal. It can call the internet for appropriate information. It just is capable of doing more than just reasoning about a thing you gave it or input from a source context file.
And then the models. Opus 4.5 to me is one of the other points we're going to have on the line, where it's the first model that continuously and consistently would shock me with the quality of its output, the quality of its analysis on the basis of vague inputs, and even more importantly the quality of its output. It produced code I wanted to merge without very much, if any, alteration. And if I did want to do alteration, I could tell it and it would remember and it would not make the same mistake next time. That, to me, the combination of those two things was the unlock.
And you have a high bar, like you have a really high bar.
Incredibly high bar. As we've talked about now at length, the aesthetics of the output really matters if I'm going to look at it and I'm going to review it. I'm going to give you another anecdote in a second where those things don't even play in. But when I'm using agents to work on Ruby code, I want their code to look as good as mine. I'm not going to merge their stuff if it's sloppy, no more than I would merge the work of a junior developer who has not yet fully internalized our style and so forth. So I wanted it to be on par and on parity, and the early models just couldn't. That didn't mean they couldn't produce working software. At least some of the time they could. It's very impressive. I mean, I remember when I did my first snake game and I'm like, holy smokes. I've been wanting to do this since I was 6 years old. I have this idea, I want to get it into a game, and I was able to see that in, I don't know, 30 seconds. It was done with the game. Copy-paste the HTML, magical experience, right?
So, I think that ramp was very interesting, because it actually took a while until we found this form factor of the agent harness, of the terminal interface. That to me was the big unlock, from "this is interesting, I want to have a conversation with it" to "I want it to write my code." I will now start any project I'm starting agent first, and that's a massive shift, and it just happened from November 27th, I believe, is when Opus 4.5 dropped. Now, there are other people who have different points they felt like, oh, it's Opus 4.0 or
Maybe some people talk about Sonnet 3.7. There are other earlier checkpoints, but I do feel like there's a general consensus I can lean up against, that Karpathy and others have expressed, like, yep, it was right around end of November, early December.
Everyone who worked at larger tech companies, it was the winter break, because the whole industry shuts down for 2 weeks, save for a few places where you're on call, but again no production work happens across the industry, to play with this.
My sense was that people were playing with it because you give it your side project you never finish, expecting not to finish, and then they also got shocked.
Yeah.
You're done. And that was just a complete sort of break, right? Like, if this was a movie, you'd hear the scratch sound, like, "Wait, what? Rewind, what happened?"
I feel it was the most collective shock, which happened individually, and then people came back in January. And especially because a lot of the decision makers, who are, you know, CTOs, engineers, etc., were not as hands-on, but they were hands-on, and a lot of them, it's this weird thing where they came back and they started to mandate or say, all right, you guys need to use this because I've seen the future. I've literally used it, you need to see it. So we're going back a little bit to hardware, like people were trying to give the new hardware into people's hands, saying you need to experience it because you're not going to believe it, right? There's something with this as well where you really don't believe it. We can talk about this, and whoever's not tried it or not had that aha moment, I don't think we can convince them.
This is another one of those cases where words just are not effective. You need to sit down in front of OpenCode or whatever harness that you use, use one of the frontier models, start with that. Start with Opus. I'd say start with Opus. It's the best frontier model. Other models are better at other things, blah blah. But if you're just going to work on a piece of code and you want to see what the current frontier is, and, I mean, I'd be shocked if any of your listeners haven't done it already, but if there should be some left, now is the time.
And I don't even want to say it in the sense, I found it really off-putting, this trend on X where unless you've internalized everything there is about AI, you've been left behind. Shut up. First of all, patently not true. You could literally pick up everything in the next three weeks. This is the other magical thing about this kind of progress, right? If we had been having this conversation in spring of last year, everyone would have been like, MCPs, MCPs, MCPs. And do you know what? You can now manage to just have jumped over that entire thing and go straight to CLI and skills. That's just worth having in mind, that this FOMO, that unless you're up on all of it as it happens play by play you're left behind, is complete and utter nonsense.
That being said, I can still appreciate that some people were early. And for me, Tobi Lütke at Shopify is the main individual who saw this and saw the changes that were coming from it way earlier than I did, and has really helped drag me into this by constantly sending me, like, "Hey, look at this, look at this." And I do think that's actually quite helpful. It's quite helpful to be surrounded by people who have a higher faith, or maybe their eyes are a little further up. Like, my eyes tend to be relatively close to the road, right in front of me, and some people have a gaze that's a little higher up, and sometimes they see things that don't come to pass. In this case, Tobi saw exactly where we were going two years ago.
And I finally saw it because the road came to me in December. And it's funny, because along the way I kept saying, like, "Yep, when the models get good enough, when they can do all this thing, it's going to be amazing," and thinking, wow, it's going to be, I don't know, 18 months, two years, maybe it's five years. It's very hard to predict these inflection points, and I think the industry itself didn't even predict the inflection point, right? You have an entire city, Silicon Valley and surrounding areas, San Fran, focused on making this happen, but predicting exactly when the hockey stick starts hockeying is very difficult. But then it happened, and now my daily work is very different.
So what is your daily work now?
My daily work is agent first on everything.
Going agent first is a good time to mention our season sponsor, Sonar. When shifting to agent-first work, one thing that inherently comes up is the quality of the code. Sonar, the makers of SonarQube, is deeply rooted in the core belief that code quality and code security are inherently linked. High-quality code is naturally more resilient, and as agents start writing code at a massive scale, that verification layer becomes your most important security perimeter. This is where solutions like SonarQube Advanced Security are valuable. With its new malicious package detection, Advanced Security provides a real-time circuit breaker, automatically stopping agents from pulling in unverified or risky third-party libraries before they ever hit your pipeline. The impact is measurable, too. Developers who verify their code with Sonar are 44% less likely to report experiencing outages due to AI, as per Sonar's State of Code Developer Survey 2026 report. It's really about closing the gap between the speed of AI and the reality of production security. What else is Sonar doing to help reduce outages, improve security, and lower risk associated with AI and agentic coding? Head to sonarsource.com/pragmatic to find out. With this, let's get back to David's agent-first workflow.
So, specifically Claude Code?
I use OpenCode.
You use OpenCode.
That's my main harness. I also use Claude Code a little bit. They unfortunately got that early lead. Opus is currently the best model. So then they started thinking a little bit like the game is a single match instead of thinking it's multiple rounds, and yanked their subscription from OpenCode. So if you want to use your Max subscription, you kind of have to use their harness, which I don't love. I think it's a mistake. But leave that be for a second and let's just celebrate the fact that they have the best model, and Opus 4.6 is also nice, but 4.5 to me was the inflection point.
And it creates a lot of competition, because everyone wants to catch up and overtake them now.
Of course, and especially because you see Anthropic's revenues. I think start of the year they're at 9 billion, a few weeks later they're at, like, whatever, 14, now they're at 19 or something. It's just the craziest rocket ship you could possibly imagine, which is inspiring all this capital to be deployed for competitors and so forth, which is wonderful, great to see. So even if I don't love everything that they do, and Claude Code is not my preferred harness, manage to hold two things in your head at the same time. This is what I also try to do even with Apple, which I have serious grievances about, how they operate and act as the gatekeeper and all the other nonsense we've talked about, and then I also keep my "I just love computers" hat on and go, I like the new Neo, I might even buy a new Neo and just see what is possible at $500. For Opus, I have no qualms about using Opus. In fact, whenever I feel like this is a really hard problem, I go to Opus right now, but I also use other models.
And one of the things I've incorporated into my flow is to kind of have two models going at the same time at different speeds. So, I use tmux, and I have this layout thing that's built into Omarchy where it'll start my Neovim editor on the left side, and then it'll start two panes on the right side. On the top is OpenCode running Kimi K2.5, and on the bottom is Opus running in Claude Code, and then at the very bottom I have a strip of terminal. And almost everything I start in one of the agents, and I tell them what I want. Then I hop over to Neovim. First I do space gg to look at the lazygit diff on it. Once this is changing, if it looks correct, I'll just commit. We're done. Great. And then sometimes it doesn't. It'll correct and I'll go
in and alter the code myself. But the ratio and how quickly the ratio changes is still astounding. I went from early November last year, I'm code first everything. I started the editor, I'll spend whatever long it is and then at some point if I get stuck or if I want a second opinion, I'll go ask my friendly clanker to give me a second opinion. That's just not how it is anymore. Now I start with the agent. Now he'll give me the draft. I'll review the draft and I'll make alterations if need be.
And then just recently I flipped it even further. So we're working on a CLI for Basecamp so we can get full agent accessibility for Basecamp. It's astounding. First, actually, let me rewind. As soon as I got pilled on how good the agents were and how capable they were, I immediately tried to raise my gaze up towards the end of the road and think, do we even need MCP? Do we even need CLI? Do we even need anything? Can't the agent just figure it all out?
This was when I installed OpenClaw. So, I installed OpenClaw on a VM and I thought, what should I do here? Let's see how far we can push it and what it can do by itself. So I thought I want this claw in Basecamp. I want this claw in Fizzy. Let me just try to invite it as if it was a human. So I just wrote it: Can you sign up for Fizzy? I'm not giving you any tools. I'm not giving you any MCP. I'm not giving you CLI. I'm just telling you it's at fizzy.do. Go sign up. And you see it chug along. And then, yeah, I've signed up, but it's asking for an email address, or I'm trying to sign up, it's asking for an email address. I'm like, oh yeah, right. You need an email address. An agent doesn't have an email address. Hey, go sign up for hey.com. I'm like, it's going to fail this one. And it's chug, chug, chug. I've signed up for Hey.com. Here's the password. Write it down somewhere safe. I'm now also signed up for Fizzy. I got the confirmation email in my inbox. We're all good. What do you want me to do? I'm like, what? Are you telling me that you could one-shot signing up through a browser to these things?
Now, maybe that shouldn't be surprising. Maybe that was already possible with Sonnet 3 or one of the early models. I don't know. But when you experience it yourself on your own damn claw that you're just telling over Telegram to do something and it's signing up for products autonomously, that's pretty startling. It was for me.
And then the next step I went like, well, if it can sign up for Hey, and can sign up for Fizzy, let me invite it to Basecamp. So, I send it an invitation to its own email address. Here's the invitation link to Basecamp. Can you just jump into the AI labs project that we have and introduce yourself to the team? Go, "Hey, I'm David's assistant. It's very nice to meet you all. I've read back the transcript a little bit. I see you're all excited about these things." And you just go again, "What? What?"
And that was fun because it showed me that even if it was going to take a while, it did take a while. It took a while. This is agent terms. It took, I don't know, seven minutes. That was like, "Oh, it feels like eternity." But it was able to do it. And that seems like the end state. The end state is that agents will not need any of our accommodations. They do not need any on-ramp. They're not coming on a little wheelchair. They'll be coming on bionic legs and running five times as fast as you in about 2 seconds, which we'll get to in a second, to the speed aspect of it.
But then you also realize, okay, well, I can't just sit around twiddling my thumbs until AGI happens. Let's build for today. And that's what we've been building for Basecamp. We've been building CLI. We're going to build it for Hey, we're going to build it for Fizzy. We're going to build for everything, even probably some of the legacy products. And what I love about the CLI, as much as I also love it about these harnesses, is that they validated the fundamental Unix philosophy from like whatever '71. You should just build small tools that can interoperate with pipes and you can
That's philosophy, right?
It's the total Unix philosophy. And that is actually the magic to me about seeing everything having a CLI. It's not that Basecamp is easier to use now with a CLI. No, no, it's that GitHub also has a CLI and Sentry, I don't know if they have a CLI, but they have an MCP, that you can tie all these things together and now you can tell an agent, hey, we have some errors in Sentry. Can you go check them out? Then post a write-up to Basecamp iterating what's wrong. Then go in GitHub, come up with a pull request, post a comment back to Basecamp when you're done. And now we have a central, right, Basecamp where we're following the work as it's going on while we have an agent doing work looking things up.
And again, when we try to talk about it and relay it, I guess some people can see it. And now OpenClaw has enough videos on YouTube and so forth so you can get at least a passenger ride. But try it yourself with your own product, with your own tasks and with your own prompts and you will be pilled. You will be simultaneously incredibly excited for what we've been able to make sand do. The silicon, the chips, the weights, the whole thing. And then also a little bit anxious about where it's all going to go. And it's in that tension that I and probably anyone else who's been pilled on this live, right? Wait a minute. If we're already here, what does 18 months from now look like? Like if in the last 3 months we've upended my entire understanding of what's possible with computers, what's the next 3 months look like? What do the next nine months look like?
Yeah. This is where like I was a little bit on your end for a long time and I think I still am, where I believe what works and I'm always skeptical of projections. Moore's law broke down at some point. I lived through everyone said it will continue forever and you know and then it broke as we all suspected it would.
But then it found another way. I think it's the good point about Moore's law, right? It broke for individual cores. Yes. How much can you push that? And then we just went, well, what if you just had, what's the latest chip? 256 on the AMD 10 chips, right?
And even when performance broke, we went into power consumption and size and all of those things. So, yeah, like, but it's harder for me to also just say, oh, it's going to stop here because we've seen it grow. We know the approaches that they're taking, these larger and larger training sets, and it's been working so far. And there's also the bitter lesson, which I think is, it's such a short paper that it's just so worth reading. I think it's probably one of the most popular papers outside of academic circles.
Yes.
Because it just lays out this thing that we don't want to believe. We want to believe that our knowledge, our understanding is superior, that you know, you and me knowing how to code, or me putting in these 15 years or however long it's been, it's special. Sometimes it shows that it's not as special.
What's interesting actually is like right this second, this snapshot in time, it a little bit is, and this is a funny bifurcation that's happening, junior versus senior developer, is that the most successful and applicable agent acceleration that I've seen at 37signals has been from the most senior people, the people who are able to validate whether what the agent produces is suitable to be deployed to millions of people. There was just this story yesterday about some of the major outages at Amazon.
Yeah.
And Amazon's own internal analysis essentially pinned that we can no longer let junior programmers ship agent-generated code to production without review. And the problem with that is, first of all, I think that's the realization most companies are now having across the industry. Whenever it's mission critical for something of that nature, we cannot yet rely on the agents to vet it at all, and junior programmers are not capable of figuring it out. Therefore, their role is suddenly more tenuous than it was 6, 9 months ago because a senior programmer can, and this is why senior programmers are getting so much more acceleration. They're able to, first of all, work in parallel with lots of agents, but critically examine the quality of the agent output and have a high degree of confidence of whether this is going to work or not and redirect them if not, because this is what made them senior in the first place. This was the role that they had, that they had the long insight and history and overview of the architecture. How does it all fit in? Is this going to work? Is this not going to work? This was the role they played to junior programmers. But now they can play that role to agents, and agents are faster at following instructions and redirections. And suddenly you have senior developers who can 5x, 10x their individual productivity.
And now this is the second order effect. If you manage to 5x or 10x a senior developer, that person's value per hour just went up 10x. Now take that hour, instead of that person spending it with the agents just shipping stuff and making things better, they spend that hour as they would before teaching a junior human how to do things better. There's something in that equation that's in play right now and it's not clear how it's going to map out.
Now one way it could map out is that the agents will get so good that they stop making mistakes. They become senior in their capacity to ship working code. This is what my bet would be if we look x amount of time forward, because this is what just happened with cars. So self-driving Teslas now drive better than humans do. Not all humans, not in all circumstances, but on average. It's very possible that if we're able to delegate the mortal risk, the highest criticality we basically deal with on a daily basis, sitting in a metal tube along other metal tubes that go 60 miles an hour where you can die if someone makes a mistake, we delegate that to an agent. Well, they can probably figure out how to make the code work too, right? So, I do think it's coming, but who knows when, who knows how. Right now, we're at a stage where the bulk of the benefits are accruing to the most senior developers.
And also I wonder, just like with self-driving, like you realize there's always caveats. So, for example, inside companies where it matters. When you're a startup, you have zero customers. It doesn't matter. You can one-shot it and it doesn't matter if it doesn't work and, you know, it crashes. But inside these companies, at Uber, I just got details on how they're adopting AI and they have all these tools, Claude Code and all these things. But what they realized as well, when you just put it in there, they have all these internal monorepos. They have their ticketing systems. They have their Slack. They have so much. They have their RFCs, design documents on how and why they have this jumble of a mess with microservices, which was a fun way that we originally connected many, many years ago. But what they found is they built a bunch of internal systems, a lot of it to help feed in these agent harnesses, and now they're working better. But you know, where we are right now is, and this is why if you're a senior engineer in one of these companies or a staff engineer at like Uber and you move to Google, suddenly you're not going to be as valuable, as efficient for a while until you learn all the systems. So I wonder if, just like with self-driving, you know, self-driving works great as well. I was in SF and LA and Waymos, they drive so nice. Like
My Tesla was driving in LA, driving us to the airport every time. The whole family. I sit peacefully, watch the road, but do not steer at all on that entire journey.
Well, except my Waymo got stuck because a truck was parking on a narrow street and a car had a bike shed, and I knew that I should not go there, but it didn't know. So, a human operator came in. But anyway, but even with Waymos, you know, there's things like, they drive in pretty good weather. They've been mapped out. So I wonder if in software engineering, I wonder if this has these parallels where we have all of, you know, like these companies have their specialized landscape, and once you map it, once you do all the tools, once you figure out these things. And with self-driving it took 10 years, right? Like I was at Uber when they bought the self-driving thing and we were hearing in the news that, you know, next year it's all going to be over for drivers and no
Yes, there are not going to be steering wheels anymore, which by the way is an amazing anecdote because it just shows Elon's total faith in his mission, because in '17 when he made that proclamation, it wasn't AI. It was 500,000 lines of handcoded C++,
Right?
Like that model was never ever going to get us to full self-driving. But he had just total faith in the vision. And then eventually, hey, here comes along AI and it's so good. And if you train it on billions of hours of road use, it actually can do it. And it can do it better than most humans. In fact, I'm a pretty good driver, I'd like to say. I'm not the best chauffeur because my, I don't know, impatience has a tendency to provoke the throttle. That's not always as pleasant for passengers as it is fun for me. And when I let the Tesla autopilot drive, it's just the best chauffeur in the world. It's just perfectly
Better than you.
Better than me, better than the queen's chauffeur, I think. Like its throttle actuation and deceleration is godlike. It's actually AGI-like, or ASI-like, in its application within that narrow domain.
And of course, when we get these anecdotes and these examples of holy smokes, no, it didn't take 10 years for the self... It took 10 years from the proclamation, but what they were doing for seven of those years had nothing to do with what they're doing with FSD now, because the FSD that's based on AI hadn't been running for that long. But the inflection point of, I think it was 13.1, FSD 13.1, like the first version, you're like, "Wow, this is pretty good, but like I better pay attention." 13.2, 14.0, 14.2, over the course of 18 months we went from, yeah, it's pretty good, but like I'm going to pay attention here, to why is there a steering wheel? And that acceleration, that short period of time, of course is something people look to when it comes to programming, go like, well, if we're here now and senior programmers still have to review it, because otherwise you're going to get all your whatever four severity eight downtimes at AWS because some AI pushed out some nonsense, what is it going to look like when they take the jump that FSD did over the same period of time? Now, I also think you can go completely crazy trying to just sit and soak in all of that. This is what I tried to do over the past year. Go, I'm really excited for where this is going, but I'm also going to deal with what's possible today and what's enjoyable today and what we do right now. I'm not going to try to plan what my life looks like 12 months from now when maybe we do have AGI or we don't. Now, there are other people who do that very well. I just watched an interview with Leopold on Dwarkesh from last year. He's thinking like, what does 2030 look like? What does the whatever 10 gigawatt data center look like? I'm like, I'm very glad we have individuals who put thought into that because that's not my favorite spot to be, and I think most people are not that good at polishing the crystal ball.
No. Well, I mean this is a little bit unsettling as a software engineer in the sense of, like, clearly this is where the industry wants to go. This is where a lot of effort will be put. There will be a lot of businesses, software businesses built on this. A lot of VC money raised on this, by the way, who are going to tackle this and they will either succeed or die. That's what these companies do. But today, what do you see at 37signals with software engineers? You of course have mostly experienced engineers, although you did hire junior engineers as well. How is their kind of work changing? How is their satisfaction with
with work change? Because that's also a thing, right? We keep arguing about is it making us more miserable at these things? Is it what we want to do? And how's it changing for you? Right.
I think it's, that's the biggest revelation actually, more than even the capacity of the agents, is my enjoyment running them. When I was on that Lex interview last summer, I was talking about, you know what, I don't want to be a project manager for agents, because I had the mental model of a project manager of humans and I thought that's not what I enjoy. I don't want to be that far away from the production. I want to be in the mix. I want to have my hands in the code.
What I failed to realize at the time was that running a bunch of agents feels less like being a project manager for agents and more like stepping into this super mech suit where suddenly I don't just have two arms. I have 12 and I can now look at seven screens at the same time running five keyboards. I'm still the one doing it even if I'm not typing this as a keyword in a program.
I have been hyper accelerated as a programmer. It's a different kind of programmer, but it still has the same affinity to aesthetics, at least when I'm producing Ruby code. And I'm able to combine that while being vastly more productive on a bunch of things. It's also like getting an incredible brain upgrade on even assessing issues.
One of the pilling moments I had was before the release of Omarchy 3.4. I went into GitHub and we had, I don't know, 250 PRs pending and I kind of just sighed a little bit, and like, 250 PRs, if I spend, I don't know, 15 minutes on each PR, how long is it going to take before I get to the end of it? And I thought, you know what, let me try something else. Let me just try to ask Claude to, I'm not even doing anything with a system, I just do review URL and the URL is the issue or is the PR, are shocked.
In 90 minutes, I think it was, I processed 100 PRs. And it wasn't that I merged all of them. In fact, I'd say I merged a small minority. Maybe 10% got merged as is. Then maybe 20% got merged, but with Claude's implementation. The programmer had correctly identified an issue but hand rolled some code that I could see I didn't want to keep, or sometimes I couldn't even see it. I just asked Claude and they say, ah, it's not quite right. And then I just asked Claude, can you just clean room this? This is the right problem. Let's fix it, but let's do it right. It would do it right away in exactly the style as I would have written the rest of Omarchy.
Now this isn't the high code of something. It's mostly just bash code, but there's still a shape to bash code and how you want it to look and can it feel coherent with the rest of project. Agents, Opus in this case, would just nail it.
And then the second half of it was split between 25% things I then just realized I just don't want this. We shouldn't have it. And 25% Claude telling me maybe there's something here, but it's really not a good implementation. We don't have a straight shot to making a great one. 100 issues in 90 minutes. And I sat back. This would have been a week's worth of work, days at the very least. What the heck?
And even more than that, Claude's analysis of at least half the issues pertained to things I knew nothing about, where it was undeniably a smarter, better reviewer, programmer than I could ever dream to be. Well, not dreamed to be, but wasn't that
moment? No, but you would have not put in the effort. This was why the PR sat in the first place. In many cases, I would look at it and go, I think there's something here, but then I now have to read up on this debug thing. I have to figure out is this the right way of doing it. I don't want to just merge something that then has other issues. And to be able to do that agent accelerated was one of top 20 programming moments.
I like how you put agent accelerated, and it sounds like it's especially efficient for work that is waiting on you but you don't want to do it, or you're not as skilled at doing it, but it's a hassle to delegate because, again, you have a team, right? But you probably didn't delegate it because you probably knew that it wouldn't make it faster or better. So I wonder if there's a part of AI that, because we talk a lot about, you know, companies love to measure, especially larger ones, efficiency, PRs, and they want to see impact, but about the impact of doing work that we would have not done before.
That's the kicker for me. That's the fact that the pie is just exploding right now. It's not growing. It's exploding. The number of projects we have tackled internally that we would never even have contemplated starting on are legion.
We had a great project where normally on performance work you worry about P50, P95, P99. Jeremy, one of our most agent accelerated people, went like, what about P1? What about the floor? Can we fix the floor? What is the floor? And he went like, well, right now our floor is, I forget what it was, 4 milliseconds. Let's say that, right? Well, actually 4 milliseconds can add up if you have a bunch of fast requests. It still matters. And he just went like, "We're gonna do P1. We're gonna optimize P1, literally the fastest 1% of requests. We're going to make them even faster." He took it from, I think it was four milliseconds, to less than half a millisecond. He 10x'd the performance, and I was like, I would never have signed up on this, and he did the P1 project over a couple of days as like a side gef because now he could.
Now he could because he had a hunch. He had an intuition that there was something here. He let agents run with it, and the number of PRs, like, all right, we fixed this, we fixed this. I think in total the P1 project, I maybe misremember, but I think it was like 12 PRs, just fixing all sorts of things, where I look at the single PRs, I'm like, yeah, actually, okay, yeah, makes sense. I look at the total sum of it, you've changed 2,500 lines of code. You're like, you've done that in a few days.
So I've never heard anyone do P1 because it just feels like a vanity experience. It makes no business sense. This is not true, right? Because everything adds up. But you know what I mean, right?
I know exactly what you mean. And this is exactly why the explosion of the pie suddenly lets us look at problems we would never have contemplated looking at before.
It's funny. I remember this scene from Terminator 2 where they found this chip from the Terminator in the first movie and he goes like, "This thing gave us ideas we would never have investigated before." And there's some beautiful parallels here about, maybe we're about to build the Terminator, the cliche, but also we're getting ideas, we're getting ambitions we would never have looked at before, because suddenly the cost of exploring a hunch has just dropped by a thousandfold.
I do this all the time now, too. I'll give it some vague crappy instructions just because I have this fleeting idea. I haven't even crystallized it into a neat prompt. I just want to see something. And then I go like, oh yeah, delete, as in revert code back to normal. Before, I would be a little more precious about 75 lines of code because it would have taken me two hours to do them. Now there's no residual value to any of this stuff and I can just go like, show me a draft.
I feel a little bit like a king where you just go like, show me the analysis of the far-flung regions. Where are we with the tax receipts? And this servant is like, "Yes, I shall do so and return in 3 weeks." Except you can just wave your hands around, and agents just come back with answers to stupid questions, terrible ideas. Then suddenly it wasn't so terrible. It was actually a great idea. And you go like, whoa.
I did this with, I haven't even pulled the trigger on it yet, but one of the things with Omarchy people have been asking for since the beginning is dual boot, being able to install Linux next to the Windows installation so that they can still play all their games. And I just went like, do you know what? I have more than one computer, so when I play games, I can just do it on the PC. It's not a me problem.
I totally get why a bunch of people want it. I'm not heavily inclined to spend four hours figuring it out. And I just, a little while ago, went like, oh, this is exactly the kind of problem, like, I don't have to figure it out. Just make the agents figure it out.
So I kicked off initially the process of just coming up with a plan. This is a pretty big change, right? If you [ __ ] up someone's boot records or you overwrite their partition, criticality high, which was one of the reasons I didn't want to engage with it. Secondly, it's a little finicky if you want LUKS encryption on the Linux partition, but the Linux partition doesn't own the whole drive. It's a little hairy. I didn't want to take on the criticality. I'm like, this is perfect for the kind of agent stuff.
So it started off basically just having Opus and Codex ping-pong a plan. I asked Opus first, come up with a plan for this. It thinks for minutes and minutes and comes up with a good plan, and then I kick it over to Codex, like, critique the plan, and then I had them ping-pong back and forth a couple times, and at the end, looking at the plan, going like, yep, that's a good plan, we should totally do that. And I can't wait to kick that one off and just go, yeah, now does dual boot, not because I did it, but thank you, your helpful clankers.
That level of ambition is still something I've yet to internalize. Even just that, like, hey, here are these hunches or demands, projects that I would like to do maybe someday, and you could kick it off on a hunch while you go to lunch. That is a new world.
Which is also one of the reasons I think a lot of people are thinking, well, the model continues to improve, but even if we somehow hit a wall tomorrow, the bitter lesson is no longer true. There's actually a limit. It's 19 trillion tokens. That's how much they can learn. Not true at all. But if it was and we had to be stuck with these models, we would spend the next decade just getting more and more out of them, learning how to use these tools.
You see this actually with vintage computers. The kind of games they were able to make on the Commodore 64 when that was released, back in '81 to '85, I think, was the main run. I know they made it a little longer, but then the Amiga and other machines came out. Were great games. I mean, I got interested in games on the Commodore 64, Yung Fu, and all that stuff. The stuff they were able to do 20 years later, when someone had just noodled all the secrets and tweaked the one MHz processor, when they're building games for the old, old, are so much more technically impressive because we just know so much more about the... I mean, same thing with the PlayStation. You look at the first games that come out on launch, and the last games before we go to PlayStation 2, they look like they're from different generations. We could totally continue to do that with the models, but we're not going to have that particular enjoyment because there's a new model dropping in 3 months.
But this is interesting, because if we just run with this thought, of course we know new things are going to come, but the point is we will be spending so much time learning, applying them, building either our internal systems, changing how we build things, taking on new projects. If you're an existing team, now that people can do more work and more ambitious work, how are you thinking of the team taking on more work, launching more products? Are you thinking of potentially growing the team or keeping it as is?
My best assessment for our setup is that the same people can do much more. Let's internalize that. But that's also enough. Already we were doing enough. Already we had margin that we could hire way more if we had enough good ideas for that.
So all this extra productivity we're getting out of the team allows us now to do things like P1 and these other projects that are awesome, and they're going to improve the product faster too. Of course they are. The old way of thinking, like it's going to take 2 months to deliver a major feature, I mean, that's out the door. Of course there's going to be rapid acceleration that's going to filter all the way into our software methodology process. Shape Up was built on two-month cycles. That doesn't make sense in the same way at all anymore. We have not fully rewritten those scripts yet because the acceleration is still so fast. No company really has rewritten the scripts on all that.
When you're shipping that much faster, you need a way to control what goes live and measure whether it's working. This is a good time to mention our presenting sponsor, Statsig. Experimentation and feature flags for teams that ship fast. Statsig built a unified platform that enables both experimentation and continuous shipping. Built-in experimentation means that every rollout automatically becomes a learning opportunity, with proper statistical analysis showing you exactly how features impact your metrics. Feature flags let you ship continuously with confidence. And because it's all in one platform with the same product data, teams across your organization can collaborate and make data-driven decisions. To learn more, head to statsig.com/pragmatic.
With this, let's get back to the shift about to hit developers.
But I still think software developers are delusional if they do not think a shift is coming, where before they were the constraint on how much could be produced and therefore could command the salaries that flow to the constraints. If suddenly those constraints now loosen, especially if we fast forward a little bit to where the product manager is actually able to produce changes that can be shipped and work, things are going to change.
I do actually think, if I was going to bet, we've seen peak programmer in terms of the learned guilt of programmers who went to either school or spent hours getting really good at it. We're not going to need the same number of them to do the same amount of work. Now, Jevons paradox, where as the price of something goes down, you get more of it or you get more demand for it, is true, but that doesn't mean that all programmers are going to get bailed out by it just because more software than ever is going to be produced. That's for sure.
By the way, I think GitHub has gotten a lot of slack, or flak, lately. A lot, justifiably so. I saw a chart saying they had a 92% uptime, which sounds insane. I'm not sure exactly what that was measuring, but I feel it. I have a little bit of sympathy in that. I also think there's some mistakes that were made, but also the amount of software that's currently being produced is on a rocket ship. We are producing as a civilization globally way more software than we've ever done before.
I mean, OpenClaw itself, I think he said it was 400,000 lines of code. That used to take 10 years and 2,000 people to get to that. Well, not 2,000, but yes, it took a long time. I mean, a long time, right? You look at, I think, the main monolith at Shopify is 3 million lines of code. That's 20 years. And if you collectively sum up all programmers who've worked on that, probably like 20,000 people. Yeah.
Big shifts are coming right now. Lots of software is being produced. I can see why it's creaking a little bit over there, because the pushes are just going to accelerate, right? And we haven't even seen anything yet.
If you look at AI adoption curves, basically no one's using it. We're all in our little bubble on X like, oh, everyone's... No, they're not. Most companies in the world are just not doing it. Notwithstanding that, I think ChatGPT got to 800 million users very quickly. Obviously, there's adoption, but nothing on the scale of what the companies that are furthest along are doing and how much they're accelerating with it.
So, I do think it is correct for the average programmer to think maybe we've seen the best of the golden days. Certainly there will be pressures on price because one thing are
companies like ours that have essentially unlimited scope to come up with new features and do more, and we can then plow in all that additional productivity into just do more. There's also a lot of companies who just need to do a thing, and if they can do that thing at a tenth of the cost, that's actually their advantage, right? They just need to do this thing. It's very neatly scoped and defined. It's a cost center. Anywhere where software development is a cost center, which is actually probably the majority of software development in the world, they're going to face these pressures.
Yeah. Sounds like if I'm a software engineer right now and I'm worried about, well, you know, I just want to make sure that I'm at a place where things are going to be better, you want to be at a place where you either get out of a cost center or become really valuable there. Obviously, you know, brush up your skills.
And also I'm wondering if the shape of software engineers who will be hired will be changing, because if I just look back from the '90s, right, even if you look at the movies, you saw the stereotypes: they were the nerd who didn't talk to anyone, but they knew how to code, they knew how to do assembly. And then we went into the 2000s, it was still based on languages, and over time, I think in the 2010s, startups started to not hire for languages but just hire for algorithms, because you could learn the stuff. And now I'm seeing some of the latest VC-funded companies hiring for product engineers, where they're actually asking for empathy, communication, on top of, like, it's kind of a given that you know how to code or whatever. So I wonder if I'm just looking at this curve, right? If I'm just painting it up, you're starting to get people... Oh, and the developers I meet at all these companies, they're all really pleasant. They're all just very communicative, and they talk with customers. For most of them it's not even a drag. It's like, and more and more of them love doing it.
That's the constraint value. Now the constraint value is figuring out what should we build, how should it be built, which customers should we be talking to, where should we be focusing. It's product management. It's so funny for me too, because historically I've not necessarily had the highest esteem for product management as a function. I thought there was a lot of [ __ ] and I thought it was a lot of people who maybe didn't do as much, right? And one of the reasons was that they couldn't, because the constraint resource was the implementation. The product manager could find out that they want to do something, I want to do this feature, and then they had to wait four weeks for some very expensive programmers to make that reality happen. And in those four weeks, I mean, I guess they could go talk to some... they were underutilized. They were not the constraint, right? The constraint was on the implementation. That absolutely is going to switch.
And now pure implementation is going to be solved at some point. I'm not claiming it is right now, and anyone who is has not tried to just deploy vibe-coded stuff with no review to major code bases. But as the lesson of last summer on Lex, I'm not going to put my head on the block and say that's not going to happen before next summer.
Again, this is just common sense, but implementation will be solved for a general use case. For the edge cases it will take longer, and for some cases it will not make sense. Same thing as, I know, self-driving is fine for these size of cars, but for trucks it'll either take longer, or if you're specialized you do. But the point is there will be pockets, but those pockets will be smaller.
Yes, I do think the stereotype of "I just want to sit and code"... You have to be John Carmack levels of good to retain that privilege to just, "I just want to sit and code."
And even John Carmack is also super AI-pilled and lead.
Well, but also he saw some trends that he could do, like for example, you know, the type of games that people would buy, right? He needed to have some business skills, or just be surrounded by people who did that.
Totally, totally, totally. But you need to literally be the very best. And not just the very best, but you need to be better than the agents, right? For you to get the privilege to just be an implementer, you have to be better than what's available off the shelf from agents.
So who are the very best? And you're a good person to ask, because whenever you advertise a position, and this was even well before AI, I remember that you put out a job for both software engineer and a designer. And actually I want to interview your designer who you hired. And because you published the salary, which is a San Francisco salary, you put the exact number, you can check it. You have a social media presence, so it kind of goes wide and you get a lot of applications, and you do a pretty good job, as I understand. You try to be very fair. You put a lot of effort into it. So what did it take to get hired at 37signals? Because now you are trying to hire some of the best, and based off of this, what advice do you give to people who are like, okay, I want to be the best in this age right now?
Incredibly good question. No one has figured out... we haven't cracked it. And I say that as someone who has run an organization where we must have looked at tens of thousands... now, of course, if you're running Google, you've looked at millions, but we've looked at tens of thousands of candidates. The number of candidates we've hired is quite small. I mean, the total number of programmers that's been through 37signals over its entire lifespan, what's that going to be, like, I don't know, 100, 150 at the most? I haven't even...
How big is your team right now?
We're 60 people at the entire company, and we are, what is that going to be, like 20 programmers, something like that. Yeah, that's probably about right.
Oh, so who are the other 40 folks?
We have designers, probably like 10 of those.
Wow.
And then we have customer support, which is at 14. Then we have a bunch of support functions, HR, finance, and then we have operations. Operations is quite large. We have 10 folks managing all our servers. And yeah, that's about it. But yeah, it's probably about 100 people in total that I've worked with or employed at the company as programmers.
Out of tens of thousands.
We've looked at. And even all those hires did not pan out in the long term. I'd actually say, I think I looked at this recently, our batting average at best, I think, is slightly better than 50/50. So half of even those hires...
You go through all of... because you have a really long and thorough process. You put in a lot of effort, right?
No one has figured out how to hire with such efficiency that they don't make mistakes. There's a great paper that Google published quite a long time ago now where they tried all sorts of different hypotheses. Well, can we predict employee outcomes on the basis of Ivy League education background, on GPA, on all of these things? And the conclusion was basically, we know nothing. We can't predict it on any of these things. We can't predict it on LeetCode. We can't predict it on any of these metrics.
What I'd say is I've clearly been spoiled by working with some very good people, not just at my company, but in open source in general.
Yeah. Oh, yeah.
And therefore, I've ended up with occasionally a twisted perspective of what the average programmer is capable of. And when we do hiring rounds, I am sometimes, well, not sometimes, I mean, every time, I'm kind of surprised how poor the majority of the submissions are, how little effort is put into being presentable. And that can sound really boomery very quickly, but it's also just the reality of trying to get a job. You've got to stand out. And I understand that that's uncomfortable, right? Who wants to look at this as, well, the odds are kind of against me? But it's also a trap to actually fall into thinking of this in terms of odds, because the miscalculation I've seen happen time and again is people go, okay, so you have a thousand applicants, there's only one who gets the job, or maybe two who get the job, so that's a 0.1% chance. No, it's not. Not at all. With that math, you had 0% chance.
Yes.
Zero. And the very... they probably had a 10% chance, 20%, 30% chance. It is not equally distributed. It is not a lottery. We don't just pick a thing out and be like, "Oh, it's going to be this person because they happen to be the one drawn from the bunch." Not at all. We discard off the bat probably at least half the applications, maybe it's two-thirds, just because they're either not addressing the job directly, they are not following the instructions in the relatively clearly spoken written openings that we have, right? They're obviously not right for it, or whatever, or we get some other smells. Then there's perhaps a third left, and then we start looking at some of the submissions. Then we narrow it down, historically, to a pool of around 20 people that we give an at-home test.
The at-home test is wonderful. Some people hate it. They feel like it's free labor. I'm like, what the [ __ ] are you talking about? I'm not going to use your submission to a code test. What? I'm going to deploy it to production? How do you think we came up with that code test? Because it already exists in the system. I say that a little harshly. I also get the sympathy of, I don't want to put six hours into making a test if it's not going to go anywhere. Okay, I get it. But there's no way around it, because if you have it in your head that you just send in a resume, someone's going to call you up on the phone, have a 30-minute conversation with you and go, you're hired, sir. I don't know if that ever existed, but it certainly does not exist today. It never existed in the lifetime I've been in this.
Well, the only time it exists, right, is through a very warm referral.
Correct.
Where you're starting a typing, if you're skipping the whole pipeline.
And when you skip the whole pipeline, it typically only happens at the very beginning of a company, when you're founding a company, and often it goes both ways, where it's very risky, and then you say, this buddy of mine, I worked with this person for two years straight, I would trust them with my eyes closed.
So that's actually the black pill on the whole hiring process. If we look at the long-term success rates, we have had more long-term employees from "I've worked with this person for 2 years, we should hire them" than we have from the open calls. It has actually been exceptionally difficult for us to find the kind of programmer who thrives in our environment from open call. It has happened. We have hired people that way, and I continue to want to believe, even if the odds seem insanely long when you start doing the math of, oh my god, we've looked at tens of thousands, and how many then got hired, and how many then didn't work out. Jesus, there's only a handful left from starting with that. That's kind of black-pilling. But then hiring directly on the basis of warm referral, as you call it, has worked very well, and the hit rate there is really high. But how does that help anyone, right? That's not very actionable advice, except to say: get as good as you can get and put in as much effort as you can and work with someone.
Because I want to say that as a counter. Some people have this notion in their head that if they work at a place they consider shitty, they shouldn't try. You're shooting your own feet, buddy. If you show up at the shitty place of work, and we can even be objectively in unison about that, that it is a shitty place of work, and you then go, "Well, I should just try to skirt. I should just try to goof off. I should just try to read X or Reddit all day," right? Everyone else you work with, they're going to watch that. You know where that warm referral is going to come from? It's going to come from someone who worked with someone else at a shitty job, but identified that that individual still showed up and did as best as they could to learn, to ship, to do all of this stuff. There is no shortcut here. You simply just have to be good. And you will not get good if you do not practice. And if you think your place of employment is not worthy of your best, you're cheating yourself.
If you're not helping, even if it's a shitty place, if you're not helping that place get better, why would a great place hire you, who only hires people to further raise the bar?
This is total cope. And it's cope on the side of, I work at a shitty place, so I don't want to put things in. You could be annoyed. I'm not telling you you have to love your boss. I'd actually say the majority of people I used to work for, I didn't have the warmest feelings about them. I still tried really hard for my own edification, for my own education, for my own sense of "I'm the kind of person who shows up and does a good job," just so that I will be ready when the opportunity arrives, when all my talents are needed and all my skills are honed.
Right. Well, was this not how you ended up at 37signals, where it was just a contract job or something? And you know, on a contract job you have no ownership, but you showed up and...
Correct. And Jason ended up realizing, okay, this punk had better get some equity, otherwise he's out the door. Now, that's a seminal story and you shouldn't extrapolate everything from that. I mean, all founder stories, by the way, are seminal stories in that regard. But the fundamental principle is still the same: show up, do as well as you can, learn more.
There also was, to my chagrin to some extent, and I perhaps contributed to it a bit for a while, this notion that you can be a great programmer and not really like programming. That you don't have to ever care about programming outside working hours.
Was this what you thought of, or...?
Well, I thought of it mistakenly, because I was pushing back on the overwork, 100-hour week, 120-hour week maniacal obsession, which, by the way, never was my experience. We did not start Basecamp that way. We have worked on a 40-hour week rolling average over those 25 years. But also, as I said at the very beginning, I really like computers. So I play with computers in my free time. I look at computer things in my free time. It's not work in the sense that I'm, whatever, shipping features to Basecamp customers 24/7. That's not what it is. But I am playing with computers. I am looking at new things. I am exploring new systems and whatever. And I think there was for a while in the 2010s a misconception that you didn't have to do any of those things. You could just show up and do your work and you would be so sought after, because programming was such a valuable activity and there were so few people who could do it that they'd take anyone, even people who barely gave a [ __ ]. And I think that's over, if it ever was true, and I think it was true.
The boot camps were the perfect catalyst, or they were the canary, when...
Which also, by the way, is how the economy is supposed to function. When salaries are really high, it means that there's not enough supply of labor. Therefore, we should get labor into the pool.
Exactly.
And so I don't even have any qualms about internet. I'm just saying that's over.
No, I think looking... you know, we're talking about, is it the golden age of the programmer? Have we passed peak programmer? And I wonder if peak programmer really meant that almost anyone who wanted to get into the industry and was willing to put in some effort, a few months or maybe a few years, could do it. You could learn how to code. You could go to either college or to a boot camp or put in the hours, and you could get hired at a place, because the interviews were... the references were not needed. We didn't check. And it's probably coming to an end. You do need references. I think more and more companies will be doing
reference checks as part of our thing, and it's not just going to be have you worked there, like would you... I've had these calls from, like, Databricks is famous for reference checks. They don't only check for references. They drill you: not just would you work with this person again, what were their weaknesses,
Right?
Where would you hire them, etc., etc. And
No, I understand it. The weird thing is peak programmer sounds like this is something that affects all programmers. It does not. The best programmers, not even the best as in like it's 10 people around the world, really good programmers are currently more valuable than ever because they're the ones who are able to get the most out of the AI acceleration.
And this was the kicker for me in changing my perspective on this, is that I've also found, and maybe it's not universally true, but certainly within 37signals in my own experience, I'm enjoying my time as a programmer more than any time since early 2000s when I just discovered Ruby. This has the I-just-discovered-Ruby feel to it, that it is so satisfying to be able to move this fast on so many levels at the same time, to be able to explore the P1s, to be able to think about dual booting Omarchy, to do all of that stuff, that the work itself has gotten vastly more enjoyable. And I've seen the same thing for the most AI-forward programmers that we have. Maybe they also have some of these anxieties, but they're kind of pushed to the side just out of sheer enjoyment working with the new capacities.
So there is a bifurcation here where we should all feel like, well, we don't know what's going on, and for some people that's going to produce some degree of anxiety. I understand that, especially when it's your livelihood and you're like, well, I'd also like to be able to pay for my kids' college in seven years. What does that look like? I get it. You're not going to be able to manifest that anxiety into anything productive unless you just plow it into leaning in. Right? Because if you just sit and spin around, try to think about what the world's going to look like seven years from now, you're wasting your time.
So that's the only path. The only path is to either get excited about this, which I don't even think takes that much effort. As we said, if you sit down with these models, you pull out one of your hobby projects from the closet
that you never finished,
that you never finished, and you just give it a try, I don't see how you really like computers and not find that experiment enjoyable.
And I've seen this with people who are getting into it. Kent Beck is such a great example. He's been a programmer 52 years and he is saying like he loves doing it, and he found this balance between using the agents to build something ambitious that he always wanted to build. He's building his Smalltalk server, which used to take forever, and now it's getting closer, and it's still taking a long time. And then in between he's chilling at his, he has his house on the lake, and he just goes and just looks at the birds for two hours and then gets back to it. It's beautiful.
Kent is, by the way, one of my all-time heroes. This was right when I got started in programming, right before I was picking up Ruby, I saw Kent speak at a Danish conference in 2001 on stage, and I was completely mesmerized by his command of both the material, how bold he was, and how great of a speaker he was. And this was after having read Extreme Programming and many of these other things. Smalltalk Best Practices is my number one recommendation for any programmer who wants to learn the nitty-gritty of how to structure a method and a class and the rest of it. Smalltalk Best Practices, which is Kent's book from '95, I think, or '96, is to this day my favorite book of all time on tactical programming patterns.
So, it's wonderful to hear him being agent-pilled while also enjoying the birds. I mean, I try to do that, too. And there's actually a bit of tension right now, which is that most of the people I find who are all-in, they're working harder than they ever have. And I've seen that with myself now too. When you can be this effective and impactful on an hour of supervision of these agents, it's really intoxicating. If you have an active dopamine loop up there that gets triggered when something is shipped, it is just hyperactive right now.
And I need to go, do you know what? This is not like a limited sale. AI is going to be here next month and the months after that. I cannot just operate as though it is a limited sale and I need to get all the dopamine harvested within the next two weeks. That I actually think is the main challenge right now for the people who are furthest along and most pilled on it, is like, remember that this is as bad as they're ever going to be, as the cliché goes, right? You damn well better find a way not to get consumed entirely by it, as exciting as it is.
And then yeah, this consuming is a big deal. Like with Steve Yegge, he looks a bit more drained, like you can see it on the video, but he's honest, like he's being pulled into this. He has friends who are, and when you're on the edge, you're there. You've clearly been AI-pilled, but how are you finding keeping a balance of, like, all right, stepping away? I think you previously talked about the importance of sleep. Apparently you don't have an alarm.
Correct. I don't use an alarm, although my wife now does because the kids need to go to school on a regular basis. But yeah, for me, eight hours a night is the best investment you can make in your own cognitive capacity. So, I just am reminded every single time I do not get eight hours that it is such a poor trade. If you go from the eight to the six, I go like, well, I'm going to be awake for, in that case, 18 hours. What is the drag I'm going to carry for all those 18 hours for getting one more hour, two more hours by cutting back on the sleep? It is such a bad piece of math. It makes no sense.
Now, occasionally it's involuntary. I have actually had, especially around this AI stuff, a couple of times, very rare, I can count on two hands the number of times where I've been sleepless, like the brain racing a little too much. That's not typical for me and it's still not typical. But I have had a couple of them, right? So, I get where some of that excitement comes from.
But I'd also say the last thing you should trade is sleep, and then you should not trade your health. You should not try to save the 3 hours a week of working out to do more agent work. That's a very poor trade. Keep in good condition. There's nothing that can be more important if you want to keep sharp up there than that the rest of the system is operating, if not at peak capacity, then at a good sustainable level, right? And I do think there are some individuals right now who are at fear of running ragged on something that we're going to be dealing with for, like, slow down, buddy. Again, it's not a limited sale. The next 10 years we're going to see more and more, it's going to get crazier and crazier. So don't squander your health, don't squander your sleep, don't squander your diet in the service of anything, because even on the short term, it does not work. You cannot get more productive within 3 weeks, let's say, by trying to cut back two or three hours of sleep every night and then think there's anything coherent left after 3 weeks. You will be a hot mess.
So, let's close. We talked about the stuff that we don't know. A lot of things we don't know, but let's close with what you do know. You could have retired a long time ago and just, you know, kicked back and listened to birds. What is it that keeps you doing, keeps you building, keeps you getting up every day? Before AI you would open your terminal, I think you shared, like you would go and write; now you're doing it with agents. What drives you, and looking ahead, what are things you're excited about?
My drive continues to be a deep love of computers. This is simply the best way, the most fun way to spend my time. I could spend my time on a lot of things. I do spend my time on a lot of things. I don't just do computers. I drive race cars. I take lots of time up. I have three kids. We enjoy all of that stuff. But if I'm going to fill eight hours every day with an activity, my best bet is computers. And it has been so since I was literally 5 years old. Whether it's video games or what now feels a little bit like a video game, actually instrumenting all these agents and playing a little bit of StarCraft with moving them around and
Toro.
Yes, exactly. So, I just really like computers. So, whether I need to do so for economic reasons or not, I will continue to play with computers, see what makes them tick, and make things.
I think that's the other big misconception that some people have about wealth, is that they conceive of it as some sort of checkpoint. Like once you've made it, then you can just kick back in leisure as though that was happiness. We simply have a hundred years of psychological studies telling us no, that's misery. If you have all the time in the world and no purpose, no mission, leisure is not going to cut it. It's not going to be fulfilling.
And this should be obvious by the example of literally every entrepreneur who sells their business. They sit on the beach for three weeks and then they're back into the game, right? Because this is actually not just something they do in pursuit of a goal. It's the goal itself. It is the mission itself. It is the satisfaction. It is the affirmation of being a human, that I'm not just a blob laying around. I am a useful individual who puts my skills to the best use possible.
So, I'm going to continue to do that. And I'm going to continue to do it whether I'm sitting typing at the keyboard, whether I'm instrumenting these agents, whether they're teaching me, however which way it is. I want to play with computers, I'm going to continue to do that.
And then even more specifically, after the last three months, I'm leaning in hard now with agent accessibility. For example, this is what I've been doing the last few weeks. We've been working on the new CLI, which also taught me we're not quite at AGI yet, right? You think like, well, just ask your agent to make a CLI. It will, but it's not quite there, right? I want it to be just right, and the agents still need a little bit of help. I'm very happy to provide that help to these agents, and we'll release a great CLI for Basecamp very, very shortly. By the time this is out it'll probably be out, and for the rest of them too, and I want to lean into all of this. How can we use this as much as we possibly can?
And then right now I'm also just an incredibly curious person. I wake up every morning, I have a new ritual, which is not to pull my phone up and start hopping on X right when I wake up. I don't think that is actually great. But it takes tremendous willpower to not do so, because I'm just so curious about what happened. There's so much happening right now. I want to know. I want to know. I want to be enjoying it, be a part of it. So I don't foresee that ending. I don't foresee a love of computers evaporating. In fact, if anything, right now I'm seeing a flourishing of it. I'm liking computers more than I did five years ago. And that's amazing.
Amazing, David. This was awesome. Thanks a bunch.
All right. Thanks for having me. This is really great.
This was a fascinating conversation and I love the energy that David has. I hope some of this energy that is obvious in person also came across to you. I really appreciated that David was open that his stance did not change about AI because his philosophy changed. It's just that the tools became good enough to do useful stuff. AI for autocomplete was annoying for experienced developers. AI agents that can produce pretty good working code by themselves, on the other hand, are now pretty useful.
And yet David kept coming back to taste, judgment, and craft. He wasn't saying just let the model write whatever. It's the opposite. He has a very high quality bar and he wants the output to be code that he would actually be proud to merge. It feels like AI might make good judgment even more valuable than before.
I also really liked how David thinks about the importance of design. At 37signals, designers help figure out what should be built, how it should work, and increasingly even decide how it gets implemented. I wonder if 37signals is a step ahead of the industry in thinking about designers a bit like developers as well, and developers a bit like designers as well.
Finally, I found David's take that we might have hit peak software engineer an interesting argument. David thinks we'll produce more software than ever. But his observation is that we might be nearing the end of the time when developers could command high compensation simply because they were the bottleneck. My two cents is that there will surely be high demand for professionals who can build profitable software. But this will mean software engineers who are not only good at coding or using AI to generate code, but can oversee building complex systems and have taste and business sense as well.
If you'd like to hear more from David, check out a bonus episode with him linked in the show notes. Also, check out the show notes for related Pragmatic Engineer deep dives on software craftsmanship and practical ways of building software. If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. And a special thank you if you also leave a rating on the show. Thanks and see you in the next
Article published