  > he might shrug and say "I don't know"

I have far more trust for people willing to say this.

  > I would start blurting out half-baked ideas to fill the silence

I find that I'm more likely to do this but try to make an effort to stop. There's times to spitball but we should also spend time thinking. And let's be real 30-60s is not that long

  > This manager also typed with one or two fingers, and pretty slowly too. But he wrote a lot of good code.

I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close. Plus, while typing is when I'm doing my best debugging and best simplifying.

▲ Quothling an hour ago | parent | next [-]

> I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close. Plus, while typing is when I'm doing my best debugging and best simplifying.

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.

▲ jimmaswell 6 hours ago | parent | prev | next [-]

> typing isn't the bottleneck. Not even close.

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.

▲

Ma8ee 24 minutes ago | parent | next [-]

If you use that much time for donkey work, you are using the wrong tools. If it is so simple so that can delegate it to a LLM, you need to use a language with more expressive power.

▲

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

How often are you actually doing this though? I think I probably work in something greenfield about once a decade. The hard part is always going down a rabbit hole in established code bases. I can do the boilerplate in a few days. It saves time, but not really even one hairy issue a year.

	▲	bornfreddy an hour ago \| parent [-]
		> The hard part is always going down a rabbit hole in established code bases. 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.

▲

anhner 2 hours ago | parent | prev [-]

> I've had Copilot make flawless 500+LOC C++ classes in the first pass

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

▲ bigiain 8 hours ago | parent | prev | next [-]

If shrug-guy is anything like me, he sat there blurting out half-baked ideas and then shooting them down all in his internal monologue, instead of out loud.

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"

▲

godelski 7 hours ago | parent [-]

Sure, but isn't there still an advantage to this? If two people are silently doing this then they don't influence one another as much, helping find a wider range of solutions as well as identify issues with certain solutions that the other might not have seen.

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.

▲

jaredsohn 7 hours ago | parent | next [-]

Another way to think of it is if you're blurting out your thinking you're reducing redundant work and perhaps inspiring the other person to think of additional solutions that are offshoots of what you're dismissing. I see merits to both ways of looking at this.

	▲	vnorilo 27 minutes ago \| parent \| next [-]
		Probably true for many. When thinking about hard problems I'm usually not thinking in language, at least not the kind we speak between us humans, so it can be incredibly distracting if I have to "translate" back and forth while both thinking and communicating.
	▲	godelski 5 hours ago \| parent \| prev [-]
		Yeah I agree but that's why I think there's a balance. But the context here is the more nervous blurting which I think is going too much in the other direction. We should be comfortable with some silence and thinking. 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)

▲

jcims 6 hours ago | parent | prev [-]

I had the same thoughts reading this. I think there’s an optimal blend of blurters and thinkers, one isn’t better than the other. I find that I do both, it just kind of depends on my comfort with the subject matter.

▲ rgoulter 8 hours ago | parent | prev [-]

> I'll be honest, this is the big reason I don't get all the hype around coding agents. I do find them useful but typing isn't the bottleneck. Not even close.

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.

	▲	godelski 7 hours ago \| parent [-]
		`> typing faster takes discipline and effort. >> *typing isn't the bottleneck` I believe you read too fast `> 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.` You've missed the critical part of what I was saying. 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.