Steve Yegge on AI Agents, Gas Town, and Why Coding by Hand Is Ending
The Pragmatic Engineer
Steve Yegge has been writing software for about 40 years, including long stints at Amazon and Google, and is known for blunt, often funny blog rants about the industry. In this conversation with Gergely Orosz on The Pragmatic Engineer, Yegge, currently unemployed and "doing whatever I want," makes a sweeping case. He argues that writing code by hand is ending, that most engineers are dangerously behind, and that the next few years will bring both societal upheaval and a burst of bottom-up innovation. He also talks about Gas Town, his experimental agent orchestrator, which he openly calls a mess that most people should not use.
What engineers need to know keeps moving
The conversation starts with two of Yegge's old essays. The one readers most often call their favorite is "Execution in the Kingdom of Nouns," written in his early days at Google. It was a fairy tale about a land with no verbs, and it made the point that Java's code volume grew faster than the functionality it delivered, which is a bad trade. Yegge wanted a language with first-class functions. He notes that Java has improved a lot since then, and that the post "raised a lot of eyebrows at Sun."
Orosz then brings up "Rich Programmer Food," the essay arguing that programmers who don't understand compilers work with "a layer of magic" between their code and the machine. Yegge calls it one of his most important posts. At Swyx's AI engineering conference in New York, a man introduced himself as a longtime player of Yegge's (never open-sourced) game and said that reading the essay in high school led him to become a compiler expert, earn a PhD, and found a successful startup.
Asked how the essay has aged, Yegge takes a broader view. The goalposts for what a software engineer must know have moved every few years since he started in the 1980s. It used to be assembly language and bit manipulation. In the 2010s, he and his colleagues noticed their favorite bit-twiddling interview questions "bouncing off candidates who'd never seen a bit before." After some soul-searching they concluded the knowledge was no longer needed. Yegge admits much of his ego and identity was tied to his compiler background, and says it is not useful "in any meaningful sense anymore." The explanation is simply that "we're just walking up the abstraction ladder."
His clearest example is computer graphics. In 1992 he learned the algorithm for deciding where the next pixel on a line goes, the building block for rendering triangles and polygons. Two years later the same course was teaching animation. The jobs moved too, from writing device drivers to building game worlds and physics. "Graphics showed us the way," Yegge says. By contrast, he sees software engineering jobs as having been very stable since mobile and cloud, a period where he thinks people stagnated and assumed the curriculum was finished. Orosz adds that distributed systems were the last hard problem of the 2010s, and that the rest of that era was busy with migrations and a hot hiring market, including bootcamp graduates getting good offers in 2021.
From skeptic to believer
Yegge says his first real moment came when the original ChatGPT (he and Orosz settle on December 2022) could write reasonably coherent Emacs Lisp functions. The output was small and janky, but it worked in an obscure language. Friends in AI had been saying "any minute now" for 20 years. This was the first time he thought, "oh, okay, I see now."
He was still skeptical. When rumors spread early the previous year that Anthropic had an internal command-line tool writing its code, Yegge says he flatly rejected the idea along with everyone else, until he used Claude Code: "I was like, oh, I get it. We're all doomed." He wrote "Death of the Junior Developer" around then.
What convinced him was the trajectory. If GPT-3.5 could write a coherent Emacs Lisp function, he wanted to see what it would do a year later. A year later GPT-4 was writing around a thousand lines of code. Since most of the world's code sits in files of a thousand lines or fewer, Yegge reasoned that models could now make credible edits. He decided he was on a curve that wasn't stopping, admitted he was behind on AI fundamentals, and says he spent a year doing nothing but reading papers.
"The days of coding by hand are over"
The back cover of Yegge's book Vibe Coding, co-written with Gene Kim, says the days of coding by hand are over. Orosz says he only came to that view recently with Opus 4.5. Yegge says the realization came 12 to 13 months earlier, and that the line comes from Erik Meijer, whom he describes as one of the most important compiler and language people in the world, with contributions to Visual Basic, C#, LINQ, Haskell, and PHP tooling. What struck Yegge and Kim was that someone who had spent his life building tools for writing code was saying developers would stop writing code. Yegge's explanation: "He sees the curves." Exponential curves get steep fast, and he believes we are entering the steep part this year.
Orosz plays devil's advocate: nobody knows when a curve flattens. Yegge says the world is full of "unbelievers" who picture an S-curve and have believed we were at the top ever since GPT-3.5. His counterargument has three parts. First, Opus 4.5 was already two months old and most people hadn't really used it. Second, by his estimate the gap between Anthropic model releases shrank from about four months at the start of the previous year to about two months at the start of this one. Third, he says the bugs and mistakes people complain about now get fed back into training so the next model doesn't make them. He predicted the next Anthropic model would "freak people out."
Layoffs and the 50% dial
Yegge says the collision of these curves will cause societal upheaval and that it has already started. He is angry at Amazon for laying off 16,000 people and blaming AI "without an AI strategy for it." He expects most of those people to struggle to find jobs and thinks nobody has a plan for what comes next.
His explanation, which he expects people to hate, is economic. Every company has a dial from 0 to 100 for what share of engineers it must cut to pay for the rest to use AI, because engineers are starting to spend the equivalent of their own salaries on tokens. To make half your engineers maximally productive, he argues, you may have to let the other half go. He adds that roughly half of engineers don't want to prompt anyway. In his view companies are setting that dial to about 50%, and big companies will lose about half their engineers, a disruption he expects to be far larger than what happened around COVID.
At the same time, he sees AI letting non-programmers write code, and letting engineers who "believe the curves" form groups of two to thirty people whose output rivals big companies. He points to Andy Jassy saying Amazon will do the same work with fewer people. He speculates about a future where Amazon "is not even a thing anymore," while admitting we lack words for much of what is happening. He is blunt that anti-AI knowledge workers will struggle ("like being anti-the sun"). He also frames AI as augmentation rather than replacement, and thinks it will be quite a while before companies trust fully AI-written and AI-deployed code with no human involved.
The eight levels of AI adoption
Orosz raises Yegge's provocative line that engineers still using an IDE are bad engineers. Yegge softens it: he knows excellent engineers, better than himself, who are at level one or two on his chart. But he says he feels "profoundly sorry" for engineers who ask Cursor occasional questions, carefully review its code, and check it in, and warns that such a person is "going to get fired."
He first drew the chart on a whiteboard in Australia for a group whose members were at very different stages:
- Level 1: no AI.
- Level 2: the IDE agent asks yes/no permission for each action.
- Level 3: "yolo" mode, where trust rises and the agent just does its thing.
- Level 4: the code gets squeezed out of view. You focus on the conversation with the agent, not the diffs, and review less.
- Level 5: you work only through the agent and maybe look at code in an IDE later.
- Level 6: you get bored while your agent is busy, start another, and get hooked. With enough agents running, one is always waiting for you, so you end up multiplexing between them and "can't leave."
- Level 7: you've made a mess, for example by texting the wrong agent, which then built a whole project inside another project.
That mess is what pushed Yegge toward coordination: can Claude Code run Claude Code? Throughout the previous year, people kept trying to make it run itself, and it kept stopping. Yegge says he pushed hard on that problem and built tooling for it.
The IDE isn't dead, it's changing shape
On his public debate with Nathan Sobo of Zed titled "the death of the IDE," Yegge says his position follows from believing AI will eventually do everything. IDEs were never really about writing code. They were about bringing tools together into one big tool, a role MCP now partly fills. He now sees the IDE returning in a new form and points to Claude Cowork as "Claude going, 'Oh, I need to be for real people.'" He thinks its form factor probably suits the average developer better than Claude Code: IDEs again, but built around conversations and monitoring.
Orosz mentions that his brother built Craft Agents, a similar visual tool connected to company data sources, and that some developers preferred it because parallel agents are easier to see. Yegge's point is that the tool doesn't matter as long as people try. He calls token burn "probably the single most important proxy metric" a company can track today, because it shows people are trying, failing, and learning. That surfaces organizational bottlenecks early and moves engineers up the levels.
Trying well is its own problem. People ask for something, the model does the wrong thing, and they dismiss it as garbage. Yegge compares AI to a shovel: you still dig with it, not like the enchanted brooms in Fantasia, but it's a shovel you didn't have before. He then makes what he calls a contentious claim: "most people can't read," meaning they read slowly and five paragraphs feels like a lot, while "that's the AI just clearing its throat." Because Claude Code demands reading "waterfalls of text," he expects a limbo period until better UIs arrive, with recursive summarization needed. His bold prediction is that by the end of this year most people will program by talking to a face on screen, such as Gas Town's mayor rendered as a talking fox, which will dispatch workers on their behalf.
What Gas Town is and how it's organized
Yegge places Gas Town on a simple progression: 2023 was completions (he calls the completion acceptance rate a stupid metric, though a decent proxy for whether people were trying), 2024 was chat, 2025 was agents. If chat is completions in a loop and agents are chat in a loop, the next step is agents in a loop, which is an orchestrator. "It's agents running agents."
He admits the system is complicated and had been broken all week while he migrated it to Dolt, a Git-backed database. His own Beads project, he says, is "just Git plus database crammed together badly," and Dolt does that properly. Ideally, Gas Town has one "mayor" you talk to, who dispatches workers.
The structure reflects a debate Yegge heard from people at Anthropic, which he calls the "min-maxing context" argument. One camp fills the context window with rich material so the model is "wise and all-knowing." The other keeps windows as short as possible, one task then kill the agent, because of quadratically rising cost and declining cognition as token counts grow. Yegge noticed he used both, and turned them into two worker roles. Polecats are the minimal-context workers. They get well-specified, self-contained tasks broken into subtasks. Crew are the maximal-context workers for hard design problems, where he says, "Read all these docs and then we'll talk."
Polecats differ from ordinary sub-agents in being first-class: they have their own identity and inbox, you can talk to them, and you can track their performance over time by computing skill vectors on their work. Yegge thinks standard sub-agents are opaque ("let me know when you're done"). In Gas Town you can look at a stuck polecat and poke it. "It doesn't try to get out of your way. It's in your way." He says that after Gas Town had been down for a few days, working with plain Claude "just stinks by comparison," because Gas Town works like an idea factory. He also warns it can pull you into not sleeping or eating.
A deliberate overreach
Yegge says he built something that "deliberately doesn't work," because it is too hard for current models. Even Opus 4.5 is "barely enough." Some Anthropic people told him they like it but are a bit embarrassed, since much of it works around their model's weaknesses. Yegge's view is that the model was never trained to be a factory worker and will be soon. Much of Gas Town's complexity, especially the monitoring roles that just tell Opus to be smarter, puts it "on the wrong side of the bitter lesson." He expects it to flatten into crew and polecats and then scale.
His main goal, he says, was to shift the Overton window. A year ago, people said swarms and orchestration weren't coming. Now they tell him he's "being pretty aggressive," which he sees as moving the conversation from impossible to possible. He also wanted to have fun and see what's next. His next plan is to link 100 Gas Towns through the project's Discord community. Pointing to Moltbook as proof people will pay for their own agents' inference for fun, he expects to learn the mechanics of federation, while guessing they may be "retracing Ethereum's steps."
Where swarms might work today
Yegge repeats that people shouldn't use Gas Town unless they are doing research and understand it's a proof of concept. Still, he describes people at large companies looking for problem spaces where it could work reliably now. One company sets up bespoke data centers in any region and describes the process as about three months of "miserable button presses" installing and checking software. The acceptance criteria are very clear, and they think a swarm could converge on a working data center, which could meaningfully expand how many they can open. The same person noted that during production incidents the system is already in an unknown broken state, and wondered how much worse AI could make it. Yegge cautioned that it could make it a lot worse, but saw a case for AI in certain investigation-mode outages. The pattern he sees is "fuzzy problems" where messy results are fine because the cumulative work is what counts, and he says that's how he codes now.
Asked why a craft-focused engineer would stop looking at code, Yegge gives a ceiling estimate. By his reckoning, what agents can productively build before dissolving into a mess currently sits between half a million and five million lines, probably nearer the lower end, and he expects the next Anthropic model to push it to a few million. That is still small next to enterprise code. So he thinks your ability to benefit from AI depends on whether you have a monolith. Most companies do, and he says no model in the next 18 months will fit one in context. You'll need to break it up, or, since it's getting faster, consider rewriting your stack.
The vampiric effect and the new work-life balance
Yegge describes something he thinks the industry needs to discuss: a "vampiric effect." AI gets you excited, you work very hard, and you capture a lot of value, but it drains you. Even working only for himself, he finds himself pushed to his limit and napping during the day. Friends at startups report the same, and he jokes that they load each other up with context to force each other into naps. People are getting tired and cranky.
His frame is value capture. Companies are built to give you more work until you break, and people have always had to learn to push back. If an engineer becomes, for argument's sake, 100 times more productive and still works eight hours, the company captures all of that, which Yegge calls unfair unless the engineer holds meaningful equity. The opposite extreme also exists: people who work ten minutes a day, get 100 times as much done, tell no one, and keep all the value. Neither is healthy for a group. His answer is that everyone must learn to say no quickly and decide how much of their gain to keep and how much to pass on. This is "the new work-life balance," and he says our cultural expectations point the wrong way.
For leaders, his warning is that max-speed vibe coding leans heavily on System 2 thinking. The easy work is automated and the hard thinking remains, so people drain faster. You might get only three productive hours a day from someone who is still 100 times more productive than before. Should you let them work three hours? "Yeah, you better. Or your company's going to break." Orosz brings up Peter Steinberger, whose output he compares to a team of ten good engineers, and notes that he doesn't sleep much but owns his project. Yegge's historical parallel is Perl, which he calls a massive accelerator (Amazon's website was built in it, and he calls PHP "a fake Perl"). It created a rift in the industry, with second-class citizens and new cultural dynamics.
Anthropic's hive mind and slot-machine programming
Orosz mentions Dario Amodei floating the idea of paying staff for value they created even after leaving. Yegge jokes that Google can send him a check. He describes Anthropic as "unlike any company on Earth right now," operating in a fragile space and running as a "hive mind." He compares it to a purely functional data structure from Chris Okasaki's book, which never mutates and only adds, like improv's "yes, and." Instead of spec, build, complain, ship, people gather around a prototype "like a campfire" and keep building it until it becomes the product. In his view Anthropic does this at scale with thousands of people.
Orosz notes this reverses the Lean Startup norm of discarding prototypes. Yegge says what changed is that prototypes are now effectively unlimited: you make them until one is great, then launch it. He says Claude Cowork reportedly went from someone's prototype to launch in ten days. Orosz adds that Boris Cherny told him he built 20 working prototypes of Claude Code's task-list feature in two days. Yegge calls this "slot machine programming," while saying he doesn't want to put words in Cherny's mouth. It ties to his book's FAFO framework for the value of vibe coding, where the "O" is optionality: making many prototypes lets you defer decisions until you know the answer, "which is cheating," and he expects it to change how companies are run this year.
Why Google stopped innovating, and why big companies may be dying
Yegge offers what he calls a take he has never shared before. He went through Google's golden age, when it was a hive mind like Anthropic, nobody was mean, and you could chat with Larry and Sergey. Then, he says, innovation died. Since about 2008 he sees nothing new from Google except acquisitions. He excludes Gemini as "a different Google," pointing out that Google invented LLMs and did nothing with them for five years. Google became ossified and territorial. A strong engineer he brought over from Microsoft needed six months to find work nobody had claimed, because people at Google claim work and never do it.
His diagnosis is Larry Page's "more wood behind fewer arrows" when he became CEO. Before that there was more work than people. Afterward there were more people than work, and he traces the land grabs, backstabbing, and empire-building to fighting over work. Anthropic, on a frontier with effectively infinite work, doesn't have this problem. A friend told him Amazon avoids some of Google's problems by keeping everyone slightly oversubscribed, and Orosz says he has heard the same about Apple.
Orosz asks the obvious follow-up: if AI lets people do all the work, won't big companies drift into politics? Yegge agrees. Their biggest problem will be finding more work or cutting people. He sees the same thing in Gas Town at small scale: the hardest part is feeding it, because it works so fast, and coming up with good designs for it is why he's napping all day. He adds that Gas Town itself will probably be dead in four months, since it's "the shape that worked in December 2025."
Orosz then asks why, despite all the claimed productivity, we don't see much more output from companies. Yegge first points to low tolerance for non-determinism: firms won't replace, say, call-center software because AI can be wrong, even though humans are often wrong too. He expects early results from adopters to appear quietly in quarterly earnings. Then he reframes it: maybe innovation at large companies is simply dead, and new platform shifts bring innovation from the fringes because of the innovator's dilemma, as with cloud, or Facebook starting as one college student. Hyper-productive engineers at big firms hit downstream bottlenecks, get shut down, and quit. "We're looking at the big dead companies. We just don't know they're dead yet."
Platforms, building blocks, and the end of permissioned open source
Orosz uses Zendesk as a "punching bag." It sells a UI and workflow, but AI-native companies want an API, which he says Zendesk won't provide because it wants to sell its own AI at a steep markup. Yegge calls this his old platform rant in real life: a company that doesn't become a platform will build itself out of existence. He isn't sure MCP will stay dominant. He notes Anthropic found that having models write code against APIs can work better, and says he doesn't follow the space closely enough to know. He expects a large ecosystem of building blocks for non-technical builders, such as storage and matching services, and agrees with Orosz that reliable, stateful services with SLAs are a real opportunity, because "AIs are lazy" and will use anything that saves tokens.
On open source, Orosz describes widespread remixing: people have AI modify a project and republish it without asking. Yegge says forking used to be a declaration of war (Roo Code forked Cline, then someone forked Roo Code, and Cursor is a fork too). He expects it to become an everyday occurrence because maintaining a fork is now cheap. When Jeffrey Emanuel apologized for forking Beads, Yegge told him to go ahead: "Let's have Beads in every language."
Gamification and product stickiness
Orosz revisits Yegge's 2012 essay about the Borderlands Gun Collector's Club, where players kept returning after finishing the game to chase custom guns, an emergent "elder game" the designers seemed not to have planned. Many products have since adopted such mechanics. Yegge notes people are making games out of Gas Town, and says factory-management games show why running a real factory of agents is fun. Asked whether Claude Code's constant on-screen activity is a form of gamification, he credits Anthropic with "the best product managers in the world" and "absolute magic" with command-line UIs, but repeats that this won't work for most developers, which is why he sees Cowork-style tools as the direction.
Vibe-coding debt: "heresies" and the bitter lesson
Yegge says vibe-coding debt is real, and previews an upcoming blog post about what he calls "heresies." In code bases nobody is reading, an incorrect idea such as a wrong architecture or data flow can take root among the agents. It spreads and keeps coming back. Gas Town had a recurring "polecat heresy." The symptom is a product that misbehaves at the edges for unclear reasons, until digging reveals a fault line, for example two complete, live databases being chosen between at random. Even after cleanup, one stray mention in some doc can revive it. His fix is to document the heresy at the top of your prompting, remind agents periodically, or add tooling to block it. Another example: his agents insist on opening PRs when, as maintainer, he wants them to push to main or a branch and leave the PR space for contributors. He could add hacks, but that would fight the bitter lesson, and he predicts "Opus 5 will be fine."
He explains the bitter lesson through Richard Sutton's roughly 800-word essay: don't try to be smarter than the AI by adding human domain knowledge, because bigger always wins. He mentions much larger training centers being built in Australia for energy and land, and predicts models 10 times smarter or more. Asked whether it pains him not to step in as architect, he says that, having been a VP of engineering, managing 80 agents feels much like managing 80 engineers, since any of them can screw up. He calls the two "isomorphic." He then concedes the skeptics' point: the curve is S-shaped, because resources eventually run out. But he claims at least two more cycles remain, which he says means models at least 16 times smarter than today, enough for AI to subsume all knowledge work.
Personal software, human moats, and radically transparent startups
Yegge believes demand for software will only grow and that nearly all current software, SaaS and HR systems included, is "garbage." At a vibe-coding workshop in Sydney, an attendee built his own airline check-in app and got it into the Android queue before Southwest shut him down as a bot. "That's what people want," Yegge says: personal, bespoke software. Orosz lists his own frustrations, including a Dutch postal system that couldn't ship to Canada for a week. Yegge replies that your agent will deal with it, and that whoever builds software agents prefer, and markets it to them, will win big. He calls himself an optimist who believes "it's all going to work out."
To a question about what can't be cloned if all software becomes trivial to copy, Yegge's answer is human connection. As more is automated, he expects people to want humans to curate, deliver, and do things for them.
He says small startups of two to twenty people now work very differently. His core belief is that everything must be either fully transparent or deliberately hidden. He recounts a team member being scolded for shipping a feature requested two hours earlier, because too much had changed in the meantime. At this volume, work is effectively invisible unless you announce it loudly, so others can stop you or integrate right away. He applied this to Gas Town by launching as soon as it roughly worked and asking for help. That led him to Dolt and brought over 100 PRs in the first few days. VCs are now "finding me everywhere," just as they chased Geoffrey Huntley after his "Ralph Wiggum" loop. He advises caution because anything built now has a short shelf life, and he isn't attached to Gas Town, which he expects to be replaced within six months.
Advice for the Copilot holdout, and what if he's wrong
For a staff engineer at a company still on GitHub Copilot, which Orosz says describes perhaps 70% of engineers who aren't yet adopting, Yegge says "get out." He calls Copilot the best tool in 2021 and now at the bottom, recalling an AI Tinkerers meeting where someone asked who uses Copilot, a person raised a hand, and the reply "Do you have to?" got a laugh. A "barbarian horde" using Opus 4.5 will eventually destroy companies that think Copilot makes them fast, he says. His prescription is half an hour a day with Claude Code, and for companies, as much token burn as investors allow. He also predicts that proof of work, meaning visible actual work rather than a résumé, will matter enormously, and that proprietary work is under threat because everything is easy to fork and route around.
Orosz asks what happens if Yegge is wrong and models plateau at 3x, or the next model is somehow worse. Yegge says learners would still be right, because "the damage is done." In his view Opus 4.5 turned this into a pure engineering problem. Models can already take a "town-size" bite out of a mountain, and engineers will wrap layers around them, like harnessing fire or steam. He adds that he worked on a nuclear reactor in the Navy.
Debuggers, workstations, and languages
Yegge's first job was at GeoWorks, whose debugger Swat he still considers unmatched. He later built a Clojure debugger for the JVM, but dropped it after disagreeing with Rich Hickey about JVM support. He notes that agents debug with printf. Maybe they just haven't been trained on debuggers yet and will "wake up in 6 months," or maybe debuggers are no longer needed. He doesn't know.
For workstations, his answer is "phone." He wants his agent setup on his phone and nearly has it working over Tailscale. The only thing stopping him from being addicted all day is how hard it is to type control characters. Orosz mentions that Steinberger dropped his phone-based tool because it was too addictive. Yegge has argued for 15 years that development doesn't need to be local, citing Google's cloud-based client (CitC, with Cider on top). He says Gas Town already maxes out his laptop because Claude Code uses a lot of memory, and he expects work to move to servers and mobile devices.
On languages, he thinks some currently work better only because of training data, and that eventually all existing languages will work equally well. He says TypeScript is a struggle for models today but won't be within one or two model generations. Part of him thinks languages no longer matter, like assembly for most people. Another part says energy is the scarcest resource and better algorithms are often language problems, such as finding the right DSL. So he expects the search for new languages to continue for efficiency, and possibly AI-designed languages for AIs, while in everyday work "you might not even ask your agent what language it's using."
Grief, and what comes next
Asked how he handled losing much of the craft he loved, Yegge again points to graphics: people were sad when hand-built techniques moved into hardware, then got much better games. In 1992, he says, people claimed you weren't a good engineer without assembly language, and today that sounds absurd. He describes going through grief about two years ago: intense anger, then roughly six or seven days at the peak, with weeks or months of lesser grief around it, when the world "went monochrome." He found himself checking off things that no longer mattered, like his ability to memorize, write, and compute. Then he realized he was writing ten times more code and having fun, and that he was clinging to the old just as he had with graphics. "The future is actually more fun than the present."
His prediction for 2027 is that his wife, who is not a developer but loves their family's video game and has many ideas, will be its top contributor, and perhaps the whole family will join in. He believes programming is becoming something everyone can do, and that mashups, now easy to make, are where innovation happens. That creates a new problem: with so much being made, people will need agents that know them well and can search this flood of new software and experiences, much as the early web needed aggregators and search engines. None of that exists yet, he says, and it is an opening for engineers who "believe the curves, pick a point on the curve and aim for it," so they're first in line when the AIs are ready for their idea. For now, he says, engineers are ahead of everyone else.
Tell me about your levels.
Level one, no AI. Level two, it's the yes or no, can I do this thing in your IDE. Level six, you're bored because your agent's busy.
What is Gas Town?
If chat is completions in a loop and agents are chat in a loop, well then we're going to put agents in a loop and that'll be an orchestrator. That's all it is. It's agents running agents.
There's a vampiric effect happening with AI where it gets you excited and you work really, really hard. I find myself napping during the day, but I'm talking to friends at startups and they're finding themselves napping during the day.
We're still not seeing that much more output from companies, teams that you would expect.
What if what we're actually observing is that innovation at large companies is now dead. So, I think what's happening is
Steve Yegge has been a software engineer for 40 years. He's spent decades at Amazon and Google, is famous for his brutally honest rants about the industry, and for being right a lot. He recently built Gas Town, an open-source AI agent orchestrator, and co-authored the book Vibe Coding with Gene Kim. In today's conversation, we discuss Steve's eight levels of AI adoption for engineers, from no AI to running multiple agents in parallel, and why 70% of engineers are still stuck at the bottom levels. Why AI is creating a vampiric burnout effect on developers, where you can be 100 times more productive, but only get three good hours a day. His prediction that big tech companies are quietly dying, and that small teams of two to 20 people will rival their output. And many more.
If you want to understand what the day-to-day of software engineering will look like in the near future, and how not to get left behind, 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.
So, Steve, really good to have you on the podcast again. What have you been up to?
Gergely, great to be back. It's been 10 months now.
Closer to a year, yeah. Close to a year, yeah. Boy, seems like forever. Yeah, sure does. There's been a lot going on. I'm unemployed right now, which has been incredibly fun. Unemployed or funemployed?
I am just doing whatever I want. That's what I'm doing, which is real nice. And had a couple software launches, which was nice. I had a book launch last year, which was nice. I've been living life.
Yeah, so for a very long time, you've been known as this kind of truth-teller of bringing in sometimes comical, sometimes really uncomfortable facts or observations, should I say? You wrote often in really kind of fun ways with rants. And a lot of them resonated with people. Do you remember what was a rant that really stood out at any point in time where you got some really good feedback either at that point or later you felt validated by it?
Oh, well, so a lot of people tell me, well, those who know, their favorite Stevey blog is actually Execution in the Kingdom of Nouns. I don't know if you remember that one.
I do.
Way back in the day. I was at Google, early days Google, and I was struggling to sort of get this idea across to people that Java's growth was super linear with the amount of code. So the amount of code would grow more than the amount of functionality, which is not a good place to be. And Java's gotten a lot better since then, right? But my post raised a lot of eyebrows at Sun because they were like, what is this guy complaining about? Why doesn't he just shut up, you know? But I was like, I want to use a language that has first-class functions. And so I wrote a very, very, very unusual blog post called Execution in the Kingdom of Nouns. People really loved it, where it was a story. It was just a fairy tale about a land where there were no verbs. And it was fun.
So one of your lesser-known blog posts, or for a lot of listeners, is called Rich Programmer Food.
Essay, Rich Programmer Food.
Yeah. And this was about compilers. Do you remember what you argued or what points you made?
Of course, that's one of my most important blog posts ever. I'm going to tell you, I met a guy, okay, who introduced himself at Swyx's AI engineering conference in New York. And he's like, I've wanted to meet you, Steve. I'm one of your players, okay? And I'm like, "Whoa." Cuz this dude's, you know, in his 30s and you know he's played my game. You don't understand the game that I wrote.
Well, why haven't
Most people haven't seen it cuz I didn't open source it. I will someday. It's just a pain in the butt. It's a really beautiful thing. And it created so much love in the players. For decades they would come back, right? But this guy was so into it and he's like, "I read your Rich Programmer Food blog post and decided to become a compiler expert. I became a PhD." He was in high school when he read it. Became a PhD, started his own company. He's got a startup that's doing really really well now. And he said it was all cuz of that post.
And this post talks about, I think you argued that unless you know how compilers work, you're not going to be a good programmer, an efficient programmer. I'm not sure what the phrase was.
There's going to be a layer of magic between what you're doing and what the computer is doing that is forever going to be sort of friction for you.
And then I think you even argued that some PhDs don't even understand how compilers work and this will make it really hard for them to be efficient.
At the time that was definitely true, right?
How do you think that post has aged? Because I think it was 2012 or so. Even then I would just assume it was a bit unconventional to say you need to understand assembly cuz it was high-level languages, right? Java was in its prime, C#, Ruby was starting to come out. I mean, heck, JavaScript was starting to become big. React will start in a few years. And most developers would have thought, "Why would I need to know compilers, assembly? I mean, that's what the compiler is for, right?"
Yeah. You're asking a really really really foundational question. You're asking me what university should teach, is what you're asking me, Gergely, okay? In the skies. And you know, those goalposts have moved every few years since I got into this game in the '80s, all right? What you need to know in order to be a software engineer, it used to be assembly language. It used to be lots of bits and stuff like that. And over time, my buddies and I realized that our favorite bit manipulation questions were starting to bounce off candidates who'd never seen a bit before, right? And we really, you know, we did some soul-searching in the 2010s, and we were like, "Do you really need to know how to manipulate bits in a byte with XORs and stuff like that anymore? Probably not, right?" And that was a depressing realization cuz we had prided ourselves in knowing how that stuff works, but we just don't need it anymore. And the sad reality is that I had a lot of my own ego and identity wrapped up in my sort of compiler background. It's interesting, right? But it's not useful in any meaningful sense anymore.
And is it not useful because the compilers have gotten so good at optimizing, for example? Is it that the problems have moved on to higher layers?
Yeah, we're just walking up the abstraction ladder, that's all.
And we're not even talking about AI just yet. Like this happened even
AI? Did you say AI? No, not yet. We will say it, but even in the, I remember, late 2010s, it didn't really come up. In my career, I can only remember one time where it would have been nice to know what the compiler did, but even then it might have been a red herring, honestly.
Look, what you have to know just keeps moving. They keep changing the courses, they keep changing what they teach. Many people don't see this because they're only looking a year or two or three back and, you know, looking a little bit forward, but I've been doing this for 40 years, and I can tell you they teach you very different things now than they used to teach, because you need to know very different things. And nowhere is it more evident than when we saw the exponential curve of the graphics industry, computer graphics. Look at graphics today compared to '92 when I was learning graphics in university and I had to learn how to literally do the algorithm to figure out where the next pixel goes on a line so I can render it so eventually turn it into a triangle, which is a polygon. Meanwhile, 2 years later I took the same course and we were doing animation. I didn't need to know what a polygon was. I mean, I did, but not at that level, right? The whole ladder just kept moving up and the jobs changed. Originally, they needed people that could write device drivers and now they need people who can do game worlds and physics and all this stuff, right? Graphics showed us the way. This is what happens. And software engineering jobs have been very stable for, I don't know, since iOS, since mobile and cloud. Those are the last two big innovations, right?
Yep. Steve just made the point that the industry goes through these massive material leaps from raw pixels to game engines, from bare metal to cloud. And if you're building software today that needs to make that leap to enterprise grade, there's a tool that handles exactly that. This is our season sponsor, WorkOS. If you're building any SaaS, especially an AI product, authentication, permissions, security, and enterprise identity can quietly turn into a long-term investment. SAML, SCIM, directory sync, audit logs, and all the things enterprise customers expect. It's a lot of work to build these mission-critical parts and then some more to maintain them. But you don't have to. WorkOS provides these building blocks as infrastructure so your team can stay focused on what actually makes your product unique. That's why companies like Anthropic, OpenAI, and Cursor already run on WorkOS. Great engineers know what not to build. If identity is one of those things for you, visit workos.com. With that, let's get back to the question of what the last real innovation in software engineering actually was.
And it's been kind of dead since then, actually. I don't want to say AI cuz we're not talking about it yet, but I think we went through a period where people stagnated a little bit, where the courses didn't change very much, and we thought this is all we're ever going to need to know.
I feel the last big innovation, correct me if I'm wrong, was distributed systems. I thought that was the last kind of hard problem, starting from the 2010s when Uber brought microservices into there, how you scale services, how you store large amounts of data. I feel that was the
It was a big slow
Yeah, but honestly, I feel there's a lot of migrations happening, new React versions coming up and developers struggling with that, Apple every year throwing a screwdriver in the wheels with the new breaking version, Android developers needing to retire an old Android version and deciding where to cut it off. So, I feel there was that kind of migrations thing, and also business was just good, right? Everyone was growing, everyone was busy hiring like there's no tomorrow. There was a time in 2021 the market was so hot, a lot of boot campers with 3-month experience were getting offers at pretty good companies cuz everyone was so desperate to hire.
Yeah.
And then came AI in 2022. One thing that always struck me about you, even in the 2020s and even before, you're always pretty pragmatic. By trade you were always into compilers, debugger tools, that's where you started. You worked on hard problems at Amazon, at Google, never shied away from getting into hard technical problems and all these things. And when AI came out, I don't remember you saying, "Oh, this is amazing. This is going to change the world." How did you feel? Were you kind of observing, skeptical, at the very beginning, right? When you first came across LLMs? How was that?
I was pretty blown away that they could write fairly coherent Emacs Lisp functions. Like ChatGPT, the original one in December 2023.
2022.
2022? Yeah. Boy, time flies. It could already write code in a weird language, right? Not very much of it and it was janky, but for me that was the beginning of, oh, right. You know, cuz I've had friends in AI for 20 years saying any minute now, any day now, right? And they'd show us and it would complete better and better and better and this was the first time it was like, oh, okay, I see now, right? But I was still skeptical like everybody else, and I can tell you because when the rumors came out about Claude Code at the beginning of last year, right? That Anthropic had a tool internally that was writing code for them and it was a command line tool. I, along with everyone else, went, no, it's not. We were just flat out rejection. Just absolutely not happening, right? Until I used it and then I was like, oh, I get it. We're all doomed. Right? And then I wrote Death of the Junior Developer right after that, actually, I think. Gosh, it might have even been after 4.0 came out that I did Death of the Junior Developer. But things changed really fast once that came out. So was I a skeptic? Yes, but did I pay attention to the curves from the very beginning? I figured if GPT-3.5 can write a coherent Emacs Lisp function, then in a year, let's see how they do. And in a year, 4.0 was writing a thousand lines of code. A thousand lines. Dude, most of the world's code is in files of a thousand lines or less, which means that it can make credible edits. It wasn't able to up until 4.0 came out, right? And so, man, it was at that point when I was like, okay, we're on a curve. This is a ride. It's not stopping. Let's get on the ride and see where it goes. And I dove in, right? And I was behind. I didn't know AI. I didn't know the fundamentals, I didn't know the lingo. You know, everybody knows this stuff now, right? But I spent a year doing nothing but reading papers and catching up, right?
So, in this book, Vibe Coding, I remember last time you were on the podcast, this book was about to come out and I was reading an early version of it. But the back cover, I just read the back cover and I realized that you must have written this about a year ago and it says the days of coding by hand are over. When did you realize this? Because I've realized this recently with Opus 4.5, but this was well before that.
Mhm, yeah, it was a year ago. Let's see, what is it right now? January, so it was over a year ago. It was 12, 13 months ago when I first realized. And that wasn't even my quote. That was Dr. Erik Meijer, right? The inventor of many many many things in the programming world. One of the most important compiler people in the world. That dude, think about it. He spent his life building technology for developers to be able to write code. And he's saying developers aren't going to write code anymore. What would possess somebody to say, "Well, my life's work isn't really," right? And that's what caused Gene Kim and I both to go, huh, right? You know, he made huge contributions to Visual Basic and C# and LINQ and Haskell and PHP with a pig, is that what it's called? Right? All him. And he's just like, "No, we're done. We're done writing code." I mean, that's
That's pretty big words from a languages person. One of the most famous in the world.
Right? What does he see that we didn't? And he sees the curves, man. It's that simple. It's like exponential curves, they get real steep real fast. And we're heading into the steep part this year.
So, the inventor of C# and Visual Basic is saying that we're done writing code. But even if the AI writes all the code, someone has to verify it. And that's where our season sponsor, Sonar, comes in.
Sonar, the makers of SonarQube, has introduced the agent-centric development cycle framework, ACDC, a new software development methodology designed for the unique scale and speed of AI-generated code. It's towards a more intentional four-stage loop that gives agents the guidance they actually need.
The four phases being guide. First, agents need to understand the canvas on which they're being asked to create so that the output fits with what the developer and organization require. Generate. The LLM-based tool generates the code it believes will achieve the desired outcome within the right context. Verify. Next, the agent is deliberately required to check its work, ensuring it actually achieves the desired outcomes and is reliable, maintainable, and secure. Solve. Finally, any issues identified are provided to a code repair agent to fix.
To power this, Sonar has significantly strengthened its offering, introducing products and capabilities like Sonar context augmentation, SonarQube agentic analysis, SonarQube architecture, and SonarQube remediation agent. Head to sonarsource.com/pragmatic to learn more about the latest with Sonar and how it's empowering organizations to embrace the agentic era. With this, let's get back to Steve's exponential curves of AI improvement.
Playing devil's advocate, you know, one thing about being an engineer is you can draw up curves, but you never know when they end or if they flatten or whatnot. We can see where it has come. What made you believe that this curve would keep going, especially that with LLMs, the fact that it even kind of works was a bit of a, I guess, surprise for a lot of people. And the fact that it kept scaling is a surprise. And there's this question of how long they will scale.
Yeah, so the world is filled with unbelievers. Okay? People who, specifically, believe the curve looks like this. An S. It goes up and then it flattens. Okay? And they actually think we're at the hump right now. And they have thought that ever since GPT-3.5 came out. They're like, "Yeah, it's not going to get any better." 4o comes out. We love 4o. People loved 4o. They still do. They can't get rid of it. But they still think this is as good as it gets, you know?
What if 4.5 is out and most people haven't played with it? Most people don't realize what's there. And that thing is already 2 months old. The half-life between model drops, far as I can tell, has gone from about 4 months beginning of last year to 2 months from Anthropic at the beginning of this year. So, any day we're going to see another model from Anthropic. It'll probably be out by the time we have this podcast out, right? And that will be so much further up the curve that people are going to start to be really freaked out by it.
It's going to worry people when they see the next model, okay? Because all of the bugs, all the mistakes that they're complaining about right now get fed right back into training so that it doesn't make them next time. And this is what people aren't understanding, right? And also, time continues. There will be 3 and 5 years from now. The sun's not going to stop, right? And it's coming.
So, this inevitable collision of these curves, man, there will be societal upheaval is what's going to happen, and it's already started. And people are justifiably mad and I'm mad with them, Gergely, okay? I'm mad at Amazon for laying off 16,000 people and blaming AI without an AI strategy for it. Those people are not going to be able to find jobs, by and large, and they're the first of many to come and nobody has a plan for this.
Why do you think Amazon did that if they don't have an AI strategy?
Because unfortunately, and people are going to hate me for saying this, but me saying it doesn't make it true. It was true already. Everybody has a dial that they get to turn from 0 to 100, and you can keep your hand off the dial, but it just has a default setting of what percentage of your engineers you need to get rid of in order to pay for the rest of them to have AI. Because they're all starting to spend their own salaries in tokens.
And so, at least for a while, if you want your engineers to be as productive as possible, you're going to have to get rid of half of them to make the other half maximally productive. And as it happens, half your engineers don't want to prompt anyway and they're ready to quit. And so, what's happening is everybody on average is setting that dial to about 50% and we're going to lose about half the engineers from big companies, which is scary.
Yeah, that's wild. That's way, way bigger than we've seen back at COVID. And I think—
It's going to be way bigger. It's going to be awful. But at the same time, something else is happening, which is AI is enabling non-programmers to write code. And it's also enabling engineers who have seen the light and believe the curves are going to continue to go up to actually get together in groups of two and five and 10 and 20 and 30 people and start to do things that rival the output of these big companies that are tripping over themselves.
And so we've got this mad rush of innovation coming up bottom up. And we've got these knowledge workers falling out of the sky as the big companies lay them off because clearly the big company is not the right size anymore. Even Andy Jassy's saying it. We're going to do the same thing with fewer people, right?
And so does this mean we're going to have a million times more companies? Is there going to be a massive explosion of software? Are people going to get out of software altogether and we're all going to go to other stuff? I mean, I'm very curious where all this goes.
Yeah. Small teams that have the right skill set or see the right business opportunity or have advantages can do way more. So there is something there in that.
There is. So there's this land rush starting. I think a lot of the people coming out of knowledge work are just anti-AI. And those people are going to struggle. I'm sorry, but if you're anti-AI at this point, it's like being anti-the sun. You're going to have to go live underground, right? But the people who are pro-AI, I think we're going to see a big redistribution of who's doing the work and where you get your software from.
And we may well wind up... I could actually see a happy place where Amazon's not even a thing anymore. I really could, because software becomes... We don't have the words for what's happening, right? You know, there's so many things happening this year that we don't have words for. Have you noticed that? But software becomes sort of like a distributed... I don't know.
I do see non-technical people getting into software. Could there be a job there for engineers to come and actually take over maintenance?
Yeah, I mean, I think there's going to be plenty of opportunity. There are going to be a lot of engineers doing software engineering. I just think we're all going to be doing it with AI, right? But I think it'll be quite some time before companies are comfortable trusting their code to be fully written and deployed by AI without any human being involved at all.
I think the important point that the naysayers and the skeptics are missing is that AI is not coming to replace your job. It's not a replacement function. It's an augmentation function. It's here to make you better at your job, right? And that's not a bad thing, actually. I don't know why people would fight that, but...
Speaking about the job as developers, you've said something that can be triggering for a lot of people. You've said, I think this was at the AI Engineer Summit, that if you're still using an IDE now, you're a bad engineer.
Ha, yeah. Well, you got to be a little provocative. Let me put it this way, okay? I'm not going to say you're a bad engineer, cuz I know some very, very good engineers better than I am who are still at like level one or two in my chart, right? But I feel profoundly sorry for them. I feel pity for them like I've never felt in my life for these grown people who are good engineers, or used to be, and they're like, "Yeah, you know, I use Cursor, and I ask it questions sometimes, and I'm really impressed with the answers, and then I review its code really carefully, and then I check it in." And I'm like, "Dude, you're going to get fired, and you're one of the best engineers I know."
Tell me about your chart. Tell me about your levels that you came up with.
Yeah, so I was drawing this on the board in Australia for a big group of people, trying to show them what happens, cuz I saw them at all different phases. Some of them had their IDEs open. Some of them had a big, wide coding agent. Some of them, the coding agent was really narrow, right? And so I was like, "Okay, we're going to put you all on a spectrum just to show what's going on, right?"
And level one, no AI, right? And level two, it's the yes or no, can I do this thing, in your IDE, right? And then level three, you're like, YOLO, just do your thing, right? Your trust is going up, right? Level four, you're starting to squeeze the code out, right? Because you want to look at what the agent is doing and not so much at the diffs anymore, right?
Not reviewing as much now?
You're not reviewing as much. You're letting more of it through and you're really focused on the conversation with the agent.
And then at level five, you're like, okay, I just want the agent, and I'll look at the code in my IDE later, but I'm not coding with my IDE. At level six, you're bored because you're like, okay, my agent's busy. I got to do something. I'm twiddling my thumbs. And so you fire up another agent and now you're addicted, because you'll very quickly get into an equilibrium where there's always an agent waiting for you because somebody's finished, right? As soon as you spin up enough of them, mathematically, right? And so you find yourself just multiplexing between them, going like this. And you can't leave.
Practical question. Assuming I'm working on the same code base, how do you spin up the multiple agents so that they don't get in conflict? Are you going to use like—
Yeah, so that takes you to level seven, which is, oh my god, I've made a mess, right? I accidentally texted the wrong agent and didn't realize it, and they did a big project inside of this project because I asked them to, and now I got to clean up this mess, etc., right? All that stuff. And that was when I started going, okay, what if we were to coordinate this? What if Claude Code could run Claude Code?
That's the question everybody wants to know. And everyone was trying all last year to go, Claude Code, run yourself. And it would run for a while and it would stop, right? And so it was the whole stopping thing. So yeah, I pushed on that really, really, really hard and wound up building some stuff to help with it, but... Yeah, boy, it's changed a lot, man. It's changed so much.
Going back to the IDE, you had a really good live debate with Nathan Sobo from Zed, and the title was the death of the IDE, and both of you argued your view. What is your view about the IDE, and also what did you learn from Nathan on his take? He was a bit more pro-IDE, and you're a bit more like, "Mm, this is not going to be around forever."
Yeah. I mean, you know, I am where I am in my journey, which is I think that AI will do it all for us eventually. And so, the way I see IDEs is, what do they really do and what are they really for? Okay, it's not really for writing code, it's for bringing tools together and for making a big tool, right? And now you have MCP for that. Or whatever, right?
And so, I see IDEs returning, and I think Claude Cowork is a return to the IDE form. It's Claude Cowork going, "Oh, I need to be for real people." Right? But I think Claude Cowork's form factor probably works better for the average developer than Claude Code does. Right? So, I see us coming back into a world where it's IDEs, except it's all conversations and, you know, monitoring.
And this is a really good point. My brother built a thing called Craft Agents, which is pretty similar to Claude Cowork, except they connected in their company their own data sources. And he said that some developers started to prefer that because it's a visual that's easier to see parallel agents. For example, if you're not a power user, it's easier to scroll. It's just a nicer UI.
So, your point on maybe some developers should try it out. Like, if you're not sold on Claude Code, try Claude Cowork or any other similar more visual thing. It might be more your thing. Some people love the command line. I actually just use the UI cuz I just don't like memorizing the commands, as embarrassing as it is to admit, or maybe these days it's not as embarrassing.
That, yeah. The key was try. As long as you're trying something.
Yeah. Probably the single most important proxy metric that you can have in a company today is token burn. Because what token burn says is your engineers are trying to do stuff, or your non-engineers. And when they're trying, they're failing and they're learning.
And so, if you want to get those organizational bottlenecks discovered early on, and you want to get your engineers leveled up on my eight-level spectrum early on, and you want to solve your business processes ahead, you need to start now, which means try. It doesn't matter what you try. It doesn't matter which tool you use. As long as you're using AI and you're trying to get it to do the work, you're doing the right thing.
Yeah, and I think, you know, as professionals we really ought to just at least try. You get firsthand experience and then you can make your decision.
Steve's point about token burn is really interesting. The companies that win are the ones that experiment the most. And if you want to bring that same experimental mindset to your product, not just your AI usage, that's exactly what our presenting sponsor Statsig is built for.
Statsig gives you the complete toolkit without building it yourself. You get feature flags, experimentation, and product analytics all in one platform and tied to the same underlying user assignments and data. In practice, it looks like this. You roll out a change to 1% of users at first. You see how it moves the top line metrics you care about, conversion, retention, whatever is relevant for that release. If something is wrong, instant rollback. If it's working, you can confidently scale it up.
Companies like Notion went from single digit experiments per quarter to over 300 experiments with Statsig. They shipped over 600 features behind feature flags, moving fast while protecting against metric regression. Microsoft, Atlassian, and Brex use Statsig for the same reason. It's the infrastructure that enables both speed and reliability at scale. Statsig has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30-day enterprise trial, go to statsig.com/pragmatic. With that, let's get back to Steve's take on the state of Gas Town.
Now, there's a huge problem with people not knowing how to try, and they say, "Oh, let me do something." And then it does the wrong thing, because they always do, and then they're like, "Whoa, this is garbage." So, you know, you have to teach them
that it's a shovel and you don't go "shovel, dig" like in Fantasia, right? Like make the brooms walk around. No, you pick up a shovel and you dig with it, but it's a shovel that you didn't have before; you were using your hands. It's a really, really simple analogy, but people just don't get it. They don't get it.
And I'm going to say something that's contentious, but it's just the reality of the world. Most people can't read. I've ruined much of my work in my life. I've just completely gone down the wrong path by overestimating people's ability to read, and I think that reading is, if anything, getting harder to come by as a skill these days. And this is the situation that we're in right now: Claude Code makes you read a lot. So I think we're in a weird limbo for the rest of this year, where until the UIs arrive that are good enough for everybody who can't read, everybody who can't read is going to be at a severe disadvantage.
Tell me a little bit more about your observation that a lot of developers cannot read, because you were at Amazon, and that place supposedly is running on six-pagers and people actually reading. Does it?
I mean, dude, most people can't read. I don't know if you know this, man. They just read really slow, okay? And the AI is, I mean, come on. To most people, five paragraphs is an essay. Remember five-paragraph things in high school? That's a thing we have in America. I guess maybe yours were 100 paragraphs in Amsterdam, but to us five paragraphs is a lot. And that's the AI just clearing its throat, right? Yeah. [laughter]
You've got to be able to read waterfalls of text, and so we're looking at a world where that won't work, and so you're going to need recursive summarization. You're going to need a factory. And it's funny, because this is why trying UIs is so important, because Gas Town right now, the reason I say you can't use it, is that it's a factory filled with workers and you're talking to it through a telephone. You can also go and look through the window and count on it and talk to the workers, but it's not like you're in it, right? With a UI you're in it and you can see what's going on. It's all invisible in Gas Town by and large, right? Hard to see.
And so I really do think, and I'm just going to make a bold prediction, I think that by the end of this year, and we'll see demos of it right away, but by the end of this year most people will be programming by talking to a face. A face as in a face on the screen. Your AI, like the Gas Town mayor, will be a fox talking to you, and you'll say, "Why doesn't it work?" And it'll say, "I'll go look at it." And it'll go spin off its workers just like it's doing, but you're talking to a face. And it will talk back. Yeah, I think that's the only thing that's going to work for most people.
Fascinating. Let's write this down as a prediction. Why do you—
It. I'm not going to.
Let's talk about Gas Town. You mentioned Gas Town. For those— a lot of people have heard about it. What is Gas Town?
Gas Town is an orchestrator. So, 2023 was completions.
Code completions. Yeah, autocomplete, yeah.
That's what it was. Completion acceptance rate card, do you remember that?
Oh my god, people were measuring it, yeah.
Stupid metric, by the way. But it was close. It was a proxy for "are they trying," right? Then there was chat, that was 2024, right? And then agents was 2025. You could just look at that curve and go, "Okay, well, if chat is completions in a loop, basically, and agents are basically chat in a loop, well, then we're going to put agents in a loop, and that'll be an orchestrator, right?" And a bunch of them started coming out, and I built one of my own. I built my own vision. But that's all it is. It's agents running agents.
And can you talk through, as software engineer to architect, how is it organized? How can I imagine the setup?
Sure. I mean, look, Gas Town is really complicated, and it's been really broken all week because I'm migrating it to Dolt, and that's where I actually learned how complicated it was. It has a lot of features.
You're migrating it to?
To Dolt. It's a new database.
Oh, okay.
Yeah, Dolt is amazing. Dolt is a Git-backed database. It's a Git database. Beads is just Git plus database crammed together badly, and there's actually a database that does this. So I'm migrating to it.
But yeah, anyway, Gas Town, what it should be is one mayor that you talk to. That's your person. And then whatever else needs to get done, they're just going to fire off workers. Okay? It's a little bit more complicated than that, because there are really, I think, two kinds of work that people go back and forth on, and people are arguing about which is the right one.
And some people at Anthropic told me it's the minimaxing context argument. Okay? There are people who believe that you should maximize your context and fill it with rich, juicy context so that the AI is wise and all-knowing when it's talking to you. They want to be just right at the edge of the context. And then there are others who are like, "Task, kill it. Task, kill it. I want the shortest possible window."
Because of the quadratic increase in cost.
Yeah. Combined with the dramatic drop-off in cognition as the tokens go up, right? Losing their track and stuff. So which one's right? And we've got people who are full on in the minimizing and in the maxers. And I looked at my workflow and I was like, "Well, polecats are the min and crew are the max." I have two fundamental worker roles in Gas Town.
So you have the really simple one, which is the small context.
Yeah, if you have a really well-specified task all broken down into subtasks, and it's self-contained, it says what to do, then you can give it to a worker and have it go do it, right? Meanwhile, you have a really difficult design problem. You're going to have to have a series of conversations about this. I maximize context. I'm like, "Read all these docs and then we'll talk, right?" So it's just two workflows.
And I like the idea. I think it's so easy to imagine it's a little town, you know, like in the wild wild west. There's the mayor, the crew, the workers. Everyone's buzzing and going around and the houses are being built. In practice, how does this work? How has it worked for you? What are you hearing about people getting projects done versus not getting it done versus it turning into absolute chaos? What have you learned with Gas Town?
It's been a great experiment. I mean, I've really enjoyed—
Experiment, right?
Well, yeah. I mean, right? I went out and built something that deliberately doesn't work. It's too hard. It's too hard for the models. Even Opus 4.5 is barely enough. And it's funny, because the folks at Anthropic told me they like it, but some of them are kind of embarrassed, because it feels like I've got all these workarounds for bugs in their model. Which it kind of is, right? But it's not a bug. It's that their model was never trained to be a factory worker, and it will be soon.
So a lot of Gas Town is going to disappear. A lot of the complexity, a lot of the roles that are monitoring, all they're trying to do is tell Opus 4.5 to be smarter, and that's being on the wrong side of the bitter lesson, right? So Gas Town's going to simplify and flatten into just min-max roles. Crew for your max, and your polecats for your mins. And I think that's the natural shape, and they'll just scale up.
And could the polecats just be sub-agents, for example?
Well, polecats are sub-agents. It's just that they're more first class. They have their own identity, inbox. You can talk to them. You can actually see how they performed over time by computing skill vectors on their work and things like that. So a little bit more than sub-agents. I think sub-agents have the problem of being opaque. I'm going to fire off a bunch of sub-agents to go do this work, and then you're like, "Okay, let me know when you're done." Whereas with Gas Town, you can go look at them and be like, "Dude, your polecat's not working. I'm going to poke it." Right?
So Gas Town gives you a lot of hands-on, I don't know, steering, right? It doesn't try to get out of your way. It's in your way, Gas Town. It's really fun, though. I miss it. It's been down for a few days for me, and I tell you, man, working with regular Claude just stinks by comparison. Because it's like an idea factory. Once it's actually running and all booted up and everything, you can have so many things going on at once, and actually track them reasonably well. Now, it can suck you into a mode where you don't sleep, you don't eat, and it's not good for you. And I actually wanted to talk to you a little bit about what's happening in the industry at some point.
But Gas Town itself, I mean, it was all calculated. All the characters, the naming. Why did I even do Gas Town, right?
Why?
Because I wanted to move the Overton window. Right? Because people last year, when I would say orchestration's coming, they'd say no, agents aren't— no swarms, no orchestration, everything you're saying is just not true. And now what they're saying is, bro, you're being pretty aggressive. Right? Which is a different conversation. Now they're like, well, your swarm, I don't know, maybe your swarm can't do blah blah blah. But it's just completely shifted the conversation from the realm of impossibility to the realm of possibility.
So is it fair to say that you took on more than you reasonably thought you could chew, you took on this more ambitious one because you wanted to both stress test what these models can do—
Uh-huh.
And find out what's next.
Find out, and honestly just have some fun. Have some fun, find out what's next, and I'm continuing to do that. So my next thing is I'm going to string 100 Gas Towns together. We have a community, a Discord, and if Molbook can get people to pitch in tokens for fun— you're paying for the inference of your agent on Molbook, right? So if I string 100 Gas Towns together and we decide to build something together, we will learn the mechanics of federation. We're probably retracing Ethereum's steps, but we will, and we're going to come up with something remarkable.
It's like the people version of Molt app, right? Molbook, whatever it is. And what are misconceptions about Gas Town, or what it's trying to do, that you feel have gone off the rails a little bit and are good to clean up?
Well, for starters, I don't think people should be using it, and they are, and I really mean it.
Well, I'm always saying people should not be using it, except if you're doing research, or if you actually understand that this is just a proof of concept.
So some very, very clever people that I've been talking to have been searching their problem spaces for subsets, categories that Gas Town could predictably use today at a big company, a big Fortune 50 company, say.
Wow.
And they've identified some problem spaces that you could put Gas Town on today. And I was like, "Oh, that's pretty clever thinking." One of them was this company I talked to that sets up bespoke data centers for you, okay? In any region you want, which is something AWS has never been able to do; Google's always tried. And they say it's just 3 months of miserable button presses to try to install the software and check that it all works. And the acceptance criteria are very clear. It's almost a Ralph loop, but they think Gas Town could swarm it and eventually converge on a data center that works, and save all the people the trouble, you know what I mean? And I was like, "Oh, I ate." And this could potentially meaningfully move the needle on their ability to open up more of these data centers for people, right?
Wow.
Yeah, go figure. And the same guy was telling me that he's been looking at production incidents, and he's realized their system is already in an indeterminate, unknown, broken state when they're down. So how much worse can AI actually make it? Now, I cautioned him and said, "Actually, it can make it a lot worse." But he's thinking along the lines of there's certain categories of outages where you could have them in investigation mode or whatever, right? Where they could speed things up. So people are looking for the fuzzy problems.
Mhm.
There was a third one that came along; I forget what it was. But there's a class of problems emerging for which you can swarm them, because you don't care that the results are messy. It's the cumulative work, right? But that's actually how I code now. I mean, I bit off more than I could chew. There's no question about it, man. Gas Town is a huge mess right now, and everybody's going, "He's going to vibe code himself into a corner and come crying out, you know?" They're pretty close to true. Although I did manage, just before we got on the plane, to get it back on track, and it's working again, right?
So one interesting thing about Gas Town is that you said you don't look at the code; you have the agents write the code. Which is very, very unlike what your career has been, right? You cared about craft, code, elegance. Why did you decide to do it, and what are the results? Are the results as bad as I would think they would be? Because if you imagine we're going to put a thousand interns on a project, we've kind of seen that in the past, and the result has been, well, eventually a senior engineer comes in and cleans up the mess. And I'm just curious how it is better or worse.
Well, the ceiling of what it can actually build productively before it just dissolves into a mess is going up. But right now I think it's sitting somewhere between half a million and five million lines of code, somewhere in there. Probably more on the half-million side right now, and with the next drop of an Anthropic model, we're probably going to see it jump up to a few million lines. Which is a pretty good size, but it's nothing compared to what enterprises have, right? Nothing. Enterprises are very, very, very, very big, Ben. Hundreds of millions, ten billions of lines.
Yeah, but not in one code base. Having a few million lines of code is already a big code base, and you'll typically have 50-plus people, sometimes 100-plus, working on it.
What it really comes down to, just to summarize this conversation and get to the end, is how well you're going to be able to take advantage of AI totally depends on whether you're a monolith or not. If you're a monolith, which almost every company is— they have one monolith and then a bunch of microservices, right? If you're a monolith, you're kind of hosed, because I told you the ceiling's going up for what they can do, but it ain't ever going to hit your monolith. It will never fit in the context window, and you're never going to be able to, never in the next 18 months, be able to tell a model, go fix my monolith. You have to break it up. Okay? If you want to take advantage of AI, or rewrite it from scratch. It's starting to get faster at this point to think about rewriting your stack, yeah?
One thing you mentioned even before we started is that AI can really drain you. It can drain your energy, it can pull you in, it can suck you in. Can you tell me about this?
Dude, there is something happening that we need to start talking about as a community, as an industry. Okay? There's a vampiric effect happening with AI where it gets you excited and you
work really, really hard and you're capturing a ton of value. For me, I'm doing it all for myself and it's still kind of like pushing me to my ragged edge. I find myself napping during the day, but I'm talking to friends at startups and they're finding themselves napping during the day. It's funny, they literally try to load each other up with enough context to force the other one into a nap, almost like a compaction event. It's so weird.
And we're starting to get tired and we're starting to get cranky. And I started talking to people in the industry and they're starting to get tired and cranky. And what's happening is, see, companies are set up to extract value from you and then pay you for it, right? But the way all companies have always been set up is that they will give you more work until you break. If you can do it, they'll just happily just say give you more, give you more, until your plate flows over and you die. And people have to learn the art of pushing back, right?
And that's been a thing for a long time, but it's changed the equation. The way you push back, the reasons to push back and all that have changed very dramatically and are changing right now because you've got all these people now who can be super productive. And it's like, let's say an engineer can be 100 times as productive, just for sake of argument, all right? Who captures that value? If the engineer goes to work and works for 8 hours a day and produces 100 times as much, the company captured all of that value.
Yep.
And that is not a fair capture exchange. I think we can argue, unless if they have, or let's say startup and they have a meaningful equity, that's a bit different. It goes with the— but that's not the majority of people, right? It's a minority. Yeah.
Yeah. We're probably getting there pretty quickly. I didn't— you know, we did notice one thing, like, and you probably saw this as well, about six months ago we talked about a lot, the 996 problem at AI startups. And we were like, oh, it's interesting. AI startups, people are working really freaking long hours and they're posting that they're in the office at 3:00 a.m. and you could tell it
with people what 996 is who don't know, okay? 996 is 9:00 a.m. to 9:00 p.m., 6 days a week, if I'm not mistaken. Yeah, which is— 996 is the standard you're expected to work in most of Southeast Asia as far as I know. I haven't been to China or India, but I assume it's pretty much similar there, too, right?
There's another group of people who are capturing all of the value for themselves, okay? They go in and they work for 10 minutes a day and they get 100 times as much done and they don't tell anyone and they've captured all the value. And that's not really ideal, either, right? So, at least in terms, if you're thinking in terms of how can groups of people be successful, it's best if they're all contributing, right? So, what do you do?
And I think that the answer is each and every one of us has to learn how to say no real fast and get real good at it. And we need to learn how to start capturing and the correct— This is the new work-life balance. Okay? It's how much of the value are you going to capture from being 100 times as productive and how much of it you're going to pass along to your employer? And this is a really difficult place to be, cuz we don't have any cultural— All our cultural expectations are pointed in the wrong way. For us to work harder, and they want us to— they, right? Everyone wants to extract, extract, extract.
And so I seriously think founders and company leaders and engineering leaders at all levels, all the way down to line managers, you're going to have to be aware of this and realize that getting your engineers onto this treadmill is pulling them into a— they're using much, much more of their System 2, you know, they're doing much, much more of that hard thinking now. The easy stuff is getting automated, but you're actually draining them at a higher rate. Their batteries are draining at a higher rate.
You might only get three productive hours out of a person at max vibe coding speed. And yet they're still 100 times as productive as they would have been without AI. So, do you let them work for 3 hours a day? And the answer is yeah, you better. Or your company's going to break.
It's very interesting, cuz also, like, the value extraction, I think I see us speeding up and we see it with a few prominent people. Peter Steinberger single-handedly pushes out so much more value, output, you name it, commits, in any way, that would have been a team of 10 pretty good engineers before. And he, you know, like in all fairness, he is capturing it in the sense that it's his project, his baby. He does not sleep much. So that's definitely showing, but the value capture there is kind of okay. But I agree with you that this could be something like—
In the past, whenever there was a technology shift where people were more efficient, in your lifetime, have you seen this, where engineers became more efficient and suddenly you could do a lot more with a lot less? And what happened at that time?
People got mad. Yeah. I was so— An example, Perl. The Perl programming language was a massive accelerator. Amazon's website was built in Perl, probably still is, actually. I think Facebook's technically is too. PHP is a fake Perl. And you can quote me on that. So, both of them were incredible productivity accelerators and everybody just could see it. You don't want to build websites in C. You just don't. Amazon tried it and they gave up, right? So, that caused a huge rift, a huge schism. There were second-class citizens, all kinds of cultural dynamics happened there, right?
I'm curious about how some AI companies deal with this. Can we talk about how Anthropic works?
Yeah. Yeah, from what I know.
From what you know from the outside. I know that, you know, you talk with people across the industry, but Anthropic is a very interesting place. One interesting thing that Dario recently said is he thinks compensation, specifically for their staff, the people who are building all these things and they're actually using the models and doing— He said something interesting, that maybe we should have compensation where people are compensated even after they leave the company for the value that they created, which is just something completely unheard of. But it's clear that he's thinking about this thing that is changing, where individuals can create massive value in a relatively short amount of time.
Google, you can send me a check for all that stuff you never paid me for. Okay. Just got to get that out of the way. I like that idea. Anthropic is unlike any company on Earth right now. They're operating in a space that is really fragile and they're very protective of it, and they need to be, because they've created a hive mind. They're running the company, as far as I can tell, like a pure functional data structure. Remember Chris Okasaki's book? That was such a mind-blowing— You can make data structures that never mutate. Then how do you mutate them, right? And the answer is you just keep adding. It's improv. Yes, and. Yes, and. Right? And that's how they operate.
And when you say hive mind, what do you mean by that?
It's a lot of— It's like the markets today. Vibes. Everything's vibes. It just shifts. It's just— Right? But it's vibing. It's kind of hard to explain, but you see, here's the thing, right? We used to build products by, like, making a spec and then implementing it and then complaining about it and then shipping it, right?
Or having a road map and planning for it, and like—
And timing it for the company annual events. Right. Apple, right? Once a year. The way you work with systems like Gas Town, and they've got their own internal orchestrators, is you create it, and your founders, like the co-founder that was non-technical, you create the prototype and that's your product, and you start building it and you just make it the product until it's— Right? So everybody just gathers around the prototype like a campfire and builds it. And that is what Anthropic's doing at scale with thousands of people.
So you're saying that the playbook of a successful tech product might have changed, because the traditional wisdom since the lean startup in, like, 2010 or so was you use your prototype to get signal, then you throw it away and then you build a lot more polished stuff, right? And we used to— I think every software engineer who's been around, you don't ship a prototype, you tell people it's a throwaway, you start again, you make it production-ready, scalable, that kind of stuff, cuz you don't want to give a bad experience to people.
Yeah. What changed, though? Just the ability to do an infinite number of prototypes. So instead, you make prototypes until you get a great one and you're like, "Let's launch this." And so, apparently, Claude Cowork happened in 10 days. Somebody went, "Hey, I did a prototype." And they were like, "We're going to launch this." And 10 days later, they launched it. So, I mean, it works.
But I guess one important concept there: when I talked with Boris Cherny about a feature that they did, about how they did the tasks in Claude Code, the task list of how it completes, he told me that in 2 days he built 20 different prototypes that were all working, thanks to AI.
But he's doing what I'm talking about. They call it slot machine programming, right? You do 20 implementations. And is that what he's doing?
Something like that. I don't want to put words in his mouth, but I was just floored, because building 20 working prototypes, that would have been 2 weeks. And you would have not— You would have stopped at three, right?
That's in our book, actually. If I can pitch the book for a moment, FAAFO, F-A-A-F-O, is the dimensions of value that you get from vibe coding. And the O is optionality, which is the ability to create lots of prototypes. What it lets you do is defer your decision until you know what the right answer is, which is cheating. So, of course, everybody does it, right? And it's going to fundamentally change the way that companies are run. It's going to change the way that people are organized to create software. And it's going to happen this year.
It's just fascinating how these changes are coming. But what enables these changes? Is it the fact that we can iterate faster with these things?
Look, I saw a phenomenon happen at Google. This is kind of a big company question. There's kind of two— There's a big company and a small company answer to your question, right? So, something happened at Google. I went through the golden age of Google, where it was like Anthropic. It was a hive mind. Nobody was mean. Everybody was innovating. And it was wonderful.
Yeah, this was a time where, like, the founders were pretty close. You could just—
And Larry and Sergey would be sitting there and you'd hang out with them and just chat. And it was like golden age, right? Yeah. And then, rather abruptly, we made a few pivots and it became not that company anymore. In fact, innovation died on the vine altogether, and since, I don't know, 2008, there has been no innovation from Google. It's all been acquisitions. They've created nothing new.
I mean, they did Gemini a few years later, right?
Gemini, yeah, okay, sure. They created LLMs and then did nothing with them. That's a perfect example of why innovation dies there, right?
Yeah, for 5 years. Right? 5 years they did nothing. So, I don't count Gemini. That's a different Google. Yeah, fair. We're talking about the Google that screwed up. Yeah. I don't want Anthropic to screw up this way, the way that Google did. Google put safeguards in place to try to keep them from turning into the company that they turned into, which was ossified, you know, territorial. Nobody could— I hired a brilliant dude from Microsoft, brought him into Google and said, "Figure out what you're going to do. Take as long as you need." It took him 6 months to find something that nobody else had claimed already. People claim work and then never do it at Google.
So, I'm going to tell you something I've never said before. This is a brand new take. I think what happened to Google was when Larry Page became CEO and he said, "We're going to put more wood behind fewer arrows." That was a motto. And he put a halt to innovation. Okay? Before then, there was more work than people. And after that, there were more people than work. And so people started to fight over the work. And that's where people started to do land grabs and backstabbing and territoriality and empire building and all the bad stuff you see. All the politics that you see is about fighting over work.
And going back to Anthropic, they're at a frontier and there's infinite work, and like literally all of them have too much to do. And a friend of mine at Amazon once told me that we don't have a lot of the problems that Google has because everyone at Amazon is always slightly oversubscribed. They have too much work.
I've heard similar with Apple as well. That's kind of deliberate. Interesting thing, I mean, if we assume— I am seeing productivity gains for myself, so I'm not disputing that agents actually make you more productive, and I think we can agree on— by how much, but for me it's a lot. But if this happens at a lot of companies, people can actually do a lot more work. Do you think a lot of companies that are larger will see politics show up, which typically happens when—
If, right, if like the catalyst for the bad stuff beginning is more people than work, and all of a sudden people can do all the work— Yep. Then the company's biggest problem is going to be finding more work, or they're going to have to get rid of people, which is kind of bad, right? But it's not unlike Gas Town in the small. My biggest problem with Gas Town is feeding it, cuz it works so fast. I have to work really hard to come up with good designs for it, right? That's what I spend all my— which is why I'm taking naps all day long, cuz I'm trying to come up with difficult work for it, right? Other people have said this, too. This is the problem with Gas Town. And this is the problem with everybody who's going to use any orchestrator. It doesn't have to be Gas Town. That thing will be dead in 4 months, probably, right? I mean, it's the shape that worked in December 2025. Not going to be the shape that works in 4 months, right?
One thing that I think, you know, where it might sound that we're talking really abstract, especially for people who have not done this type of work themselves, is like, well, we're talking about orchestrators, they're all productive. Can you point to something that has been built with an orchestrator with this higher productivity that is production software, either you built it or you observed someone build it, that could show, like, actually this is way more productive and we can actually see the output? Or turning it the other way around, like, we're still not seeing that much more output from companies, teams, that you would expect. Okay, like, a lot of them are having more productivity, but, like, from the outside it's easy to be skeptical when we're seeing not much has changed in terms of our day-to-day life. The apps, you know, we're seeing signals here and there, but nothing major. Like, why might that be?
Yeah. That's fair. My feeling is that probably people have a low tolerance for non-determinism. And these things are fundamentally non-deterministic. So, they can't just go replace customer call center software, because they could be wrong. And it doesn't seem to matter that humans are also wrong very often, and AIs these days can very easily get to the same level as an average human in the job. But I think there's still a lot of risk aversion. Right? So, I think that the companies that are
actually running with this are actually starting to see the results and they're just going to be reflected in quarterly earnings invisibly and in other ways at first.
Could it be that we're focusing on building the tools?
I'll turn it around and I'll say, "What if what we're actually observing is that innovation at large companies is now dead and we are only going to see innovation from small places, which is kind of what happened when cloud came out?" And Facebook was a college kid at one point. Facebook feels like the biggest company in the world right now, but it was one dude. Okay? And so, when a new enabling platform technology substrate appears, you're going to see innovation at the fringes because of the innovator's dilemma. Big companies can't innovate. They're all running into this problem. They may have hyper-productive engineers who are producing at a very very high rate, but the company itself can't absorb that work. Downstream, they're just hitting bottlenecks and these engineers are getting shut down and they're quitting, right?
So, I think what's happening is we're all looking at the big companies going, "When are you going to give us something?" And the answer is we're looking at the big dead companies. We just don't know they're dead yet.
Do you think they're dead because, for example, it can now be cheaper to do something like, look, we can just say it's our internal punching bag, Zendesk customer support. They have been the de facto place to do your customer support because your agent can sign up, they get this UI, they get this workflow, etc. And for AI native companies that are using MCPs, whatnot, it makes no sense for them because they actually want an API, which Zendesk does not want to give to you because they want to charge extraordinary amounts for you to come to their platform and buy their AI for, you know, 10 times the cost.
That model is going to struggle a lot in coming years because people will build their own stuff bespoke with APIs. This is my platform rant in real life, right? If Zendesk doesn't make themselves a platform, then they're going to build a product and build themselves out of existence, I think.
And the platform for looking ahead, is it APIs? Is it the heavy MCPs?
I mean, as far as we can... No, maybe not MCP, right? I mean, what Anthropic found is that what works better than MCP is its own API to call the MCP because they're so good at writing code.
Nothing really changes because platforms were always APIs from the beginning, right?
Why do we need MCP? Well, we needed some way to declare what the tool does in an AI way, but I mean, it's so loose and so flexible. Integration's going to be really easy. I don't know. I'm not following that space well enough to know if MCP is going to continue to be an important dominant player or if the AIs just use stuff directly, like via command line tools, right? Or APIs. But either way, we're leading into this world where the innovation is coming out of new shops who have adopted and adapted, and I see big companies struggling really bad right now with this.
I wonder if we will see a lot more of these building blocks that we didn't know we needed.
Dude, I think we're going to see a huge ecosystem of building blocks for people who are non-technical who want to build stuff and they need those APIs. Right, you know what I mean? Like for storage or for matching or for whatever it is they need to do.
I guess if you're in tech and if you're looking for an idea, either because, you know, your job is looking a bit shaky or you actually just want to do something, now could be a great time to start building some of these building blocks that we're going to need, like reliable building blocks that we'll probably need, that have state, that have SLAs, whatever. They have some importance, right? That's not trivial to do.
That's right. Because AIs are lazy. And with good reason, they don't want to burn tokens if they don't have to. So, if you provide a service that's going to make something convenient for them, they'll absolutely use it.
Yeah, and especially if it's a service that you need to maintain, for example, that you need to keep up with, may that be regulation or changes or logging or whatever. That's kind of a lot of work to do even to prompt, like to go back every day to prompt again to update and all that. Also, as humans, we're also lazy.
Yeah, I mean, well, Larry Wall called it, right? That's one of the virtues of a programmer.
I want to go back to another one of your essays from 2012, which was called the Borderlands Gun Collector's Club.
You're the one that read that one.
I got recommended it on Bluesky and a lot of people liked it and I read it. I realized I didn't read it. And this was a really interesting essay because seemingly it has nothing to do with what we're talking about, but you talked about gamification and you talked about how this Borderlands game, which you played apparently, right? Back in the day, yeah. Back in the day, you mentioned how after you completed the game, there was this weird thing that the game developers probably accidentally put in there: people kept coming back to have custom guns, and these were like a meta goal that the designers probably never thought of, but it actually made the game pretty addictive, and you called this, I think it was some sort of elder game or something like that. And you were kind of saying that, "Hey, this is pretty smart. This was accidental from the game designers, but maybe more game designers should do this because it just makes the game addictive." And since that in 2012, we've seen so many games just have deliberate gamification, and not just games, but a lot of other things.
Yeah, a lot of them found that mechanic eventually. Who is it that did Borderlands, Take-Two or... I forget. Anyway, they figured it out early. Then they didn't capitalize on it, but yeah. So, interestingly, I think gamification's kind of rearing its head. People have pointed out that people are making a game out of Gas Town, right? I mean, why not make it all a game? Like, come on, man. I mean, look, we literally have games for running factories. Imagine you're running an actual factory. How cool is that? Right? Guess what Gas Town is. That's why it's so fun, actually.
And do you think that one of the reasons that some of the agents are more successful than others, looking specifically at Claude Code, is they also did some gamification where there's always something showing there, right? There's a tinkering, there's the different things that keep talking to you. There's always... Is some of it maybe accidental or maybe deliberate?
Oh, I think they have the best product managers in the world, and they've done absolute magic with command line UIs and stuff. It's wild. But, look, I mean, come on, right? That's not going to work for most devs. So, that's why Claude Cowork is so cool, right? Because that's... It's not going to be that. That's the direction that things are going to evolve, I think. Yeah, so I think developers will use Claude Cowork or something more like it.
With traditional software, we have tech debt, and we know how to deal with it, and we've talked so much about this. In fact, if we think about what we were very busy with in the 2010s: tech debt, collecting it, paying it off, migrations, yada yada yada. Now that we're doing, you know, a lot of vibe coding, or you call it vibe coding, but agentic engineering, just turning out a lot of code, how do you think we will recognize or deal with, or do we need to deal with, this vibe coding debt?
Oh, yes, you do. You do. One of my up-and-coming blog posts is about this, actually. I've discovered that there's a thing, I've given it the name of... it's called a heresy. Okay? That happens in vibe coded code bases that you're not looking at, where an idea can take root among the agents that's incorrect. It's a wrong architecture or wrong data flow or whatever that's causing an impedance mismatch for the rest of your code. And what happens is, I call it a heresy because they have a tendency to grow and to come back and they're really hard to weed out, okay? I had a bunch of them in Gas Town. There was a polecat heresy that kept coming back.
And so what would happen was it's invisible. And your product stops working properly along the edges and you don't know why, and you start having the agents dig into it and you realize you've got a fracture. You've got a fault line. You have, say, two complete databases that are both alive and operational and you're randomly choosing between the two of them, right? And you didn't realize this until just now, right? Okay, yeah.
You find terrible, you know, things in your code, right? And you try to get them all out, but there'll be one reference to it in some docs somewhere that an agent picks up on and goes, "Oh, that makes sense." It's the heresy and it returns. And the agent does the wrong thing and goes off and rebuilds the heresy and it starts to spread again. It comes back, right? It's like the agents want the system to work this certain way and you're telling them, "No, I want it to work this other way." And you're fighting with them, and what you have to do is you have to actually document the heresy in the beginning of your prompting and say, "This is one of the ways that you can go wrong on my project. Don't do that, right?" And then you have to remind it periodically or even put in tooling to keep it from doing that.
Another heresy is that my agents all think they should be doing PRs. It's like, "I'm the maintainer of this code, man. Just push to main, right? Or a branch or something. Don't make a PR. It's just polluting the PR space. That's for contributors." They can't get this today. Now, I could put a bunch of hacks in, but that's fighting the bitter lesson. Opus 5 will be fine. Opus 5 will be, "Oh, you don't want PRs. I won't do PRs."
What is the bitter lesson in this talk?
The bitter lesson, yes. Richard Sutton wrote a very, very short essay. It's like 800 words. It's one of the best essays ever. What I call the bitter lesson, where he's like, "Yeah, we're AI researchers and we learned the bitter lesson and you need to learn this lesson." The bitter lesson is don't try to be smarter than the AI, okay? You think that you've got special knowledge. The humans bring special domain knowledge to this problem and we're going to teach it to the AI and it will be smarter. What we found was bigger is smarter. Always.
So more data, right?
Yeah, and so when they're going into Australia right now, you know, you've seen the drawings of how big OpenAI's training center was, how big Anthropic's training center was, and now the training centers they're building are, you know, 10 times larger. They're massive. They're in Australia because they have all the energy and the land and everything, but they are going to make models that are 10 times or more smarter than the ones we have today, right?
We talked about the vibe, but does it not pain you? I mean, as someone who has built software, you know how to build good software. You went in there to clean up the mess of junior teams or messes. You could clean it up with your eyes closed, or maybe you had to keep them open. Does it not pain you when you describe, "Oh, the AI going off stream and doing it," that if you scaled it back and said, "Hang on, let me step in. Let me make these decisions. Let me be the architect," it would not happen?
Yeah, well, see, the thing is I've also been a vice president of engineering at big companies. True. And so, when I'm working with a team of 80 agents, it's not very different from working with a team of 80 engineers. Any one of them can screw up, too. Engineers.
And you've done that, right? Yeah. I have, and I'm telling you they are isomorphic. So, what is the bitter lesson? The bitter lesson is don't try to be smart. Just try to be large, okay? Now, that's not the only way to make the AI smarter. They can also make them smarter in a couple of other important frontiers that are also getting developed. And so, to tie it full circle to the beginning of our conversation, everyone who believes right now that the curve is S-shaped, they're 100% correct. They are 100% correct. It is S-shaped. Eventually, we'll run out of resources. The world will be out of resources and it will flatten, right? But I can tell you that there are at least two more cycles left in this, and that means they will be at least 16 times smarter than they are today, and that is going to cause all of knowledge work to be subsumed by this stuff.
Before we go all the way there, let's talk about how all this, the better models, being more productive, could impact personal software. Things that people can build themselves.
This is what I thought you were asking about earlier when you said you wanted an API from Zendesk. Think about it, everyone's going to want to build their own software.
Oh, I was talking about a business for now. Not personal, but
Oh, businesses, yeah. But also personal software. What would the future look like when everyone could have OpenClaw running in their closet, or Gas Town, or they don't have to run it on their thing, but they can turn to this agent?
Yeah. How could that change both personal software and also the software industry as a whole? Because for a long time personal software was a privilege of us engineers who could build it, and we built our tools and we had open source and we had some billion-dollar companies grow out of some of the cool things. But what do you think could happen now that this will be democratized to some extent? How do you think open source could change? Open source? How would open source change? Could it change? Because one interesting thing that I'm seeing is a lot of remixing happening. So people, you know, now a lot of open source projects don't really take pull requests because there's a lot of not great ones, but a lot of people are just remixing. They're just taking the open source project, they're telling the AI make this change, and they publish it as open source as well. Often no one looks at it. But now they don't need to ask for permission. A lot of people are weaving things together. They say, "Take this project, take this thing." And it's actually going to make a lot more open source.
I know what you're saying. In the old days, the F-word, "fork you," used to be kind of a declaration of war. Yep. If you forked somebody's project, it meant you had had enough of them. Like Roo Code forked Cline, and then somebody else forked Roo Code, and I think it's now going to be an everyday occurrence. Right?
Because it used to be that to fork it would be a lot of time and effort, to maintain a fork, to merge back the
Cursor is a fork, isn't it? It is. Yeah. I mean, that's a lot of work. That's a lot of work.
Yeah. It's a lot less work now, right? So, yeah, everyone's going to be forking. So, yeah, I think that's a natural consequence of everybody writing code. Yeah. Just like everyone can take a picture now. That didn't used to be true. Yeah.
What are some of your beliefs from early on in your career that held really, really well until recently and that we've now just abandoned because of AI?
Engineers are special. Here's one.
Come on, we are special, no? I think we're so special.
Yeah, sure. We learned how to do something by hand that computers can do now. Kind of cool, I guess.
What about the engineering mindset? We have that. It's not just coding that we do, right?
Well, look, for one thing is I believe that our thirst for
new software will never ever ever diminish. It will only grow. And so, we're at the beginning of software. All the software we have right now is garbage. That right there, OBS especially. And we're going to see a new world over the next 10 years where software is commonplace and good, and you'll have your choice. And it won't be I have to pick and choose between three really bad OS solutions or company HR systems or whatever stupid ass thing, right? Like today, the selection is terrible. SaaS is awful. The whole, right? Yeah, airline apps.
Airline apps, right? I mean, we ran a vibe coding workshop in Sydney where a dude actually wrote an airline check-in app for himself. He got it into the Android queue before Southwest realized and shut him down cuz he was a bot. But, that's what people want. They want personal bespoke software, and they're going to get it. And so, yeah, I think you're going to see... That's why when Jeffrey Manuel forked Beads, I was like, you go. You go. He was like, I feel so bad about it. And I'm like, dude, this is the new world, man. Fork fork fork. Let's have Beads in every language. I don't care, right?
I mean, in all fairness, just looking at it from the positive side, I wouldn't mind just having good software for the stuff that I use day-to-day. My utility provider is what is getting better, the government websites that I have to access, paying my parking fine. The other day I tried to send a package to Canada from the Netherlands and the official post has been broken. They cannot send anything for a week and I see the exception, they cannot fix it. So I had to go DHL and pay a bunch more money, and there's a lot of bad software out there.
Your agent will be dealing with it, not you. Yeah. But I think people who write software that agents like and prefer and choose, and then they find a way to market it and get the agents aware of it, they're going to win big because everyone will use agents. We'll all be dependent on it.
Well, plus also I guess software or ways of making agents write quality software, cuz I have a feeling like you will want to do better stuff, that if you do the same you're not going to have a business, right? Yeah. So I mean
look, I think businesses will compete on more and more complex software. The ceiling will just keep going. We're building, like, we're going to until we build the Death Star or whatever, right? I mean, we're building bigger and bigger things. Oddly enough, Gergely, I am an optimist through all of this. That's my first belief, I think, first and foremost, is that it's all going to work out.
So asking the optimist now, I got this question off, I think it was on Bluesky. This person asked, how do you think the software industry will continue to exist if we get to the point that any software could be trivially cloned? Yeah. Where will that leave us? What cannot be cloned? What is the moat? Just we just jump ahead. We assume that these things actually can do it.
Human connections are probably the biggest one, kind of almost counter-intuitively. As software does more and more automated for you, people are going to be like, oh well yeah, but that's just automated. I want a human to do it. And they will literally want a human to bring their thing instead of a drone, you know, they'll want humans to curate things for them, and I think that's going to be... humans will be a moat.
Do you think if you look back at some of history, like the history of the rest of history, have we seen some changes that felt a bit like this, and then we saw some professions thrive because of either more automation or, you know, like
Stack Overflow, I don't know. I mean, that one jumped to mind. Mechanical Turk. I mean, we've seen a bunch of big step functions. It's just that we're about to see a whole bunch of them at once. Mhm. Right? I mean, look at the news lately. This is the funny thing, is everyone's like, "Where's all the innovation?" And the news all day long, they're seeing all this innovation in AI. It's just not coming from, you know, the Walmarts and Microsofts. It's coming from random individuals, right? But the innovation's there.
And from the startups that I've been talking to, you know, I've been talking to anywhere from two, five to 20-person startups, I think we're going to see some really impressive stuff launching in the next couple of months.
Are you seeing these small startups change how they work?
Oh god, it's so different, dude. Tell me. Tell me how.
So different. Okay, for starters, I think in the new world, and I'm convinced of this, okay? Everything that you do will either have to be fully transparent or you're hiding it for a reason. Tell me more. In other words, if you don't want people to see what you're doing, just don't show it to them and they will never see it. And if you do want them to see what you're doing, then you had better get it out in front of them as you do it, instantly, or else the train will pass you by.
So what they're saying is, so I told the story on my blog, people have heard it, but they yelled at a teammate, they were mad because he implemented a feature that they'd asked for 2 hours before. And they were like, "2 hours ago, that's changed too much since then, right?" And he's like, "Well, what do I do, you know?" What's happening is they're getting into this mode where they've realized that stuff moves so fast that everything is invisible, effectively, from the volume. And so you have to be extremely loud and transparent and intentional about saying everything that you're doing. So that if anybody else is doing it, they can stop you right then. And if they need to integrate with you, they can start right there.
We're talking about startups that are looking for product development, for customers. They actually just want to get what we call product market fit, where the traditional wisdom was build something amazing and then release it to the world. That's right. That's right.
Try to find product market fit in secret as much as you can and then launch it and then tune, right? That's the formula, and many people fail at it.
Used to be. Now, like you're saying, with Gas Town, I realized I'm not going to find product market fit by myself. So, I launched it as soon as it kind of worked and was like, help me. And that's how I found out about the Dolt database, which was a big change, and people fixed a bunch of bugs. I got 100-plus PRs the first couple days, right? And so, it found its way closer to product market fit just by me getting it out there.
And would you say that has brought you... like, on one end people look at you, well, yes, just one other open source project, but is it bringing actual opportunity? If you wanted to, could you turn this into a business? Has it brought you the things... where I'm getting at is, these things that take off as open source projects, can they actually turn into actual businesses? Or would that that stage?
I promise you if you had made Gas Town, you would be shaking venture capitalists off of you like ticks right now.
I am. They're finding me everywhere, okay? And I tell you it's because there's a lot of money out there right now sniffing, want to find its way into it. I know something big's going to happen, right? And it's looking, and you can see it in all these different microeconomies that are springing up, but nowhere can you see it more clearly than when you launch something cool, like Geoffrey Huntley did Ralph Wiggum. VCs, right? You know, everyone want to talk to... You just got to be real careful because anything you build probably has a real short shelf life at this point, right? A real short one. I don't know. I'm not attached to Gas Town in any way because I think it'll be supplanted by something better within 6 months if not sooner, right? So, too attached.
So, let's assume that a staff engineer is listening to this podcast or watching it on their commute, and they're at the type of company where they have Copilot still. There's people like this, and they're using it and they want to believe you but they're not sure they can. What would you tell them? What is the thing that they can do to get proof that you're actually right and this thing is working? We're not 100%, we're not even 50%, for people like... a lot of people who are in this field have tried it out, but there's a lot of... Oh yeah, no, they probably still 70% aren't doing it. Yeah.
So like what would I say? I had a really good message for them. Oh yeah, get out. Get out. So here's the thing, right? Copilot is, if you were to line up all the tools, you know, from best to worst, right? Copilot is like, here's a line, right? It doesn't even know about the line, right? But it used to be the best four years ago in 2021, right? Yeah, and I was personally, even maybe two and a half years ago, I was quite stunned that somebody asked, does anybody use Copilot, at an AI tinkerers meeting, and somebody raised their hand and he goes, "Do you have to?" And everyone laughed and I was like, "What happened, right?" The brand just tanked.
But I'm serious, if you're working at a company that gave you Copilot, they think that they're starting to move faster, and there's a barbarian horde of people using Opus 4.5 that are going to destroy your company sooner or later. So what you need to do is go into the crazy part of crazy town and figure this stuff out and start building, because we are moving into a world very quickly this year where proof of work is so important. And I mean proof of work not in the Bitcoin sense, but your proof of what you have done, your resume. And I don't mean your resume because nobody's going to believe that. I mean the actual work that you did, which has to be visible, back to our transparency, right?
I think everyone's going to be bringing their work with them. I mean, the notion of proprietary work is starting to get threatened, I think, because it's so easy to fork, it's so easy to clone, it's so easy to route around. If you have anything proprietary, you become this thing that everybody just wants to route around. And so, right? So, big changes are afoot.
But man, if you're working with Copilot right now, you are going to get left behind. And so, what you need to do is find half an hour a day to go play with Claude Code, right? And so, like I said, or if you're a company, make your token burn as high as your investors will let you go. Right? Because that token burn is your practice. It's your sorting things out.
So, I want to ask you the other way around. Let's assume you're just wrong in terms of the curve and we're at the peak, and it will not be 10x, it will plateau at 3x. Or what? Let's just say the next model is inexplicably dumber than Opus 4.5 and we peaked. What would happen to the person who takes your advice and they go all in and they learn these things? What's the worst thing that could happen to them? You know, if these things take off, it's a great investment, right? But what would happen to them if they followed your advice and the models didn't follow? Where would that leave them?
Exactly where they need to go. Because the damage is done. Opus 4.5 made this officially an engineering problem. We don't need you AI researchers anymore. Thank you. You can make smarter models, I guess, but we don't need them. Because we have something... you can take a bite-size chunk out of a mountain, and it's a bite-size about town-size now. And so, we can eat mountains, okay? It's purely an engineering problem at this point. It's like fire or steam. It's a force. It's a power. And we wrap layer, layer, layer, layer. I worked on a nuclear reactor. I was in the Navy. I know how these things work, okay? Yeah, I thought so. We are going to put layers around Opus 4.5 if that's the smartest model ever. And that will do all of the engineering from now on. So, it's done. So, it's okay to jump into the pool now.
Your first job was about debuggers, or not debuggers, but you worked at this amazing company. You told me they had the best debugger tools. What was the name?
It was GeoWorks and the debugger was called SWAT and it was amazing. Time machine and all that.
And on the first Pragmatic Engineer interview when we talked, this is in the newsletter, you were actually saying that to this day you've not seen as good of a debugger, but you're kind of determined to build at some point, or help build that.
I did build a good debugger in Clojure for the JVM called Ganja. It was actually pretty cool, but then I got in an argument with Rich Hickey about how well he wanted to support the JVM, and he doesn't. So, yeah, but anyway. You're a guy who is passionate about... somewhere though. [laughter]
You're passionate about debugging. What will happen with debugging? What will happen with debugging tooling? What do you think the future of debugging is? With agents?
When I see agents say I'm going to debug this, they all use printfs. So, you know, I'm curious. It could very well be that they just haven't been trained on debuggers yet, and that they'll all wake up in 6 months and go, oh, I should have been using this. But it could also be that we don't need them anymore. I don't know.
And another step further, what do you think the future of the developer workstation, like our rigs, our machines, will be, right? Like do you think it'll...
Phone. Phone. I want GSD on my phone. I almost have it, I have it but I just haven't worked on it.
Peter Steinberger told me that he had VibeTunnel where you could do it from your phone. He said he stopped it because it became too addictive.
Oh yeah, no, Tailscale and yeah. Actually, the only thing that's keeping me from just being addicted to it all day long is it's too hard to enter control characters in. But that's going to get fixed at some point. Programming on your phone will be a thing.
But so do you think that developer workstations can be just like a Chromebook or whatnot, or we actually want beefy ones which can run our local agents and whatnot? Where do you think it'll be headed in the short term and then maybe in the longer term? Yeah. See what I mean? Local models.
No, look, I love my laptop. I've been programming 40 years. I get the local thing, but I've been saying for 15 years that we don't need this stuff locally, right? Google had an amazing client in the cloud, high-speed network connection, and... So it's Cider, right? CitC was the base, and then Cider was built way up on a higher layer. But when you get something like that, and you're not restrained by that, especially in the world where you can run kind of unlimited agents based on your pocketbook, yeah, people are not going to be wanting to work on their laptops. And Gas Town has already completely stressed out my laptop to the wire, you know, cuz Claude Code actually takes quite a bit of memory. So yeah, I think we're moving to a world where people will work on servers and on mobile devices, probably less on iPads, not on laptops as much.
In the past, you've said that one of the most important kind of predictors of productivity is language design. Well-designed languages are easier to work with. Do you think this has completely erased, or do you think it might come back at some point, either purpose-built languages...
I think there'll probably be purpose-built languages by AIs for AIs, maybe. But right now we're in a funny place where some languages work better than others still because they have better training data, but in the fullness of time, all languages will work equally well.
I'd push back on that. Like, if a new language never has training data, how would it work with that? No, I mean
Sorry, all the existing ones. Like TypeScript, it struggles with TypeScript today. Yeah. Like, it does. But it's not going to in one or two models. At least it won't matter.
Could we see a stagnation? Just fewer languages or no languages launching because they just get the job done. And launching a new language seems a bit suicidal unless you like being a bunch of training data with that, right?
Man, that's a loaded question. I mean, like...
I didn't mean to make it a loaded question.
A good question, right? Part of me says, like, languages just don't matter anymore, right? Any more than assembly languages matter, except for a few people who are trying to optimize really important things. And then everybody else, it just doesn't matter, right?
But then part of me says, "Well, energy is the most constrained and important resource on this planet, and it's only going to get worse. So finding better algorithms, finding better ways to solve problems is often a language problem. Finding a DSL, you know." So, I think from an optimization perspective, an efficiency perspective, the search for new languages will probably continue. But for everyday, I don't think it matters what you pick. You might not even ask your agent what language it's using.
So, as a software professional who, like, loves the craft, is into, you know, languages, debuggers, tooling, etc., a lot of what we talked about is pretty sad because, you know, a lot of the beauty, the challenges that we worked on, it seems they might be going away if we continue on and if this continues as well. How did you work through this yourself? And also, what is the thing that actually excites you looking ahead?
Right. So, I had the benefit of going through 30 years of graphics evolution. And so, I saw the sadness, and I saw the resulting much better games we got after all that happy stuff we were doing by hand moved into the hardware. We're sad because we're used to it. Change is part of life, okay? And, you know, at one point I had to say goodbye to assembly language, right? I was like, "Well, the compiler writers. They finally caught up, right?" And then we were mad. But then we were happier, because compilers are obviously way better than writing in assembly language. And anybody would be stupid to say, "Oh god, yeah. No, you're not a good engineer if you can't write in assembly language today." But that was actually what we were saying in 1992.
Yeah, and then you had the blog post out in 2012 as well. Yeah, no. I'm just saying stuff changes. What you need to know as an engineer will change, and you can't rest on your laurels, and we're going through a period of faster change now. But you have helpers called agents that can actually help you through this change. So, stop complaining and just go do it.
Yeah, and I think just recognize we're in this industry where change is a thing, and... That's right. Now, with that said, there's a bunch of opportunities.
...of grief, right? The five stages of grief. I mean, like, I went through... I don't know about anger. I was really, really angry for a lot of reasons 2 years ago. But no, I mean, if you've ever truly grieved, if you've lost someone, you know that it hits you in a lot of weird ways where you feel reality is disconnected, you feel sick, you feel stunned, you feel it all day long. The world goes monochrome, all color disappears, all kinds of weird stuff, right? And I went through that for about, I don't know, 6 or 7 days. It didn't take me that long to get through it, fortunately. Or maybe that was the peak, and I was, you know, surrounded by a few months of it on either side. But there was a period that I went through where I was checking off things that no longer mattered that I had really cared about. Like my ability to memorize, or my ability to write, or my ability to compute, or whatever. Anything computing related, I was very sad, right? Because those things made me special somehow, right?
But then to your question, what makes me excited? As soon as I got through that, I was like, "But wait, I'm writing 10 times more code than I ever was, and I'm having fun. And why should I be sad that I did this, right?" So I realized it's just me holding on to the old, just like I did in graphics, and there's no point, because the future is actually more fun than the present. It's going to be.
You're known for your predictions, and I'd like to put it to the test. Let's give some specific predictions for next year, 2027. Things that you think will happen, either with how we develop or how the industry works.
I think that my wife is going to be the top contributor to our video game.
Ooh, bold claim.
...of next year.
And she is not a developer, I'm guessing? No. Oh, no, no, no. But she loves our game, and she has lots of ideas. Right? Amazing.
Yeah. In fact, I think my whole family might be in on it. I'm serious, man. Programming is going to be for everybody, and it's going to be the most amazing thing, because you know how much fun we've been having all those years, and we've been telling people it's really fun, but now they're going to get to experience it, right?
I look at my kids and how they look at AI. They're having so much fun with it, creating. They're just prompting Gemini or any of these with their imagination, and they don't think it's weird. I think it's weird, so I never would think of it, but they just enhance our photos with, like, squirrels on my head, and it just made me laugh, and it's fun, and you realize there's just a lot of fun and new things with it when you let go, or you never knew what was before.
It's given people the ability to do very sophisticated mashups of anything, and mashups are really where innovation happens, right? Innovation comes from taking things and putting them together and seeing where it goes, right? We're going to see everybody innovating, man, and it's going to be the most amazing thing ever. And then we're going to need ecosystems of agents that can go find stuff that you like, because there'll be so much content. How are you going to find the stuff that you really like? You're going to have an agent that knows you really well.
I think any software engineer who wants to go make a big business right now should go start working on agents that know how to go and search the new world, everything that's coming out. I don't know what we call it, right? The work pile, for software that you like, for experiences that you like. And if everybody's creating it... Think about it. When the internet came out and everybody could make a webpage and upload, we needed aggregators. We needed, you know, search engines. We needed ways to organize and find and surface the good stuff, right? None of that exists right now, but everybody's about to start coding. Right? You know, and so you can get ahead of this. This is why I keep saying just believe the curves, pick a point on the curve and aim for it, and you will land there, and you'll be first when the AIs are ready for your thing.
And I think as engineers, we already can build. We don't need permission. We can use these tools super efficiently. And we are ahead of the rest of the world right now. Right now.
Well, it's exciting times. We'll have to check back on whether that prediction will come through, with your wife contributing more. But this has been, I think, really eye-opening, and, you know, sometimes I think it's good to go through the has-been and the can-be. Yeah. Well, thanks.
I hope you enjoyed this conversation as much as I did. An interesting thought from Steve is his parallel between the graphics industry and what's happening in software engineering right now. In 1992, Steve was learning to calculate where individual pixels go on a line. Two years later, the same course was teaching animation. The work in graphics went from writing device drivers to building game worlds and physics engines. It all just moved up the abstraction layer. Steve's argument is that software engineering is going through exactly that same shift right now, except it's faster. Instead of asking, "Will engineers have jobs at all?" a better question might be, "What will the new jobs we do as software engineers look like?"
Another thing was the grief of this change. Steve is someone who spent 40 years building his identity around compilers, debuggers, elegant code, and then one day he sat down and started checking off, one by one, the things that made him special that no longer mattered. His world went monochrome, as he said. Within a week or so, he came out the other side and realized he was writing 10 times more code and that he was having more fun doing it. Still, I think a lot of engineers are quietly going through something similar right now, and it's usually taking longer than a week to digest all of this.
Finally, one thing I found really honest from Steve was his point about value capture. If you become 100 times more productive with AI, who benefits? If you work eight hours and produce 100 times the output, the company captured all of that. But if you just work 10 minutes in a day and produce the same value as before, you technically captured all of it and your company captured none of it. Now, neither extreme is sustainable. Steve is saying that this new work-life balance is a question that we'll need to figure out. We don't have the cultural norms for any of this, and it's going to be messy as we figure it out.
If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating for the show. Thanks, and see you in the next one.
Article published