The Day I Couldn't Read My Own Code

I opened a function in my own repository last month and did not recognize a single line of it. Not the logic, not the variable names, not the reason it existed. My first honest thought was that a teammate had written it and forgotten to tell me.

Then I ran git blame.

It was me. Committed six weeks earlier, my name, my email, a message I clearly typed. And I could not, standing there, have told you what the thing did without reading it top to bottom like a stranger's code. I had shipped it. It worked. It was in production serving real users. And it lived in my brain the way a movie you watched half-asleep lives in your brain, which is to say not at all.

I did not write that code. I approved it. Somewhere in the last year those two things quietly became different verbs, and nobody sat me down to point it out.

What delegation actually swapped

Here is the trade that happened, and it happened so smoothly I never noticed the moment it closed.

I used to produce code. I would sit with a blank function, hold the whole problem in my head, and grind it into something that worked. That was slow and often annoying. But the grinding did a second thing I wasn't paying attention to. It carved the problem permanently into me. By the time the code worked, I owned it. I could have rewritten it from scratch on a whiteboard with no notes, because I had, in a real sense, already done exactly that.

Now I describe the problem and read what comes back. I still make real decisions. I reject the bad version, ask for the better one, catch the obvious mistakes. It feels like work, and it is work. But it is a different muscle, and the old one is not being used. I have quietly moved from producing code to recognizing acceptable code, and those feel almost identical right up until the moment they are catastrophically not.

Because recognizing and producing are not the same skill. They are not even close. And we have a word for the gap between them, we just usually apply it to French class.

The menu you can read but can't order from

Anyone who has half-learned a language knows this feeling in their body.

You can read the menu. You see poulet and you know it's chicken, you see frites and you're set. Reading is easy. Recognition is easy. Now the waiter asks a follow-up question you didn't script for, and your entire fluency evaporates on the spot. You could recognize the right answer if someone said it. You cannot produce it. The distance between "I understand this when I see it" and "I can generate this from nothing" is the distance between a tourist and a person who actually lives there.

Reading code the AI wrote is recognition. It's the menu. It feels like knowledge because understanding-when-you-see-it genuinely is a kind of knowledge, the comfortable passive kind. But the skill that makes you a developer, the one people pay for, is production. It's ordering dinner, arguing with the landlord, cracking a joke the locals actually laugh at. And production is a muscle that only grows when you produce. Reading a thousand correct answers builds it about as much as watching a thousand pushups builds your chest.

Every time you let the tool produce and you merely approve, you get a little better at recognition and no better at production. Multiply that by a year of daily use and you get a very specific, very modern kind of professional. Sharp at spotting wrong answers. Slowly going soft at generating right ones. Completely unaware it's happening, because the paychecks keep clearing and the tickets keep closing.

Why your brain is thrilled to make this trade

None of this is a character flaw. Your brain is doing exactly what it evolved to do, which is to conserve effort like it's the last calorie on Earth.

Think about GPS. Before it, you drove somewhere new by building an actual map in your head, streets and turns and landmarks, because you had no choice. After it, you follow a blue line and arrive with no memory of how. You've driven to that one place fifty times and still can't get there without the app, and the reason is not that you're stupid. It's that your brain, offered a way to stop building the map, took the deal instantly and gratefully. Why store the route when the machine stores the route? The map-building muscle went quiet because nothing was asking it to fire.

Coding assistants are GPS for the whole job. The blue line is a very good blue line. It usually goes to the right place. And your brain, which has never once valued long-term skill over short-term effort, is delighted to stop building the map. Every "accept" is a tiny vote to let the muscle rest. No single vote matters. The election still gets decided.

The cruel part is that atrophy is invisible while it's happening. A weakening skill and a strong one feel exactly the same on any ordinary day, because ordinary days never test the skill. You only discover the muscle is gone the moment you actually reach for it. Which, in this job, is always the worst possible moment.

The 2 a.m. test you can't delegate

Everything is fine until production is on fire and the tool can't help you.

Picture the incident. Something is down, real users, real money bleeding out per minute. The bug is a nasty one, tangled across three systems, the kind where the actual cause is nowhere near the symptom. This is the exact situation you cannot describe to an assistant, because if you could describe the problem cleanly you would already have the answer. Debugging a live incident is precisely the work of not yet knowing what's wrong. It is pure production. It runs entirely on the map in your head.

And the map is thinner than it used to be. Not gone, not for those of us who spent a decade building it before the tools showed up. But thinner. I felt it during a real outage: I went to trace a data flow through a service I had "written" and realized I knew the shape of it only as well as I'd know a house I'd been given a tour of once. I recognized the rooms. I could not have drawn the floor plan. And drawing the floor plan, from memory, under pressure, is the entire job at 2 a.m.

The tool gave me speed on all the easy days and quietly borrowed against the hard one. That's the trade nobody prices, because the invoice doesn't arrive until the emergency, and by then it's not a bill, it's a crater.

The move is not to quit the tool

I want to be clear about what I am not saying, because there's a smug little sermon lurking near this topic and I don't want to preach it. I am not telling you to code by hand like it's 2009 to keep your soul pure. That's nostalgia cosplaying as wisdom. The tools are extraordinary and I'd fight you for mine.

The enemy is not delegation. It's unconscious delegation. It's letting the blue line make every decision until the map quietly disappears without your consent.

So the move is to delegate on purpose and keep one lane manual. Pick the code that matters, the core of your system, the parts you'll be debugging at 2 a.m., and actually write those, or at minimum read what the tool produces until you understand it well enough that you could have written it from scratch. Not skim. Understand. Close the tab and see if you can reconstruct the logic. If you can't, you don't own that code, you're just its landlord, and it will betray you the day you need it most. Let the AI have the boilerplate, the glue, the tedious stuff that was never building your map anyway. Guard the part that does.

The itch that makes a senior valuable was expensive to earn and it is even easier to lose than it was to build. It came from producing, from grinding, from owning code down to the bone. A tool that produces for you is a tool that, left unsupervised, will slowly stop you from being the kind of person who can.

I ran git blame and found my own name on code I didn't know. The fix isn't to blame the tool. It's to make sure that the next time I put my name on something, I actually put myself in it too.