I Let AI Pair-Program a Real Client Project. Here's What I'd Do Differently.

I've been skeptical of the "AI writes your whole app now" narrative, mostly because most of the demos I'd seen were greenfield todo-list apps with no real constraints. So on a recent client build — a CRM automation tool with a moderately complex lead-scoring engine — I decided to actually use an AI coding assistant for a meaningful chunk of the implementation instead of writing everything by hand, and pay close attention to where it helped and where it quietly cost us time.

Boilerplate, and I mean that as a real compliment, not a dismissal. API route scaffolding, TypeScript interface generation from a MongoDB schema, repetitive form validation logic across a dozen similar fields, converting a Figma component spec into a first-pass Tailwind layout — all of this went from maybe 40% of my week to closer to 10%. That's not a marginal gain. That's a genuine reallocation of time toward the parts of the job that actually need a human's judgment.

It was also better than I expected at explaining unfamiliar code. Dropped into a section of a legacy module nobody on our team had touched in a year, asking "what does this function actually do and why" got a useful answer faster than tracing it manually would have.

The lead-scoring engine had a rule: leads from a specific acquisition channel got a scoring multiplier, but only if they'd also completed a secondary qualification step within 14 days. The AI-generated implementation got the multiplier logic right and quietly dropped the 14-day condition — not because it couldn't handle date logic, but because that constraint lived in a requirements doc, not in the code it was looking at, and it filled the gap with the most common pattern instead of flagging that a condition was missing.

This shipped. It passed code review, because the reviewer was checking for correctness of what was written, not auditing for silently missing business rules — which is a much harder thing to review for, because there's no diff that shows you what isn't there. It surfaced two weeks later when a client asked why leads outside the qualification window were getting boosted scores. Finding it took longer than writing that function correctly by hand would have taken in the first place, because by the time we went looking, the bug was three commits deep in a feature nobody suspected.

Not "use it less." The boilerplate gains were real and I'm not giving those back. What changed is where I put my attention as a reviewer. Business-rule-heavy logic — anything with a conditional tied to a requirement that lives in a doc or a Slack thread rather than in the code itself — now gets written by a human first, or at minimum gets a second human pass specifically checking "does this match every condition in the spec," not just "does this run correctly." Boilerplate and pattern-matching work stays AI-assisted with a lighter review. The split isn't about trust in the tool generally. It's about matching the review depth to how much the correctness of that specific piece of code depends on context the tool can't see.

The uncomfortable honest takeaway: AI-assisted development didn't reduce the amount of senior engineering judgment a project needs. It moved where that judgment gets applied — away from typing out repetitive code, toward auditing for the thing that's missing instead of just the thing that's wrong. That's a real shift in how a team should structure code review, and most teams I've talked to haven't updated their review process to account for it yet.