This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages

▲

efficax 6 hours ago | parent [-]

You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.

▲

skydhash 6 hours ago | parent [-]

Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome.

That’s why we read code. Because only there the correct and incorrect cases are clearly separated.

▲

efficax 4 hours ago | parent [-]

But that's just more data. Create the error conditions in your test harness and exercise them. The machine will tell you what happened. Then correct the machine.

	▲	krupan 2 hours ago \| parent [-]
		You make it sound so easy. Have you ever worked in QA?