Leading Engineering Teams When AI Writes Half the Code

A pull request that used to take an engineer half a day to write now shows up in twenty minutes, fully formed, tests included. That’s not a hypothetical anymore on most teams I talk to — it’s Tuesday. The problem is that the review process, the ownership model, and the way we judge whether someone is growing as an engineer were all built for a world where writing the code was the hard part. When AI generates a large share of the diff, the hard part moves, and if your team’s process doesn’t move with it, you end up with reviewers rubber-stamping code they don’t understand and engineers who can ship features they couldn’t debug.

Move Review from the Line Level to the Intent Level

Line-by-line review made sense when the main risk was a typo or a subtle logic error introduced by a tired human typing at 2am. It makes a lot less sense when the code was generated in one pass by a model that doesn’t get tired but also doesn’t share your team’s context about why a particular approach is a bad idea in your system.

The review question that matters now isn’t “is this line correct” — a model is often quite good at locally correct code — it’s “is this the right thing to build, and does it fit how the rest of the system works.” That means restructuring what reviewers spend their attention on:

• Read the prompt or spec before the diff. If you can’t tell what the author asked for, you can’t tell whether the output actually satisfies it, only whether it compiles.
• Push scrutiny toward boundaries and assumptions, not syntax: what does this code assume about its inputs, what happens at the edges, does it match existing patterns in the codebase or quietly introduce a new one.
• Require the author to explain the change, not just paste it. If an engineer can’t articulate why the generated approach is correct, that’s the actual defect, independent of whether the code itself works.

This is a genuinely different skill from traditional code review, and most senior engineers were never trained on it. Treat it as a skill to develop deliberately, not something people will pick up by osmosis.

Guard Against Skill Atrophy Without Giving Up the Velocity

The uncomfortable tension here is real: the fastest way to ship is often to let the model write it and move on, and the way engineers used to build deep systems intuition was by writing a lot of code themselves, including the boring parts. If you optimize purely for velocity, you get a team that can integrate AI-generated code quickly but can’t reason from first principles when something breaks in a way the model hasn’t seen before.

A few things I’ve found actually work, rather than just sound good in a values doc:

• Protect a slice of hard, foundational work — the pieces of the system that define its actual architecture — as human-first, at least for engineers earlier in their growth. Let AI accelerate the routine 80%, not replace the 20% that builds judgment.
• Rotate people onto debugging and incident work regularly. Debugging a system you didn’t fully write by hand is exactly the muscle that atrophies fastest, and it’s also exactly the muscle you need most when production is on fire.
• Make “explain how this works” a normal, non-punitive question in 1:1s and reviews, not a gotcha. The goal is calibrating whether understanding is keeping pace with output, not catching people out.

Redefine “Done” and Ownership for AI-Assisted Work

“Done” used to mean the code was written, reviewed, and merged. That definition quietly assumed a human wrote it and therefore understood it. Neither assumption holds automatically anymore, so the definition has to get more explicit:

• Done includes understanding, not just passing tests. A change isn’t done if nobody on the team can explain what it does and why, regardless of how it was produced.
• Ownership travels with the merge, not the authorship. Whoever approves and merges an AI-assisted change owns it in production the same way they would if they’d typed every line — that has to be stated plainly, because it’s the opposite of how a lot of people are currently treating AI-generated PRs.
• Track provenance lightly, but track it. Knowing which parts of the system were substantially AI-generated is useful information for prioritizing review depth and refactoring later — it doesn’t need a heavyweight process, just a habit of noting it.

None of this slows teams down in the way people fear. It redirects the time you save on typing into the review and understanding work that was always the actual job — it just used to be hidden inside the time it took to write the code in the first place.

Key Takeaways

• Shift code review from checking lines to checking intent: read the spec before the diff, scrutinize assumptions and boundaries, and require authors to explain generated changes in their own words.
• Deliberately protect foundational, judgment-building work for hands-on engineering, and rotate people through debugging and incident response to keep systems intuition from atrophying.
• Redefine “done” to require team understanding, not just passing tests, and make it explicit that merge ownership means production ownership regardless of who or what wrote the code.
• Track provenance of AI-assisted changes lightly rather than heavily — enough to prioritize review and refactoring, not enough to create process overhead.