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: 2) by gnuman on Monday May 04, @09:35AM (1 child)
With correct oversight, LLMs make software development more reliable and faster. Think how often you didn't have time to write unit tests. LLMs solve that excuse once and for all. Even if they did nothing else, having unit tests makes things faster in the long run and safer in general.
6 months ago, LLMs were rather crap at writing code. Since then (gemini-3 days), they do not make mistakes they used to. But just like chainsaws, if you do not know what you are doing, you will cut yourself faster than you realize that LLM wrote you a 0-day.
(Score: 3, Insightful) by Bentonite on Monday May 04, @12:45PM
Last time I checked, LLMs make software development slower and less reliable, although sloperators are successfully conned into thinking they're programming faster; https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ [metr.org]
Now that I've checked the latest results, with the latest slop, appear to show that maybe there's a minor speedup, but it seems likely developers are actually still slowed down when it comes to the writing code stage; https://metr.org/blog/2026-02-24-uplift-update/ [metr.org] (the study doesn't seem to take into account the future maintenance burden of a mountain of inscrutable slop code)
LLMs cannot write code - all those can do is copy existing (bad) code and combinations thereof.
Most code that exists is bad and is also full of vulnerabilities and as a consequences, it is impossible for a LLM to not on average output bad code, that is full of vulnerabilities.
Provided reasonable tooling is used, unit tests don't take a significant amount of time to write and I don't see how a significantly high chance of having slop unit tests that fail to test anything, would be useful (it seems that it would take the same amount of time to just write the unit test, rather than checking to see if a unit test actually tests something).
Writing code is a small fraction of the development time of actually useful programs - most development time is rather spent on debugging (debugging LLM slop of course would take significantly longer than decent code - but it seems that whatever the slop does is accepted as a feature and not a bug).
Despite the unreliability of slop programs, it seems those somehow still tend to be more reliable than traditionally developed proprietary software?
That would match how I've seen that functionally decent proprietary program are rare and if they are functionally decent, that is because most of the functionality is implemented by software that used to be free.
If you want to copy code, you should copy it properly and also comply with the license terms - that will save you a significant amount of time in the future.