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 OrugTor on Friday May 01, @05:09PM (1 child)
Missing the point. Did the feature implementation go through code review, QA and all the other processes that human-coded software should be going through? If the code survives all of that then who or what produced the code is of little interest.
(Score: 4, Insightful) by JoeMerchant on Friday May 01, @06:38PM
>If the code survives all of that then who or what produced the code is of little interest.
Exactly. Also - in my experience mandatory 100% code reviews become somewhat of a performative farce when developers are tasked with review of their peer's code, development of their own to be reviewed by their peers, etc. There's the very human tendency to "not be a pain in their ass so they don't become a pain in mine" - and there's also a strong human tendency to notice things you don't like, that may not matter, more frequently than noticing subtle problems that are concrete bugs waiting to bite - especially race conditions in our Rust dominated "THREAD ALL THE THINGS!!!" world we have recently been thRUST into. No, "MUTEX ALL THE THINGS!!!" is not a workable strategy.
To this point, LLM reviews of code vs requirements, requirements vs design details, unit tests vs enumerated testable requirements and design details, requirements and design details vs readiness for implementation, etc. tend to be MUCH more thorough, dispassionate, occasionally nit picky, and VALUABLE than human code reviews, particularly what a human can practically review in an hour vs what a human armed with a recent frontier model LLM can review in an hour. And, yes, LLMs find plenty of problems with LLM generated code and documentation - but... most of the time lately, what they find is real. You can make judgement calls about whether or not you care that the spec says "check the total size of recorded log files every 2 minutes and delete the oldest to maintain a maximum 100MB of files in the folder" and the code may only check every 125 seconds, and the maximum size might actually exceed 100MB after the 2 minute scan due to additional logs being recorded after the folder snapshot was taken... The LLM may point out 0.1% discrepancies between spec and code in cases like that where it doesn't matter while also missing big important problems, but generally if you keep iterating LLM reviews until it has no new findings, it does eventually find most of the problems.
🌻🌻🌻🌻 [google.com]