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, Disagree) by Whoever on Friday May 01, @03:18PM (9 children)
On the other hand, at my company, we have been able to add features to our main product that we simply didn't have the capability to do in any useful time frame.
So, the choice is: no feature, or feature with less than ideal code?
Don't let the perfect be the enemy of the good.
(Score: 5, Insightful) by Anonymous Coward on Friday May 01, @03:39PM
And I'm sure the code for those features is absolute garbage. You're argument to add subpar, AI-generated code for features just because actual coders don't have time is utterly ridiculous.
(Score: 5, Insightful) by Thexalon on Friday May 01, @03:49PM (5 children)
However, that code may do something drastically bad, like, say, delete the database or expose data to the world that is supposed to be private. What is not doing that worth to your company?
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 3, Informative) by JoeMerchant on Friday May 01, @06:53PM (2 children)
> delete the database or expose data to the world that is supposed to be private. What is not doing that worth to your company?
Is it worth enough to have processes in place to prevent these damages? According to the horror stories, apparently not. "Smart money" prefers to move fast and break things instead of taking the time to move deliberately and safely.
Deleted database should never have been a problem, ever. Even paper punch card systems had backups.
Exposure of private information is a trickier situation. Did the code _need_ access to the private information? If it didn't it never should have had access in the first place. If the code does need access, but is also expected to protect said information, then there should be rather extensive V&V procedures in place to assure that the private information is handled properly.
LLMs aren't perfect (neither are people), which is why extensive checks need to be performed before trusting them with Humpty Dumpty.
🌻🌻🌻🌻 [google.com]
(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]
(Score: 4, Informative) by Whoever on Friday May 01, @08:43PM (1 child)
The software has no possible catastrophic possibilities. It only interacts with a local sqlite database, and the data in that is really quite transient. It's run as an application on a local desktop.
We did have the AI tool go back and clean up some of the code, but that was readability and code duplication issues.
(Score: 0) by Anonymous Coward on Saturday May 02, @04:50PM
You deserve mockery if you believe that the software does only that. You simply don't know.
There's a reason auditors don't audit themselves.
(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]
(Score: 4, Insightful) by Mojibake Tengu on Friday May 01, @04:03PM (2 children)
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.
(Score: 5, Insightful) by JoeMerchant on Friday May 01, @05:17PM
>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
It promises to bring employment cost to zero, so it's pure reward for investors.
(Score: 3, Interesting) by looorg on Friday May 01, @05:17PM (12 children)
Who gets fired when the vibe project does something stupid? Or turns out to have opened some kind of chasm of a security vulnerability? When the bad vibes are showing ...
(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]
(Score: 3, Insightful) by EEMac on Friday May 01, @05:52PM
> Who gets fired when the vibe project does something stupid?
It won't be an executive.
(Score: 2) by JoeMerchant on Friday May 01, @06:42PM (1 child)
>Who gets fired when the vibe project does something stupid?
IMO, the moron who trusted it with more responsibility than it had earned.
If your vibe project has $10M worth of responsibility - can potentially cost the company $10M if it screws up - how much verification and validation do you think is warranted before letting it out of the sandbox into production?
Did you just say "what's a sandbox?" - yeah, your talents will be better appreciated elsewhere.
🌻🌻🌻🌻 [google.com]
(Score: 3, Funny) by krishnoid on Friday May 01, @07:57PM
We don't have a fancy college-boy "sandbox", we just git 'er done [thedailywtf.com]!
(Score: 2) by sonamchauhan on Saturday May 02, @01:15PM
> Who gets fired when the vibe project does something stupid?
Who? The culprit LLM, of course!
With 3 to choose from, fire them one by one for three successive incidents before reinstating the first one again.
(Score: 4, Interesting) by turgid on Friday May 01, @05:31PM (3 children)
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.
Remember that the entire point of a company is to move money from the pockets of customers to those of the shareholders in the quickest and cheapest way possible, nothing more and nothing less.
In the short term, this means that companies which adopt this AI approach will dominate and they will put their competitors out of business. The shareholders can retire rich.
What happens next is for the birds. Probably vultures, corvids and the like.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Insightful) by JoeMerchant on Friday May 01, @07:07PM (2 children)
>Remember that the entire point of a company is to move money from the pockets of customers to those of the shareholders in the quickest and cheapest way possible, nothing more and nothing less.
I work for a company that is "mission driven" and most of the mission is about things other than "make a fair profit" - but that element has to be in there, because if it isn't, the company ceases to exist rather quickly.
In a perfectly frictionless competitive market, only those companies which move money into the shareholders' pockets the most quickly and efficiently will survive. As business has been "streamlined" by technology, we have moved closer and closer to this reality.
The advertising spend thread is bleeding into my thought process here, but: money is nothing more (and nothing less) than a way to influence the behavior of people. You may think that a ton of copper has a value of $13,000US, but what that $13,000US really is, is monetary incentive sufficient to get people to deliver a ton of copper into your possession (FOB, most likely...) The copper may have been recycled, or mined and smelted from ore, or stored in a warehouse for a decade, but all in all, the market has currently decided that one ton of copper is exchangeable for $13,000US because that's what it takes to pay for the warehouse storage, and/or the recycling, mining, smelting, shipping, handling, regulatory overhead, corruption, security, taxes, and everything else that goes into delivering a ton of copper. The cost of the warehouse isn't about the cost of the materials of the building, it's mostly about the labor, and the labor that goes into provisioning of the supplies, and cost of maintenance, debt service, and the other various payola/taxes required for the warehouse owner to continue their "quiet enjoyment" of the property.
All the money eventually ends up being used to convince somebody somewhere to do something at some time, because that's actually the only thing money can do. This is also why advertising is so valuable, because advertising also convinces people to do things - just like money does.
🌻🌻🌻🌻 [google.com]
(Score: 3, Insightful) by turgid on Saturday May 02, @10:18AM (1 child)
Here's one: all companies tend towards Private Equity funds.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by sonamchauhan on Saturday May 02, @01:19PM
I miss the days when corporate ambition was limited to embedding an email client
(Score: 3, Informative) by mhajicek on Friday May 01, @10:58PM
I had Claude do a quoting spreadsheet for my machining business. It took eleven iterations to get out all the bugs I could find.
I don't think it was any faster than doing it by hand, but the end result looks more polished than I would have done, with fancy cell colors and an instructions sheet.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 4, Insightful) by gnuman on Saturday May 02, @09:34AM (4 children)
And for tools, people need analogy. So, let's have analogy that comes to forestry.
Long long time ago, forestry was the real of burly men with big axes. Some even have youtube or tiktok channels. Then we had a revolution. Instead of axes or manual saw ... chainsaws appeared. Suddenly, anyone and everyone was strong enough to cut a tree and in seconds. But instead of just getting crushed by a falling tree at much increased rate (ie. no experience), people started to also cut their own legs at alarming speed.
AI is that chainsaw. With a plan and experience, you can cut trees faster. But anyone can grab it and cut their hand or leg off in the process too. And even with experience, the likelihood of getting crushed by a falling tree or getting splinters in the eye and some infection is increased.
(Score: 2) by JoeMerchant on Sunday May 03, @03:41AM
I frequently use the chainsaw analogy - also lightsaber...
Powerful tools create problems much easier than primitive tools. Doesn't mean I want to use primitive tools when powerful ones are available.
🌻🌻🌻🌻 [google.com]
(Score: 2) by Bentonite on Sunday May 03, @11:13AM (2 children)
Chainsaws are too reliable and too safe to be comparable to LLMs.
A chainsaw will predictably cut a tree down if wielded correctly and kept maintained, while it is entirely unpredictable what a LLM will do.
LLM usage is gambling over and over whether it will output total slop, or slop that looks like the text you want.
(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.