Sonar asked more than 1,100 developers two questions. How much of the code you pushed into shared codebases was written by AI? Roughly 42%. Do you trust that code to work correctly? 96% said not fully.

Sit with that pair for a second. Almost half the code landing in shared repos comes from a machine, and nearly every developer shipping it has reservations. The only thing holding that together is review. Review is also the part of the pipeline that got the least investment this year.

IEEE Spectrum ran a piece on this yesterday about whether junior engineers will learn enough in an AI-first coding world. Companies are responding by trying to turn early-career developers into sharper reviewers who catch the subtle defects before release. Sensible instinct. It runs straight into a problem nobody has solved yet: review judgment is built by writing bad code and then living with the consequences.

Review is a skill with prerequisites

When a senior engineer flags a line in a pull request, they are usually not applying a rule from a checklist. They are recognising a shape. They have seen a retry loop without jitter take down a service at 3am. They have watched a nullable field quietly poison a finance report six months after it shipped. That recognition came from being on the hook when it broke.

An engineer who spends their first two years accepting agent output and skimming diffs has not built that library of shapes. Asking them to be the safety net for 42% of the codebase is asking for a skill nobody gave them the reps to develop.

The gap is easy to miss right now because AI code mostly compiles and mostly passes the tests it wrote for itself. It fails where tests are weakest: concurrency, error paths, data migrations, permission boundaries, anything that only misbehaves under real load or real users.

What the teams handling this well actually do

Four patterns are showing up repeatedly, and none of them are about buying another tool.

Review the plan before the diff. Make the agent write what it intends to change and why, then argue with that. Catching a wrong approach in three paragraphs is cheaper than catching it in 900 lines.
Let agents take the boring pass. Style, obvious null handling, missing error checks, dependency drift. Machines are good at the pass humans do badly because it is dull.
Route by risk, not by volume. A copy change and a migration touching the payments table should not enter the same queue. Tag the blast radius and send the dangerous ten percent to a human who has been burned before.
Make the author defend it. If you opened the PR, you explain the tradeoffs, including the ones your agent made. "The model wrote it" is not a review comment.

Put the reps back in on purpose

If your juniors are going to be your reviewers, the apprenticeship has to be designed rather than assumed. A few things that work:

Give early-career engineers real incident ownership, not just observation. Nothing teaches failure modes like being paged for one.
Have them write the failing test by hand before the agent writes the fix. It forces a theory of what is actually wrong.
Ring-fence one ticket a sprint that gets built without assistance. Not for productivity. For calibration.
Run narrated reviews where a senior talks through what they are scanning for and why, out loud. Most review knowledge is tacit and never gets written down.

Velocity is not the risk here. Teams are shipping faster than ever. The risk is a codebase where nobody has the standing to say "this is wrong" with any confidence, and the defects that survive are the ones that only surface in production.

We are here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you are looking to build something, get in contact with us today.

The teams that come out of this decade strongest will not be the ones that generated the most code. They will be the ones who still had people who could read it.