The current state of LLM-driven development

Post by thefourthchime » Mon, Aug 11, 2025, 2:09 AM UTC

hn_throwaway_99 wrote: post #168

thefourthchime wrote: post #159

Earlier quoted context omitted.

It entirely depends on the exposure and reliability the code needs. Some code is just a one-off to show a customer what something might look like. I don't care at all how well the code works or what it looks like for something like that. Rapid prototyping is a valid use case for that. I have also written a C++ code that has to have a runtime of years, meaning there can be absolutely no memory leaks or bugs whatsoever…

> It entirely depends on the exposure and reliability the code needs. Ahh, sweet summer child, if I had a nickel for every time I've heard "just hack something together quickly, that's throwaway code", that ended up being a critical lynchpin of a production system - well, I'd probably have at least like a buck or so. Obviously, to emphasize, this kind of thing happens all the time with human-generated code, but LLMs…

Post by SkyPuncher » Mon, Aug 11, 2025, 2:18 AM UTC

Jensson wrote: post #173

SkyPuncher wrote: post #171

Earlier quoted context omitted.

No, it actually has an exponential growth type of effect on productivity to be able to push it to the boundary more. I’m making this a bit contrived, but I’m simplifying it to demonstrate the underlying point. When an LLM is 80% effect, I’m limits to doing 5 things in parallel since I still need to jump in 20% of the time. When an LLM is 90% effect, I can do 10 things at once. When it’s 95%, 20 things. 99%, 100 thing…

Do you understand what parallel means? Most LLM responds in seconds, there is no parallel work for you to do there. Or do you mean you are using long running agents to do tasks and then review those? I haven't seen such a workflow be productive so far.

Post by AndyNemmity » Mon, Aug 11, 2025, 5:04 AM UTC

donperignon wrote: post #124

simonw wrote: post #14

Learning how to use LLMs in a coding workflow is trivial. There is no learning curve. [...] LLMs will always suck at writing code that has not be written millions of times before. As soon as you venture slightly offroad, they falter. That right there is your learning curve! Getting LLMs to write code that's not heavily represented in their training data takes experience and skill and isn't obvious to learn.

I’m still waiting that someone claiming how prompting is such an skill to learn, explain just once a single technique that is not obvious, like: storing checkpoint to go back to working version (already a good practice without using Llm see:git) or launch 10 tabs with slightly different prompts and choose the best, or ask the Llm to improve my prompt, or adding more context … is that an skill? I remember when I was a…

Post by troupo » Mon, Aug 11, 2025, 5:38 AM UTC

Karrot_Kream wrote: post #184

Tainnor wrote: post #118

Earlier quoted context omitted.

There have been so many "advances" in software development in the last decades - powerful type systems, null safety, sane error handling, Erlang-style fault tolerance, property testing, model checking, etc. - and yet people continue to write garbage code in unsafe languages with underpowered IDEs. I think many in the industry have absolutely no clue what they're doing and are bad at evaluating productivity, often pri…

> I wish we had at least the same amount of discussions about those things I mentioned above as we have about whether Opus, Sonnet, GPT5 or Gemini is the best model. I mean we do. I think programmers are more interested in long term maintainable software than its users are. Generally that makes sense, a user doesn't really care how much effort it takes to add features or fix bugs, these are things that programmers ca…

Post by donperignon » Mon, Aug 11, 2025, 6:11 AM UTC

AndyNemmity wrote: post #205

donperignon wrote: post #124

Earlier quoted context omitted.

I’m still waiting that someone claiming how prompting is such an skill to learn, explain just once a single technique that is not obvious, like: storing checkpoint to go back to working version (already a good practice without using Llm see:git) or launch 10 tabs with slightly different prompts and choose the best, or ask the Llm to improve my prompt, or adding more context … is that an skill? I remember when I was a…

You may not consider it a skill, but I train multiple programming agents on different production and quality code bases, and have all of them pr review a change, with a report given at the end. it helps dramatically on finding bugs and issues. perhaps that's trivial to you, but it feels novel as we've only had effective agents in the last couple weeks.