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.

▲

tjr 3 hours ago | parent | next [-]

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.

▲

jmalicki 2 hours ago | parent [-]

I find that AI allows me to get into algorithm design more, and the intersection of math and programming more, by avoiding boilerplate.

You can indulge even more by letting AI take care of the easy stuff so you can focus on the hard stuff.

▲

zeroonetwothree an hour ago | parent | next [-]

What happens when the AI does the hard stuff as well?

	▲	tjr 39 minutes ago \| parent \| next [-]
		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.
	▲	jmalicki 29 minutes ago \| parent \| prev [-]
		SkyNet. When it can do the hard stuff, why do you think we'll still be around for project management and prompting? At that point, we are livestock.

▲

QuercusMax 17 minutes ago | parent | prev [-]

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.

▲

nightski 3 hours ago | parent | prev | next [-]

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.

▲

netsharc 3 hours ago | parent [-]

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...

▲

FeteCommuniste 2 hours ago | parent [-]

The equivalent of "employee development" with AI is just the release schedule of new models, I guess.

▲

kccqzy 2 hours ago | parent [-]

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.

▲

visarga 39 minutes ago | parent | next [-]

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.

	▲	skydhash 15 minutes ago \| parent [-]
		> I had claude make a tool that scans a file or folder, finds all symbols, and prints them with line number. ctags?

▲

FeteCommuniste 2 hours ago | parent | prev | next [-]

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.

▲

dingnuts 2 hours ago | parent | prev [-]

[dead]

▲

sowbug an hour ago | parent | prev | next [-]

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."

▲

sho_hn 3 hours ago | parent | prev | next [-]

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.

▲

bigstrat2003 2 hours ago | parent | prev [-]

> 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.