AI-assisted development: what I actually trust it for — and what I still do by hand

I use AI assistance on most projects now, so I'll skip the hype and the dismissal — both are lazy takes. The honest answer is narrower: it's very good at some things, quietly wrong in ways that look confident on others, and it changes how you have to work to get the benefit without the risk.

What it's actually reliable for

• Boilerplate and repetitive scaffolding — CRUD routes, form validation, config files, the tenth Kubernetes manifest that looks like the ninth. Patterns I already know cold, just faster to type.
• Translating between things — porting a script from one language to another, converting a REST handler to match an existing project's conventions, reshaping a dataset.
• A first draft of something well-understood — a migration, a test suite skeleton, a first pass at a Helm chart. I still read every line, but starting from 80% is faster than starting from zero.
• Rubber-duck debugging that talks back — describing a bug out loud (to it) surfaces the cause half the time before it even answers.

Where accuracy breaks down

The failure mode isn't "obviously wrong code" — that's easy to catch. It's plausible code that's subtly wrong: an off-by-one in pagination, a race condition in async code, a security check that looks present but checks the wrong field. It reads fine. It even runs fine, most of the time. It fails at 2am under a load pattern nobody tested.

It's also weakest exactly where the value of a senior engineer is highest: anything that depends on context it doesn't have — your actual system's constraints, a client's specific compliance requirement, a decision you made three months ago for a reason that isn't in the code. It will confidently fill that gap with something generic and wrong rather than tell you it doesn't know.

Does it dull your skills? Only if you let it

This is the question worth asking honestly, not just batting away. It will atrophy your skills if you accept output you don't understand, or use it for things you haven't already built the underlying model for. You lose the ability to debug what you never learned to build.

It won't, if you keep a few rules:

1. You're still responsible for every line. Reviewing AI output with the same scrutiny you'd apply to a junior developer's PR — because that's functionally what it is.
2. Use it to explain, not just generate, on anything new. Ask why, not just what. If you can't explain the code back, you don't own it yet.
3. Do some things by hand on purpose. Not everything — that's not sustainable — but enough that the fundamentals stay load-bearing, not decorative.

The actual shift

AI assistance doesn't replace the judgment that comes from having shipped things that broke and fixing them yourself. It changes the ratio: less time typing things you already know, more time on the review, the architecture, and the parts that need context only you have. Used that way, it's a force multiplier on real expertise — not a substitute for building it in the first place.