AI doesn't multiply your skills. It multiplies your habits.

Last year I wrote roughly three times more code than the year before. That's true. AI tools genuinely accelerate. But a significant chunk of that code I later deleted.

The "AI multiplies your skills" take is real. It's just incomplete. A multiplier doesn't care what it multiplies. It takes what you feed it and makes more of it. Good practices become more good practices. Bad habits become more bad habits — just faster.

I didn't learn this from an article. I learned it from my own git history.

What "AI multiplies skills" actually means in practice

AI-assisted development amplifies input quality: the clearer the context you provide, the more useful the output. When I write a task for Claude Code with a clear spec — inputs, outputs, edge cases — the result is usually solid on the first try. When I write "do X, here's some context" without a spec, the result technically works but hides assumptions that surface three weeks later.

The difference isn't the model's capability. It's what I brought to the prompt.

An engineer with spec-first habits produces better code faster with AI. Someone without those habits accumulates technical debt at the same pace — just with less resistance along the way. The tool removed friction. And that friction was doing some useful work.

Three habits AI amplifies the hardest

Spec-first discipline, decision logging, and early observability are the three engineering habits that determine whether AI makes your codebase better or worse over time.

1. Starting without a spec

Before AI, starting without a spec meant: I'll figure it out as I go. You would figure it out — slowly. The code itself would push back. You'd hit a question, pause, read something, think.

That friction is gone now. I hand Claude Code an unstructured request, it generates several hundred lines in 30 seconds. The code looks convincing. There are even tests. "Looks good" — and I move on.

A week later: the task is solved under the wrong assumptions. AI didn't guess — it made reasonable inferences from the context I gave. That context was incomplete because I didn't bother to articulate it.

Result: instead of spending an evening on the wrong solution, I spent two — one to write quickly and one to unpick what went wrong.

I wrote about this in detail in the post on spec-first discipline before any AI session. Short version: five questions before the first prompt cut rework in half.

2. Not capturing the "why" behind decisions

This is the habit that's always easy to defer. "I'll remember." "It's obvious." Later.

With AI, this habit produces a new failure mode. I ask Claude Code to extend a function or refactor a module. It looks at the code and does something reasonable. But it doesn't know why I made a particular structural choice three months ago. Because I didn't write it down either.

Result: AI suggests changes that are technically correct but violate invariants that "everyone knows" — except that "everyone" is me and my past thoughts, neither of which are written down.

Concrete case: one project had a non-standard discount calculation order in Bitrix. The logic lived in my head. When I asked AI to help refactor that block, it did it "correctly" by standard Bitrix patterns — and broke the calculation. Not because it was wrong. Because I hadn't written "here's why it's like this."

This isn't about documentation for its own sake. It's about the fact that AI works with what's written, not with what's implied.

3. Deferring observability

Classic. "Ship first, add logging later." AI doesn't help with this problem — it helps you ship faster. "Later" stays later.

I wrote about a specific case in the post about the AI-written bug that ran in production for seven days. The bug existed for a week before logs surfaced it. But the logs were incomplete. Because we'd deferred proper logging. AI had nothing to do with it — it wrote the function correctly per spec. The spec didn't account for the edge case, and there weren't enough logs to catch it early.

AI generated a system where observability was "later" because that's exactly how I'd described it: "build X, we'll add logging." The multiplier did its job.

What I changed: spec-first before any prompt

Now I have a simple rule: don't open Claude Code until I've answered five questions.

1. What does this function do — in one sentence?
2. Who calls it, with what input?
3. What's expected on output — including edge cases?
4. Are there constraints (performance, dependencies, invariants)?
5. How will I know it's working correctly?

Five minutes. Sometimes I realize I don't know the answer to question two, and that's already useful — without AI I'd also discover that gap, but an hour into coding, not five minutes in.

It's not magic. It's just moving friction back to where it helps: before generation, not after.

For autonomous tasks, I wrote separately about how I spec task descriptions for AI agents running without human oversight. Same principle: if you can't define the exit condition, the agent can't stop correctly.

What doesn't work: waiting for AI to remind you

The first instinct is: "Fine, I'll ask AI to remind me about the spec." I tried this. It doesn't work reliably.

AI will remind you if you ask. But if you didn't ask — it answers the question you gave it. This isn't a model flaw. It's normal tool behavior: it does what it's told.

Counting on AI to catch your missing habits is like counting on the compiler to tell you about wrong business requirements. The compiler checks syntax. AI checks what you explicitly described.

I looked at this systematically when I spent three months tracking where AI misses things in code review — there's a dedicated post on AI code review blind spots. The pattern: AI's blind spots almost always land where the engineer also has a blind spot.

The multiplier is neutral

AI is a forcing function. It forces what's already there.

If you have good habits — spec-first, capturing decisions, early monitoring — AI helps you do those things faster and more consistently. I've seen this work.

If the habits aren't there or they're bad, the consequences compound at the same rate as the code. I've seen that too.

The "AI multiplies skills" take is true in the best sense. It's just that skills aren't the code you write. Skills are what you do before you open the editor.

The multiplier takes what you bring. What you put in is your call.