> I don't understand why we should be talking about generating a high level plan with multiple tests etc. for a single function.
You don't have to, you can write it by hand. I thought we were talking about how we can make computers write code, instead of humans, but it seems that we're trying to prove that LLMs aren't useful instead.
No, it's simply being demonstrated that they're not as useful as some claim.
By saying "why do I have to use a specific technique, instead of naively, to get what I want"?
"Why do I have to put in more work to use this tool vs. not using it?"
Which is exactly what I said here:
If we have to break the problem into tiny pieces that can be individually tested in order for LLMs to be useful, I think it clearly limits LLM usability to a particular niche of programming.
> If we have to break the problem into tiny pieces that can be individually tested
Isn't this something that we should have doing for decades of our own volition?
Separation of concerns, single responsibility principle, all of that talk and trend of TDD or at the very least having good test coverage, or writing code that at least can be debugged without going insane (no Heisenbugs, maybe some intermediate variables to stop on in a debugger, instead of just endless chained streams, though opinions are split, at least code that is readable and not 3 pages worth per function).
Because when I see long bits of code that I have to change without breaking anything surrounding them, I don't feel confident in doing that even if it's a codebase I'm familiar with, much less trust an AI on it (at that point it might be a "Hail Mary", a last ditch effort in hoping that at least the AI can find method in the madness before I have to get my own hands dirty and make my hair more gray).