They told me to lighten the review
Someone on my team floated the idea last month, and I keep hearing versions of it everywhere. The pitch goes like this: AI writes code so fast now that we can ease up on review and just let the new hire run. Give them the tool, point them at the backlog, get out of the way.
I have a problem with that. Not because the speed is fake. The speed is very real. My problem is that we’re drawing exactly the wrong conclusion from a true premise.
The deliverable was never the lines of code. It was the decision to approve them and ship them to production under your name. Author yesterday, guarantor today. And when execution speeds up, you don’t lower the bar. You raise it.
The reflex is backwards
The ambient instinct is: the machine codes fast, so let’s trim the review. Read it again slowly. That’s upside down.
When execution accelerates, the need for judgment doesn’t disappear. It concentrates. The bottleneck just moves. It used to live at the keyboard, where someone had to actually type the thing. Now the typing is cheap and the bottleneck slides to the review, where someone has to look at a wall of generated code and decide whether they’ll stake their name on it.
So the one part of the job we’re being told to shrink is the part that just became the whole job. That’s not optimization. That’s removing the brakes because the car got faster.
Author versus guarantor
Let me split two roles that people keep mashing together.
- The author is the one who types it.
- The guarantor is the one who answers for it.
For decades those two were basically the same person, so nobody bothered to separate them. The machine just pried them apart. The author can now be a model. The guarantor still has to be a human with a name and a pager.
The craft slid from one to the other, and nobody’s rewriting the onboarding manuals to match. We’re still teaching juniors how to go fast, when the machine already handles fast. What we’re not teaching them is how to answer for what comes out under their signature.
“I didn’t write it” is not a defense
Here’s the line I never want to hear from someone on my team: “Well, the AI wrote it.”
Pushing generated code you don’t understand doesn’t offload the accountability. It keeps the accountability whole and adds ignorance on top. You’re now fully responsible for something you can’t explain. That’s strictly worse than writing a clumsy function yourself, because at least the clumsy function lived in your head once.
In my world the systems run 24/7 with availability targets around 99.5 percent. Riders tap a card, a gate opens, a bus shows up on a screen. Quality isn’t a trade-off you negotiate when you’re in a hurry. It’s the product. That’s the exact reason the bar goes up when the machine speeds up, not down. Faster wrong is still wrong, it just gets to production sooner.
Definition of done hardens before line one
Most teams treat the definition of done as a checklist you reach at the end. Wrong moment. In an AI-assisted shop the standard has to be set before the first line ships, and it has to be drilled in on day 1, not bolted on at the end.
A definition of done you can check off without understanding what you’re shipping isn’t a standard. It’s a form. And forms are exactly what people fill out on autopilot while the machine generates the thing they’re signing for.
So we harden it early. Can you explain what this does? Can you explain why this approach and not the other one? Can you tell me how it fails? If the answer is “the model suggested it,” we’re not done, we haven’t started.
What the machine doesn’t guess, it doesn’t cover
Documentation debt used to be a tomorrow problem. Now it’s an accountability problem today.
The model fills the gaps it can infer. The business rule that only lives in one architect’s memory, the weird exception for one transit agency’s fare logic, the reason a timeout is set to that specific value: the machine doesn’t guess it, so it doesn’t cover it. And a guarantor can’t answer for what they don’t understand. So every undocumented decision becomes a hole in someone’s signature. That’s not a nice-to-have you clean up next quarter. That’s the thing that makes the accountability real or fake.
A practice that needs the tool isn’t a practice
Watch out for this one, because it hides well. A good practice that depends entirely on a tool isn’t a practice. It’s a crutch.
When you onboard someone, you transfer the practice, not the access to the tool. If your new hire can only review code with the AI assistant running, you didn’t teach them to review. You taught them to ask the machine, which is the thing you were supposed to be checking. Take the tool away for an afternoon and you find out fast whether you built an engineer or a passenger.
The autonomy signal changed its face
I interview a lot of people, and the tell I look for has shifted.
The weak candidate describes the ideal onboarding they’d want. Clean docs, a mentor on call, a tidy codebase, two weeks of ramp. The strong one describes how they unblock themselves when conditions are degraded. No docs, flaky environment, a half-finished module and a deadline.
Depending on perfect conditions used to be reasonable. Now it’s a red flag, because the AI already handles the easy case. The human is there for the mess. If you only function when everything’s clean, you’re applying for a job the machine already does better.
The first real milestone
Here’s how I know onboarding actually worked. It’s not the first merged PR. It’s not velocity. It’s the day the new hire refuses to push a generated block they don’t understand.
That day, they stop being an author and become a guarantor. They’ve understood that their name on the commit means something, and that the machine’s speed doesn’t transfer to them as a free pass. It transfers as a heavier responsibility. That refusal is the whole job arriving in one moment.
Day 1, show them where the bar is
So no, on day 1 in the AI era I don’t show the new hire how to go faster. The tool already does that, and they probably came in faster than me on it anyway.
I show them where the bar is. Then I tell them the part nobody likes hearing: the bar isn’t staying put. The machine got faster, so the bar goes up. You answer for what ships under your name, whether your hands wrote it or the model did.
That’s not a constraint I’m putting on them to be difficult. It’s the only thing that still makes them worth more than the tool.