AI-Assisted Development, Six Months In: An Honest Workflow

I introduced AI-assisted code review into my pull-request workflow as the sole engineer on three codebases, I build production pipelines on the Claude API, and I use AI assistance daily. So this isn't a hot take from either camp. It's a field report, with the failure modes included.

Where it genuinely multiplies

Review coverage. As a one-person team I had no second reviewer, so every PR now gets an AI first-pass before I make the final call: unhandled rejections, missing null checks, inconsistent error shapes, the forgotten await. It doesn't replace human review. It's the closest thing to a second pair of eyes a sole engineer has, and I arrive at my own PR with the mechanical noise already handled and can spend attention on design. The order still matters: AI first, human final, my name on the merge.

Unfamiliar territory. As the sole engineer I was also the Python engineer, the DNS admin, and the person writing Slack integrations. AI assistance collapses the "I know exactly what I want but not this ecosystem's idiom" gap. It's like having a competent colleague in every language.

The blank page. Migrations, test scaffolding, the fourth similar adapter. Starting from a 70% draft and editing with judgment is reliably faster than starting from zero, when you have the judgment to edit with.

Where it lies to you

The failure modes are consistent enough to name:

• Confident interpolation. Ask for code against an API version it half-knows and you get something beautifully plausible with one method that doesn't exist. It compiles in the model's imagination only.
• Agreement bias. Frame a question with a wrong assumption and the default is to build on your error, not challenge it. I've learned to ask "what's wrong with this approach?" instead of "improve this."
• Local coherence, global drift. Each generated function is fine, but the fifth one quietly invents a new error-handling convention. Codebase consistency is exactly the thing a context window can't hold, and exactly the thing that determines maintenance cost.

None of these are exotic. All of them are manageable with one rule: AI output is a proposal from a brilliant colleague who doesn't run the code. Proposals get verified.

The trust boundary, again

Building production AI pipelines taught me an architecture rule that turns out to be a workflow rule too: the model proposes, deterministic checks dispose. In the pipeline, that's schema validation before database writes. In development, it's types, tests, linters, and CI between generated code and production:

LLM extraction  →  zod schema      →  database
AI-written code →  types + tests   →  merge
AI review pass  →  human reviewer  →  approve

The stronger your deterministic verification layer, the more aggressively you can use AI. That produces the counterintuitive conclusion of these six months: AI assistance raises the value of engineering rigor. Types, tests, and CI budgets used to be quality insurance. Now they're also the throttle that determines how fast you can safely go.

What changes for senior engineers

The tasks that compressed are implementation tasks. The tasks that didn't (deciding what to build, modeling the domain, choosing trade-offs, knowing what "correct" means for this business) got relatively more important, because they're now the bottleneck.

Six months in, my job description has quietly shifted: less typing, more specifying, verifying, and deciding. That's not a demotion of engineering. It's engineering with the boring parts delegated, to a colleague who never gets tired, occasionally hallucinates, and needs everything double-checked.

Which, honestly, is a colleague I know how to work with. I've been one.