SoylentNews is people
SoylentNews
An interesting essay about the issues with vibe coding ...
A marketing manager with no engineering background opens Cursor on Monday morning. By Wednesday afternoon, she has a working customer-facing app. It looks polished. It performs the core task. She demos it to her VP, who forwards it to their CMO, who then shows it in the executive staff meeting as evidence that the team is "moving at AI speed."
By Friday, it is in front of customers.
No one asked who owned the decision to ship it. No one tested it against the conditions it would actually face. No one had the cultural standing to say this looks great, and we are not putting it into production. The prototype became a product because the organization had no system for telling the difference.
I watched a version of this scenario play out recently in a boardroom. A senior executive demoed an AI-built internal tool. The room admired the speed. What received less attention were the harder questions: Who would own it after launch? Who would maintain it? And what would happen when it produced an answer that was confidently wrong?
This is what vibe coding is about to expose across businesses. The companies that think the story is about software are going to lose to the companies that understand the story is about judgment.
The Real Trend Is Decision Compression
Andrej Karpathy coined the term "vibe coding" in early 2025 to describe an AI-assisted style of building software through natural-language prompting, often without close inspection of the underlying code. Google Cloud describes vibe coding as a software development practice that makes app building more accessible, especially for people with limited programming experience. Tools like Cursor, Replit, Lovable, Bolt, GitHub Copilot Workspace, v0 by Vercel and Claude Code have moved the practice from novelty to workplace reality with stunning speed.
All of that is true. None of it is the point.
The point is that vibe coding collapses the distance between idea and artifact from months to hours. When that distance collapses, every quality-control mechanism your organization developed over the last 30 years gets bypassed by default. Design review. Security review. Legal review. Brand review. The simple friction of having to convince an engineer your idea was worth building. That is a governance story, not a software story. It is happening at every level of the org chart simultaneously.
[Source]: Forbes
(Score: 5, Insightful) by Thexalon on Friday May 01, @03:49PM (5 children)
However, that code may do something drastically bad, like, say, delete the database or expose data to the world that is supposed to be private. What is not doing that worth to your company?
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 3, Informative) by JoeMerchant on Friday May 01, @06:53PM (2 children)
> delete the database or expose data to the world that is supposed to be private. What is not doing that worth to your company?
Is it worth enough to have processes in place to prevent these damages? According to the horror stories, apparently not. "Smart money" prefers to move fast and break things instead of taking the time to move deliberately and safely.
Deleted database should never have been a problem, ever. Even paper punch card systems had backups.
Exposure of private information is a trickier situation. Did the code _need_ access to the private information? If it didn't it never should have had access in the first place. If the code does need access, but is also expected to protect said information, then there should be rather extensive V&V procedures in place to assure that the private information is handled properly.
LLMs aren't perfect (neither are people), which is why extensive checks need to be performed before trusting them with Humpty Dumpty.
🌻🌻🌻🌻 [google.com]
(Score: 3, Interesting) by krishnoid on Friday May 01, @08:23PM (1 child)
In that regard, are there ways to pre-prompt [sic] (I think the term is "system instruction") the AI code generation to think of itself as a hypervigilant security- maintainability- reliability- accuracy- paranoid software designer, prior to requesting that it generate *any* code?
And then when writing any code, to add comments describing how it could fail in any of those areas? Seems like it would help:
Similarly, maybe there's a way to system instruction [sic] an AI to write code and comments in a very didactic way, so future readers can better learn from it and follow along.
(Score: 5, Informative) by JoeMerchant on Friday May 01, @08:31PM
You can prompt them for all these things, but the main problem is that their "context window" only holds so much, and a year ago prompts like that really kind of fell short / fell apart when things got too complicated to hold in a single context window.
Over the past year, they have made great strides in the automation of creation of documentation, work instructions, implementation plans, system requirements, etc. structured appropriately to enable the desired tasks and as such the smaller context window can bite off more appropriately sized chunks to chew on while not losing sight of the bigger picture (as they so often did before.) They're still nowhere near perfect, but the "oh, my doG, how idiotic are you!!!" moments are getting much rarer.
🌻🌻🌻🌻 [google.com]
(Score: 4, Informative) by Whoever on Friday May 01, @08:43PM (1 child)
The software has no possible catastrophic possibilities. It only interacts with a local sqlite database, and the data in that is really quite transient. It's run as an application on a local desktop.
We did have the AI tool go back and clean up some of the code, but that was readability and code duplication issues.
(Score: 0) by Anonymous Coward on Saturday May 02, @04:50PM
You deserve mockery if you believe that the software does only that. You simply don't know.
There's a reason auditors don't audit themselves.