{(P(AI mistake) * P(human spots the mistake | AI mistake) * P(human fixes mistake | given AI mistake, human spots it) - P(AI mistake)} * cost of AI mistake
So even if you can “make things right” or “tell the difference” as you say, the value of any given engineer is dropping.
Not remotely the case. LLMs make mistakes very frequently, much more frequently than humans do.
My last project had 2 guys from India and one guy from a consulting company that I take any LLM over them. The guy from the consulting company spent more than a month trying to implement a design that actually was not implementable. I obviously also blame the supposed professional design company that produced the design, and I mean it took me about 6 hours spread over a day and a half to figure out waitaminute this is actually not doable! But I have to wonder how badly would an LLM have done. I sort of think the same, because probably an LLM is never going to announce - hey, this design as stated is impossible, some parameter needs to be changed.
human mistake, AI spots the mistake
Human mistake, human spots mistake
AI mistake, AI spots the mistake.
Everybody is always talking as if they don't make mistakes, but every software engineer does; it used to be that human caught those mistakes and fixed them, but if AI catches those mistakes and fixes them, then that is also a decrease in value of human.
This is not my experience. Well, at least not for what I'd consider very low.
For example, I have a standard task of adding support for a well-specified regex scheme as a dependency-free module to the Wren language (which grew out of actually needing it at one point). When done autonomously, errors still occur, some of them very basic. For example, trying Fable 5.2 at medium the other day produced the following:
- memory unsafe behavior on 32-bit architectures (the good old problem of size overflowing on an allocation call).
- O(n^2) behavior for searchAll() and replaceAll() operations.
- Various minor subtle semantic issues, though none of them particularly critical.
This is a well understood problem, and in general, Fable's construction (Thompson NFA by way of a Pike VM) was in principle correct, but it still had these pretty basic problems. (Other frontier models produced their own, e.g. a use-after-free bug or a combinatorial explosion in the regex compiler for some types of regexes.)
(As an aside, so far I don't consider Fable 5.2 an improvement over Opus 5.5 in coding ability, more of a sidegrade; while it is smarter and can do some hard, but also pretty esoteric stuff that Opus fails at or takes much longer with, for regular coding problems it's neither better nor worse, more ... different. And sometimes Fable seems to outsmart itself, producing a seemingly clever solution from its vast knowledge that is actually worse than the standard approach in practice.)
One area where I absolutely do not trust even frontier models yet is parallel and distributed programming. I absolutely value them as a second set of virtual eyes for tricky situations in this area, but I do not trust them to get things right, and even if the solution is correct, it's often inefficient or convoluted.
Futhermore, what would be the organizational cost if these bugs were in the codebase?
This was actually from a personal project, and my point was not about the type of task, but the types of errors I am still seeing from modern LLMs.
> Futhermore, what would be the organizational cost if these bugs were in the codebase?
The particular errors that I highlighted above are what I call "landmines". They may not manifest at all depending on what you do, but if they do, they can hurt a lot, especially in production.