What I Let AI Write, and What I Never Will

"AI is going to replace developers" and "AI is useless hype" are both wrong, and the truth is more boring and more useful than either. After a year of Claude Code being a daily part of how I build software, here's the honest breakdown — not the LinkedIn-guru version.

The short version: AI is excellent at removing friction and terrible at owning consequences. Everything about how I use it follows from that one line.

What I hand to AI without hesitation

Building out new features. Most feature work has a tedious first mile — scaffolding, wiring, boilerplate, the same patterns you've written a hundred times. I let AI handle that so I can spend my attention on the part that's actually specific to the problem: the logic, the edge cases, the decisions. It's the difference between spending an hour setting up and spending that hour solving.

Writing tests. This is the one that changed the most for me. Tests are the thing everyone agrees they should write and quietly don't, because writing them retroactively is miserable. The barrier was never skill — it was friction. AI removes the friction of starting. I still decide what's worth testing and read every assertion, but the blank-page cost that kept tests from getting written at all is gone.

Exploring unfamiliar codebases and libraries. Dropping into a new codebase or a library I haven't used used to mean an hour of reading docs and tracing files before I could do anything useful. Now I get oriented in minutes — "where does X happen, how does this library expect to be called" — and then verify against the real source. It compresses the ramp-up, it doesn't replace understanding.

What I never let AI own

Security-sensitive code. A subtle mistake in a normal feature is a bug you fix later. A subtle mistake in auth, access control, or input handling is a breach. AI produces code that looks correct, and "looks correct" is exactly the failure mode you can't afford here. I write and reason through this myself.

Anything touching money or payments. Same logic, higher stakes. When the cost of a plausible-looking error is a double charge, a lost transaction, or a financial discrepancy, I'm not delegating the reasoning. AI can help me around the edges, but the core logic is mine to own and defend.

The final review before merge. This is the firmest line. AI can draft code, suggest changes, even review a diff. What it cannot do is approve one. The final judgment — is this correct, is this safe, do I understand every line — is mine, because my name is on the pull request and the accountability doesn't transfer to a tool.

The principle underneath

The line isn't "simple vs. complex" or "frontend vs. backend." It's risk of being wrong.

Where being wrong is cheap and recoverable — boilerplate, a test that fails loudly, a first pass at exploring code — I let AI move fast and I correct as needed. Where being wrong is expensive or invisible — security, money, the final call before code ships — I keep the work, because the value of a human there isn't speed, it's ownership.

AI didn't make me a worse engineer, and it didn't make me a "10x" one. It moved my time from typing to thinking. The tedious mechanical work got cheaper, which means the scarce resource is judgment — knowing what to build, what to check, and what not to trust. That was always the actual job. The tools just made it more obvious.