Tipping Point - Reader Followup
Writing about my positive experience with Claude Code recently (Tipping Point) I got a number of reader replies, including this one, with thoughtful and important observations. I'll quote it below in full and then attempt to answer the issues raised:
The questions
When modifying a codebase which I understand well using Claude Code it is usually easy to understand what it is doing and direct it if necessary. The problem is that the more I use Claude Code the less familiar I become with the codebase.
For one-off data analysis tasks Claude Code is incredibly fast at writing queries and visualizing results. The problem is verifying the results is often difficult. Furthermore, I usually get to know the data sets by writing queries and when Claude Code writes the queries for me I just don't get the same in depth knowledge about the dataset.
There seems to be a general trade-off where Claude Code can speed up my work, but I just don't get the same depth of understanding. Here's an analogy. It's like watching a good tutorial on some topic, like building a transformer from scratch. After watching the tutorial you think that now you know how to do this yourself, but when you actually sit down to do it you struggle a lot and you realize that there are details which you don't understand. Through that struggle you actually learn how to do the thing, but when using Claude Code it's as if you never actually sit down to do the thing yourself.
Experience Drift
Questions 1 and 3 deal with a problem that's not actually new; it just wasn't typically encountered at the level of an individual contributor: If you let someone (or something) else do the coding, you lose touch with the codebase over time, and you don't get that nitty-gritty exposure to it that build up a detailed understanding, a mental map, in your brain.
Those who make the transition from individual contributor to manager know this all too well: Suddenly, you're no longer writing code at the same intensity as you used to, because now you're managing a team and delegating those tasks to your direct reports. The question then is: How do you stay technical as a manager? Luca Rossi wrote a great article about that on his Refactoring newsletter. Many of the points apply whether you delegate to direct reports or AI.
For the specific issue of losing familiarity with the codebase: Look over Claude's shoulder, check where it puts things and how it does things. Imagine you're a manager asking your report to walk you through their recent work. That should give enough of a general sense of how it all fits together.
And for the issue of not getting the same depth of understanding: Pick your battles. Imagine you're a manager and you asked one of your reports to do something. Do you need to be able to follow along exactly, or are there higher-leverage things you could be doing? Additionally, working through a novel concept (a programming language, library, or framework) through the help of AI, is an entirely new way of learning by doing.
Disfluency
Question 2 deals with an interesting concept: Disfluency. We gain a deeper understanding of something if there is some friction involved, because it forces us to build up a complete mental picture of it rather than having everything done for us automatically. The question then becomes: What are we trying to achieve? If we need to build up that complete mental picture, then, yes, don't ask Claude to write the data queries for you. If it's not required to have that complete mental picture (because we just want to get to a certain visualization quickly), then by all means use Claude.
Conclusion
If we use AI in earnest to enhance the way we're working, it requires a different way of working, not just doing the same things, just faster. One mindset shift that we'll see often is that principles of good management are now relevant to individual contributors as well, not just managers.
