When I was nine, my dad bought a Pentium 166 MHz on a consórcio — the Brazilian installment-plan financing people use when they can't pay upfront. He likes to tell the story that I sat down in front of that monitor and never got up.
It's not literally true. It's not entirely false either. I've been in love with computing for as long as I can remember. Even when teenage social life pulled me away from the PC for a while, I'd find ways to drag it back in — like the year I wrote a little hack that got me and my friends free invites to every party in town.
Then careers happened. After I started my first company, the real world made an inconvenient point: I might be passionate about programming, but I was constrained by my own time and my own skill, both of which got scarcer as responsibilities piled up. Fifteen years later — CTO, CEO, executive — programming had shrunk to a hobby practiced during the precious hours my son took his weekend naps.
Until 2026.
123,000 Reasons to Come Back
The last six weeks have been chaos. Being on Stone's executive committee gets you a calendar you have little — none? — control over. Between people-management meetings that eat entire days, board sessions where AI is one of the main agenda items, and the multiple pulses of the dozens of projects my team has in flight, I somehow shipped 76 pull requests containing 123,000 lines of production code. (324,000 if you count docs, assets, lockfiles, and config. I'm only counting the lines I'd have to defend in a code review.)
All of it went into Masons — an internal AI-tooling product we're building at Stone with a deliberate constraint: 100% of the code, 100% of the reviews, 100% of the verification has to be produced by AI agents. No safety net of "a senior engineer will catch it in review" — the reviewer is an agent too. No "the human writes the hard parts" — the human (me) is there to direct, gate, and decide what gets built. We chose that rule because we wanted to learn what AI-driven development actually looks like when there's nowhere to hide. You can't accidentally smuggle human craft into a product where the rules say a human can't touch a line.
I'm not the only one doing this. Tobi Lütke, CEO of a $150 billion company, recently opened a pull request against Shopify's own Liquid templating engine and let an autonomous agent loop run roughly 120 iterations against it. The result: 53% faster parse and render, 61% fewer object allocations, all from the CEO's terminal. Different setup from mine, same instinct: the people running tech companies are quietly back at the keyboard, because that's where you actually see what's changing.
I went back to the trenches because I wanted my own answer, from first principles, to one question: what actually changed? In Nothing Will Be the Same I argued that AI is dismantling the assumptions our entire industry runs on. That post was the view from the executive office. This one is the view from the keyboard.
From the Trenches
A few things I learned shipping a real product end-to-end with AI as my pair, that I haven't seen written down in many places.
AI is still extremely inconsistent. It needs strong direction. Left to its own devices it'll wander into a swamp of plausible-looking code that doesn't survive contact with reality. The most important skill in 2026 is not typing. It's knowing where to point the agent.
The hardest failure mode is UX. Claude can write a working API endpoint in thirty seconds. Ask it to ship a feature end-to-end and the surface will look fine — but it'll be quietly incomplete in ways a real user catches in five minutes. A screen where you can create a resource but never edit it. A page that exists but has no link reaching it. A destructive action with no confirmation. The visuals look consistent across the product. The journeys don't connect.
I spent more time fighting Claude over usability than over correctness. The fix was discipline: I built up a written list of specific UX patterns the product had to follow — confirmation dialogs, empty states, loading affordances, microcopy conventions, every CRUD verb wired before a feature ships — and made them non-negotiable. Once those rules existed in writing, Claude could enforce them on itself. Without them, every feature shipped with holes.
Then there was the QA problem. The system would look done — unit tests green, type checks clean, every function working in isolation — and then fall apart the moment I opened a browser and walked through it as a human. I had a moment of frustration with Claude that I remember vividly: I'm not going to be your QA. We worked out a structure together. A set of named User Journeys describing the product's critical paths. A written set of testability principles that every component had to honor. A robust end-to-end test suite that simulated a real person using the product, headless and automated, running on every commit. After that, transverse regressions basically stopped.
To prevent the rest of the regressions, I started building deterministic gates that fire locally, during the development cycle. Not in CI — that's already too late. The gates run on the agent's machine, before the code ever leaves it. This is the part I think most people are still sleeping on. When you find a class of mistake the AI makes repeatedly, you don't write a polite comment in your AGENTS.md begging it to stop. You write a piece of code that fails the moment the mistake happens. Example: if a button is missing a loading state, an AST check catches it the next time Claude runs the gate. Claude sees the failure, reads the rule, fixes the button, re-runs the gate. The more of these gates you have, the more stable your codebase becomes — independent of how good the model happens to be on any given day.
The combination of AI plus real verification software is what produces stable code. Not the AI by itself. Not the human by themselves. The dual loop. Claude generates, the deterministic gates judge, and the AI iterates until the gates go green.
AI Slop is a discipline problem, not a model problem.
The biggest myth in this whole conversation is that AI Slop is unavoidable. It isn't. You just need the patience to build the verification layer that calls the AI's bluff every time it hallucinates and forgets the rules — which it does, frequently.
Humans and Machines
If one person can ship 123,000 lines of production code end-to-end while sharing a calendar with the corporate world, the old premises about software development — that it's expensive, slow, and carries a punishing opportunity cost — are at minimum in the ICU, breathing through a tube.
Here's what surprised me most. The bottleneck didn't disappear. It moved.
At one point I had six Claude instances running in parallel, each building a different feature. Six. And the constraint on throughput wasn't the model. It wasn't the CI pipeline. It was me. Every time Claude hit a decision point — should this feature go here or there, is this UX flow right, does this trade-off make sense — it had to wait for a human. Every time a feature was ready for review, I had to make time to actually look at it. Even with six AIs doing the work, the queue piled up on my desk, not theirs.
The bottleneck didn't disappear. It moved. And it moved to me.
And yes, I tried handing those decisions back to the AI. Let it pick what to build next, which trade-off to take, which UX flow made more sense. The pattern I saw: each individual decision looked defensible in isolation, but the decisions wouldn't compose — feature N+1 would contradict the priorities implied by feature N, and the product would drift sideways. The bet I'm making isn't that this gap closes tomorrow. It's that the gap stays open longer than people think — that the division of labor (humans decide what, agents build it) is stable, not transitional.
And even when the models eventually do close it — they will — you still wouldn't want to use that capability. The moment you let the model decide what to build, you're building whatever everybody else with the same model is building. Differentiation collapses. The fleet of agents I describe later in this post is a fleet that builds, not a fleet that decides.
And then there's the other end of the pipeline. Once the code was built, I watched the users of the product struggle to absorb even a fraction of what I was shipping — call it 10% on a good week. Not because the work was bad. Because human attention hasn't been upgraded along with the models. Learning curves still exist. UI friction still exists. The pace of human comprehension is the same as it was in 2016, even if the pace of software production has gone up a hundred-fold. If your users are humans, every old UX rule still applies — only now you're producing features faster than they can metabolize them.
The bottleneck is at the edges now. At the front, in the decisions about what to build and how it should feel. At the back, in the human capacity to learn and use what got shipped. The middle — the actual production of working code — is no longer where the constraint lives.
Good Instincts, High Agency
So given all that, what will my teams look like going forward?
Start from two premises that I think hold. First: humans still need to give direction and make strategic decisions about business, product, and UX. For the foreseeable future, the model isn't going to do that part for you. Second: we're still building products for humans to consume, and humans have not been upgraded.
If shipping software has become ridiculously cheap, then building software that's worth shipping becomes the entire game. Anyone can produce ten variants of a feature this weekend. The hard problem is knowing which variant is worth a human's time. Taste, judgment, and direction — the three skills that used to be slightly devalued because they didn't ship code by themselves — are suddenly the only skills that scale.
If the bottleneck lives at the edges of the development cycle, every minute spent waiting for a decision compounds downstream into hours of wasted agent time. Speed of judgment, not speed of typing, is the new measure of throughput.
If the AI with proper harnesses can build basically anything, then most of the planning machinery I built to prevent wasted engineering effort becomes overhead. I used to need an engineering manager, a data science manager, and a product manager around the table to estimate ICE — Impact, Confidence, Ease — for every new bet. When Ease becomes marginal, two of the three variables collapse and you're left staring at the only one that ever really mattered: Impact.
Which, to be clear, doesn't get easier. It gets harder. When the menu of things you could build was constrained by capacity, prioritization was mostly a question of feasibility. Now the menu is essentially infinite. The discipline shifts from "what can we ship this quarter" to "what is actually worth shipping at all" — and the cost of getting that wrong is a product cluttered with a thousand half-baked features nobody asked for. The hard work just migrated upstream.
And if decision agility is the throughput-defining factor, then organizational entropy is the enemy. Fewer people. Fewer handoffs. Less politics. More room for the agents to actually run.
That's the shape of the team I want to build:
- Small, decisive teams. Few humans. Low entropy. Real ownership.
- No technical managers on the sideline. People management, hiring, and career growth don't disappear — but the pattern of senior engineers who only coordinate, never build, is over. If you're senior enough to lead, you're senior enough to also play. The new multiplier is leaders who direct agents themselves, not leaders who direct the humans who direct the agents.
- People with good instincts for taste, judgment, and direction. The kind of people whose first draft of a feature is already 80% right because their priors are right.
- People with high agency — the ones who don't wait for things to happen, who go after the answer, who make the calls that unblock the queue. Every decision they make on time is worth ten that get made late.
The honest objection here: people with these traits are rare. You can't snap your fingers and conjure a team of them. The whole bet — small teams, no sideline managers, high autonomy — only works if you actually have the people. That scarcity is the point. The competitive advantage of the next five years won't be the size of your engineering org. It'll be the density of judgment, taste, and agency per head. The companies that can hire and retain those people will out-execute the ones that can't, by margins that won't be subtle.
Two or three of those people, paired with a fleet of agents, can out-ship a squad of ten from two years ago. I'm betting on it because I watched it happen on my own machine for six weeks straight.
The Pentium 166 is long gone. So is the kid who hacked party invites for his friends. But sitting back down at the keyboard, with Claude humming in another terminal and a real product taking shape under my hands, I felt something I hadn't felt in fifteen years. The hobby came back.
Turns out the bottleneck was always me. Not in a bad way. In the way that means I get to do the part that matters again.