A PR lands in the repo with a clean summary, a tidy diff, and an AI review note that basically says:

“Looks good.”

I skim. I nod. I merge.

Monday, 10:12 AM.

A teammate pings: “Why are we making three API calls per page view now?”

It worked. Tests passed. It looked correct.
It also quietly doubled latency and introduced a failure mode that only showed up under real traffic.

That’s when I stopped asking:

“Does AI make me faster?”

…and started asking a question that doesn’t lie:

“Does AI reduce time from idea -> safely in production?”

Because “faster” is easy to feel.
“Productive” is something you have to measure.

The productivity mirage: the verification tax

AI makes code appear instantly. That creates the illusion of momentum.

But in real repos, the work often shifts from writing -> verifying.

The verification tax looks like:

• rereading more carefully because you don’t fully trust the output

• reprompting to match your team’s patterns

• cleanup commits because the diff is bigger than it needed to be

• extra test runs because something feels off

So yes, you typed less.
But you didn’t necessarily ship sooner.

The only metrics that matter (if you care about shipping)

If you only measure “how fast I generated code,” AI wins every time.

Shipping isn’t typing. Shipping is finishing.

Here’s what I track now:

• Lead time: ticket start -> deployed

• Rework time: time spent fixing AI output after the first draft

• Defect escape rate: bugs found after merge (especially within 7 days)

• Review burden: how many human minutes it took to verify the change

One painful lesson:

AI can make one dev feel faster by making everyone else slower.

AI agents in code review: helpful, not authoritative

I used to treat AI review like a senior engineer.

That was my mistake.

Think of it like a junior dev who:

• has great pattern recognition

• writes confidently

• and occasionally invents reasons something is safe

Where review agents are great

• missing null checks / edge cases

• inconsistent patterns

• suggesting tests you forgot

• summarizing diffs (huge win)

Where they get dangerous

• domain logic (“is this billing rule correct?”)

• security boundaries (authz, tokens, tenant isolation)

• performance reality (N+1s, caching, query behavior)

• architecture (“does this belong here?”)

So my rule became simple:

Agents don’t approve PRs. Agents do chores.

“Vibe coding” is fine. Shipping vibe code isn’t.

Vibe coding is amazing for exploration.

But it becomes risky when “looks good” becomes “is good.”

These are the guardrails that made it safe for me:

1) Keep diffs painfully small

If the AI needs 800 lines, I probably don’t understand the problem yet.

2) Require tests that fail without the change

Not happy-path tests. Tests that would catch regressions.

Minimum bar:

• one failing test before

• one edge-case test after

3) Force invariants into words

Not “what did you do?” what must always remain true?

Examples:

• “authz is enforced server-side”

• “billing events are idempotent”

• “cache keys include tenant id”

4) Use feature flags when uncertainty exists

Flags are honesty. They let you learn without breaking trust.

Two prompts that genuinely improved my workflow

Strict review prompt (no approvals)

You are a strict code reviewer. Do NOT approve this PR.

Review the diff and output:
1) Correctness risks
2) Security risks
3) Performance risks
4) Maintainability issues
5) Test gaps

Rules:
- If unsure, say "UNCERTAIN" and why.
- Reference specific files/functions.
- Suggest minimal fixes and minimal tests.

Smallest-diff prompt (prevents AI spaghetti)

Make the smallest possible change to implement the requirement.

Output:
- Unified diff only (no commentary).
- Add/modify tests to cover it.

Constraints:
- Preserve existing architecture.
- No new dependencies.
- Prefer existing patterns/utilities.

These keep AI in useful mode, not “confident autopilot” mode.

My merge checklist (last line of defense)

Before merging AI-assisted code, I ask:

• Can I explain the change without reading the code aloud?

• What invariant does this rely on?

• What happens on bad input / retries / timeouts?

• Would a test fail if this change didn’t exist?

• Did we widen permissions or expose data?

• What’s the rollback story?

If any answer is “not sure,” it’s not ready.

The point isn’t “AI everywhere”

The point is predictable shipping.

AI is incredible at drafts, scaffolds, summaries, and catching the obvious.

But the moment you trust it by default, you’re not moving faster.

You’re just moving uncertainty into production.

And production collects interest.

Quick question for you:

Where has AI genuinely reduced your end-to-end shipping time (not just typing time)?

And what’s your “never let AI touch this” zone-auth, billing, infra…?