For a long time, code told you who wrote it. You could look at how someone named their variables, where they drew the boundaries between modules, how they handled the error path, and get a fair read on them in a minute — in a review, in an interview. That’s mostly gone now. The same code might have come out of an agent in ten seconds, and there’s no way to tell from the diff. Everything that used to separate a strong developer from an average one — knowing the syntax cold, having the APIs in muscle memory, typing fast — is free now, and everyone has it.
But the leverage didn’t go anywhere. It just moved off the code and onto everything around it: the commit history, the shape of the repository, the tests, the habit of actually reading changes. This is the stuff that always got cut first when a deadline was close — optional hygiene you’d get to later. With agents in the loop, it stopped being hygiene. It’s the interface the agent uses to see your system, and it’s turned into the clearest way to tell a strong engineer from someone who just hits Tab quickly.
TL;DR
- Code stopped being the differentiator: the agent writes it, and it looks the same for everyone. What differentiates now is what the agent reads as context.
- The win isn’t generating faster — it’s having a system where both humans and agents move fast. Discipline now multiplies across every agent run, and there are hundreds a day.
- METR: experienced developers in mature repos were 19% slower with AI — and didn’t notice. DORA: “AI doesn’t fix a team; it amplifies what’s already there.”
- Three signals that now matter more than the code itself: a clean commit history (memory externalized), decomposition (context, not aesthetics), and reviewing someone else’s diff (the core job, not a formality).
The leverage moved, it didn’t vanish
Simon Willison puts it plainly: «AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents». The word doing the work there is amplify. An agent doesn’t clean up your mess; it just moves faster through whatever you hand it, mess included.
There’s a study that makes this uncomfortable to read. METR ran a randomized controlled trial in 2025 with experienced open-source developers working in repos they’d maintained for years. Allowed to use AI, they came out 19% slower. The strange part is that they never felt it: going in, they expected a 24% speedup, and even afterward — having actually lived the slowdown — they still believed AI had made them about 20% faster. METR points at context to explain it. The effect was worst in projects with “very high quality standards” and “many implicit requirements” — the documentation, the test coverage, the linting. Which is to say, exactly the places where the discipline lives in people’s heads instead of being written down in the repo.
DORA’s 2025 report scales the same idea up to whole organizations: “AI doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems.” It’s specific about the mechanism, too. Teams with loosely coupled architectures and fast feedback loops pull ahead; teams “constrained by tightly coupled systems and slow processes see little or no benefit.” How your code is structured and how your CI behaves end up deciding whether the agent pays off or backfires.
So that’s the thing being amplified. It’s worth going through it signal by signal.
Signal 1. Commit history is memory, externalized
Birgitta Böckeler at Thoughtworks names exactly what an agent is missing: «no social accountability, no aesthetic disgust at a 300-line function, no intuition that ‘we don’t do it that way here,’ and no organisational memory». Organizational memory — the why behind the code — lives in someone’s head and in half-remembered conversations at a whiteboard. The agent has access to neither. The one place that memory gets written down in a form a machine can read is the commit history.
And agents do read it. Anthropic’s Claude Code best practices suggest pointing the agent straight at history: instead of asking “why does ExecutionFactory have such a weird api,” ask it to “look through ExecutionFactory’s git history and summarize how its api came to be.” A clean history of atomic commits with real messages is context you can query on demand. A log full of “wip,” “fix,” and “asdf” is context that simply isn’t there.
This is why Willison thinks version control matters more with AI, not less: “Being able to undo mistakes and understand when and how something was changed is even more important when a coding agent might have made the changes.” A tidy history used to earn its keep during the occasional git bisect. Now it feeds context into every session with the agent.
Signal 2. Decomposition is context, not aesthetics
“Clean code” got sold for years as a matter of taste. With agents it turned into a matter of performance — and one you can measure. Armin Ronacher: «Simple code significantly outperforms complex code in agentic contexts». Not nicer to look at; it literally works better. Böckeler describes why: in a tangled codebase the agent “might look in the wrong place for an existing implementation, create inconsistencies because it has not noticed a duplicate, or be forced to load more context than a task should require.” Bad internal quality hurts the agent the same way it hurts a person — except the agent runs into it on every task, not once in a while.
That leads to a conclusion that flips the usual argument on its head: «the code design itself is a huge part of the context». Splitting a system into modules with predictable boundaries isn’t an aesthetic choice — it’s how you keep the agent scoped to the part that matters. Anthropic makes the same point from the other direction: «Claude works best when it’s scoped to the part of the codebase that’s actually relevant to the task». A 2,000-line God class isn’t just painful for the humans; it forces the agent to pull the whole thing into context just to change one line.
You can see what happens without that discipline in the numbers. GitClear recorded an 81% jump in duplicated code blocks between 2023 and 2026 — the first time copy-paste has outpaced moved code. An agent left to run without structure or review «compounds inadvertent technical debt», which is how Böckeler put it after an experiment where she pushed a modularity review “until later.”
Signal 3. Reviewing the diff is the core job, not a formality
Once generation is basically free, the bottleneck becomes verification. Willison doesn’t dress it up: «A culture of code review. This one explains itself. If you’re fast and productive at code review you’re going to have a much better time working with LLMs». Review used to be the courtesy you paid a teammate at the end. Now it’s the part of the job the human keeps after handing generation to the machine.
The data lines up from every direction. In Stack Overflow’s 2025 survey, the top complaint about AI code is that it’s “almost right, but not quite” — 66% of developers said so; 46% actively distrust how accurate it is, and the more experienced the developer, the more skeptical. That’s not Luddism. “Almost right” only gets caught by a person who can read a diff and knows where to stop. Even the best-practice guides admit as much: Anthropic suggests reviewing AI code from a fresh session, since “Claude won’t be biased toward code it just wrote” — the same reason you don’t let an author approve their own PR.
Mitchell Hashimoto, who has gone deep on agentic development, keeps one hard line: «I’m not shipping code I don’t understand». That’s really the whole signal. Not how much code you produced, but how much of what the agent produced you actually sat down and understood.
How to check it — in yourself and in a candidate
A LeetCode problem now tests a skill you’ve handed to a machine. There’s a better exercise. Give the candidate a 200-line diff that an agent generated and ask them to review it out loud. Everything shows up there: whether they catch the silent duplicate, whether they notice the missing case, whether they can tell “it works” apart from “it’s correct.” A hiring writeup on Built In says it well: “The signal isn’t the code itself. The signal is the hesitation. I want to see where they pause.” The same piece, on what’s changed: “Generation is cheap. Verification is expensive… It’s the core of senior-level engineering judgment.”
Checking yourself is just as easy. Open git log for the past week — does it tell you what you actually did, or is it a wall of “wip”? Could a new hire, or an agent, figure out where a module starts and ends without reading all of it? Does the code an agent wrote go through the same review yours does? Three yeses and you’ve built a place where AI leverage compounds. Three noes and you’ve rebuilt the environment from the METR study, where the agent slows you down and you don’t feel it.
The takeaway: a strong engineer is one who leaves a system behind
This one’s personal for me. I work on a payments and billing platform in Go, where a bug can mean charging a customer twice, and agents have been part of my day for a while now. I move fastest not when the agent emits more lines, but when the repo is set up so it lands in the right place on the first try — clean history, modules with clear edges, tests it can check itself against.
That’s the shift, start to finish. Discipline used to multiply only your own speed — the twenty percent you can always shave off when the deadline is close. Now it multiplies across every agent run, and there are hundreds of those in a day. The small stuff became the lever. The strong engineer today isn’t the one who types fastest, or even the one who writes the cleverest prompts. It’s the one who leaves behind a system where everybody moves fast — people and agents alike. Everyone writes the code the same way now. The difference is in everything around it.