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: 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]