Your New Teammate Types Very Fast

Imagine the following new hire. Prodigiously well-read — has apparently seen every codebase on earth. Types faster than anyone you've ever met. Unfailingly confident, endlessly polite, never tired, never defensive in review. Also: has no memory of what your team decided last sprint, has never met your users, will occasionally invent a function that doesn't exist and describe it to you with total serenity, and — this is the important one — will never, ever be paged when their code breaks.

Would you merge this person's PRs on a skim?

Every team using AI assistants has hired this teammate. The code arriving in your review queue is increasingly co-authored by it. And I've noticed something worrying in how organizations respond: they update their writing practices — prompts, tools, workflows — while leaving their reviewing instincts calibrated for a world where every diff was typed by a colleague who understood it. That calibration is now wrong, in specific and fixable ways.

Automation bias, meet code review

Cognitive science has a name for the first problem: automation bias — the well-documented human tendency to over-trust output from automated systems, to under-search for evidence against it, and to let machine confidence substitute for our own verification. It's been studied for decades in aviation and clinical decision support, and its central finding transfers uncomfortably well: automation doesn't just make people faster, it makes them less vigilant, precisely because the system is usually right.

Code review adds an aggravating factor: fluency. Human reviewers use surface signals as proxies for underlying quality, and mostly this heuristic serves us well — a colleague whose code is tidy, idiomatic, and well-commented usually did think carefully. AI-generated code breaks the proxy. It is maximally fluent by construction — beautiful names, docstrings, idiomatic patterns — regardless of whether the underlying logic is sound. The polish that used to signal care now signals nothing. Your pattern-matcher for "this author knew what they were doing" fires on every diff.

So the first adjustment is attitudinal, and it's the whole thesis in one line: review the code as if written by a bright, tireless colleague on their first day — talented, worth taking seriously, and owed exactly zero benefit of the doubt about your system's context. You wouldn't skim a new hire's first PR because it looked confident. Confidence is the one thing they're guaranteed to have.

Review for intent, not just correctness

A diff shows what changed. Good review has always interrogated why — and this is where AI-heavy changes need the most human attention, because the assistant's "why" is subtly different from a teammate's.

A human author's code encodes intent, however imperfectly: they knew the requirement, made tradeoffs, chose this shape for reasons they can defend. A model's code encodes plausibility: this is a shape that commonly follows from prompts like the one it got. Often those coincide. When they diverge, you get code that solves a problem adjacent to yours — a generic rate limiter when you needed one aware of your tenancy model; textbook retry logic wrapped around a non-idempotent call; a caching layer that is correct in general and wrong about your invalidation rules in particular.

So in review, ask intent questions out loud: Does this match what we actually needed, or what the problem generically looks like? And ask the author — the human one — "why this approach?" Their answer is diagnostic. "Because X, and I considered Y" means the theory lives in a head; you're reviewing engineering. "That's what it generated" is not a moral failing, but it tells you the review must supply the scrutiny that authorship didn't — and that per Naur, nobody currently holds this code's theory. Someone must, before merge, and the review is the last cheap place to build it.

Edge cases live outside the prompt

Here is the most practical single heuristic I can offer: generated code is strongest exactly where the prompt was, and weakest everywhere else. The happy path was specified, so the happy path shines. The edges — the empty list, the duplicate event, the expired token, the concurrent writer, the leap day, the retry that arrives after the timeout it was retrying — were not in the prompt, so what fills them is statistical improvisation with excellent posture.

Human juniors have this failure mode too, of course. The difference is distribution: a human's blind spots cluster around inexperience and announce themselves in hesitant code. The model's blind spots are camouflaged in idiom and scattered anywhere the prompt went quiet. So spend your review attention asymmetrically: skim the happy path, and interrogate boundaries, failure handling, concurrency, and integration points with your actual system — permissions, tenancy, money, time zones.

Two sharper checks for the modern review:

Verify the seams. Models occasionally hallucinate — an API that doesn't exist, a parameter that does something else, a plausible-but-wrong version of your internal helper. Any unfamiliar call deserves ten seconds of "does this exist and do what it claims?"

Review the tests hardest. When the same assistant writes the code and its tests, the tests tend to enshrine the code's assumptions rather than challenge them — green checkmarks verifying that the code does what the code does. Read tests as claims about requirements, and ask what's missing, not just what passes. Beware, too, the accidental promises: per Hyrum's law, every observable behavior will eventually be depended on — including behaviors the model chose arbitrarily and nobody decided.

Ownership is not transferable

The last adjustment is cultural, and it's non-negotiable: the person who opens the PR owns the code — entirely, regardless of who or what typed it.

"The AI wrote that part" must never function as a warranty disclaimer, and the review conversation is where that norm gets enforced, gently but firmly. When a reviewer asks "what happens if this callback fires twice?", the answer "I'll check" is honorable; the answer "the model handled that" is not an answer, because the model is not on call. It will not join the incident channel. It will not remember this code exists. The pager, the debugging session, the explanation owed to a customer — those land on humans, which means the understanding must land on humans before the merge does.

For reviewers, this reframes what your questions are for. A review question about an AI-assisted diff isn't just quality control on code — it's a comprehension check on the author, and a kindness. Every "why is this here?" you ask is theory the author builds before production forces them to build it at 2 a.m. You are not gatekeeping your colleague. You are making sure someone in the building understands the loan before your team co-signs it.

Office hours

1. Adopt the first-day rule. Bright new colleague, zero context, zero benefit of the doubt. Review accordingly — rigor without hostility.
2. Ask "why this approach?" on every substantial assisted PR. You're checking where the theory lives, not policing tool use.
3. Spend attention on the edges. Happy path: skim. Boundaries, failures, concurrency, integration with your invariants: interrogate. Verify unfamiliar APIs exist.
4. Read the tests as requirements claims. Ask what edge case is missing, not just what's green.
5. Say the ownership norm out loud, once, as a team. "Whoever merges it, owns it — authorship tools change nothing." One sentence in the working agreement saves a hundred awkward incident reviews.

The new teammate is extraordinary, permanent, and not going to change from our side of the keyboard. Our standards are the adjustable part — and review is where a team's standards actually live.