Hacker News Reader

Comment by _diyar | Hacker News Reader

You sound dismissive, but taking your description to its conclusion, the engineer value can be approximated as:

  {(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

For many engineering jobs, P(AI mistake) is very low and decreasing, and cost of AI mistakes is also usually (consider the cost of a bug for an average engineer; unless you’re building avionics or working on MRIs or such, usually very low).

So even if you can “make things right” or “tell the difference” as you say, the value of any given engineer is dropping.

View on HN

> For many engineering jobs, P(AI mistake) is very low and decreasing

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.

Your work sounds interesting, but I hope you agree that it’s not representative of the median engineering task.

Futhermore, what would be the organizational cost if these bugs were in the codebase?

> Your work sounds interesting, but I hope you agree that it’s not representative of the median engineering task.

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.

Most devs don't even know Wren exists, and their job can be easily automated by Workato, Boomi, SitecoreAI, Optimizely Opal, PowerPlatform, ....

That this is in the context of Wren is completely inconsequential here. It was just what motivated the original task (because of lacking functionality). What I was pointing out was that fundamental coding errors such as memory safety errors or O(n^2) code still happened with what is considered one of the most advanced models we have, even though this was overall pretty clean code.

In that case, still quite similar to the quality of offshoring projects with Human Intelligence, thus management hardly cares.

No disagreement (except that I wouldn't generalize it for all management), but I was only arguing a limited point about the likelihood of AI mistakes.

It really depends if you consider "AI mistake" to be "code logic error" or "code doesn't match real world expectations". The former is getting quite rare I agree, but the latter is still extremely common.

> For many engineering jobs, P(AI mistake) is very low

Not remotely the case. LLMs make mistakes very frequently, much more frequently than humans do.

source? I'm wondering at the curve of those mistakes actually, I doubt modern LLMs make mistakes at the level of the worst engineers I've worked with.

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.

What's the doubt based on if even in your only example you only wonder, yet still conclude that LLM would not do better??

my doubt is based on the fact that I do not have data to draw a conclusion one way or another, I have what is called a supposition, and my supposition may be affected by all sorts of fancies and ideas that prey on my mind but are not established as true.

I had no doubt that your doubt could be based on nothing and affected by anything, that wasn't the question.

it's worse than that, as you need to also compare

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.

Human - Human and AI - AI mistake and spotting thereof basically cancel each other out, or can be considered no mistake. Human - AI just speaks in favor of AI, and my comment was responding to somebody dismissive of how crushed engineers can feel by AI.

Reply on news.ycombinator.com