Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by jelizondo on Friday May 01, @03:11PM   Printer-friendly

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


Original Submission

 
This discussion was created by jelizondo (653) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by Mojibake Tengu on Friday May 01, @04:03PM (2 children)

    by Mojibake Tengu (8598) on Friday May 01, @04:03PM (#1441280) Journal

    Vibe coding is direct attack on investors. Pure greed by executives.
    It has no rational justification. It actually breaks many established engineering safety locks. And too often, technical standards.

    What is inevitably coming, fragility of vibe coded applications will backfire.
    Then, the companies will stratify into layers by severity of accumulated failures.
    Those at bottom will be crushed to shards. A grub food for lawyers.

    --
    Rust programming language offends both my Intelligence and my Spirit.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Interesting=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 5, Insightful) by JoeMerchant on Friday May 01, @05:17PM

    by JoeMerchant (3937) on Friday May 01, @05:17PM (#1441293)

    >It actually breaks many established engineering safety locks. And too often, technical standards.

    I think this is a question of organizational / process maturity.

    Did your organization develop maturity "organically" with people trained on the job by "the school of hard knocks" and processes developed through respect such as: "Joe requires all of that kind of thing to go through him before release, remember when (insert terrible problem anecdote here)? Yeah, now he checks first." If so, does upper management respect their worker bees, or merely tolerate them because they can't figure out how to get cheaper worker bees? If it's the latter, and your upper management is all too ready to shortcut all the developed processes just because they think they can, then they are doomed to repeat (terrible problem anecdote) again - then likely jump ship, spin the problem as somebody else's fault that they told them not to do and that's why I left, then go "lead" another company to their doom.

    If your organizational processes are both mature and respected, and management continues to respect the value of those processes enough to require LLM assisted endeavors to also go through the mature processes, then I believe LLMs can be a "force for good" - even being used to make the quality gate checks more effective with less effort and therefore more valuable in multiple ways.

    --
    🌻🌻🌻🌻 [google.com]
  • (Score: 1, Touché) by Anonymous Coward on Sunday May 03, @04:10AM

    by Anonymous Coward on Sunday May 03, @04:10AM (#1441399)

    It promises to bring employment cost to zero, so it's pure reward for investors.