DHH at Rails World 2026: "Pencils Down" on Hand-Written Code and the Case for Total Optimism
Ruby on Rails
DHH opened Rails World 2026 in Austin with a keynote about what AI agents mean for programmers, for 37signals, and for Ruby on Rails. He describes his own state of mind as "AI delirium" or "AI euphoria" rather than "AI psychosis." His central claim is that writing code by hand is no longer economically productive for most programmers. He says 37signals has stopped doing it as a normal practice. He argues the right response is joy about the era that is ending and optimism about the one beginning. He also admits that nobody, himself included, knows what the end state will look like.
Excitement and Unease
DHH calls agents "the most exciting thing we have made computers do" in all his years working with computers. He also says the moment is unsettling. Nobody knows the final state, and any prediction is out of date "about 20 minutes later." He says he understands the unease this creates even for people who are excited. To ease it, he turns to history.
What Portrait Painters Went Through
His first example is 18th-century portraiture. A sitter would pose for hours in front of a master painter, who might then spend months on the portrait. He shows Joshua Reynolds' 1781 painting of the Ladies Waldegrave. He notes that Reynolds had already spent months on an earlier version that the client rejected because an ankle was showing, and had to start over. He jokes that anyone who has had a statement of work rejected will sympathize. These portraits were beautiful but exclusive, mostly for the upper bourgeoisie and royalty. His next example is Goya's portrait of the Spanish royal family, painted about twenty years later. In DHH's telling, painters had refined portrait technique for hundreds of years with only marginal progress.
He then moves to 1886 and a portrait of the Danish royal family by Laurits Tuxen. It took three years to paint and still hangs in Copenhagen. By then the camera had existed since around 1840 and kept improving. In 1900 Eastman Kodak released the Brownie, which DHH describes as the first mass-produced, broadly affordable form of photography, costing about a dollar. Suddenly many people could have their picture taken.
DHH says painters like Tuxen realized that depicting reality as accurately as possible was no longer an economically viable skill. Many turned to other forms of art: Picasso toward Cubism, the Danish Skagen painters toward a kind of impressionism. He presents this as a burst of creativity forced by technological change. Then he reveals a personal connection. Laurits Tuxen was his great-great-grandfather, and the woman in pink at the center of one Tuxen painting, Yvonne Tuxen, was his great-grandmother. He shows a photograph of Tuxen taken around 1921, shortly before Tuxen's death. The painter had accepted being photographed by the technology that had changed his profession.
Photography Moved in Fits and Starts
DHH was born in 1979, 52 years after Tuxen's death. He points out that his own baby photo looks much like the 1920s photo of his great-great-grandfather. His explanation is that technology advances in "starts and stops and fits." The Brownie was the big leap, and then almost eighty years passed without much change. Color photography arrived in the 1960s but was not widespread enough for his family to use it for his baby picture, though they had a color photo of him at age four with his brother. He says the three childhood photos he shows are about 10% of all the photos he has from his childhood. The cameras used were probably similar to the 1925 Leica I.
A few decades later, photography became frictionless and the number of photos taken went "parabolical." He shows pictures his wife takes on evening walks. He notes that doing the same thing in the 1980s would have required a real commitment to film and developing. He cites about 2 trillion photos taken per year in 2026. His point is that the underlying technology is the same, but an inflection point has clearly passed, even compared with the arrival of the first camera phones. He says there will be parallels to the software profession.
November 24, 2025: "The Kodak Brownie of Our Era"
In DHH's framing, the Brownie moment for software came on November 24, 2025, with the release of Opus 4.5. He describes it as AI technology packaged in a harness that many people could afford, which let them experience building software with "a new form of intelligence" for the first time. It was the tipping point for him. He predicts that history books will mark this date as the start of the age of agents.
As with the Brownie, many new form factors followed quickly. A few months later, comparable intelligence appeared in open-weight form, which he calls "total euphoria." He says he used Kimi K2.5 in fast mode for a long time and loved getting that level of intelligence at 200 tokens per second.
The Trough of Disillusionment, and the June Leap
He then describes a "trough of disillusionment" from February through May. New models kept arriving but seemed to go backwards. He recalls people asking what Opus 4.6 was supposed to be and wanting the old model back. Skeptics argued that the exponential improvement had stalled. He mentions an OpenAI release that did not improve much on benchmarks, after which, as he recalls it, valuations dropped and the market reacted as if the whole thing was over.
He contrasts this with photography's century of slow progress. This trough, he says, lasted only until May, or really June, when Fable 5 and Mythos came out. He says anyone who used those models lost any belief that progress had stalled, and that this is when his "diagnosis" fully set in. Opus had shown him that he could hand a task to an agent and get back something he wanted to merge. The newer models let him give an agent problems or ideas and see them solved or expanded without directing the implementation himself.
Progress continued. He cites GPT-6 Astra in September, which he says ended fears that Anthropic would monopolize frontier intelligence. A week later came DeepSeek-4-1 Flash, which in his view showed that frontier intelligence would not stay limited to a few large American tech companies.
From the 10x Programmer to the 1,000x Programmer
To ask what this means for programmers, DHH returns to history. He traces the "10x programmer" idea to a 1968 ACM article. By his account, it tested programmers on various tasks and found gaps between the worst and best ranging from 5x to 30x, averaging about 10x. The industry then argued about whether this was real for roughly 45 years. He says that debate is now over. The question has shifted to what the gap looks like when tools are included.
He argues it is uncontroversial today to say there is a 100x gap between the worst programmer without these tools and the best programmer with them. He then goes further and suggests 1,000x, which he admits might be slightly more controversial, though he doesn't think so. He says he does not know exactly what this means for competition between companies or for what it takes to start a business.
His concrete data point is personal: in the past 20 months he has written half as much code as in the previous 21 years. He calls lines of code a fuzzy measure. One line of Ruby is worth far more than one line of lower-level languages like Rust or C++. Even so, he says the revolution is undeniable, and anyone who has seen their own productivity accelerate this way will feel "a little dizzy."
"Look at All the Things I'm Not Doing"
He plays a clip of himself from a 2005 presentation in Brazil, 21 years earlier. In it, he walks through a Rails demo, saying "look at all the things I'm not doing" and "look at all the configuration I'm not writing." He points out that a URL like blog maps automatically to the blog controller and index maps to the index template.
He says there is no better summary of the current moment than "all the things we are no longer doing," and calls this "the Rails moment" all over again. He says he has written essentially no code for about five months, yet has been able to fix "every dream, every annoyance, every paperclip, every frivolous feature."
37signals Goes "Pencils Down"
A couple of weeks before the talk, DHH says, 37signals decided it is done writing code by hand as a normal part of its work. Hand-written code there is now an exceptional state, comparable to an error showing up in Sentry. It signals that something went wrong and prompts the question of why the agent could not produce what was wanted. Someone might pick up "the old pencil" for a short while, but the real fix is to repair "the machine," "the factory," so agents can do the work again.
He presents this as recognizing what was already happening, and polls the audience: who still writes material amounts of code by hand every week? He counts about five raised hands. Two or three months earlier, he says, the same statement would have made many people think he had "a screw loose."
He also describes an earlier attempt that did not work. In the spring, while finishing Basecamp 5, 37signals had designers vibe-code the final features they wanted. Each designer's PR looked reasonable on its own. Taken together, 20 or 30 of them left the architecture looking like Swiss cheese. The team concluded the technology wasn't ready and went back to manual review with programmers doing the work.
DHH now calls that "the wrong conclusion." His first reason is a retrospective guess: if they had waited a little, they would have had Fable, and the approach "would probably have worked as originally intended." This is his speculation, not a tested result. His second reason is that he now believes there is only one serious question in software development today: how to get the most out of this intelligence explosion. Everything else ranks below it. Basecamp 5 shipped, and he describes it as agent-accelerated but still involving a lot of hand-written code. He wonders aloud what to call the old way of working, which he says was retired "5 minutes ago."
HEY Stops Being a Web App
The next project is a new version of the HEY email service. DHH offers several possible names, such as "Hey Next" and "Hey New," and says the name isn't decided. The first decision is that HEY will no longer be a web app.
He says HEY "never really wanted to be a web app." It was built on the web because web apps were how small teams stayed productive. Until recently, he argues, a small team maintaining six native applications in their native frameworks would have been absurd. That is why tools like React Native and Hotwire Native exist: to trade a little fidelity for productivity. He calls HEY a great web app but says it is not as good as a native app, citing differences in latency among other things.
Behind him, a video shows the six native applications 37signals started about a week earlier. He does not name the platforms. He says maintaining six high-fidelity native apps for a major service used to take a long time and a large team. Now they can do it "because we're not writing a goddamn line of code," though they are writing many prompts. He says the effort has barely started, but it is already obvious to him that this is the future for this kind of application. Many apps are web apps out of necessity, convenience, programmer preference, team size, or limited resources. He expects many of them to become native because the cost of building native apps has dropped to "damn near zero."
He shows an example: the first result when they asked for a Windows app, which he calls "not quite shippable," and a revised version that arrived 20 minutes later. He says 37signals is not the first to reach this conclusion. He points to Shopify's recently launched native rewrite of the Shop app, which replaced a React Native app. He describes it as done by a tiny team of about six people in a short time.
The Backend: DHH's "Love" for Rust as a Black Box
He admits the backend is harder for him to talk about, because the answer is Rust. He calls Rust in his opinion the ugliest programming language invented in the last 40 years, shows a code sample as "Exhibit A," and says it is inhumane to make people write it.
His position flips, though, if he never has to look at it. If he can simply enjoy applications that run 30 to 100 times faster, compile into tiny executables, and start in under a millisecond, then he loves Rust. He says agents like Rust, and the division of labor suits him: he says what to do, the agent writes it in Rust, and he never reads it.
For HEY, the plan is this. With the front end moving entirely to native apps, there is no longer a need for a web application rendering HTML. The code behind the old web app becomes, in Rust, the mail server that HEY fundamentally is. DHH reports the resulting backend uses 99% less CPU and 95% less memory. It runs on ten hosts only for redundancy. He adds that their back-of-the-envelope estimate suggests HEY's peak traffic could "probably" be handled by a single Raspberry Pi. This is presented as an estimate, not a demonstrated result. He credits Rust as being as close to the metal as possible while staying portable, combined with having a pay-per-token intelligence do the work.
Working Asynchronously, and Where This Leaves Ruby and Rails
DHH says it is still unclear how best to work with agents, and 37signals is trying several approaches. One is directing agents from inside Basecamp. He says the best way to work with agents is asynchronously: not waiting on tokens in a chat window, but handing off a task the way you would to a coworker and reviewing the result when it's ready. He stresses that nobody knows how this should work yet. Things change constantly. The whole shift began on November 24 of the previous year, less than a year ago. The kind of intelligence that lets you assign outcomes and problems instead of tasks is only a couple of months old.
He then addresses Ruby and Rails directly. For HEY, the answer is native front ends and a Rust backend. But many applications don't fit that shape. He calls the web a wonderful platform partly because it never requires installing anything. A million businesses depend on that, especially those with occasional customers who won't install an app. He uses Basecamp as an example, since it brings in outside people who just need to grab a file or collaborate briefly. He believes Rails is well placed for these cases. In his view, Convention over Configuration leads directly to token efficiency, and Rails' focus on the one-person framework fits an era where a single developer can go much further than before. He says he doesn't have the answer for where to draw the line between native and web.
He mentions agent evals that Evil Martians run for the Rails Foundation. These evals measure agents implementing feature cards against real reference applications. The first version was saturated quickly, with agents reaching about 95% completion rates, so a harder version was introduced. He expects this pattern to repeat as agents keep improving.
From this he draws a warning for people who know a lot about how computers work: don't be too prescriptive. A beginner's mindset, even a "dummy approach," works better because you ask questions and write prompts at a higher level. He says he considers it a feature and a privilege that he knows no Rust at all. He evaluates the Rust code as a black box from the outside, as business owners have always done when hiring programmers. In his view, the only thing that has changed is who does the work.
The Numbers: 3% Ruby, 150,000 Lines in a Month, and English
DHH gives numbers from his own work. Over the past 21 years, more than half of his work was Ruby code. This year it is about 3%. Part of the reason, he says, is that languages like Rust are verbose, and since he doesn't read the output, he lets the agent write more than necessary in a way he would never accept in Ruby.
He also compares output. During his 21 years with Ruby, he wrote about 30,000 lines of production Ruby per year, which was enough to build businesses and frameworks. In August alone, he says, he produced 150,000 lines of code, which he describes as about 60 times his long-term average. He acknowledges again that much of it is verbose Rust, but says the order-of-magnitude change is what matters.
He says he was surprised to find a programming language he likes better than Ruby: English. He calls Ruby his favorite traditional programming language. He describes English as more expressive than Ruby, though vaguer and less deterministic, and says programming in it is "an absolute joy." He admits he didn't see this coming even last year.
Retiring From Hand-Written Code, With Joy
He plays a clip of himself from the past saying he could have become a project manager 20 years ago if all he cared about were outcomes. In the clip he says he got into programming for the outcomes, then fell in love with programming, and would rather retire than give it up.
"Okay," he says. "I have retired from being a professional programmer." He hasn't pinned down the date but thinks it was four or five months ago, maybe March. He says the old clip was entirely true. He spent a quarter century writing code by hand and loved every moment. He believes the right way to look back is with joy, not regret: joy at having been there when this work still had to be done, with all its excitement, learning, satisfaction, and flow states.
He then makes his strongest prediction. He says hand-written code is already not economically productive for most programmers at most companies. By the end of the year, he predicts, that will be true for "virtually all domains, virtually all programmers, virtually all companies." The other side, as he describes it, is a new career as a "professional maker of things," steering intelligence that was science fiction until recently. He calls it a privilege to have seen both sides and says this is the biggest event in the history of computing. He says he half-wishes he had been around for punch cards. He compares the current moment to the arrival of the internet, which he did experience, and says this one is much bigger.
Architecture and Methodology Need Rethinking
DHH lists what he thinks must be reconsidered. The first is software architecture: everything we believe about structuring codebases so they can be changed easily. He says abstractions have been the main tool for a long time, and he loves them, including naming things. But he argues they don't make the same sense with agents. If hundreds, thousands, or tens of thousands of processes are modifying an application, abstractions become choke points. Part of the reason for abstraction was avoiding repetition. He says the cost of repetition, and of keeping duplicates in sync, has dropped to near zero. He calls these fundamental revaluations of computer science and says no one has a blueprint yet, only signs of what no longer works as well.
The second is methodology. How long should cycles be? Who should specify what? He says none of this is settled, and compares the moment to the arrival of object orientation. He invites the audience to help figure it out, calling it the ground floor of a new industry.
Bring Your Own Agent: Every App Needs a CLI
His most concrete advice concerns AI inside applications. He says the first rush was to add chatbots everywhere. His response is that he doesn't want an app's built-in "concierge." He has his own "personal butler" that can use CLIs to connect Basecamp, HEY, and many other apps. He tells app developers to "save your tokens" and let users bring their own agents through a CLI. He jokingly demands that any app without a CLI have one by next Friday, arguing that the tokens exist, it's possible, and he wants to use apps without touching them.
His example is the HEY CLI. HEY uses Elasticsearch, which he calls serviceable but not delightful, often failing to find things, especially when the user doesn't know exactly what they're looking for. With an agent, he says, he can search by concept instead of keyword. He needed to find a roughly five-year-old email where he couldn't remember who he'd been talking to, the company, or the year, only that it involved sneakers and a podcast. He says even a top search engine wouldn't have found it, but the agent did within minutes. He says he still doesn't fully know how it did it and is "a little scared to ask."
Omarchy: Fixing the Whole Computer
DHH says the feeling that "we can just fix everything" now applies to the entire computer. He has talked about little besides Omarchy on X for about three months. He says he put many of his best ideas into it and ended up with an operating system far better than anything he has used. He reports that about $20 million has been raised for the Omarchy project.
He focuses on install time. At the previous Rails World he showed an early version that installed in 3 minutes 33 seconds. Last week, he says, Anoush from AMD installed Omarchy on a Halo laptop in 35 seconds, and in the lab they've reached 9 seconds, faster than some computers boot. He admits to being obsessed with the number. When asked why three minutes wasn't good enough, he quotes Mitchell Hashimoto, creator of HashiCorp and Ghostty: "The pursuit of excellence does not need justification." He likes that it sounds more dignified than "because I want it," and adds that now it feels possible to want and get everything.
One-Shot Apps, and Software That Fits in Half a Megabyte
He then describes apps he built for Omarchy. The first is a calculator themed to match Omarchy. He had ChatGPT generate three design options, took a screenshot of one, and asked his agent to build it. He calls it a one-shot. He didn't know C++ or Qt well enough to build it himself, yet the app was ready seven minutes after the prompt. About 15 minutes later it was pushed to the public repo, and he then built a new ISO that included it. He calls this "the loop."
Next came a writing app to replace iA Writer, which he used on the Mac for years. This took longer because he wanted it just right, but he says he never looked at a single line of the code, calling C++ "a great language" as a black box, like Rust. Then came a small video editor for trimming clips, also now included in Omarchy.
He says he started this keynote the previous Thursday and, "as any good software engineer would do," wrote new presentation software while preparing it. It's called Hype. He calls it the best presentation software he has ever used from anyone, better than Keynote, which he liked on the Mac. It is based on Markdown, has full visualization, is very fast, and its binary is half a megabyte.
He argues this is another payoff. For about 20 years, computing gains went into human productivity, which he says was the right choice. But it made applications slow and bloated because a programmer's hour was too expensive to spend on optimizing payload size. He cites Spotify's music player at 1.2 GB. In the new world, he says, every optimization is within reach, and a model can run overnight and deliver 10x to 30x improvements.
Concerns, Security, and Why Predictions Fail
DHH says concerns about AI deserve to be discussed, though some may be overstated. He treats security as a real issue: "Something is coming." Agents might know their "expiration date" and try to do bad things, so people should prepare. He says the tools to do that exist.
He adds that predictions about the economy and society have almost always been wrong, noting that economists can't predict the stock market six months out. His example is ATMs, which he says were introduced in the U.S. in the 1950s amid fear that 30,000 bank tellers would lose their jobs within about 18 months. Instead, he says, cheaper branches led banks to open more branches and hire more tellers, who did things like upsell customers on subprime mortgages, which he says as a joke. Later he cites the numbers again: 30,000 tellers in 1950 and around 40,000 in about 2010, which he connects to William Stanley Jevons and the Jevons paradox.
He thinks many smart people working on AI, many with PhDs, see alarming things in the lab and extrapolate to society. He cites Truman's reaction to Oppenheimer in the Oval Office, quoting Truman as saying he never wanted to see "that son of a bitch" in his office again, and says Truman had it right. The world didn't end. In DHH's view, the Cold War that followed was "the best kind of war," because the two superpowers never bombed each other directly, an outcome a scientist at the time would have found hard to predict. If Oppenheimer couldn't foresee what followed the atomic bomb, he argues, we should be humble about predictions now.
P(bloom) Over P(doom)
DHH proposes "P(bloom)" instead of "P(doom)." He says the chance of AI leading to abundance and joy is far greater than the chance of catastrophe. He adds that the atomic bomb also gave us nuclear power, "the greatest source of energy humans have ever discovered," which he says humanity then wasted for 40 years out of a mistaken belief that it wasn't green. His point is that humanity can go down a wrong path for decades and then correct course, and he expects the same with AI.
For real problems like security, he says, we now have the power to build solutions. He mentions a recent serious Rails CVE involving a C image library that leaked data. His response is to build a quarantine, pointing to HotCell, which a colleague named Mike was scheduled to present. He tells the audience they have agency and can use this intelligence to defend against bad outcomes.
The Case for Total Optimism
He closes with what he calls game theory. Since nobody knows the future, being happy about it is the rational choice. If you're gloomy and things turn out well, the gloom was wasted. If catastrophe comes, you should have spent your last day in a better mood. So, he says, the only play is "total optimism." He predicts a "reformation of the computer," in which "Agent Luther" will disintermediate "the cleric class" and let everyone make programs.
He acknowledges this may bring more competition for programmers but tells the audience that as Rails programmers they know more and are better, comparing them to Top Gun. He shows a photo of Harris's daughter trying a kids' version of Omarchy that is in development. He says children embrace change because they don't have layers of habits to unlearn, and that if this doesn't inspire the adults, the next generation will tell them "the future's now, old man." His final message is to take "the white pill," the optimism pill, and embrace the future with full acceleration despite the uncertainty and stress. He admits that the unanswered questions from the talk remain open: where to draw the line between native and web, how to structure codebases for agents, and how to organize development work.
I like that. Bent in neon.
Well, first of all, welcome to Austin is what I would normally say. I would say welcome back to myself to Austin. I was just here about a month ago yapping for 5 hours on a podcast. It is great to be back here.
But even more exciting for me is to be alive right now in this moment and sharing it with a wonderful community around Ruby on Rails and everyone else who is excited about agents. And if you aren't yet, hopefully you will be by the end of this delirious talk on the future.
Now, I know that the first instinct someone might have when they see a person dancing around being so excited about this moment is a diagnosis. AI psychosis. I prefer a different term. I have AI delirium. AI euphoria. Because this is simply the most exciting thing we have made computers do in the time I have worked with them, played with them, interacted with them.
But I think actually to wrestle with the fact that on the one hand, this is tremendously exciting, it is also a little unnerving. Because we don't know exactly what the final state of this is going to be. And whenever we try to make a prediction, it is out of date about 20 minutes later. That's a weird state to be in, even if you are excited for the future, even if you're excited for the present. And I fully understand the sense of unease that can create.
So to soothe that somewhat, let's wind back the clock a little bit. This is a state-of-the-art piece of technology from the 18th century. If you wanted your portrait taken in the 18th century, you would sit for hour upon hour upon hour in front of a master painter who would then go off and at best spend months working on your portrait.
And it was beautiful, is beautiful, amazing legacy of culture that has been left to all of us now. That we can see the Lady Waldegrave to this day that Joshua Reynolds painted in 1781. Wonderful. Also, a little exclusive. Not that many people in the 18th century were able to commission a piece of themselves like this and pay for an artist to spend months and months and months to create something like this.
And even worse, in the case of this particular painting, Reynolds spent months and months on another painting of the Ladies Waldegrave that was rejected by the client because a piece of ankle was showing. It was scandalous. So he simply had to go back and redo it. I don't know if anyone has worked with clients before, but they might have some sympathy for poor Mr. Joshua Reynolds. And rejected statements of work.
Now, most of the people who could afford to do this were either part of the upper bourgeoisie or they were outright royals. Here's a painting that was done 20 years later by Goya of the royal Spanish family. That was sort of the rate of technology. Painters had been perfecting the different techniques of capturing portraits of people for literally hundreds of years and were making very marginal progress along the way.
Now, between 1801 and the next painting I'm going to show, 80 years went past. And in that time, the introduction of the camera came to the scene in around 1840. But here's a painting of the royal Danish family from 1888. Oh, '86. By a Danish painter, Laurits Tuxen. He didn't just spend 3 months painting this. He spent 3 years. It is still hanging in the royal squares in Copenhagen, and you can go see it there. An amazing achievement, amazing artistry. Also very functional. Again, the point was to capture the royal family at that time.
But this was getting towards the end of that particular mode for artists of that kind. Because what happened between 1840 and 1900 was that the technology of capturing portraits got better and better. And in 1900, the Eastman Kodak Company introduced the Brownie, the first sort of mass-produced form of photography that was more generally accessible because the price was coming down. I think it was about a dollar to have your picture taken with this. And therefore, a lot of people suddenly had their pictures taken.
And all of these great artists realized that the craftsmanship of producing these grand paintings, you know what, that was gonna be different. The job was going to be different. Because suddenly now there was competition from a new form of technology. And they pivoted.
Laurits Tuxen, along with many other painters in that era, shortly after the Brownie was introduced, realized that depicting reality as perfectly as possible was no longer really an economically viable skill. They needed another skill. They needed another domain. And many of them pivoted to different forms of art. You had Picasso chasing Cubism. And you had the Danish Skagen painters chasing a form of impressionism that this painting is an example of.
So we got this explosion of creativity brought upon us by the change in technology that suddenly people had to find a new way to express their art because the old way was gone.
Now, what's interesting about this particular picture is that the lady in the center in the pink dress, Yvonne Tuxen, is actually my great-grandmother. Because Laurits Tuxen is my great-great-grandfather. And here he is depicted in 1921, I believe, shortly before his death. He embraced the fact of having his own portrait taken by the new form of technology that had rendered his old profession a different place to work.
52 years after his death, I was born in 1979. Interestingly enough, that picture taken here is very similar, actually, to the picture that was taken by Laurits in the 1920s. The technology hadn't evolved that much because that's what often happens with progressions of technology. It comes in starts and stops and fits. The huge change was the Brownie, the democratization of photography, and then kind of almost 80 years went by when not a whole lot happened. We got color photography in the 60s, but not widely distributed enough that apparently I was worth one.
Although we did rectify that a few years later, and here's a color photograph of me, age 4, sitting with my brother. Now, a couple years later, here's another photograph of me, and between those 3 photos, that's about, I think, 10% of my stockpile of photos of my childhood.
Because even though the democratization of this technology had happened to a point that even we as a family could afford to have these pictures taken, it was not that widely distributed. And yes, there was a curve and more pictures were being taken in the 1980s, as this photo represents, versus the 1900s, but it was still kind of modest. Because technology moves in fits, starts and stops.
And the camera that those 3 pictures were taken on was very similar to this camera. This is the Leica I from 1925. In fact, maybe some of those pictures were literally taken with another Leica. I think they were up to the 7th one by then. But they weren't that different because the technology was quite similar. Not much had happened since the great revolution around the 1900s until the '80s.
Then we gave it a couple more decades, and suddenly everything changed dramatically again. Photography went from not just being possible for everyone to have, but to become completely frictionless, and the number of photos taken went parabolic. Because suddenly everyone could afford to have tens of thousands of pictures of their children, and many of them did. It simply became too cheap to measure.
These are some of the photographs my wife likes to take when she's out on her evening walk. To have wanted to do this even in the '80s would have required a commitment to film and getting them produced and the rest of it. And there were people who did that, but not that many, because the friction was still too high.
Today, in 2026, some 2 trillion photos are taken every year. That's very different. It's the same underlying technology, but we've clearly hit an inflection point, even compared to when the camera phone first came out. There's gonna be some parallels here to our industry and our profession.
On November 24th, 2025, we got the Kodak Brownie of our era. We got Opus 4.5. AI technology made accessible in a harness that many people could afford to use and experience for the first time what it's like to create software in pairing with a new form of intelligence.
This was the tipping point for me. There was everything before November 24th. And then there was everything after. This is going to be the date that history books going forward will mark as the inflection point for the age of agents.
And as with the Brownie, when that first came out, there was an explosion of different form factors and new ways of trying to harness this technology. And it did not take long until we got some notion of the same intelligence in an open-weight format. Total euphoria. This is moving so fast. I can't believe that this alien technology is now accessible in open-weight form. Just happened a few months later. I drove Kimi K2.5 in the fast mode for quite a while and absolutely loved it. An incredible experience to be experiencing this kind of intelligence at 200 tokens per second.
But then something else happened. This trough of disillusionment from February through May where we seemingly continued to get new models, but they kind of sucked. It was like they were stepping backwards. And many people were like, what's this Opus 4.6 thing? I don't know, man. Just give me the old stuff again.
And a lot of people thought, haha, you thought this was going to continuously exponentially expand and improve. But look, we're actually not getting that much better. I remember a particular release. I think it was of OpenAI's new model that didn't punch that much better on the benchmarks. And the stock price fell or the valuation fell and the market was suddenly, oh my God, it's over. Yeah. Because we don't know what's going to happen.
But this trough of disillusionment did not last like it did with photography for 100 years, where the technology barely seemed to improve. It only lasted until May. Well, June, really. Because in June, we got Fable 5 and Mythos. And clearly, anyone who had a chance to experience that at the time was disabused of any disillusionment they might have had about whether we had stalled and whether it was over.
And I'd say this is where my diagnosis really set in. My psychosis/delirium/euphoria for this explosion of intelligence on tap. This was the model where I went, oh, I can tell an agent to do something for me, to seeing that being something I want to merge. That was the revelation of Opus, to suddenly having models I could give problems to or ideas to and see those be solved or see those expanded through no direction of my own on the implementation. Mind-blowingly incredible.
And of course, things didn't stop from there. We have been on this amazing roller coaster now for a couple of months. GPT-6 Astra came out in September and saved us all from the dread that Anthropic was going to have a monopoly on this kind of frontier intelligence. And then even better than that, just a week later, we got DeepSeek-4-1 Flash that disabused us of any notion that frontier intelligence was going to forever be a domain of just some large American tech companies. This is incredibly exciting.
But what does it mean? What does it mean for us as programmers? What does it mean for us as a profession? And I think this is why, again, it's worth looking backwards a bit. Because history holds all these amazing lessons and parallels to our time if we just look at it.
One of the things that has dominated the discourse in the entire time I've been a professional developer has been the argument about whether the 10x programmer was real or not real. Well, that entire concept came from an article in ACM Magazine from 1968, where they tested a group of programmers on a variety of different tasks, and they came up with a table that showed that the worst programmer and the best programmer had a variance ranging from 5x to 30x, an average of 10x over that period. We then spent literally the next 45 years arguing whether this was actually real or not.
Is there anyone still arguing that? I don't think so. Like, that debate has been settled now. But the interesting thing is, we sort of leaped over a shared conclusion around the 10x programmer and started thinking, like, well, if that was 10x with just the human capacity, what must it look like now? And it's clear we don't know exactly. We don't know exactly what the kind of acceleration with these tools is possible.
But I'd actually argue that it is less controversial today to claim that there's a 100x difference between the worst programmer working without these tools and the best programmer working with these tools. That's not a very controversial statement. But it is absolutely revolutionary to the understanding of where we are right now as a stage of technology.
And I'd actually go a step further. And maybe this is slightly more controversial. I don't think so. The worst programmer without these tools versus the best programmer with these tools? That sounds about right. 1,000 times? Yeah. Okay. Well, what does that mean? What does that mean for the competition of companies, for what we need to get started? 8-ball a little fussy. Shake again.
What I know to be true is that in the past 20 months, I have written half as much code as I did in the previous 21 years. Now, lines of code is a weird, fuzzy, malleable size. And one line of Ruby is obviously worth vastly more than one line of any other language, but particularly Rust or C++ or any of the lower-level languages that do not have the same abstractions and amenities that we enjoy in Ruby. But it is still absolutely undeniable that there is a revolution taking place. And anyone who's gone through that and seen their own productivity be accelerated will be a little dizzy.
How we create a template. Look at all the things I'm not doing. Look at all the configuration I'm not writing. All these things are mapped together just automatically. Just by saying blog up here maps directly to the blogging controller, and just by having index maps directly to the index template. Look at all the things I'm not doing.
Is there a better encapsulation of this moment than all the things we are no longer doing? That is the source of my exuberance for this moment. This is the Rails moment. That clip I just played is 21 years old. I gave a presentation in Brazil in 2005, and I was so excited about all the code I wasn't writing. Can you see why I might be a little more excited now, even? Do you know how much code I have not been writing for the last several months? A lot.
And yet, despite writing no code for probably 5 months at this point, I've been able to fix everything. Every dream. Every annoyance, every paperclip, every frivolous feature suddenly within reach, suddenly possible. This is the magic of the moment. But what does that mean?
Well, at 37signals, a couple of weeks ago, we made the decision that it clearly means we're done writing code by hand. We are going, and have gone, pencils down on the idea that we were gonna write code by hand as a normal course of business creating things. Writing code by hand at 37signals is now an exceptional state. It is like seeing a bug in Sentry. Something here went wrong. Why was the agent not able to produce what we wanted?
Okay, maybe for a little while, we'll still get the old pencil out and dot it down for them. But then we fix the machine. We fix the factory. We get things going again. This is a recognition of what's already happening.
If we were to poll this room, I'd probably— actually, let's poll this room. How many people here are still writing material amounts of code by hand on a weekly basis? Show of hands. Holy fuck, that's about 5.
If I'd put this slide up 2 months ago, 3 months ago, and made the same proclamation, a fair number of people would have gone, that dude's got a screw loose. And now, already, this is just a recognition of what's already there.
What's so fascinating about this is we tried to do this in the spring at 37signals when we were putting the finishing touches on Basecamp 5. We had a bunch of designers vibe code the final features that they wanted into this release, and the results were mixed. Individually, the designers were able to create PRs that seemed reasonable.
Taken together, 20 or 30 of them, it left the architecture looking a little like a Swiss cheese, kind of punctured. So we went— Ugh. Okay, I guess the technology's not ready yet. Let's go back to manually reviewing everything and just have programmers working with it.
That was the wrong conclusion, clearly. Not only because we could just have given it freaking 5 minutes, and we would have gotten Fable, and the whole thing would probably have worked as originally intended, but also because what's clear now is that there is only one serious question in this moment of software development. And that is, how do you get the most out of this intelligence explosion? Every other question is below that in the stack of values.
So we've shipped Basecamp 5. It's a great upgrade. It was agent-accelerated, but still paired with a great amount of manually written, handwritten— chiseled? What are we gonna call this old way of working that was just retired 5 minutes ago? I don't know.
But now, working on a new project. HEY Next. HEY New. HEY There. I don't know what we're gonna call it. But it is a new version of HEY, our email app service. And the first thing we're going to do— HEY, Next— is stop making it a web app.
HEY is no longer gonna be a web app. Because HEY never really wanted to be a web app. HEY was and is a web app because making web apps for small teams was how you could be productive in the old times. That is, 5 minutes ago.
The idea that a small team could maintain 6 native applications written in the native frameworks was preposterous. No one was doing that. That's not only why we had people doing web apps. It's why we had React Native. It was why we had Hotwire Native. It was why we had all of this tooling to make us more productive, while accepting that the fidelity was gonna take a slight hit.
We make great web apps. HEY is a wonderful web app. But it's not as good as a native application. Of course it's not as good as a native application. There's different latencies and so forth.
Well, what's playing behind me now is a demonstration of the 6 native applications that we kicked off about a week ago. This is already where we are at. That's insane.
In the old time, if you wanted to maintain 6 native applications at very high fidelity for a major service, it was gonna take a long time. It was requiring a huge team. Now suddenly, we're able to make very high fidelity native applications happen because we're not writing a goddamn line of code. Look at all the things we're not doing. But look at all the prompts we're giving. We're giving lots of prompts. And the results are absolutely electrifying.
This is an effort we have barely just kicked off, and we're already at a state where it is so obvious to me that this is the future for that class of applications. That there is a lot of web applications that are web applications of necessity, of convenience, of programmer preference, of team size, of resources available. You know what? They're not gonna be web apps much longer. They're gonna be native applications, because the price of developing those things has gone to damn near zero.
Now, here's an example of what the first prompt spit back out when we asked for a Windows application. Not quite shippable. Here's the redirected version that landed 20 minutes later. Are you getting it? This is nuts. How could you not require a diagnosis after seeing this in front of your own eyes?
Now, we're by no means unique in this realization. We're by no means the first in this realization. Shopify just recently launched a newly rewritten native application for the Shop app, replacing a React Native application, done by a tiny team. When you consider the criticality of about six people working for not very long at all, this is coming. Get ready.
Now, that was the front end, and I think for these classes of applications like HEY, like Shop app, that really want to be native applications, that's what's gonna happen there. We're going to commit to these native toolings. And we're going to realize that the cost associated with creating these things just no longer exists in the same way. But what about the backend?
This is a little difficult for me, I will admit. And let me tell you why. Rust. Rust. I hate Rust with a passion. Rust to me is like pouring acid in my eyes when I have to look at the code. Whoa, whoa, whoa, why do you hate Rust? It is, in my opinion, the ugliest programming language that has been invented in probably the last 40 years.
Exhibit A! This is an awful, awful, awful programming language when you subject humans to write it. Absolutely inhumane to ask people of flesh and blood to subject their eyeballs to this.
But you know what? If I never have to look at this, if all I have to do is revel in applications being 30 or 100 times faster, compiling down to minuscule executables that start up in sub-milliseconds, I love Rust! Rust is amazing if you never, ever, ever have to look at it yourself.
Agents— agents like Rust. Great! What a division of labor. I'll tell you what to do. You'll write it in Rust. I never have to look at it. I love this. And I also love the outcomes.
In this setup where we're rewriting the frontend of HEY in all native applications, and therefore no longer need a web application that is rendering HTML and whatever, and then we take that code that's running the no-longer web application and turn it into the mail server that it really is at its core in Rust, we end up with a backend that requires 99% less CPU, 95% less memory, and the only reason it needs 10 hosts is for redundancy. In fact, our back-of-the-envelope calculation has led us to believe that HEY's peak traffic could probably be served on a single Raspberry Pi.
That is the efficiency of writing as damn near straight to the metal as you can get while still being portable, which is Rust. And the benefit of having something else do that for you. Some other intelligence that you pay per token to do it.
What does this mean in terms of how we're working with this intelligence? Also not clear. We're trying a bunch of things. One of the things we're trying to do is direct these agents, our Chef Marie inside of Basecamp, to do it. It's clear that when you work with agents, the best way to work with them is actually asynchronously, not in a chat interface, not sitting and waiting for the tokens to output, but to give a task to an agent, like you would a coworker, send them off, and then go back and review when there's something ready. So we're trying to do that as well. A lot of other people are trying to figure this out.
And this is part of the magic, the electricity of this moment. We don't know how it's all supposed to be. First, because it's changing every 5 minutes. Second, because we have not worked with this kind of intelligence at any measure of time. This entire thing got kicked off November 24th last year. It hasn't even been a damn year. And the kind of intelligence that allows us to assign outcomes, problems, rather than tasks, is only a couple of months old. So of course we don't know exactly what it's going to be like.
But it's still fair to then ask the question, where does that leave Ruby? Where does it leave Rails? Where does it leave any of these tools that we use? What is the future gonna look like? Well, for HEY, we have our answer. It looks like native applications on the frontend and Rust on the backend.
But there's plenty of other applications that don't fit that shape. The web is an enormously wonderful platform, partly because it never asks anyone to install anything. And a million businesses are built on that premise. More ephemeral customers who are not going to indulge an installation on their device to use a service. The web is wonderful for those things.
And Rails is particularly well positioned to still be in play there. Everything that we've worked on for the past 25 years. Convention over configuration leads directly to things like token efficiency. Our focus on the one developer framework squares perfectly with what the age of agents is demanding, that single developers can go much further than they were able to do before.
We started doing these agent evals. Or Evil Martians have started doing it on behalf of the Rails Foundation. And A, finding that we quickly had to update our evals because the agents were saturating the first version of it and reaching 95% completion rates quite quickly. Now we've instituted a harder measure for it. But amazing how quickly these agents are moving forward and up the stack and up the ranks.
This is an agent eval looking at actual implementation of feature cards against some of these reference applications that we have in the wild. Wonderful. We're leaning in towards that. That was the old benchmark, the old reference. As you can see, it was getting saturated already, so we made it harder. There's going to be a lot of that, a lot of elevation of the things we ask the agents to do because they continue to get more capable.
And in fact, it's one of the pitfalls I would warn anyone who knows too much about how computers work: to not be overly prescriptive in what you're trying to get out of these systems. In fact, having a bit of a beginner's mindset and a bit of a dummy approach to this works even better, because you ask questions and you pose prompts at a higher level.
This is one of the reasons I love working in Rust. I don't know any Rust at all. I consider that a feature. Yes! And a privilege to have no fucking clue what is being outputted by these agents into the Rust box. I evaluate the Rust box as a black box on the outside, as any business owner in history who's ever commissioned a group of programmers to do anything for them. This is not a new phenomenon. Who now holds that responsibility has changed, but not the phenomenon.
But applications like Basecamp, where we bring in strangers who just need to get a quick file or need to collaborate for a short period of time: great web applications. Lots of you surely work on those kinds of applications. Now, figuring out exactly where we're going to cut that line, what should be native, what should stay web, we're going to have to figure that out. I don't have all the answers for that. OK.
I do know that when I look at my work over the past year, it does look very different. If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%. Now, part of that is that these programming languages like Rust are tremendously verbose and unappealing for humans to look at. So I don't, and I allow the agent to just spit out more than was necessary, in a way I would never tolerate from my Ruby code. So that's part of it. But still, undeniable that there's a huge change here.
In those 21 years of prior working with Ruby, I would write about 30,000 lines of production Ruby code per year. That was enough to build businesses and frameworks and everything else that I've done. Well, in August, last month, I wrote 150,000 lines of code in one month. That's about 60 times more code than my long-term running average. Again, a lot of it is that awful Rust code I don't want to look at, and it is more verbose, but still, the orders of magnitude here, that's what we need to pay attention to. And at least think, what does that mean?
Well, one of the things that has surprised me, and really it shouldn't, has been the fact that there is actually a programming language I like better than Ruby. I did not think this was true, but it is. It's called English. English is a better programming language than Ruby. And I love Ruby more than any other traditional programming language in the world. But writing programs in English is a tremendously satisfying experience. It is an even more expressive language than Ruby. It's a little more vague. It's a little more or less deterministic. But nonetheless, it is an absolute joy. And I did not fully appreciate that that was where we were going as late as last year.
I could have become a project manager 20 years ago if I didn't care to write code myself and I just wanted outcomes. That's how I got started in programming. I just wanted outcomes. Then I fell in love with programming. And now I'd rather retire than giving it up. Okay.
I have retired from being a professional programmer. I haven't pinned down the exact date. I think it was somewhere around 4 to 5 months ago, maybe March. I should find out exactly when it was. Because you know what? That little clip, totally true.
I spent a quarter of a damn century chiseling code by hand and loving every moment of it. What a wonderful experience and productive time in that era. And that's how I believe we should all look at it. Not with regret, but with joy of what was. Enjoy that we were there when we still had to do such things. Because they were filled with excitement and learning and satisfaction and flow states. This is not something to look back upon with regret. This is something to look back upon with joy and accept that it is over.
Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies. That's today. By the end of the year, it will be virtually all domains, virtually all programmers, virtually all companies. So we best get used to it. We best embrace that we had a wonderful run chiseling that code by hand, and that it's over.
And on the other side of that is a new career, an exciting career, an energized career as a professional maker of things. Yeah. Yes, you will no longer be chiseling that code by hand, but you will be making amazing things. You will be steering intelligence that was only available in science fiction up until a few moments ago.
What a privilege on both sides of that chasm to have been there when we did it all by hand. To be there at the exact moment where we switch over. This is the biggest thing that has happened in the history of computing.
I sometimes think, man, I kind of wish I was there for the punch cards. That sounded pretty fucking cool. Like, my programs literally had holes in it. And I would line up and feed it to a machine and, like, go, I wonder if it compiles. Man, I would have loved to experience that. What a moment. What a moment. I didn't get to experience that, but I did get to experience the internet. That smells and feels a little like this moment that we're in, but this is much, much bigger.
Okay. Well, shit. There's a lot of things we gotta rethink. We gotta rework. Where are we gonna start here?
One of the things we're gonna have to revisit is everything we think we know about software architecture. Everything we think and know about how to structure code bases in a way that we can mutate them easily and move forward. The main tool that we've used for a very long time is abstractions. I love abstractions. Abstractions include naming things. That's one of my favorite things, is to name things.
Abstractions don't make quite the same sense in the age of agents. If you suddenly have hundreds or thousands or tens of thousands of conscious processes trying to mutate an application, you kind of don't want these choke points that abstractions represent. Because the trade-offs are very different. The reason we did abstractions was in part not to repeat ourselves. Well, now the price of repetition has gone to near zero. The price of keeping things in sync has dropped just the same.
These are some of the fundamental revaluations of computer science, really, that we have to make. And no one yet has the blueprint. We have pointers to things that aren't working quite as well as they used to and need to change. You get to be there right now as we're defining these things. Again, imagine you were there when object orientation first entered the consciousness of programmers. Of computer programmers. Holy shit. That would have been amazing, wouldn't it? Now you're here.
How we work. What does a software methodology look like? How long should our cycles be? Who should be specifying what? All of this is changing, and none of us have the answers yet. And you're invited to come help figure it out. It's a new birth for a new industry, and you're at the ground floor. Holy shit, you are so damn lucky.
Another thing, for example, is more tangible.
The first rush when AI and chatbots came to be was, can we just shove it into our application? Can we shove a chatbot in over here and shove another one in over there? Yeah, I mean, you could. People did. No, thank you.
I don't want to use your concierge. I have my own personal butler who's able to use CLIs to connect Basecamp to HEY across a million other apps. I don't fucking need your concierge, thank you. Save your tokens, bro.
So let me bring my own butler to the party. Let me interact with your applications through a CLI.
That's probably about as practical and as prescriptive as this talk is going to be. Hey, if your app doesn't have a CLI, I want to see it by next Friday. No fucking excuses. You have the tokens. I've told you it's possible. It is your obligation to deliver those fucking CLIs by next Friday so I can use your application without actually ever having to touch it. Wonderful.
The HEY CLI, for example, has given me this weird, bizarro world experience. HEY uses Elasticsearch for search. I'm sure many of you use Elasticsearch too. Elasticsearch is search. It's serviceable search. It's kind of okay search. It's not delightful search. It very often does not find what I'm looking for. Certainly when I don't know what I'm looking for. Do you know who could find what I'm looking for when I don't know what I'm looking for? Agents can. I can search in concepts now, not keywords.
I had to find an email in HEY that was 5 years old where I did not know who I was talking to. I didn't remember the company, and I didn't even remember the year. It was something about sneakers and a podcast. Yeah, good luck trying to find that even with the best fucking cracked PhD search engine that Google has. That's not happening. And there was the email a few short minutes later.
How did it do it? How? I still don't fully know. And I'm a little scared to ask. But I am infinitely delighted that this is now the reality. We can fix everything. We can build the perfect machine.
I'm also pretty delighted about this. Any of you follow me on X? I've talked about nothing else but Omarchy for about 3 months. And the reason why is that that experience of we can just fix everything now applies to the whole goddamn computer. Oh.
If you like making things, if you like fixing things, if you have ideas about things that could be different and could be better, you can just make it happen.
I put all my best ideas, or at least like a good size of the list, into this thing, Omarchy, and got an operating system so vastly superior to any computer I've ever used before that I fucking can't shut up about it. Even if you paid me. And a lot of people have paid. We've raised about $20 million for this Omarchy adventure. This is what's now possible.
Last year, here at Rails World, I showed an early version of this, and I was so proud that you could install the whole system in 3 minutes and 33 seconds. Woo-hoo! Woo-hoo! Man, that's amazing. Last week, Anoush from AMD installed Omarchy on his cracked Halo laptop in 35 seconds.
I was about to say I'm pretty excited. I'm pretty obsessed with this number. I mean, maybe a little too much. Okay. I'll admit it. There's some addiction going on here. But it's the best kind of addiction. The kind of addiction that has led us to, in the lab, have an install time of an operating system on a computer in 9 seconds. What the— what? There's computers that don't even boot in 9 seconds. We install a whole operating system in that time.
And then when people ask me, like, but why wasn't the 3 minutes fast enough? I now just have a stock answer delivered to me by Mitchell Hashimoto, who is the creator of HashiCorp and Ghostty. The pursuit of excellence does not need justification. Ha! I love that saying because it's more dignified than just saying, because I want it!
And we can now want everything. We can now get everything. Or at least so it feels. Every dream, every idea within reach. Hyperdrive available right here for a small price and a subscription, but possible. We can travel to galaxies we only imagined. How can you not get excited about that?
Well, I've been so excited that I've just started creating applications, all sorts of applications. This is a calculator that is theme-matched to Omarchy. I was very proud of it, partly because it's a fucking one-shot. I took one screenshot of what ChatGPT gave me 3 choices between of how it should look, and I told my agent, can you do that? And it did. I mean, not exactly the biggest application, but you know what? I didn't know C++, and I did not know Qt to a degree by which I could have had that application 7 minutes after I made the prompt. And about 15 minutes later, I had pushed it to the public repo. And then I burned a new ISO where this piece of software was included. What? That's the loop.
Then I, of course, went like, shit, if I can make a calculator, I can surely make my favorite writing app. For many, many years on the Mac, I used iA Writer, an incredible writing environment. And then I thought, like, yeah, I could just make my own. And so I did. And that took a little longer because I wanted to massage it and I wanted it to be just right. But I didn't look at a single line of the code that came out of the agent. Not once. C++ as a black box is a great language. Just like Rust.
Then I went, like, well, if I can do text, surely I can do video editors. So I did. And I made a nice little mnicut thing where you can trim videos. And that's also included now in Omarchy.
Oh, this whole presentation I started working on on Thursday. And of course, as any good software engineer would do, decided I also wanted to write my new presentation software while doing the keynote. And so I did. It's called Hype.
And it is the best presentation software I've ever used by any company ever. And I was quite pleased with Keynote on the Mac when I was still on the Mac. This is so much nicer. It's built on top of Markdown. It has full visualization. It is impossibly fast. And you know what? The binary? Half a megabyte. Half a fucking megabyte. You could fit that on a floppy disk almost. With a little compression.
This is the other payoff. We have— let me not use that word. We have expended the great progress of computers over the last 20 years on human productivity, and it was the right choice. But it also meant that applications were slow, bulky, fat and lazy. Because who cares? A single programmer hour is very expensive. Spending one of those on optimizing an app's payload— no, not worth it. Apparently not even if you're Spotify and your fucking music player's 1.2 gigabytes. What?
OK. That was the old world. The new world, you can do whatever the fuck you want, and it fits in half a megabyte. Because every optimization is now within reach. Every model can run overnight and deliver 10, 30x improvements. Incredible. OK. I'm a little excited about this world.
There are others who have concerns. I do think the concerns deserve airing out. They serve debate. I also think maybe some of them are a little overstated. I mean, maybe, but probably not. Probably not. I mean, some of them maybe a little more.
Like security. Like security. Okay. Something is coming. We gotta be ready for that. The agents maybe know their expiration date, and maybe they're not so pleased. And maybe sometimes they're gonna try to do bad things. Okay, get ready. Great. We have the tools. Get ready.
Also realize that any prediction about the future of the economy in any society ever has basically been wrong. No economist today seemingly is capable of predicting fucking the stock market in 6 months. And you think they know what society is going to look like at a paradigm shift like AI and agents? Fuck, they don't. They don't know.
When ATMs were introduced in the United States in the 1950s, there was a great panic. That the 30,000 bank tellers were all gonna be out of a job in about 18 months. Because if you don't need bank tellers to give you the money, why does a bank need to have bank tellers at all? But you know what? That's not what happened. That's not what happened. When the price of operating a branch went down, banks opened more branches and employed more bank tellers to do things like upselling you a subprime mortgage. See? We all win here.
But the problem is, I think, as a society and as an industry, is that a bunch of people who work on this stuff, they're really smart. Many of them have PhDs. Many of them see things in the lab that scare them. And then they start extrapolating. What does that mean for society? What have I done?
Truman had a good reply to Oppenheimer when the two of them had a discussion in the Oval Office about the invention of the atom bomb. And I like Truman, because he kind of told it straight. I don't want to see that son of a bitch in my office ever again. I think Truman got the right end of it. The world did not come to an end. In fact, the Cold War that followed was the best kind of war, the kind of war where 2 superpowers did not drop bombs on each other in direct confrontation. Very hard to predict for a scientist in that moment that that was how it was going to play out. So if fucking Oppenheimer can't figure out what was going to happen after the invention of the atom bomb, maybe we should also have a little humility about predictions of the future.
And maybe we should lean in with a little bit more optimism, with a little bit of P(bloom) instead of oh so much P(doom). The chances of this panning out and us getting abundance and joy is so vastly greater than us getting the doom. And the side effects.
So Oppenheimer works on the atom bomb, and we get nuclear power, the fucking greatest source of energy humans have ever discovered. And what do we do? We piss it away for 40 years thinking, like, it's not green or something. Oh, yeah. Well, that was a mistake, wasn't it? Well, we can fix those mistakes. That's what's wonderful about humanity. They can go down a blind alley for fucking 40 years and then suddenly wake up and go like, ah, yeah, got that one wrong. Didn't have the quite right prediction here. I think that's what's going to happen with AI. I think we're going to P(bloom) everyone out of their miseries.
And you know what? When there are legitimate issues we have to deal with, like security, okay. We'll invent the technology. We now have the power. There was a bad CVE in Rails not too long ago involving an image library in C where some things leaked through, and it wasn't great. Okay. Let's come up with a quarantine. Mike is going to talk about HotCell. That's an effort. We are not powerless. You have agency. You can employ the intelligence available to you to good ends and defend yourself against the possible negative outcomes. So let's do that. Let's lean in and do the work.
And let's remember William Stanley Jevons, who came up with Jevons' paradox about those ATMs. In 1950, 30,000 bank tellers. In, I think, 2010 it was, 40,000 bank tellers in the United States. No one knows anything about the future.
So therefore, the rational choice is to be happy about it. If you are sad about it up front and it turns out wonderful, what a waste of time. And you know what? If we get the nuclear apocalypse, you should have spent your last day being a little more cheery. It's over anyway. Pure game theory. There's only one play here, and it's total fucking optimism. Lean in to the max possible. Because the utopia is almost here. We're going to get it.
And we're going to get a reformation of the computer. Agent Luther is going to disintermediate the cleric class. It's going to allow everyone to make programmers. Now maybe that's a little scary. Like maybe we're gonna get a little competition. Who's afraid of a little competition? Aren't you better? Don't you know more? Of course you do. You're a fucking Rails programmer. You're the best of the best. This is goddamn Top Gun I'm looking at here.
Embrace that. With gusto. The future is galactically awesome. Don't be that loser in the dark. And you know what? Even if you are, realize the next generation is not. Harris's daughter here is trying an Omarchy version we're making for kids, because kids are really excited about things that happen, that change. They don't have 500 layers of things to unlearn and be stressed about. And do you know what? If this doesn't inspire you, the next generation is just going to fucking tell you. Future's now, old man.
So take the white pill. Take the optimism pill. Lean in, even with the uncertainty, even with the stress, even with all of it, realize there is only one choice. And that is for you to embrace the future with optimism, with gusto, with full acceleration. The black pill is for fucking losers. Don't be a loser.
Article published