Part 1 ended with the scarce thing moving. Writing code stopped being the constraint; judgment and accountability are. You can point more agents at code, and at a good deal of go-to-market. You cannot make trust, taste, relationships, or real usage data arrive any faster. Cheap code changes the whole game of turning software into value: what it costs, how teams plan and communicate, what you depend on, and how it gets funded.
1. The first rule to fall: never rewrite from scratch
In 2000, Joel Spolsky named the worst strategic mistake a software company can make: rewriting the code from scratch.1 His warning was about starting over: throw the old code away and write it again. The problem was not mainly the work. The ugly code you are throwing away is a record of every bug you already found, and starting over means finding them all again. His example was Netscape. I was there. Almost nobody argued with him, and for twenty-five years almost nobody had to. Rewrites were expensive enough that the rule mostly enforced itself.
That cost has fallen through the floor. While I was drafting this, Bun’s creator published an account of a rewrite that took eleven days (and two months for the post about the rewrite). The JavaScript runtime was moved from Zig to Rust: 535,496 lines ported, the full test suite passing on all six supported platforms, and the result merged and shipped in the open. One engineer ran about sixty-four Claude instances at a time and spent roughly $165,000 on API calls. He estimated the same work by hand would have taken three engineers about a year.2 Agents did nearly all of it, working in pairs, one writing code and another trying to poke holes in it, until they agreed.3
Throughout my career, “should we rewrite this?” has come up over and over. At One Medical we wanted to move an application from AngularJS to Angular, v1 to v2, which sounds like a version bump but was really a new framework. We kept putting it off because it was a resource sinkhole, and by the time we could face it React was probably the better choice. Bun’s rewrite was close to a mechanical port, file by file against the same test suite. The old code and its tests were the spec, so nothing had to be rediscovered. Ours could not work that way. Angular 2 was itself a rewrite, so nothing lined up file by file, and we had to rebuild rather than translate. It was a smaller job than carrying a runtime across languages and it still cost years and a lot of money. Today that same migration might take weeks, at a fraction of the cost.
Nobody wants to spend four years and have nothing visible to show for it, so the rewrite picks up a redesign and a feature list to justify itself. That is no longer a port, and it is the version Joel warned about. Now you can afford to do the boring version: port it straight across, get back to where you were, then decide separately what to build on top. The old system tells you when you are done.
That changes the math on work you have been putting off, like the overdue rewrite, the framework migration, or the upgrade three majors behind. Sometimes it is also how you keep your people current. Stay on a framework long enough and it can strand a team on skills the market has left behind.
The Netscape story cuts both ways. The rewrite may have cost the browser war, but it became Gecko, Mozilla, and Firefox, and without that “mistake” I am not sure we get the web we have today. Rewrites still create migration risk, and a million lines of machine-written code resting on a test suite is still a bet. Zig’s creator, Andrew Kelley, argued that languages do not eliminate bugs, dedicated engineering time does, and that some of Bun’s claimed improvements were cleanup that was overdue anyway and got credited to the rewrite.4 Fair enough.
The Bun disagreement quickly became a fight about craft. One side calls anything AI-touched “slop.” That is the wrong test. Slop is about whether the work is bad, not about where it came from. But the people saying it are protecting something real. They care about craft, and craft is for solving problems, creating value, and learning. Judge it by effort instead and all you are measuring is how hard someone worked.
Moving fast and trying things is how we learn cheaply. I can now build, see, and use fifteen working versions in the time I once might have spent thinking the problem over in the shower. That is not an argument against planning. A plan should say where you are going and how you will check that you got there. Prototypes are for the questions a plan cannot answer. Faster prototypes mean faster feedback from users, from the system, and from your own reaction to the thing on the screen. The team that closes that loop fastest still wins.
2. The two-speed team
But a team does not learn at one speed. The gap I opened with in Part 1 does not only run between companies. It runs through the middle of every team, and you can watch it at a standup. Picture two good engineers. Person A is heads-down building feature X, hands on the code, the way they have always worked. Person B spent the same week orchestrating agents against a thirty-step plan, and feature X stopped being relevant at step four. When they meet, they talk past each other. They are not disagreeing; they are describing different worlds.
Nothing in how teams coordinate was built for this. Standups, sprints, and annual roadmaps assume everyone moves at roughly the same speed, while adoption is wildly asymmetric inside teams.5 Yegge’s demand horizon (the hardest problem you bring) and discernment horizon (the hardest answer you can judge) are personal, which means a team is now a scatter of them. Each person is planning against a different sense of what is possible, while collaboration lags behind individual output.67
If everyone is working from a different sense of what is possible, the plan is the only place those senses can meet. So planning has to change in two directions at once. It has to look further out, because when building is cheap the plan is the thing everyone needs to share. It also has to be revised much faster. An annual roadmap now ages like a carton of milk, because models keep improving and every build run teaches the team something new. A plan is the current best map of where you are going, what the risks are, and what you still do not know.
Development and planning stop being separate loops running at different speeds. Every build teaches you something worth planning around: the dead ends, the surprises, the steps that turned out not to matter. But builds are not the only input. What customers do with the last thing you shipped, what the analytics say, what support keeps hearing: that evidence arrives on its own schedule and it has to land in the same loop. Otherwise you have a very fast engineering cycle attached to a stale idea of what people want. Ship, watch what happens, replan, ship. The answer is not to slow Person B down. It is to make sure what Person B learned on Tuesday is in Person A’s plan by Wednesday.
This is going to be hard for a lot of teams and companies. The rewiring has to happen while everyone still meets their commitments. Move too slowly and the gap widens. Move too fast and the change itself becomes the bottleneck.
3. The review bottleneck
There is a second bottleneck, and open source feels it worst, because reviewing there is not really anyone’s job. Any company that ships software has the same problem, with the advantage that reviewing is at least part of someone’s job. Almost everything you use is built on open source: the web servers, the databases, the language runtimes, the encryption behind your bank login. It is written in public, anyone can use it, and anyone can send in a fix. What holds it together is attention. A handful of maintainers, often just one, stand between a few million users and whatever shows up in the queue.
On AI, open source communities have split hard. Zig, whose creator called the Bun rewrite slop, now bans LLM-generated contributions outright. AI has increased the volume of low-quality contributions and security reports, at real cost to maintainers. Curl killed its bug bounty after only about 5% of AI-generated security reports proved valid. But Firefox, the browser I helped build, showed the other side: Mozilla used AI to find 271 of the 423 security fixes shipped in April. A month later, Firefox walked out of Pwn2Own Berlin unhacked.
People have been writing bad code for as long as there has been code, and open source has always had to sort through it. Hacktoberfest’s free T-shirts produced a spam wave in 2020, and in 2024 a crypto protocol called tea.xyz drew hundreds of junk pull requests from people farming tokens; one submitter, when asked, said he had “a job that requires uploading the file and I also don’t know what it is used for.” If you pay per contribution, people will produce contributions. Most people who show up still want what they always wanted: to join a project, or to fix the one thing that bit them and move on. What changed is the third group, people optimizing for a bounty, a token, or a green contribution graph, who can now have a model scan for easy fixes and open fifty pull requests before lunch. Some of those fixes could be fine. But what gets a contribution merged is trust, relationships, and communication, and nobody builds those fifty pull requests at a time.
None of that scales. A maintainer’s attention is finite and does not grow with the number of contributors.8 Neither does a senior engineer’s, and no company has more of those than it did last year. Make plausible contributions cheap and easy to produce, and the queue grows faster than anyone can work it down. Writing got cheap. Reading did not.
Projects are trying different answers. Bevy opened review up: anyone can review, two community approvals move a pull request to final, and a maintainer does the last check. Review stops being a maintainer’s chore and becomes a way for newcomers to learn the codebase.9 Others automate the first pass, with tools such as CodeRabbit and GitHub’s Copilot review commenting on pull requests before a human looks.
Review practices will keep changing. Right now the pressure runs the other way: people want more human review, not less, because they do not trust the output yet. I doubt that holds forever. We stopped inspecting every instruction a compiler emits, and something similar will happen here. But inside a company or outside one, the need for accountability, ownership, shared goals, and trust does not go away.
Companies and communities will all try different things, because the playbook does not exist yet. But refusal is the one answer that cannot hold. It depends on pretending the models have not already changed how software gets built, and a ban on AI contributions cannot actually be enforced. Nobody can tell whether a model wrote something, so enforcement becomes a witch hunt. I have watched contributors accused over an em-dash in a pull request, or a Claude commit somewhere in their history. History should tell us the witches were never the problem.
The tool at the center of the argument has to be part of the fix. Franck Nijhof, who leads Home Assistant, got there from inside a project that lives with this daily. Contributors are being amplified, he wrote, while maintainers remain the verification bottleneck, and what that calls for is better testing, documentation, and automation rather than a ban.10 Agents can reject what is simply wrong and get promising work into reviewable shape, leaving humans accountable for what gets merged. The scarce thing becomes judgment instead of cleanup. That costs money, which most projects do not have, though several vendors currently give it away to open source.11
Plenty of people think AI is killing open source. I think the opposite.
Creation has never been cheaper. GitHub now takes in about twenty million new repositories a month, and agentic workflows have accelerated so sharply that the load broke parts of the platform twice in April.12 A lot of that is noise, code thrown over the wall by someone who needed it once, and some of it will still be useful to whoever finds it later.
The harder question is why anyone takes a dependency at all when they can generate whatever they need. The code was never the expensive part. Someone else tracks the security issues, handles the edge cases you have not hit, and keeps it working on the next platform. Generate your own and all of that becomes yours to carry, forever.
A repository is not a project. Open source was always people gathered around a common interest, with the code as the artifact rather than the point. Software is never done; it has to keep growing, which takes people who show up, argue about direction, and say no. Projects will keep forming and taking shape, because they bring people together. Agents will carry more of the work every year. What they do not supply is anyone who cares whether the thing is good.
4. Build vs. buy, reopened
Building got cheap. Open source feels that as a flood of contributions; the companies that sell you software feel it on the income statement. Build vs. buy used to be a question you needed engineers to ask. It turned on cost and differentiation, and cost usually decided it. Now the cost keeps falling, and companies that never had the option to build have it. The price of buying has to follow.
You can already see it in how you get billed. Traditional SaaS ran at 80–90% gross margins; companies in ICONIQ’s 2026 survey expect AI-product margins around 52% this year, up from 41% in 2024, because inference is a real cost that scales with use.13 Pure per-seat pricing is down to roughly 8% of the market. Intercom renamed the company Fin after its outcome-priced agent, and HubSpot moved its agents to credits and per-resolution fees.14 Bain looked at more than thirty major SaaS vendors and found that roughly two-thirds had already layered usage-based AI meters onto subscriptions, though none had fully abandoned seats.15
The same math makes the bundle harder to swallow. Vendors spent a decade piling on features nobody asked for, because it is easy to sell more to someone who already pays you. You wanted a small subset and paid for the whole thing. “Build the 20% I use” versus “buy your entire suite” was never apples-to-apples, and now that you can cheaply build the useful slice, the 80% you were paying for anyway gets hard to justify. You can estimate what the part you actually use would cost to build, which makes that a very different negotiation.
Before you cancel everything, look at what happened to the companies that did. Yegge argues, and I think he’s partly right, that some who were ready to rebuild in-house discovered unpredictable AI bills. Bain found token prices fell by half while consumption grew 4.5 times, so usage more than ate the savings.16 A boring subscription has predictable costs and someone else responsible for keeping it running. So the pendulum has swung partway back toward buy.17
What changed is that you can get a real build estimate in an afternoon, from people who already work for you. Companies without engineers never could, and took the price they were given. That estimate is worth having for anything that does not make your company different, because those are the things you should be paying the least for. If you are on the other side of the table, the safe assumption is that your customer has run those numbers. The vendors in the best position do one hard thing well, charge for what they deliver rather than how many people log in, and keep overhead low enough to cut prices as the floor drops. The ones in the worst position are defending an 80%-margin, per-seat, everything-suite against a customer who now knows what the alternative costs.
5. What venture prices now
If software is getting cheaper to build and harder to charge for, you would expect investors to be pulling back. The first half of 2026 sent a record $392 billion into U.S. and Canadian startups, though that came from a few enormous rounds rather than from more companies getting funded. Anthropic’s Series H alone was about half of the second quarter.18 The biggest of those rounds went to the model labs. Part 1 showed what that does to everyone else: when Anthropic’s legal plugin landed, Bloomberg counted $285 billion off software stocks in a single session, with legal-information incumbents hit hardest. Customers are applying the same pressure from below. Either the capital is wrong, or what investors are buying was never just the code.
So is software defensible at all anymore? Defensibility used to lean on pedigree and technical depth, which made sense when engineering time was the constraint. It carries less weight now that fifty teams can chase the same idea and all of them ship fast. What holds up is the same list it always was: data the product generates that competitors cannot see, customers a team can reach without paying for the introduction every time, people who take their call after something breaks, and knowledge of how the work actually gets done that lives in a few heads and was never written down. None of it comes from the code, and none of it exists at seed.
The AI-native investors have repriced accordingly. Sarah Guo’s version is “execution is the moat.”19 Execution used to mean getting the product built. It now means aiming at the right problem, learning fast from what ships, feeding that back into the next cycle, and running sales and marketing on the same cheap leverage as the code. Grit and creativity were always part of the founder bet. The new part is that the whole company can move at that speed, not just the engineers.
The teams doing it are much smaller now. Recent Y Combinator batches include companies reaching eight-figure revenue with six employees, and a quarter of one batch shipping code that was 95% machine-written. At the other end of the market from those giant rounds, seed and angel funding fell 27% year over year, and the share of seed companies reaching Series A fell from more than 55% to 16%.20
Why write the early check at all, then? Because the power law sharpened instead of breaking. Lovable added $100 million in revenue in a single month with 146 employees.21 Fewer companies may matter, and the ones that do may matter far more, far sooner.
All of that assumes the money is behaving rationally. Bubble or not? Bill Gurley’s answer, channeling the economic historian Carlota Perez, is useful: if the platform wave is real, bubble behavior and real transformation arrive together. The skeptical math is real. Ownership of the model labs was recently marked above $1.5 trillion against well under $100 billion of collective revenue, and Sequoia’s David Cahn estimates that roughly $840 billion in annual AI revenue would be needed to pay for the datacenter buildout.22 The other side is real too. Anthropic went from $1 billion to $47 billion in run-rate revenue in sixteen months, and ChatGPT reached a billion monthly users.23 Hunter Walk’s scorecard captures the contradiction: a technology bubble, no; an infrastructure bubble, probably; a valuation bubble, absolutely; a revenue bubble, no.24 The fiber was overbuilt in 1999 and the internet happened anyway.
The investor’s job is to reprice what the check buys. Treat experimental revenue as unproven until retention demonstrates otherwise, because an enterprise pilot annualized into ARR is not revenue yet. Since none of the durable assets exist yet at seed, what is left to underwrite is evidence that the team learns quickly, finishes, and distributes. When money gives everyone skin in the game, you start looking for the founders with heart in it.25 Venture was never only pricing code anyway. It priced the people who knew what to do with it, and now that is nearly all there is to price.
6. What I think follows
The scarce thing moved. What is left is the list Part 1 ended on, and the one this essay keeps returning to: taste, trust, living data, distribution, relationships, and the speed of a company’s learning loop. None of it is new. What changed is that everything around it got cheap.
Railroads did the same thing to distance: shipping got cheap, plenty of track-layers went bust, and the durable fortunes went to the people who understood what cheap distance made possible.
My bets follow from that. Your advantage has to compound on something that takes time no matter how much you spend on it. Your pricing has to assume a falling floor. The model is a teammate that needs goals, decomposition, evidence, and supervision. And your people have to be genuinely literate with the tools, because organizational adoption is increasingly the constraint.
What does that mean for the next generation? The fundamentals I earned were a means to judgment: knowing what is worth building, sensing when a system is going wrong, and deciding what not to do. Every generation thinks the next is skipping the hard part. Usually it is learning a different one.
Judgment is where the handoff to agents gets harder. Agents are strongest where expertise can be made explicit in tests, types, benchmarks, and evidence. They can produce plausible points of view elsewhere too. The unresolved question is authority: who trusts one to choose the objective, make the tradeoff, or own the result? Senior judgment still has to make a point of view legible enough that a team—and an agent—can act on it.
If the old apprenticeship was memory management and debugging until sunrise, the new one has hard parts of its own. They have simply moved up the stack:
Splitting the work. Breaking a problem into units agents can run in parallel, and seeing where their changes will collide.
Knowing when it is right. Building the tests, evaluations, type systems, and feedback loops that let you trust work you did not personally write. I have moved much of my own work to Rust not mainly for memory safety, but because its picky compiler catches bad assumptions and hands them straight back to the model.26
Learning fast. Running your own loop quickly enough to grow judgment in months instead of a decade.
None of these throw a compiler error when you get them wrong, so you only learn them by doing the work. They also make a hiring rubric: put less weight on who types fastest and more on who decomposes cleanly, builds their own verification, learns quickly, and can see a model or two ahead.
The rubric has a second use: it tells you where to look. The adoption gap is why that matters now. These essays still hold even if the models never get better than they are today. The way I learned, reading other people’s code and banging my head into walls until something gave, did not disappear; it just got much faster. Most people with twenty years of experience are still at “I typed something into ChatGPT.” Someone two years in who learns how the models work, where they fail, and how to verify them can pass them, because experiments that once cost a week now cost an afternoon and taste can compound faster than tenure.
Taste is trainable. Every job contains work people love and drudgery they would pay to avoid. Learn to notice the latter. Talk to people about what wastes their week. Build something and watch whether they reach for it. Read the complaints they leave in forums and one-star reviews. Knowing which unglamorous problem is worth solving is a muscle anyone can train.
Anyone can build now, but building was never the hard part. What separates something that works from something that lasts is trust, and trust is the one thing time compounds and money cannot rush.
Ratatouille’s “anyone can cook” was not a promise that everyone would be great. It was a warning that greatness could come from anywhere. The rat is in the kitchen now. Whether you are a founder, an operator, an investor, or a builder, the question is the same: what can you create that will last?
The canonical case against the ground-up rewrite — Joel Spolsky, “Things You Should Never Do, Part I” (2000).
Jarred Sumner, “Rewriting Bun in Rust” (July 8, 2026) — one engineer orchestrating ~64 agents; 535,496 lines of Zig ported in 11 days; a +1,009,272-line diff; ~$165,000 in API costs against an estimated year of team-scale work.
The Bun rewrite was an early public run of Claude Code’s dynamic workflows — parallel subagents that draft, refute one another, and converge until they agree: Anthropic.
Andrew Kelley, “My Thoughts on the Bun Rust Rewrite” (July 9, 2026) — the Zig creator’s response: the craft rebuttal, the TigerBeetle counterexample, and a conclusion he publicly revised.
The fracture is being named from the organizational side too — the “velocity gap” between how fast models improve and how fast organizations absorb them, including “workforce fracture” as AI-adopters diverge from non-adopters, and annual roadmaps colliding with quarterly model releases: Forbes.
The 2026 engineering benchmarks show the same picture in the data: strong individual output with AI usage concentrated in a small slice of the team and collaboration lagging far behind — “high output doesn’t always mean teams are moving together”: Time Doctor.
Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software (2020) — the argument that maintainer attention, not code, is the binding constraint: what makes maintenance untenable is “excessive participation from users vying for a maintainer’s attention.”
Alice I. Cecile, “Open Code Review” (May 20, 2026) — how Bevy distributed review across its community after its sole maintainer became the bottleneck; review, she argues, has become the universal bottleneck for actively used open source projects.
Franck Nijhof, “Open source was not ready for AI-speed contributions” (May 31, 2026) — the Home Assistant lead on the same asymmetry: “Contributors are being amplified. Maintainers are still the verification bottleneck.” His conclusion is better documentation, testing, guidelines and automation rather than a ban.
CodeRabbit is free for open source projects and says it reviews about two million pull requests a week; GitHub exempts public repositories from the Actions minutes that Copilot code review began consuming on June 1, 2026, though the feature itself starts at a paid tier.
GitHub, “An update on GitHub availability” — about twenty million new repositories a month, commits peaking at 1.4 billion and merged pull requests at 90 million, accelerating sharply since the second half of December 2025 as agentic workflows took hold; the load contributed to two April incidents, a merge queue bug affecting 658 repositories and a search subsystem that fell over.
AI-product gross margins — companies in ICONIQ’s “2026 State of AI” survey expect an average of ~52% in 2026, up from 41% in 2024; inference as variable COGS via Ben Murray, The SaaS CFO.
The pricing shift — seat-only pricing down to roughly 8% of the market per CRV (citing SBI Growth / Price Intelligently); “Today Intercom becomes Fin” (company announcement); HubSpot’s move to credits and per-resolution fees (company announcement).
Bain & Company, “Per-Seat Software Pricing Isn’t Dead, but New Models Are Gaining Steam” (Oct 2025) — of 30+ major SaaS vendors analyzed, roughly 65% have layered usage-based AI meters on top of seat pricing; none has fully abandoned seats.
Token economics — Bain & Company, “How Token Economics Will Change Opex” (token prices halved Dec 2024–Dec 2025 while consumption grew 4.5x); Fortune on the Silicon Data Token Expenditure Index.
The capital pace — a record $392B into U.S. and Canadian startups in H1 2026: Crunchbase News. Anthropic’s $65B Series H at a $965B post-money valuation: Anthropic, TechCrunch. OpenAI’s $122B round at $852B and its trillion-dollar-target IPO filing: Sacra.
Sarah Guo (Conviction) — “Software Abundance”, “Taste”, and “Pace”; “execution is the moat” from her State of Startups & AI talk, via StartupHub.
The barbell — seed and angel funding down 27% year over year in Q2 2026 amid record totals: Crunchbase News; seed-to-Series-A graduation falling from 55%+ to 16%: Crunchbase News. YC batch economics (10% weekly growth, 95% AI-written code, tiny teams): Garry Tan via CNBC, Vanta interview.
The sharpened power law — Cursor’s record ramp: The Next Web; Lovable’s $100M month with 146 employees: TechCrunch; 90% of AI revenue in two companies: Mamoon Hamid (Kleiner Perkins), Masters in Business; the one-person-unicorn betting pool: Fortune.
Bubble or not — Bill Gurley on the Perez pairing: Tim Ferriss Show transcript; Aswath Damodaran, “Trillion Dollar Market Caps: Fairy Tale Pricing or Business Marvels?”; David Cahn’s “$600B question” and its $840B update.
Hunter Walk’s four-bubble taxonomy.
The new discipline — Alfred Lin (Sequoia) on “experimental revenue”: via IndexBox; Aileen Lee (Cowboy Ventures) on the new variables and coefficients: TechCrunch Disrupt coverage; Hunter Walk, “heart in the game.”
I landed on Rust for this independently, but it’s a recognized pattern — a strict compiler as the agent’s fast feedback loop: “The Compiler Is the Harness”; Belderbos.
I'm enjoying your conversation. I've been programming for 50 years and I've never had so much fun learning how to build at lightning speed with AI.
My experience and the bot's quick coding ability is an amazing combination. There is a clear division of labor. I'm way better at the big picture and design. But the bot can lay bricks so much faster than me. We're both quickly learning how to work together and it seems like every 6 months it's a new world.
Extrapolating, it makes me wonder where it will all end. When will the bot be better at the big picture than me. Will the bots eventually destroy humanity?