https://www.youtube.com/watch?v=ZuwC3ESdwZA

Calling hallucinations simply mistakes does not seem to me to be a healthy way to reason about LLMs. I can ask a collegue how well they can program in Ada and adjust my expectations on productivity and bug rates. I can't ask an LLM how well they can code in Ada (just a throwaway example), or even how much of Ada was in its training data. I have to actually spend money and spend time code reviewing before I can even formulate any expectations at all.

That's absolutely false. My collegues don't routinely and confidently invent apis that are not there, or spectacularly and repeatedly misunderstand the purpose of certain functions or exhibit extreme forgetfullness. Especially when I've warned them. Hallucinations and confabulations in otherwise healthy individuals are mental disorders. When I ask them why they made an certain kind of error, I can expect to get a reasonable answer. No one has uttered the phrase "Bob hallucinated again while writing those tests" when the Bob in question is a human.

The parent is implying they would prefer an AI when working in the airline and health industry because it makes less errors. Read the comment again.

They have not said, "Hey, I work in the airline and health industry and I'd love to use AI for a couple of the bullshit IT UIs we have as long as we can put guardrails on the AI to stay in its lane."

I asked a yes or no question. The guardrails you can put to mitigate errors are the same guardrails pre-AI for the humans (tests, regressions, reviews). If you were wary of employing a top lead engineer with verifiable dementia prior to AI for a mission critical system, logic implies you should think twice giving that much responsibility to an AI as well.

> The hallucination thing I think is mostly overblown

Can you predict when and how the SOTA model will hallucinate? Yes or no. Can you predict the severity impact of that error beforehand? Yes or no.

>from speaking to colleagues it seems to vary wildly depending on which model and harness you are using

You have partially answered my question it would seem.

Genuine question: your top coder seems to be producing the most error-free code from your perspective, has the deepest knowledge of the architecture and codebase, and is faster on the trigger than the others.

But your top coder has proven and verifiable dementia, where they will confidently assume the existence of apis and code that do not exist, mix up the purpose of others and forget other things, and you can't predict when and how they will introduce errors into the system or the severity of such errors.

Are you really comfortable letting this person with dementia generate most of your codebase in the airline and health industry?

I also hope you have an iron-clad agreement that prevents the model provider from doing silent updates because all your evidence of correctness you collected thus far goes out the window in that case.

Another genuine question:

You have witnessed a human coder and the AI you're using make the same important mistake. Assuming you do not have the time and resources to retrain, fine tume, and test your frontier model:

Who would you trust not to make the same mistake multiple times in the future after you have warned them that their job depends on it, the AI or the human?

The why of this is not explained by you nor the original comment referring to the lack multiculturism, it is simply asserted. That's why the original comment came off as nonsensical. More than a quarter Singapore's population are foreign workers, and they make up at least 40% of Singapore's entire workforce. Seeing as the workforce that is driving Singapore's economic growth is not a monoculture your claim needs a little tweeking I would think.

I'm not claiming this means Singapore is embracing multiculturalism in the same way I don't claim the UAE embraces multiculturalism due to similar foreign workers dynamics, but not putting a disclaimer involving these stats while talking about the benefits of monoculture and lauding a country for its realism is a ridiculous sidestepping of reality. Both Singapore and the UAE are extremely cosmopolitan.

>Multiculturalism is essentially pacification because obviously this is unpopular

Why would it be unpopular to the dominant monoculture to maintain the monoculture? Who is being pacified when a country embraces multiculturalism? Please explain.

You're responding to an assertion with an assertion. It has been empirically proven that SOTA models can create more dogshit software than pre-AI software. It is also trivially known that the user is unable to predict when and how the AI will introduce dogshit into the software. We literally had a study posted on this forum claiming models give more accurate answers if you're mean to them. This is the shit we're dealing with. Stuff you couldn't make up in a dystopian Douglas Adams novel.

>you can encode these things into prompts

Is this satire? SOTA models randomly disobey rules in prompts all the time.

When a dev drops a production db I can warn them. If they do it multiple times during their employment I can change their roles or fire them.

I can count the number of companies providing SOTA models with the fingers on my hands. Imagine having an employee pool of only 5 savant coders with dementia to choose from to hire to your company. That's it. Thats the entire applicant pool. You can only fire one of them by hiring one of the other four to replace them with. And you can't really fire them for dropping production dbs if you can't prevent the other ones from making the same mistake. This is the current AI-first hellscape as it stands.

Putting it a different way, it won't matter if the firms who went too deep at the very beginning are fucked if the rational are forced to succumb to the market pressures created by the irrational and thus are reluctantly pushed to adopt AI-first workflows for appearance's sake in order to survive anyway. Because then everybody will be likewise fucked and completely dependent on AI, despite it being a subpar development paradigm with respect to robustness of the systems under development. History has taught us that it is adoption dynamics not capability that determines the winning paradigm or technology (Betamax vs VHS is one historical example. Javascript vs everything else is another one).

(We know it's a subpar development paradigm with respect to robustness because the entire coding agent paradigm turns the most knowledgeable programmer into a person "who doesn't know what they don't know" because development speed far exceeds their ability to reason about the codebase and the underlying SOTA models that they depend on to fix the bugs that the model itself has introduced are at best unreliable narrators with no objective evidence of correctness or deterministic behavior.)

It's one thing to know these cases exist because they all have been reported in the news or having made a note of it through separate and unrelated word of mouth interactions, but one person having direct experience of all these cases is unusual for a civilian (ie non-medical or healthcare professional).

By all means don't consider it if you don't plan on using them for a considerable amount of time, but there's a lot of of distance between a decent amount of time and "forever". You listed a mini OS and a UI toolkit among your projects, I hope you can forgive me for assuming you were planning to use those things to build more things, which would in turn often entail improving and maintaining these building blocks while they are actively used.

But I agree fully with your last paragraph, and said something similar in a comment elsewhere where I stated my tangible bar as being a Ladybird like browser built from scratch achieving Chrome parity in six months while doing continuous stable releases with coding agents in tow. Otherwise, as you said, the jury is still out.

Since you said you want to make those things that you list, I assume none of these things have been built yet. If so, I would encourage you to consider how excited you will be to constantly maintain those things you build. But even if the maintainence cycle won't be as exciting, since you are the sole user you have the advantage of being able to proceed at a leisurely pace even while doing maintainence work.

In a professional setting, the dopamine hit of being able to build something quickly that works in an area that you have little to no knowledge in makes you more dependent on the AI in the maintaince cycle as you want to chase that dopamine high by maintaining the same development speed. This in turn leads to a bigger burnout crash after that peak dopamine hit. Maintainence is a phase of diminishing returns even without AI, but when your coding agents are introducing new bugs at record pace with their bugfixes with no new features to write home about you are in a special place in Hell.

I'm all for using AI to build ambitious projects. I have yet to see a person/company/organization continuously release huge software endeavours in a stable professional manner day in and day out with a coding agent harem in tow.

If something like the Ladybird browser, or any browser that is "built by scratch", achieved Chrome parity in six months and consistently maintained the same level of stability with continuous releases then I would see that as proof that this approach has become professionaly sustainable.

The reason people are getting away with so much using AI is because of the open secret in most enterprise engineering practices: the customer cares more about the response time for fixes they report than they do about overall or longterm product quality.

People in this thread are talking past and misunderstanding each other and making unrelated points.

The point of the response to the top level comment was questioning the conflict of interest in model providers creating separate revenue streams for themselves by selling a product that fixes problems their other product created, akin to OS providers selling anti-virus software back in the day.

Similarly, it should be obvious to you that a software engineer can trivially get into the mindset of writing more expoitable code by pretending the production code they're tasked with writing is hobby code or prototype code.

If profitable revenue streams with adverserial products are in place, no one should be surprised when model providers are disincentivised to improve the "garbage code quality, but hey it works!" nature of their most used code generators.

>And, LLMs are ALREADY trained negatively against writing buggy or exploitable code.

...it should also be obvious people in this forum have wildly different experiences with respect to the code quality the LLMs they use generate. I personally find it difficult to find anyone that argues that the LLMs they are using are consistently generating high-quality code across a vast codebase.

Please stop pretending to be debating many people when you are responding to a single person, otherwise quote specific statements that you think you are responding from "the crowd". No, you should not be surprised when OSS people reevaluate the landscape any time they witness OSS being weaponized against them even though the possibility of that happening is written on "the tin" so to speak. There have been an increasing number of debates around well-known cases a decade or half before the advent of this most recent incarnation of AI. Companies with deeper pockets and larger market access burying a popular OSS product through duplication was a common category.

Do you think these anti-AI folk wouldn't evaluate the situation differently if AI, trained on public data was in fact a public utility, seeing as you are concerned about democratization?

There was an initial release of "binders" to known rightwing influencers in a choreographed photo event. It was a predominantly bullshit release that pissed off the conspiratorial wing of MAGA and the Epstein Republicans (Massie et al). This happened in early 2025.

The blowback from this event resulted in Congress passing the Epstein Transparency Act in Nov. 2025.

The biggest dump of files came after this (tho congressmen are claiming most files are still unreleased) , which is what you might be referring to.

But feel free to argue your point either way.

The author's point is not specifically about Photoshop. It's right there in the second paragraph:

>Where is the vibecoded Photoshop. The vibecoded Excel. The vibecoded Maya. The vibecoded Blender. The vibecoded compiler that compiles itself. The vibecoded database, the vibecoded OS, the vibecoded anything-that-requires-architectural-judgment-to-hold-together

What do all these examples have in common, besides requiring "architectural judgment-to-hold-together"?

They are software created by mid-large companies or organizations with a large of numbers of contributors. It's not about Photoshop, it's about developing complex software with high quality control and a continuous mature and continuous release cycle to a demanding set of hundreds/thousands of users. So to take that it in and then say, "Well, I don't think AI going to be used fo build that stuff, it's going to be directly used by non-technical end users to bypass existing more complex legacy software like Excel," is only proving the author's point.

Cause at the end of the day, what are all these companies "token-maxxing" actually building and selling to their customers? That's the larger point the author is making. Just as you imply, a large swath of apps and SaaS are being wiped out by end-users directly using AI. So the only viable path is to raise the bar on what is being built. Someone should be vibecodinfg a phone OS and vibe-building an actual phone alternative to Android and iOS, if it's actually possible. Someone should be vibecoding the Metaverse and vibecoding hundreds of Apple Vision Pro apps to make VR/AR actually viable (again). And on and on.

The only honest counterpoint to the author's post, unless you can cite vibecoded software at the level of scale and maturity they are seeking, should be:

Yeah, 2026 was the year the coding performance of LLMs passed a certain maturity threshold adoption-wise so we should realistically give it a few more years to see if it is actually possible to vibecode continuously released ambitious complex software used by demanding users on the scale you mention.

The main problem currently with LLM text is not that they create incoherent sentences, it's that what they purport to be statements of fact or general consensus often times aren't, because they are bullshit machines that become better and more accurate bullshitters the more context-accurate data they are fed. AI videos may still have issues with "looking plausible" whereas LLM text currently has less issues with "sounding plausible" and more issues with "being correct" with respect to reality. Which they have no direct connection to.

No one is penalizing an AI video generator for creating a scene that never happened in real life.

>There's no competitive/market pressure on it to naturally cap spending based on value.

The parent is specifically claiming gov jobs don't allow for near market rates. That number would literally be formulated by current market pressures. If that goes lower in the private sector it will go lower in the gov sector.

For your point to be correct with respect to their specific example, you would have to claim the gov could pay £300k/year when the going market rate was £100k/year and there would be no pressure to prevent this. Whereas all it would take would be someone to ask why a run-of-the-mill programmer is getting paid 3x the market rate?