Comment by antonvs

> With a sufficiently complex prompt and a sufficiently complex codebase ...

With a sufficiently complex specification of a failure mode, you can find problems with anything.

Humans, given sufficiently complex requirements and sufficiently complex codebases, also regularly fail. You're tacitly admitting that LLMs are approaching (if not exceeding) human levels of performance now. We somehow get non-deterministic humans to achieve useful work. In fact, staff provide managers with an abstraction over the work they're responsible for - managers don't know every detail of the systems they're responsible for.

There are effective ways to use LLMs. I recommend using those, not using overly complex prompts, and not letting LLMs freely make changes to large code bases. Just as compilers only compile one source file at a time, LLMs work best if you scope their attention. Same goes for humans, in fact.

> There's no comparison to be made between this and, for example, a compiler.

A simple comparison is that both can generate useful code. You need to be more precise about the issues you're trying to identify.

Anyway, the comparison to compilers isn't really the point. It's undeniable that LLMs are an abstraction themselves, and that they can generate new abstractions. Saying that they're "not another abstraction" is just definitionally wrong.

Sure, they're not the same kind of abstraction as a traditional compiler. They require new ways of working, but actually not that new, as the manager example I gave suggests.

> When claude deletes a fix it did two weeks ago, while trying to fix some unrelated error, do you never stop and think "this is not quite the same as what GCC does"?

I never made the mistake of thinking LLMs were the same as GCC in the first place.

And once again, I've seen human developers do exactly what you just described. That's why we review code. All the arguments you're making are essentially also arguments that humans shouldn't be involved in software development either.