Until recently, an AI agent would do a few things, then stop and ask me questions, or ask me for the next steps. Somewhere in the last six months that changed: now it just runs, until it genuinely cannot go any further.
There was no lightning-bolt moment for me. It was a collection of moments, a slow creep. You're working along, and one day you catch yourself thinking: hang on... the task that took me some time a couple of months back was now completed almost autonomously by this AI agent. And then it happens again a few weeks later, with something bigger.
Here's what that creep did to my work: in roughly the last year, I've written fewer than a hundred lines of code by hand. I don't really write code anymore; I review it. And lately I don't even review every line; I sample it.
Since you probably don't know me: I've spent almost twenty years building web applications and user-facing products, several of those managing teams of ten-plus people, including products with millions of users at Bumble.
This post is about what changed between December 2025 and July 2026, where the trend is going, and how I'm changing the way I do engineering to get ahead of it. Compressed into one thought: the rules have changed, and people who think clearly and write clearly are going to matter more than ever.
Three eras in three years
First, AI was a good autocomplete and not much else. Then came about a year of closely-directed work, the Copilot era: genuinely useful, but you had to direct it tightly: look at these three files, change this function to behave like this, put this UI component here, follow that reference file. If you did that, it did a pretty good job. Honestly, it felt like things wouldn't change much from there.
Then, over a few weeks in late 2025, the frontier labs shipped a wave of models1, and agents stopped needing step-by-step instructions. They started taking high-level intent and carrying it over hours of work.
Why? My hypothesis (and it is only a hypothesis) is that while humans were closely directing AI through the Copilot era, the AI companies were learning from that interaction. We were acting as quasi-agents, and the agents learned from us. The standard account from people who train these systems is different: reinforcement learning on verifiable rewards, meaning models trained against outcomes like "the tests pass" in sandboxed environments.2 The two stories aren't mutually exclusive, and either way the result is the same: the agents stopped needing me between every step.
My job is a factory now
My work has turned into a car factory. If you hand-build a car, you inspect every piece, every gear. If you have smart workers on an assembly line, you direct instead of build, but you still check everything that comes off the line. The stage after that is where I live now: one agent makes, another agent checks, and my job is directing. I'm an orchestrator, there are minions doing the work, and I'm sampling their output and providing the taste.
Diligence doesn't disappear, it becomes random sampling: random lines, random areas, enough distribution to catch what usually goes wrong. The move that makes it compound: everything sampling catches gets converted into static enforcement (a lint rule, a code-review instruction, a pipeline check) so the same mistake can't happen again. Google's recent whitepaper lands on the same rule: "add a rule every time the agent does something it should not do again."3
Probably the most important thing I've learned this year: the loop you run depends entirely on what you're building.
Different context, different judgments
Before any work starts, a few knobs get set: how critical is this to the business (an experimental feature, by default, cannot be critical), how big is it, how many decisions are hiding inside it. Days-based estimation doesn't work anymore, because things happen in hours, but t-shirt sizing actually works now. You get a rough size and pick a path.
The throwaway path. For quick internal tools and interim artifacts, I've written zero lines and reviewed zero lines. I jump literally from my prompt to the output: prompt, agent works, I sample the output, go again. The code is never opened. I know how reckless that sounds; I'll come back to why I don't think it is.
The real-project path. For the codebase I actually live in, I'm more involved, because I don't want the models drifting in the wrong direction. The loop becomes: I do the rant, I do the plan, I break the plan into reviewable milestones. (The rant is literal: my typing never kept up with my thinking, so prompts start as speech through a dictation app called Handy.4)
The milestone loop is honestly a bit funny: the agent writes the code and opens a draft pull request against me, using my own account; I go in as a human, review my own pull request, leave comments in GitHub, and tell the agent I've left comments for it. Big features get built as vertical slices that fit together like Tetris, each slice testable on its own, the whole thing done when the slices line up, not as a waterfall where everything collapses at the end.
The floor under every path. Whatever the AI builds, a human actually has to use the feature. You are the taster. Someone made food; you taste it, you check whether it's tastefully done, whether it makes sense. This part is mandatory.
Between those extremes, review depth scales with stakes. Business-critical code, I read all of it. Non-critical, I read some. Isolated one-offs, sometimes none at all. Different context, different judgments.
Nobody reads every line
This is where I part ways with the official advice. Google's whitepaper, which agrees with almost everything else in this post, says plainly: review every line the agent produces that is going to ship.3
I don't think that's realistic, for two reasons.
The first: AI is really, really good at pattern recognition. Distill the patterns a reviewer should look out for, and one AI can impartially catch issues while another fixes them, in a recursive loop, combined with tooling we've had for years: static analysis, linters, type checkers, test runners, smoke tests, property-based testing, fuzzing. The agents can help you write those tools too. With good enough guardrails, you don't have to stress about reading every single line. It's a combination of tools, not one person sitting on a laptop with nothing else in place.
The second is more uncomfortable: realistically, no human being honestly reads every line of code they review. I know this is controversial, and most people will say they do. But almost every engineer I've worked with has admitted, at some point, that they didn't read everything. They sampled it, checked the conventions, looked hard at the critical parts they knew about, and approved. We've been sampling all along, just without the guardrails we have now. And it's not like every line of code is headed for a nuclear or medical facility. Applying the right depth of review in the right context has always been the actual job.
The tier of code where you read everything is real, but it's shrinking, and guardrails are what shrink it.
I've seen this play out at scale twice this year. In public: Bun rewrote roughly a million lines of Zig into Rust in eleven days, using 64 parallel agent instances in an implementer/reviewer pattern, with its TypeScript test suite as the conformance harness.5 It shipped with 19 known regressions (since fixed) and drew fair criticism for its heavy use of unsafe. I'm including those deliberately, because they make the point: the test suite caught what mattered.
On my own team: we migrated our entire Vue component library from .vue single-file components to TypeScript TSX (still Vue as the framework) using AI plus static migration tools I built. The static tools converted what they could mechanically, the agents took care of the rest. With good test coverage going in, I'd estimate 95% of the work landed without a single bug; what bit us were migration artifacts (global Vue and Nuxt configuration changes) and some minor class-ordering issues. (I've written about the TSX setup in a previous post.)
The counter-evidence: a widely-cited METR study found experienced developers using AI took 19% longer on certain tasks, mostly verifying and correcting AI output.6 I can't argue with their data, but it doesn't match anything I've seen, and I think the difference is the guardrails. What I've seen is prototyping going from weeks to hours, almost a J curve. At Bumble, on a highly experimental platform, these tools would have let us ship ten times the experiments. If verification is where the time goes, verification is what you should industrialize, which is the rest of this post.
The curve is accelerating
Everything above already happened. The reason I'm confident it keeps going is the trend line: METR tracks the length of task, measured in human-professional time, that models complete autonomously, and that horizon has been doubling roughly every seven months since 2019, accelerating since 2023.7 The Bun rewrite is one point on that curve. Extrapolate twelve months, and the question stops being whether the agent can do the task, and becomes whether your engineering team is set up to direct and verify that much output.
If I were running a ten-person team, here's what I'd change on Monday morning.
What I'd change Monday morning
Everyone runs agents in parallel. You can direct multiple tasks at once now; one agent per person leaves most of the value on the table.
The agents move off laptops. When your laptop closes, your agents die; on a cloud environment they keep running. We attach with tmux, and recently I've been trying out Herdr.8
Onboard agents like employees, but respect the context. An agent with no guidance does whatever it wants, but stuffing its context with your documentation fails just as drastically. Context is precious; don't pollute it. What works: self-documented code that records the why, and a knowledgebase the agent can grep when it decides it needs more.
Force the why. Agents love to narrate what they're doing, but the code already tells you that. Force them to document why: the thing you need three months later, staring at a line and wondering why it was written in the first place.
Gate on evals, not demos. Almost everybody should have an internal eval for what they're building; a passing demo tells you very little about how the thing behaves the rest of the time.9
Review from altitude. AI reviewers take the boring layer (style violations, easily-exploitable security gaps) and your review moves up to architecture, reusability, data structures, the bigger patterns. You're allowed to zoom out. A developer becomes an architect now, and that's a huge thing.
On hiring: I don't have an answer. Hiring has become difficult, because every portfolio project is now vibe-coded, so you have no idea what you're looking at. You have to somehow evaluate taste: how much care and attention went into the work. We've struggled with it, and I won't pretend otherwise.
The discipline: fighting brain rot
I'd be lying if I ended on the prescriptions, because the hardest problem on that Monday morning is me.
These models make it so easy to not read anything and just ship. You have to actively fight yourself, and I struggle with this personally. The temptation: prompt something, barely test the output, say "yep, ship it", because the models are good enough that whatever they produce will mostly work, and the saved time feels like it buys the next feature, the next experiment, the next side project.
But it leads to complete brain rot, for both the agent and for you. You lose all sense of what's actually being built: an old man yelling at the cloud, making claims about your own system without verifying that any of them back up. Google's paper puts it well: AI "multiplies both your strengths and your weaknesses."10 The taste test, a human actually using the thing, is what keeps that multiplier pointed the right way.
Code as a compiled artifact
Everything above is my plan for the next year. Here's where I think it goes a couple of years out.
I don't write binary. I don't write assembly. I don't even write C. Node and Chrome are built on C, which becomes assembly, which becomes something I've never once needed to look at, and I just write JavaScript on top. With the next generation of agents, I think the whole codebase becomes almost like a compiled artifact. Just as I don't read assembly today, you won't need to read the code agents produce. It will be some internal representation in their latent space.
Someone will say: but you're becoming dumb. Which is true, but I'm also dumb now. I don't know assembly, and somehow I still write TypeScript and do useful work.
It's not a one-to-one mapping, of course. But when your code gets compiled, most of the time (and I want to stress most of the time) you don't care what bytes it compiled to, because it works and everything is fine. Similarly, give an agent a detailed specification and guardrails, and most of the time the code it produces just works, as expected. Neither case means you go blind; it's always context. If your application is high-performance and the compiled code isn't performing, you start investigating. If your prompted code isn't good, you do the same thing: you dig down into it.
So the rules change a lot. Your ability to think clearly, to write clearly, to communicate clearly becomes the important thing, because good thinkers and good writers can impart their taste, their wisdom, and their vision, and the agents do the work.
That's the bet I'm making for the next year. I'm writing it down so that next July I can come back and check whether any of it backed up.
-
Gemini 3 Pro (Nov 18, 2025), GPT-5.1 Codex-Max (Nov 19), Claude Opus 4.5 (Nov 24), and GPT-5.2 (December). Simon Willison's 2025: The year in LLMs is the best chronicle of the wave. ↩
-
Nathan Lambert's writing at Interconnects is the clearest explanation of reinforcement learning with verifiable rewards, a term his team coined. ↩
-
Google, The New SDLC With Vibe Coding (May 2026), by Addy Osmani, Shubham Saboo and Sokratis Kartakis; there's an author's summary on Osmani's blog. A genuinely useful paper, with the caveat that its later chapters lean promotional about Google's own tooling. ↩
-
Handy: free, open source, fully offline speech-to-text. Plenty of similar apps exist, with new ones every month; I just haven't had a reason to switch. ↩
-
Simon Willison, Rewriting Bun in Rust, and The Register's coverage of the merge. ↩
-
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (paper). Worth noting the study used early-2025 tools (Cursor with Claude 3.5/3.7 Sonnet), from before the autumn wave this post is about. ↩
-
METR, Measuring AI Ability to Complete Long Tasks: the ~7-month doubling time, revised faster in their Time Horizon 1.1 update (January 2026). ↩
-
Herdr: an agent-aware terminal multiplexer: tmux that understands agents, showing at a glance which are blocked, working, or done. ↩
-
"Set the bar at the eval, not the demo." (The New SDLC With Vibe Coding, p. 44.) ↩
-
"AI is a force multiplier — and it multiplies both your strengths and your weaknesses." (The New SDLC With Vibe Coding, p. 47.) ↩
Top comments (0)