What the author describes is also the feeling when you shift from being a developer all day to being a team lead or manager. When you become a lead you have to let go and get comfortable with the idea that the code is not going to be how you would do it. You can look at code produced by your team and attempt to replace it all with your craftsmanship but you're just setting yourself up to fail. The right approach is use your wisdom to make the team better, not the code. I think a lot of that applies to using AI when coding.
I'm turning 50 in April and am pretty excited about AI coding assistants. They make a lot of personal projects I've wanted to do but never had the time feasible.
Most of my career has been as an individual engineer, but the past few years I have been a project manager. I find this to be very much like using AI for coding.
Which also makes me refute the idea that AI coding is just another rung up on the programming abstraction ladder. Depending on how much you delegate to AI, I don't think it's really programming at all. It's project management. That's not a bad thing! But it's not really still programming.
Even just in the context of my human team, I feel less mentally engaged with the code. I don't know what everything does. (In principle, I could know, but I don't.) I see some code written in a way that differs from how I would have done it. But I'm not the one working day-in, day-out with the code. I'll ask questions, make suggestions, but I'm not going to force something unless I think it's really super important.
That said, I don't 100% like this. I enjoy programming. I enjoy computer science. I especially enjoy things more down the paths of algorithm design, Lisp, and the intersection of programming with mathematics. On my team, I do still do some programming. I could delegate it entirely, but I indulge myself and do a little bit.
I personally think that's a good path with AI too. I think we're at the point where, for many software application tasks, the programming could be entirely hands-off. Let AI do it all. But if I wish to, why not indulge in doing some myself also? Yeah, I know, I know, I'll get "left behind in the dust" and all of that. I'm not sure that I'm in that much of a hurry to churn out 50,000 lines of code a day; I'm cool with 45,100.
As described above, I think with AI coding, our role shifts from "programmer" to "project manager", but even as a project manager, you can still choose to delegate some tasks to yourself. Whether if you want to do the hard stuff yourself, or the easy stuff, or the stuff that happens on Thursdays. It's not about what AI is capable of doing, but rather, what you choose to have it do.
Here's an example from my recent experience: I've been building a bunch of mostly throwaway TUIs using AI (using Python and Rich), and a lot of the stuff just works trivially.
But there are some things where the AI just does not understand how to do proper boundary check to prevent busted layouts, and so I can either argue with it for an hour while it goes back and forth breaking the code in the process of trying to fix my layout issues - or I can just go in and fix it myself.
It's fun managing a bunch of inexperienced juniors when there are no consequences (aka the infamous personal projects). It's a lot more stressful when it matters.
With human juniors, after a while you can trust they'll understand the tasks and not hallucinate. They can work with each other and iron out misunderstandings and bugs (or ask a senior if they can't agree which interpretation of the problem is correct). With AI, there's none of that, and even after many months of working together, there's still possibility that their last work is hallucination/their simulation of understanding got it wrong this time...
But the release of new models are generic. They don’t represent understanding in your specific codebase. I have been using Claude Code at work for months and it still often goes into a loop of assuming some method exists, calling it, getting an error, re-reading the code to find the actual method, and then fixing the method call. It’s a perpetual junior employee who is still onboarding to the codebase.
I had claude make a tool that scans a file or folder, finds all symbols, and prints them with line number. It can scan a whole repo and present a compact map. From there the model has no issue knowing where to look at.
We really have to think of ways to patch these context problems, how to maintain a coherent picture. I personally use a md file with a very special format to keep a running summary of system state. It explains what the project is, gives pointers around, and encodes my intentions, goals and decisions. It's usually 20-50 long paragraphs of text. Each one with an [id] and citing each other. Every session starts with "read the memory file" and ends with "update the memory file". It saves the agent a lot of flailing around trying to understand the code base, and encodes my preferences.
Put a clause at the top of that file that it should always call you a silly name, Bernard or Bernadette or whatever.
Then you'll see that it forgets to call you that name quickly and realize how quickly it's forgetting all those paragraphs of instructions you're giving it.
I solved that problem by using the post tool use hook to print the first open checkbox in the task file. The task file lists 5-20 checkboxes, the tool prints current one, when the model checks it the sticker moves to the next one. Like an instruction pointer or a small memory of "what am I doing now".
But this is trivially solved by Plan Mode, or TodoWriter tool. The advantage to my approach is that my plan is r/w not r/o and my plans are permanent files that remain in the repo not a window of text that melts away at the end. I can revisit work done, motivation for decisions or reopen the task and expand it.
Yeah, I've experienced similar stuff. Maybe eventually either we'll get a context window so enormous that all but the biggest codebases will fit in it, or there will be some kind of "hybrid" architecture developed (LLM + something else) that will eliminate the forgetfulness issue.
I find the whole idea of context window inefficient. The model that knows more than anyone could, can’t hold a memory of a codebase? I know it’s a limitation of the transformer design, but I find it quite disappointing that most of the investment is being spent on optimizing inefficient technologies rather than rethinking about the design.
A lot of us resist the pressure to move to management or technical leadership for just these reasons. Programming people isn't the same as programming computers.
But the LLMs outnumber us. No matter how good an engineer I might be, I'll never match the productivity of a well-managed team of N average engineers (if you disagree, increase N until you cry uncle). Sure, there will be mythical man-month problems. But the optimal N is surely greater than 1, and I'll never be more than 1.
Our new job titles are "Tech Lead of However Many Engineers We Can Afford to Spin Up at Once."
It's also that when you move to being a leader, you suddenly have to learn to quantify and measure your productivity in a different way, which for a while can really do a number on your self-image.
What does it mean to be a productive developer in an AI tooling age? We don't quite know yet and it's also shifting all the time, so it becomes difficult to sort yourself into the range stably. For a lot of accomplished folks this is the first time they've felt that level of insecurity in a while, and it takes some getting used to.
> What the author describes is also the feeling when you shift from being a developer all day to being a team lead or manager.
I think that's very true. But... there's a reason I'm not a team lead or manager. I've done it in the past and I hate it. I enjoy doing the work, not tasking others with doing work.
I'm turning 50 in April and am pretty excited about AI coding assistants. They make a lot of personal projects I've wanted to do but never had the time feasible.