I find it absolutely is much of the time - I'll determine the architecture/overall solution, know exactly what needs to go in a multitude of files, and now actualizing all that isn't really thinking anymore, just donkey work. Getting AI to do this has been incredible now that it's finally good enough. I've had Copilot make flawless 500+LOC C++ classes in the first pass, and when I introduced bugs by changing it by hand, it found them instantly from stack traces without even having symbols, saving me hours. I see a future where writing a large codebase all by hand is seen like raising a barn the Amish way with no powertools - impressive and maybe there's something to be said for it philosophically, but just not practical otherwise.

Granted, sometimes it's really not that interesting to type the stuff. It depends what one is working on.

And truth be told, if I'm writing the same thing many times it's time to create a library. Maybe just for myself or for the company I work for. But the same thing happens. I always learn more while doing it and it always gets better.

I fear the programmer whose bottleneck is typing. They already know the answer. But the problem is that there is none

Here's an alternative take: if typing isn't a bottleneck for you, and you don't experience coding as being donkey work, you are thinking too slow, and/or in too small increments.

Actually, I found that this is exactly where they shine (I wouldn't trust them with greenfield implementation myself). Exploring existing code is so much easier when you can ask them how something works. You can even ask them to find problems - you can't trust them to be correct, of course, but at least you get some good brainstorming going. And, incredibly, they often do find actual problems in the code. Pretty impressive for language models.

I actually felt like I learned the most when I stopped going to Google and StackOverflow for solutions and instead moved to docs. It's far less direct but the information is much more rich. All that auxiliary information compounds. I want to skip it, feeling rushed to get an answer, but I've always been the better for taking the "scenic route". I'd then play around and learn how to push functions and abuse them. Boy there's no learning like learning how to abuse code.

Fwiw, I do use LLMs, but they don't write code for me. They are fantastic rubber ducky machines. Far better than my cat, which is better than an actual rubber duck. They aid in docs too, helping fill in that space when you don't exactly understand them. But don't let them do the hard work nor the boring work. The boring work is where you usually learn the most. It's also the time you don't recognize that's happening

> The boring work is where you usually learn the most. It's also the time you don't recognize that's happening

That was always how I did it before mid-2025. And I do still do boring work when I truly want to master something, but doing that too much just means (for me) not finishing anything.

Not finishing things can be okay but also not. An important skill to learn is what's good enough. And to write good enough to be easily upgradable. It's important to write code to be flexible for this reason. It's also important to realize it's okay to completely throw away code. But also this is the reason comments are so important. Don't just write what functions do but also write how you envision the design. Even if you can't get to it now. Then when you or anyone else comes back (after lunch, next week, next year, whenever) there's good hints about all that. Knowing how to get up to speed and be effective fast. If anything this helps agents even more. Commenting is a vastly under appreciated skill and only becoming more valuable

Lmao, please tell me what products you're working on so I can avoid them

For me, I sometimes feel like I'm an old school chess engine, exploring as many possible moves/ideas as I can - as many steps into the future as time allows. Constantly evaluating them based on some known-simplified fitness function usually involving pattern recognition from past experience in similar problems. Eventually I arrive at a place where I'm either confident I know a reasonable way forward (and why some of the obvious ways forward are unlikely to be ideal) - or I've scatter-gun searched all of the quickly available ideas and discovered I have no idea if some of them are good or bad, and I need to do much deeper research and investigation of the problem.

From the outside, that'd look identical to "he could go completely silent, just staring straight ahead with his fingers to his lips"

Instead if you're blurting out your thinking more in unison. Naturally you'll stray less, exploring less.

Of course you want collaboration but I find the magic is going back and forth between alone and together. I even find this helpful when just working by myself, stepping away from the problem or context switching, allowing the problem to distill.

But everyone has their own personal preferences. Which is perfectly fine too. But I think it's worth mentioning that, as illustrated by the comment, it's typically more acceptable to blurt than think silently. And there's the bias that blurting makes it harder to think silently by thinking silently doesn't make blurting harder (the uncomfortable with some silence part is not healthy imo. Of course long silence is a different issue but we're talking 30-60s)

As you sort of point out between the lines, it depends on what you work on. I had an AI agent rewrite some ancient (and terrible code) which had stopped working because the v1 of an api on v3 was sunset. It took around 5 minutes out of my day, and most of those were having two people explaining to me where the code was and what they thought had happened to make it break. It would've like taken me a full day to fix without AI because I would have needed to understand things first, and because it was quite a lot of code.

The result wasn't very good, but it was better than what was before, and since that had run for years without anyone tuching it, well... good enough. Heck, it might've taken me more than a day because I doubt I would have left it at "wasn't very good".

Aside from this anecdote I think AI writes a good 80% of my code these days. I'm not sure I buy the whole "bottleneck or not" discussion around typing. I think for a lot of people, myself included, AI does 10x part of the process of writing software. Where it doesn't help is when you need to do computer science, and as you point out, those parts AI don't speed up. I sometimes still use AI for computer science parts, but in those situations the AI will be a rubber duck because I tend to think by talking out my own ideas, and at least the AI duck pretends to answer. Even if the answer is more useless than what the actual rubber duck comes up with, which it usually is, it's more immersive for me.

  > because I doubt I would have left it at "wasn't very good".

Don't get me wrong, we all write sloppy code and often not our best. It's one of the difficulties of being an engineer, deciding what exactly is good enough.

It's always possible to go slower for practically no cost. -- So, any benefit from going slower is obtainable for everyone.

Whereas, typing faster takes discipline and effort. There are diminishing benefits to putting in more effort to type faster.

The main benefit isn't so much "more output" so much as "reduced latency". e.g. It takes less time to type out queries that help you gather information.

  > typing faster takes discipline and effort.

  >> ***typing isn't the bottleneck***

  > The main benefit isn't so much "more output" so much as "reduced latency". e.g. It takes less time to type out queries that help you gather information.

While typing I'm doing other things in parallel.

Those other things are things that require you to scrutinize and look at each character. I think the vacuum analogy from the OP is quite apt here. It's much harder to debug other people's code and more so an LLMs.