> Given the way LLMs are marketed, we should expect a vastly more favorable project success rate, not simply a close parity, and definitely not a decreased rate. > Even if we consider that the number of attempts will rise if development becomes faster, we're told to expect a greater number of projects should also succeed because they're easier.

I'm not sure I follow why you would think this. Prior to AI was the reason most projects failed because generating the code was too slow or too labor intensive? That would be surprising to me if it was true.

▲

quintushoratius 20 hours ago | parent [-]

Generating code is not, and never was, a bottleneck to projects. Understanding the problem, designing a solution, organizing resources, testing, and customer buy-in and moving targets have always represented the real issues.

Now, with LLMs, we're supposed to be able to paper over some or all of these problems.

They're supposed to be able to understand and intuitively fill the assumptions present in vague requirements, then produce working applications. They're supposed to shrink the timelines from years and months to weeks and days. They're supposed to replace human expertise with a reliable service.

Why else would I hire an LLM service over a team of humans?

▲

tpmoney 14 hours ago | parent | next [-]

> They're supposed to be able to understand and intuitively fill the assumptions present in vague requirements, then produce working applications. They're supposed to shrink the timelines from years and months to weeks and days. They're supposed to replace human expertise with a reliable service.

But none of those sound like things that would change how likely any given project is to succeed. Shrinking timelines from years and months to weeks and days just means that you can fail faster and try again sooner (hopefully with lest costs), but nothing about that implies your rate of success is going to get better.

	▲	ryandrake 9 hours ago \| parent [-]
		I think the point is that using an LLM is not really going to shrink project timelines by that degree. Most large software projects I've worked on in a professional environment, "writing the code" was one of the fastest and smallest parts of the project. Maybe 10% of the overall calendar time of any given project was "designing and typing in software." The bulk of time spent tends to be working with customers, researching and refining requirements, reviewing the requirements with execs and leads to get their buy-in and support for staffing the project, performing various non-engineering reviews like legal and privacy, aligning timeframes among multiple contributing teams, seeking approval from Director X to move on to the next project phase, waiting for Key Team Member Y to get back from vacation, conducting QA and field testing, soaking the software through various rollout stages like internal, dogfood, internal staging, external beta, and then incremental percentages in prod, while watching and waiting for any regressions or failures. On a project that takes 6 months from idea to 100% in-production, writing the code might take a few weeks of that. So why are we so focused on a tool that speeds up the smallest part of this process?

▲

s1artibartfast 19 hours ago | parent | prev [-]

Faster and cheaper.