The New Senior Skill: Reviewing Code You Didn't Write and Don't Understand

There’s a specific kind of discomfort I’ve heard senior engineers describe lately. They open a pull request, start reading, and the code is… fine. Syntactically clean. No obvious bugs. Tests pass. And yet something feels off - like the logic is slightly sideways, or the approach is one nobody on the team would have chosen, or the whole thing is just a little too long for what it’s actually doing.

That’s AI-generated code. And reviewing it is a genuinely new skill.

The old mental model for code review was roughly: catch bugs, enforce style, share knowledge. You were looking for things that were wrong. But AI doesn’t really write wrong code. It writes plausible code - code that pattern-matches to correctness without necessarily understanding your system, your constraints, or why the feature exists in the first place.

That’s a completely different problem. And most review processes weren’t built for it.

The Bottleneck Nobody Saw Coming

Here’s the thing about AI coding tools: they solved the wrong bottleneck.

For years, the complaint was that writing code was slow. Boilerplate was tedious. Repetitive tasks ate up senior time. AI fixed all of that. A developer can now generate a 2,000-line PR in an afternoon.

But the review process is still human. And it just got a lot harder.

The code looks fine - that’s exactly the problem. You’re not scanning for typos anymore. You’re interrogating intent.

And that shift has a cost. The productivity gains at the generation stage are real. They’re just being quietly offset by a growing review burden that nobody’s talking about enough.

The New Problem: Code That Works But Doesn’t Belong

There’s a term floating around engineering circles that captures this perfectly: “AI-assisted obfuscation.” The code works, but it’s written in a way no human on the team would choose - making it hard to maintain and even harder to reason about. The review process becomes the only defense against becoming a legacy codebase on day one.

Legacy codebase on day one. That’s a brutal framing. But it’s accurate.

AI doesn’t understand your codebase, it makes educated guesses based on patterns. It doesn’t know why you made the architectural decisions you made six months ago. It doesn’t know which abstractions are load-bearing. It doesn’t know that the reason you’re not using that library is because of a painful incident last year that everyone on the team remembers.

So it writes code that’s technically correct and contextually wrong. And it does it confidently, at scale, in every PR.

The review burden isn’t just bigger. It’s qualitatively different.

What You’re Actually Looking For Now

The question that keeps coming up in senior engineering circles is a deceptively simple one: should this code exist at all?

That question - should this code exist at all? - is the new center of gravity for senior review.

Here’s how I’d break down what that actually means in practice:

• Check the imports and dependencies first. AI doesn’t understand your codebase, it guesses. It will introduce dependencies you don’t use, reference libraries you’ve deprecated, or pull in something new when you already have a solution. This is the fastest way to catch a PR that’s technically fine but architecturally wrong.

• Ask “why this approach?” Not to be difficult but to understand if the developer (or the AI) actually considered the alternatives. If they can’t explain the tradeoff, the code probably shouldn’t merge yet.

• Look for the seams. AI-generated code tends to be locally coherent but globally awkward. The function works. But does it fit the surrounding system? Does it duplicate logic that exists elsewhere? Does it introduce a pattern that contradicts the rest of the codebase?

• Treat length as a signal. A 2,000-line PR from a junior developer used to mean they’d been working for weeks. Now it might mean they spent an afternoon prompting. Volume is no longer a proxy for effort or understanding. If the PR is large, slow down proportionally.

• Distinguish “it works” from “it’s right.” This is the hardest one. A passing test suite tells you the code does what it was asked to do. It doesn’t tell you whether it was the right thing to ask. That judgment still requires a human who understands the product, the system, and the constraints.

The Mentorship Problem Hidden Inside This

There’s a second-order issue here that doesn’t get enough attention.

Junior developers are getting faster. A six-week experiment at ANZ Bank found that beginners using GitHub Copilot completed tasks 52.27% faster than a control group - a striking number. But an Anthropic study, cited in InfoWorld, found that developers using AI assistance to learn a new library scored two letter grades lower on conceptual understanding tests compared to those who learned without it - even though they completed tasks faster. The researchers noted that some developers reported feeling “lazy” and acknowledged “gaps in their understanding.”

Speed without understanding. That’s the trade being made, quietly, in a lot of teams right now.

The mentor’s job has shifted. It’s no longer enough to show a junior developer how to write the code. The more important question is whether they understand why the AI’s suggestion is good - or whether they’re just accepting it because it compiled.

That changes the review conversation entirely. It used to be “here’s how to do this better.” Now it’s “do you understand why this works? Could you have written it without the AI? What would you change?”

IMHO the goal of mentorship was never to produce developers who can generate code. It was to produce developers who can think about code. And right now, AI is making it very easy to do the first thing without ever developing the second.

The Skill That Doesn’t Show Up in Job Descriptions Yet

Addy Osmani put it well in his November 2025 piece: “AI will help you chop a lot more trees, but someone still needs to decide which trees to cut and how to build a stable house from the lumber.” That’s the senior developer’s job now. Not writing the boilerplate - that’s handled. The job is judgment. Context. The ability to look at perfectly syntactic code and ask whether it belongs in your system, whether it reflects the right understanding of the problem, and whether the person who submitted it actually knows what they built.

That’s not a new skill exactly. It’s an old skill that just became the main skill.

The review process is no longer your last line of defense against bugs. It’s your last line of defense against a codebase that nobody understands - including the people who wrote it.

That’s worth taking seriously. And it’s worth building a review practice that’s actually designed for it.

Not reviewing faster. Reviewing differently. The products I’m most proud of are the ones I took the time to build right.