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 turgid on Friday May 01, @05:48PM (7 children)
You know what people are like. They won't bother to look at the code generated by the vibe coding. Who knows what surprises it might contain? This is a whole new class of security vulnerabilities waiting to be discovered. More popcorn.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by JoeMerchant on Friday May 01, @06:47PM (6 children)
>They won't bother to look at the code generated by the vibe coding.
They can't - the code is coming at them at super-human speed. It would take a team of 10 engineers reviewing code to keep up with one engineer producing code. (Actually, IRL, it probably takes 2 or 3 engineering hours to do a thorough review of each hour of code development work - perhaps half of that can be "self review" so the producer makes 1 hour of code for every 2 hours of work, then needs another hour of independent review on the same code - so it might look like 1/2 hour of review for every hour of coder output - but then again, I have colleagues who clearly don't read their own slop before slamming that pull request in 12 hours before the end of the sprint...)
Answer: LLM review of LLM generated code.
I've only been doing it for a few months, but so far it works FAR better than human review of code, and it's really just part of any mature code devlopment process anyway. So, yeah, cool your jets on that 10x productivity claim, scale it back to about 3x to account for LLM review and correction of the LLM generated code. As if these metrics ever had any meaning in the first place.
🌻🌻🌻🌻 [google.com]
(Score: 2) by turgid on Friday May 01, @07:25PM (5 children)
Can you see the problem with that?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Informative) by JoeMerchant on Friday May 01, @08:04PM (4 children)
You don't trust the LLM because you have more experience viewing the Terminator movies than having LLMs review code?
Honestly, it's a matter of criticality...
I vibe coded a phase of the moon clock that shows a high resolution image of the moon shaded to its current phase plus a clock and day, month, date display. Did I hand review that? No. Could it have malware sitting inside my network exfiltrating my banking secrets? Sure, that is in the realm of possibility, right up there with a drifter waiting outside our house to mug us, tie us up and steal our car... Beyond possible, that has happened twice in nice neighborhoods I have lived in within a circle of about 300-1000 homes around ours. I'm still not taking extraordinary measures to prevent either one.
I also vibe coded a server which receives "protected information" into our system. I read every single line of that code, most of it twice. It was still faster than coding it myself. And, it's through exercises like that that I learned to stop worrying and love the bomb. [share.google]
🌻🌻🌻🌻 [google.com]
(Score: 3, Insightful) by turgid on Friday May 01, @08:50PM (3 children)
I'm pleased that you are trying this stuff out for us. As I said to a colleague once, I'm letting people like him figure out how it works for me and I'll ask later. Meanwhile, popcorn and beer.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Interesting) by JoeMerchant on Friday May 01, @09:46PM (2 children)
In the sad but true department... I'm the 2nd oldest member of the team, the oldest doesn't give a flip if/when they let him go, but I'd really like to ride this particular gravy train for another 12-15 years, so I'd rather not be anywhere near the top of the list during any "rightsizing" discussions. Everybody knows I know C++ and the industry, but we're moving wholesale out of C/C++ into Rust. Honestly, when I started coding in Rust was about the same the AI tools started becoming useful - so what I know of Rust, I learned through the lens of AI implementing Rust. I'd estimate that me + AI can out-class the Rust performance of our colleagues who have "been in Rust" for 2-3 years now yet feel that AI is "not the right way to do things. Not just a little better, really next level insights, performance, architecture, everything. Could I back off and "do Rust without AI?" Sure... I can quit any time I want... Absolutely... except, I never quit using Stack Exchange, or Google to find and read APIs, or API reference books when they were the best thing going, or C compilers once they started out-classing hand written assembly... why should I start going Luddite now?
🌻🌻🌻🌻 [google.com]
(Score: 4, Interesting) by turgid on Saturday May 02, @10:17AM (1 child)
why should I start going Luddite now?
Once again, I have failed to express myself clearly. You said it yourself with respect to reviewing/understanding the code: They can't - the code is coming at them at super-human speed.
To put it more bluntly, why is turning a blind eye to a potential problem acceptable in this case? Why would mitigating that problem be "Luddism?"
They're already calling this Digital Asbestos.
Forgive me for being sceptical. I find I have to push back hard against this crazy world just to stand still. The world wants me to lower my standards all the time in the relentless pursuit of higher profits. It always backfires. Always, without exception. Why is this case special?
I have developed personal tools and practices over the years where, if I can get peace and quiet and people can stop bugging me with su[id questions, I can churn out a couple of thousands working, tested, mostly bug-free lines of C per day. I am currently fortunate enough to be working on a very interesting system. It has to work properly. People have to understand what it does and how it is implemented. It needs to be reliable and deterministic. It has a real time component. Why the hell would I want to change what I know works and vibe code it?
Am I a Luddite? Or am I merely being a responsible Engineer? Should I get on this bandwagon? I could vibe code it, take the money and run away before they try to use it?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Saturday May 02, @12:51PM
> why is turning a blind eye to a potential problem acceptable in this case?
But, it's not turning a blind eye, it's giving appropriate oversight - risk based vigilance.
Our "safety critical" code, all of it, is still reviewed line-by-line. Just because LLMs _can_ whip out code 10x faster doesn't mean we have to use them that way, and even if they do put it out 10x faster, we can run them at 10% duty cycle so to speak, and do other things instead of snapping at drop-in visitors to leave us alone "we're in the zone" and have to get this out by Tuesday... (Actually, we can still snap at the drop-ins, but just for other reasons...)
>They're already calling this Digital Asbestos.
They're referring to people who are doing it wrong. So far, management has placed zero expectations on accelerated output. My primary focus for using the tools isn't actually coding, it's mostly requirements development and code review. When a (modern) LLM reviews code, the things it finds are real - then it's up to you to decide how important they are - and if they're not important, you can generally soften the requirements / specification language so that the trivial stuff is no longer "in conflict with the requirements."
On the other hand, when we needed that new server in the product, Cursor/Claude and I developed the requirements in 15 minutes, then the tool wrote the code in another 15 minutes, and I spent the rest of the afternoon reading through the code. The initial implementation ignored an existing design pattern, so I directed it to review the existing design pattern and re-implement accordingly - which it did in another 10 minutes. Then I continued re-reading the new implementation... it's all stuff I would have done, but this way I didn't have to look up the details, do the compiler iterations to comb out the syntax nits, and most importantly: I wasn't "invested" in any particular approach because it was so easy to switch approaches to a better one if a better one presented itself.
The potential for abuse is there - but the potential for abuse has always been there, we have programmers in India and China - we can just accept what they produce without deep review - that's even worse in my opinion because they are all too human, I've never caught anything malicious, but there's a ton of lazy in there if you don't maintain the force-of-will to demand iterations until all the lazy is out. And here I refer to lazy with problems, lazy without problems is genius to be shared with the team as patterns for future development.
>if I can get peace and quiet and people can stop bugging me with su[id questions
Yeah, I block Fridays on my schedule (used to be Tuesdays, but that was a schedule vacuum that attracted recurring meetings... then a couple of years ago corporate came out and actually suggested we block Fridays - I took that advice and held on to it even after they quit suggesting it) - that's my "independent work time." The rest of the week gets fragged with random meetings (aka focused attention destruction grenades). I tell myself this is how I mentor the juniors, how I share my wisdom with those who all too rarely acknowledge their appreciation of it.
>Why the hell would I want to change what I know works and vibe code it?
If you don't have any free time to investigate "vibe coding" or LLM augmented document development tools or whatever you want to label it, then yeah, you're at capacity, stick with what works. Here, marketing has been waffling about what they want for the past 5 years, and higher management is "strongly encouraging investigation and adoption of the new technology" so, I don't feel as if I'm delaying introduction of any new income producing products by doing the experimentation. We also added our "Asian partners" about 6-7 years ago, didn't really figure out anything they could do for us for the first 3 years, but invested heavily in equipping them with all the toys, and now they're starting to contribute and our role is adding much more management of them "leveraging the talent" or whatever other BS speak you might attribute to the endeavor. On the "not a bad idea" side of things, we make products that are used by people, and there's over 8x as many people in India and China as the U.S. - so it makes a good bit of sense to not only understand those markets but also to try to do development of product inside their culture and their governmental systems. Anyway, the tie-back to LLMs is: managing the LLMs feels a lot like managing Asian coders, particularly the Indians... trust, but verify.
>Should I get on this bandwagon?
That's a personal choice. My upper management is encouraging it, and I generally have had bad results when ignoring upper management's desires in the past...
>I could vibe code it, take the money and run away before they try to use it?
I guess it comes down to how you define "vibe code". If you narrow the scope to "use of AI agents to slap-dash immature and barely functional demos" then, sure, become a consultant and get paid the big bucks to make "bird calls" - fly in, drop a little shit, fly out.
I like to think that over the past 6 or so months, I have "developed skills" mostly in the areas of applying all the disciplines we already have developed for software devlopment to the LLM tools and I believe I have (finally) seen the merits of those disciplines, which used to be extremely onerous in terms of time and effort and attention span, to the point of being a lot of busy-work with little practical benefit - but, when used with LLM tools, it's somewhat like watching a time-lapse movie. Self-consistent, comprehensive requirements that would have taken much more effort to develop come together quickly - and maintenance of those requirements that would be similarly onerous is similarly accelerated. Now, in this compressed timeframe, having those higher quality more detailed better organized requirements pays off in terms of better architectural and design choices. You can also flesh out the architecture and design documents much more fully in much less time. And, finally, after hearing the Quality nerds sing all the praises of this process for the last 25 years, I see it come true: having all that structure alongside the code implementation, and being able to maintain it all with a reasonable level of effort, really does make the implementation and maintenance flow much better. Part of this is because the LLM code agents are lame, the way that "average" software developers tend to be lame. They don't develop the big picture in their heads, they get lost in the forest looking at the trees. These processes benfit both, the same way. The speed of LLM development also means that you can try things and throw them away, start over, without so much angst about "wasted time."
I never much cared for people-management, it's too "Forrest Gumpy" for me - that whole "Life is like a box of chocolates" thing, you get some good ones, and some unpleasant ones, and occasionally you bite into one with a rancid mouse fetus inside, and upper management wants you to "work with" all of them - get the best out of them. A colleague of mine from England had this comment about McDonalds: "It's not great food, it's not even good food, but it does have a certain level of predictability about it - you know more or less what you're going to get when you go to a McDonalds, and at least you're not likely to leave with food poisioning, or only have unfamiliar/strange - potentially unpleasant choices on the menu." So, for me, managing LLMs is a lot like the fast-food chain experience. Sure, I have worked with some better developers, but the LLMs are always available, they're fast, and when you figure out how to order what you want, you generally get what you want from them.
🌻🌻🌻🌻 [google.com]