Two engineers on the team get the same kind of ticket. Both use Claude Code. Both have the AI generate the implementation. Both PRs look reasonable in review.

A week later one of those PRs is still running cleanly in production. The other got rolled back Friday morning after a real user hit an edge case nobody tested.

That’s not a story about Claude Code. That’s a story about what each of them brought to it.

The reframe

Most discussions about AI in engineering treat the tool as the variable. Better model, better engineer. Faster autocomplete, faster team. The reality I keep seeing on the team is the opposite. The tool is roughly the same for everyone. What changes is what each person brings to it.

AI doesn’t make you a better engineer. It makes you a faster version of the engineer you already were.

The implications cut harder than you’d expect, in both directions.

The most common failure mode I see

Two engineers ship features. Both wrote the implementation with Claude Code. Both got code that compiles, tests that pass in CI, PRs that look right at a glance.

The engineer who already had the habit of running a local smoke test before pushing? Still runs it. They just write the smoke-test script with the AI now too. So the smoke-test step is faster, but it’s still there. Bug never reaches staging.

The engineer who’d shipped a few times to production without proper local and staging verification before AI showed up? They do it more often now. The feature looks right. CI is green. Push. The bug shows up in production at 2am, or worse, it doesn’t show up until a real customer hits the edge case three days later.

The verification step was a friction. And friction was teaching us things, every time we used it. That “looks right” isn’t “works right.” That the test runner doesn’t know what you actually meant. That a feature with happy-path coverage and zero adversarial thinking is a bug waiting for a user.

AI removed the friction. For the engineer who’d internalized the lesson, the friction was redundant. They’d already built the muscle. For the engineer who hadn’t, the friction was the only thing forcing the muscle into existence. Without it, the muscle atrophies. Or never forms.

This isn’t a juniors problem

Seniors actually atrophy faster. They had farther to fall.

The senior who’d built a careful code-review habit over a decade now lets AI-generated PRs through because “the AI knows what it’s doing.” The architect who’d always sketched three options before picking one now ships whatever Claude suggested first because the sprint is tight. The principal engineer who used to grill juniors on their reasoning now skips the conversation because the answer is already in the diff.

The bad-habits-amplified pattern doesn’t care about your title or your years of experience. It cares about what habit you reached for, today, when AI offered you a shortcut.

Multi-project work makes this worse

The pattern gets sharper when you’re shipping across several projects at once. I’m currently running a production Rails platform, an open-source MCP server, a desktop GUI, a book draft in review, and now this blog. That isn’t a brag. It’s a confession. Every additional project taxes the verification rituals first.

Multi-project work amplifies whatever habit you have. Good habits compound across projects: you carry your local-smoke-test ritual from one repo to the next, and each one gets safer over time. Bad habits compound in the other direction. Skipping verification on one project teaches you it’s optional. The next project, you skip it sooner.

AI lets you context-switch faster than your verification habits can keep up with. The cognitive load doesn’t disappear. It just gets paid later, as production bugs across all the projects you weren’t paying close enough attention to.

What “good habit, same tool” looks like

Take the same engineer, same Claude Code, but flip the habit set:

The engineer who already asks “why this approach over the alternatives?” now asks Claude that question explicitly. They get three options, compare, defend their pick in the PR description. Their architectural sense compounds with every ticket.

The engineer who already verifies before shipping treats AI-generated code as a starting point that needs proving, not a finished artifact. They write the smoke test first, run Claude on the implementation, then re-run the smoke test. They’ve shipped to production a hundred times this quarter and broken nothing.

The engineer who reads other people’s code to learn now reads what Claude produced to learn. Same posture, faster cycle. They get better, faster, with every PR.

Same tool. Three different outcomes. The variable was never the tool.

What to do about it

The interesting practical question isn’t “should I use AI more or less?” That debate misses the point. AI is here. The practical question is: which of my existing habits is it amplifying?

Audit yourself. Pick one habit you care about. Verifying before shipping. Evaluating alternatives. Reading code carefully. Defending your design choices in writing. Asking why before how.

For one week, practice that habit adversarially against AI. If AI hands you an answer, push back on it before accepting. If AI generates code, write the test first. If AI suggests one approach, ask for two more and argue out which you’d actually ship.

You’re not training to use AI better. You’re training to keep the muscle AI would otherwise let atrophy.

The principle survives the next model release

This generalizes past coding. It applies to writing. Writers who already edited carefully now ship sharper drafts faster; writers who hit publish on first drafts now publish more bad drafts at higher velocity. It applies to managing. Managers who think through tradeoffs before deciding now decide faster with better reasoning; managers who already shoot from the hip now shoot more often. It applies to learning anything.

The rule survived the calculator. It survived autocomplete. It survived Stack Overflow. It’ll survive whatever ships after Claude.

Bring a habit. The tool will amplify it. Pick which one.