chrisloyThe AI coding trap
It's a fine post, but two canards in here:
First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down. In fact: I do a lot, lot more thinking and balancing different designs and getting a macro sense of where I'm going, because that's usually what it takes to get an LLM agent to build something decent. But now that pondering and planning gets recorded and distilled into a design document, something I definitely didn't have the discipline to deliver dependably before LLM agents.
Most of my initial prompts to agents start with "DO NOT WRITE ANY CODE YET."
Second, this idea that LLMs are like junior developers that can't learn anything. First, no they're not. Early-career developers are human beings. LLMs are tools. But the more general argument here is that there's compounding value to working with an early-career developer and there isn't with an LLM. That seems false: the LLM may not be learning anything, but I am. I use these tools much more effectively now than I did 3 months ago. I think we're in the very early stages of figuring how to get good product out of them. That's obvious compounding value.
DO NOT WRITE ANY CODE YET.
haha I always do that. I think it's a good way to have some control and understand what it is doing before the regurgitation. I don't like to write code but I love the problem solving/logic/integrations part.
I'm surprised (or maybe just ignorant) that Claude doesn't have an explicit setting for this, because it definitely tends to jump the gun a lot.
Plan mode (shift-tab twice) might be what you want.
See, I called it! Ignorance it is!
>First, skilled engineers using LLMs to code also think and discuss and stare off into space before the source code starts getting laid down
Yes, and the thinking time is a significant part of overall software delivery, which is why accelerating the coding part doesn't dramatically change overall productivity or labor requirements.
This logic doesn't even cohere. Thinking is a significant part of software delivery. So is getting actual code to work.
ideally there is an order of magnitude difference between, and the latter is trivially delegable (where the former is not)
No there isn't.
if you're spending anywhere near as many engineering hours "getting code to work" as you're spending "thinking" then something is wrong in your process
Take that up with the author of this article!
Which part of the third chart do you disagree with?
Here we're really arguing about his first chart, which I agree with, and you do not.
I’m not following. It seems straightforward enough, and consistent with both charts, that a dramatic speedup in coding yields a more modest improvement in overall productivity because typing code is a minority of the work. Is your contention here that the LLM not only documents, but accelerates the thinking part too?
It does, for sure, and I said that in my comment, but no, the point I'm making is that this article isn't premised on thinking being an order of magnitude more work than coding. See: first chart in article.