I wanted to be more productive, and I got my wish. I used Claude Code to write 100k+ lines of code in a week (Week of June 1st 2025). Numbers like that make the old measures of productivity look silly. But they also hide a new kind of risk. I have to confess that while my system worked, I didn’t really know it. If asked to add a new feature, I wouldn’t know which files to touch.
This feeling is a symptom of a growing gap between making something work and understanding how it works. These used to be the same thing. To build a complex piece of software, I had to hold the entire structure in my head. The code was an extension of my own thoughts. Now, I can get the result without the deep internal model. I have the answer, but I’m not sure how I got there.
I’ve realized there are two ways to know a codebase. The first is like having a map. I can see all the streets and landmarks. I can look up a location and see where it is. This is the kind of knowledge I have when I browse a project on GitHub or read documentation. It’s static.
The second way is like knowing how to walk the streets. I know the shortcuts, the quiet alleys, the corner store that’s open late. I have a feel for the city. This is the knowledge I get from building the thing myself, from getting lost and finding my way back. It’s dynamic, and it’s what allows me to change the city, to add a new building and know how it will affect traffic on the other side of town.
AI assistants are very good at giving me the map. They can generate a perfect, sprawling city of code in minutes. But they can’t give me the experience of having walked its streets. And the danger is that I’ll become so reliant on the map that I’ll forget how to walk. I was becoming a tourist in my own codebase.
What’s the solution? It’s not to throw away the new tools. That would be like a carpenter refusing to use a power saw. The solution is to change how I use them.
I must treat the AI as a junior partner, not an oracle. I am still the architect. I must review every line it produces, not just for correctness, but for elegance and clarity. Would I have written it this way? If not, why? This act of critical review forces me to build the mental model I would have gotten from writing it myself.
I must own the debugging. When something breaks, I have to resist the urge to ask the AI to fix it. Debugging is the most intimate way to learn a system. It’s the process of tracing the messy, unexpected paths the program actually takes. It’s where the map fails and I have to start walking.
I need to design on paper. Before I generate a single line of code, I draw the boxes and arrows. I decide on the components and their interfaces. The most important work of a programmer has always been thinking, not typing. The AI has just made typing so fast that I’m in danger of skipping the thinking part.
My role as an engineer is changing. It’s less about the raw output of code and more about taste, judgment, and architectural vision. The AI can build the house, but I have to be the one who decides where the windows go, who ensures the foundation is solid, and who knows how to fix the plumbing when it inevitably leaks.