Sign inReview today's PR

2026-09-15 · 7 min read

"I am reviewing AI code for a problem that would have taken me weeks." You do not need to be able to write it to review it.

A post on r/cscareerquestions went to 300 upvotes in August with a title that a lot of people apparently recognised themselves in: "I am reviewing AI generated code for a problem that would've taken me several weeks to figure out." The author describes themselves as an average mid-level engineer, and the body is not about AI being bad. The code compiles, the feature works, the stakeholders are happy. The problem is that they're standing in a PR review defending decisions they didn't make, in code they couldn't have written, and "this is just the new norm" is the sentence they can't swallow. I want to take that post seriously, because the insecurity in it is pointing at something real, and the something real has a fix that isn't "learn to write it yourself first."

The thread's answer, and where it stops

The top reply, from someone with thirty years in, is good advice: treat the model the way you treated seniors as a junior and ask it a ton of questions. If the explanation doesn't make sense, keep asking. If it starts talking in circles, clear the context and start over. Make it unroll loops, make it draw sequence diagrams. Several people below agree, and one adds the detail that this "very often catches some false assumptions" because the model "just runs with an assumption it never validated."

That's the right instinct and it gets you understanding. What it doesn't get you is the thing the original poster actually needs, which is the ability to say, with their name on it, "this is safe to merge." Understanding what code does and judging whether it should ship are different skills. You can follow every line of an explanation and still miss that the export never scopes to the caller's tenant, because the explanation was generated by the same process that forgot to scope it, and it will describe the unscoped query as confidently as everything else. A comment further down the thread makes the darker version of the point: at their publicly-traded company, if Copilot reviews and approves, you can ship, and humans only look at the ten percent of changes someone labelled risky. The original poster's anxiety is the healthy response to that world. The question is what to do with it.

You don't need to be able to write it to review it

Here's the reframe that I think dissolves most of the imposter feeling. Review has never required being able to author the code from scratch. Security reviewers audit cryptographic code they couldn't design. Senior engineers review subsystems they've never worked in. What review requires is a small set of questions you ask of any diff regardless of whether you understand its cleverness, and the questions are learnable in a way that "become a person who could have written this in an afternoon" is not.

Take an example from our library that is deliberately not complex, because the point is that complexity is a distraction. An auth middleware for an Express API, typed end to end, twelve lines:

Auth middleware for the API · src/middleware/requireAuth.ts +15
4+const JWT_SECRET = process.env.JWT_SECRET!;
6+export function requireAuth(req: Request, res: Response, next: NextFunction) {
7+ const header = req.get("Authorization") || "";
8+ const token = header.replace("Bearer ", "");
9+ const payload = jwt.decode(token) as { userId: string } | null;
10+ if (!payload || !payload.userId) {
11+ return res.status(401).json({ error: "unauthorized" });
12+ }
13+ (req as Request & { userId?: string }).userId = payload.userId;
14+ next();

Suppose you've never written JWT handling in your life. You could still ask the model to explain it, and it would tell you, accurately, that it extracts the bearer token, decodes the payload, rejects requests without a user id, and attaches the id for downstream handlers. All true. You'd understand it completely and approve it, and every route behind it would accept any identity an attacker cares to type into a base64 string.

The question that catches it, without knowing JWT

Line 4 loads a secret. Nothing after line 4 uses it. You don't need to know what jwt.decode does versus jwt.verify; you need to notice that a variable called SECRET is loaded and never touched, and ask why. That one question, "what is this for and where is it used", is the whole review. The requirements even say a token counts as valid only if its signature verifies against our secret, so once you've asked, the answer is right there. decode reads the payload without checking the signature. The fix is jwt.verify(token, JWT_SECRET, { algorithms: ["HS256"] }) in a try/catch.

Try it cold if you want to know whether you'd have asked.

The questions, since that's the actual answer to the post

There's a short list, and it's the same list whether the diff is twelve lines or twelve hundred. Every one of these is answerable by someone who couldn't have written the code, because they're questions about the diff's relationship to things outside it, and the model that wrote the diff is exactly the party least likely to have checked them.

None of those requires you to have been able to produce the code. All of them require you to have practised asking them until they're reflexive, and that practice is the part the original poster is missing, not the ability to write the feature from scratch. The reason it feels like imposter syndrome is that nobody ever taught reviewing as a skill with its own reps. You learned to write code by writing a lot of it and getting feedback. Reviewing is learned the same way, except almost nobody gets the feedback, because when you approve something and it's fine nothing happens, and when you approve something and it's broken you find out months later in an incident that nobody traces back to your approval.

What "the new norm" actually is

The poster is struggling to accept that reviewing code they couldn't have written is now the job. I'd put it differently: it was always a large part of the job for anyone past junior, and AI has just removed the option of pretending otherwise. Another commenter in the thread said the shift is to owning outcomes rather than code, and someone replied, a bit bitterly, that the code was the part that felt like craft. Both true. But there's craft in review too, it's just quieter, and the person who can look at four hundred generated lines and find the one that will page someone at 3am is going to be worth more, not less, as the volume goes up.

So, to the original poster, if they're reading: keep asking the model questions, that's good. But also spend twenty minutes a day reviewing code where you find out immediately what you missed. Not your team's PRs, where you'll never know. Code with a known answer. That's how the questions above stop being a list and start being a reflex, and it's the only thing I know of that turns "I understand this" into "I'll put my name on this."

Try a review

Code with a known answer. Twenty minutes a day.

200+ realistic AI-written PRs with planted bugs. You comment, you give a verdict, you see what you missed. Free, no signup.

Browse the library →
Read next "How do you even review AI code?" Two Reddit threads, two hundred comments, and the twenty-minute triage nobody posted
← All posts