I Stopped Measuring My Programming Ability by How Much Code I Write.

Remember when using autocomplete meant you weren't "really" programming?

A real Stack Overflow question from nearly 15 years ago. People genuinely wondered whether autocomplete was wrong.

Now look at us.

For a long time, I had a very simple way of measuring whether I was becoming a better developer:

How much code could I write myself?

• Could I remember the syntax?
• Could I build the component without looking anything up?
• Could I solve the bug without asking for help?
• Could I stare at a blank file and turn it into software entirely from memory?

I think a lot of self-taught developers absorb some version of this idea:

• If you need Stack Overflow, you're cheating. (Meanwhile, half of us have it pinned in a tab.)
• If you need documentation, you don't really know it.
• If you use autocomplete too much, you're getting lazy.

And now, in the age of AI:

If a model wrote the code, did you really build anything?

I used to worry about that question more than I want to admit.

I don't anymore.

After building more software, breaking more software, debugging more software, and maintaining code that looked perfectly fine five minutes earlier, I've started measuring my ability very differently.

The question isn't:

How many lines did I personally type?

The questions are:

• Do I understand what this system is doing?
• Can I recognize when it's wrong?
• Can I debug it when the happy path disappears?
• Can I explain why the architecture looks the way it does?
• Can I change it without destroying three unrelated features?
• Can I maintain it next month?
• Am I willing to own the result?

Those questions have turned out to be much harder than typing code.

Code generation is the easy part now

This is the weird thing about programming in 2026.

You can describe an idea and get hundreds of lines of plausible-looking code almost instantly. Sometimes the code even works. That feels magical the first few times.

Then you build something complicated. Suddenly the model:

• fixes one bug and creates another
• duplicates logic that already exists somewhere else
• confidently misunderstands your architecture
• passes the test while violating the actual requirement
• adds abstractions you never asked for
• removes behavior you didn't realize depended on something else
• solves the problem you described instead of the problem you actually had

And you realize something important.

Generating code was never the whole job. It's just the most visible part.

The hardest skill became knowing when something is wrong

AI has actually made me spend more time thinking about software. Not necessarily typing software. Thinking about it.

When an agent produces an implementation, I have to ask:

• Why did it choose this approach?
• Does this belong here?
• Is this state owned by the right component?
• Are we fixing the cause or hiding the symptom?
• What happens when this fails?
• What happens when this runs twice?
• What happens when the user does something completely unreasonable?
• Does this implementation match the rest of the codebase?

And my personal favorite:

Why does this work?

That last question matters, because code that works and code that you understand are not the same thing.

I don't want software in my projects that feels like a mysterious artifact handed to me by an oracle. If I can't explain it, I don't trust it yet.

Debugging changed how I think about authorship

Writing code feels productive. Debugging teaches you whether you actually understand what you built.

There is a big difference between:

"The AI created this feature."

and:

"The AI created an initial implementation, I discovered why the state was leaking across components, traced the regression, changed the ownership model, tested the edge cases, and verified the fix."

The second experience teaches you far more about the system.

And at some point I realized: that is programming too. Maybe more importantly, that is engineering.

Authorship isn't just pressing the keys that produce the characters.

• It's making decisions.
• It's understanding consequences.
• It's rejecting bad approaches.
• It's deciding what stays.

I used to think needing help meant I wasn't good enough

Being self-taught can create a strange kind of insecurity.

There is always another concept you don't know. Another developer who understands networking better. Another person who can explain memory management without blinking. Another repository where every file looks like it was written in an alien language.

So you start using independence as proof of competence.

"If I can do this without help, then I must actually belong here."

AI pokes directly at that insecurity. Because now the help is always there. And it can do a lot.

I had to stop asking whether using help invalidated my skills. Developers have always used tools:

• Documentation is a tool.
• Libraries are tools.
• Frameworks are tools.
• Compilers are tools.
• Search engines are tools.
• IDEs are tools.

AI is another extraordinarily powerful tool.

The interesting question is not whether the tool participated. The interesting question is what happens when the tool is wrong.

AI can produce code faster than I can understand it

That is probably the biggest danger I've found.

The generation speed is seductive. You can add features faster than you can build a mental model of them.

One prompt becomes three files. Another prompt becomes an abstraction. Another prompt quietly changes something you didn't know was load-bearing.

Then one day something breaks, and you're standing in a codebase that technically belongs to you but that you couldn't explain to anyone, including yourself.

That's the trap. The bottleneck used to be how fast I could write code. Now it's how fast I can understand it, and the tool doesn't slow down to wait for me.

So I've had to build a few habits:

• Read the diff before accepting it. All of it.
• Ask the model to explain its choices, then check whether the explanation actually matches the code.
• Keep changes small enough that I can hold them in my head.
• Test the unreasonable cases, not just the happy path.
• If I can't explain why it works, it doesn't ship.

None of these habits are about typing. All of them are about understanding.

The scoreboard I use now

I don't count lines anymore. I ask whether I understand what I shipped, whether I can fix it when it breaks, and whether I'm willing to stand behind it.

And here's what convinced me the old scoreboard was wrong.

My GitHub account is over ten years old.

For a lot of that time, it was quiet. I took career breaks. I changed directions. Life did what life does.

And yet in the past year, I've created and maintained more projects than in all of those ten years combined.

I don't think that's a coincidence.

I'm not saying the tools wrote my portfolio for me. Someone still had to decide what to build, debug it, ship it, and keep it alive. But the old measurement, can I produce all of this from memory, alone, from a blank file?, was quietly keeping me from finishing things.

Once I stopped using it, I started building.