AI makes it quicker and cheaper to ship something. The problem with most companies is shipping the wrong thing.
VCs hope that with AI they can have a larger portfolio, shipping more things, so that by sheer luck, one is a success. That's why many employees are critical of the AI hype while VCs and C-level love it. The whole discussion about maintainability doesn't even register on the radar, employees vs. VCs and C-level are operating at a different definition of "failure".
hinkley · 44m ago
It’s based on the same category error that says I can buy a company but lose the employees and still have the value.
You don’t. You either don’t get that, or you do but would rather people not know that you really just wanted to destroy a competitor and snake some of their customers.
reactordev · 1h ago
queue the South Park "They took meh jeb!"
itsdrewmiller · 2h ago
> I suspect best practices for "vibe coding" will end up like test-driven development: a proven method for writing better software that many engineers still choose to skip.
I’d like to see the proof for TDD; last I heard it slowed development with only minor reliability improvements.
juancn · 2m ago
I think it works only for people with a certain thought pattern, the ones that like to think everything up-front before doing anything.
Most people prefer to play around and make several crappy attempts and combine them until the whole is somewhat solved, then go over and polish it a little, and maybe then add tests and fix the behavior in place.
For this last group, TDD it's jarring, unnatural and requires a lot of willpower to follow.
It's not bad in itself, it's just not for everyone.
seadan83 · 1h ago
The proof for TDD is usually looking at bug detection rates. Similar for code review. OTOH, the "design damage" of TDD is something overlooked by those metrics.
What it boils down to:
- TDD in the hands of a junior is very good. Drastically reduces bugs, and teaches the junior how to write code that can be tested and is not just a big long single method of spaghetti with every data structure represented as another dimension on some array.
- TDD in the hands of a midlevel can be a mixed bag. They've learned how to do TDD well, but have not learned when and why TDD can go bad. This creates design damage, where everything is shoe-horned into TDD and the goal of 90% line coverage is a real consideration. This is maximum correctness but also potentially maximum design damage.
- TDD in the hands of a senior is a power tool. The "right" tests are written for the right reasons with the right level of coupling and the tests overall are useful. Every really complicated algorithm I've had to write, TDD was a life saver for getting it landed.
Feels a lot like asking someone if they prefer X or Y and they say "X" is the industry best practice. My response universally is now an eye brow raise "oh, is it? For which segments of the industry? Why? How do we know it's actually a best practice? Okay, given our context, why would it be a best practice for US". Juniors don't know the best practices, mid-levels apply them everywhere, seniors evaluate and consider when best practices are not best practices.
TDD slows development when tests are written in a blind way with an eye on code coverage and not correctness and design. TDD speeds up development in being a good way to catch errors and is one of the best ways to ensure correctness.
hinkley · 42m ago
Developers have selective amnesia and only count dev time when working on what they want to work on rather than including time spent fixing things they’ve already mentally marked as done.
The worst actors find ways to make other people responsible for fixing their bugs.
dogleash · 49m ago
Your comment doesn’t distinguish between having a robust automated test suite and doing TDD.
I’ll take your comment as testing is good and constraining your workflow to TDD is worthless.
AstroBen · 8m ago
TDD is really commonly misunderstood to be a testing strategy that helps reliability- it's not. It's supposed to guide your software design
bsoles · 14m ago
TDD doesn't work for the same reasons why Todo lists don't work. I don't have a good explanation why that is so, but I know from countless examples (mine and other people's) that they don't work.
In general, doing things work, planning to do things don't.
rootnod3 · 1h ago
So, there you have it. TDD is good if applied correctly, and only if you apply it 100% correct. And so it seems for LLM usage. If it doesn't work for you, then you are obviously doing it wrong according to many folks here. TDD is nice to catch refactoring mistakes, LLMs are nice to maybe do some initial refactoring on a small enough code base. And it doesn't mean that one precludes the other. But I haven't seen TDD put engineers out of work and neither should LLMs. Trust either model fully and you are in for a world of hurt.
MoreQARespect · 1h ago
I would usually measure "TDD correctness" in terms of how closely the test matches a user story vs how closely it mirrors code implementation.
The former is desirable, not common. The latter is common, not desirable.
jcmontx · 2h ago
I see TDD exactly as the best practice for vibe coding! Context is stored as test coverage, to make sure they don't break things when they hallucinate.
YMMV though.
recursive · 1h ago
Two bad tastes that taste bad together.
RandallBrown · 1h ago
Who did you hear the it slowed development from?
My personal experience (and I think the experience of many who do it full time) is that it makes things faster.
chickenzzzzu · 1h ago
I wrote a full fledged 3D exporter in 6 days without a single test case. Used by thousands of people every day.
How did I test and debug? Run my code and printf.
unzadunza · 2h ago
> 81% of developers agreed that AI increases their productivity
I've had a few AI generated PRs come my way and the code-review process is, shall we say, not fun. It takes me a lot more time to review these PRs, there is way more back-and-forth between me and the 'developer', and it takes much more time to get the PR merged. That's not saying anything about the increased difficulty in modifying this code in the future.
I have a feeling these claims of being more productive don't account for the entire development cycle.
mattas · 2h ago
I think employees (myself included) often think, "I'm more productive" when in reality what they are actually experiencing is, "My job is now easier."
Easy does not necessarily mean more productive when you're trading ease for something else. In the case of coding, you're trading ease for things like understanding and maintainability.
zingababba · 50m ago
Yes, exactly.
itsdrewmiller · 2h ago
The recent RCT on open source ai bug fixing had most participants feeling like they were more productive but actually being less productive. It may just be perception error, and then the issue you identify makes it even worse.
ModernMech · 1h ago
Right, a machine that automates the planting of mines may make the user more productive at their job, but that doesn't really account for the time spent cleaning them up on the backend and how many limbs will be lost in the process. AI is an automated landmine planting machine.
Sure AI increases developer output, which is sometimes correlated with productivity -- but often times not. Insofar as AI is accelerating positive outcomes (we were able to write some tricky code that was blocking us), it's also accelerating the negative outcomes (we used the LLM to write 40k lines of code in an hour and no one know what any of it does). One of these things is "productive" the other is just performative work.
If "being more productive" is using an ai to write an email which is then summarized by AI on the receiving end, or students using AI to write papers which are graded by AI, or developers using AI to write code which is then reviewed by AI, then AI isn't actually making anything better.
riku_iki · 2h ago
AI search makes me personally way more productive, e.g.: write snippet how to do X using library Y I never touched before.
bootsmann · 44m ago
Maybe as a small anecdote: I had a coworker ask an AI to write them a function to auth to aws using boto3 and environment variables. The LLM happily complied and gave them a 30 line snippet but it failed to point out that if they were to open boto3 docs it would tell them that it will already default to environment variables when it has no credentials and the whole function is just reinventing the wheel.
If you’re throwing the LLM at APIs you don’t know, how could you possibly verify it is using them properly?
riku_iki · 41m ago
The question is how fast and well dev unfamiliar with that API would achieve the goal alone compared to being assisted by LLM: he could set up snippet, run test, see what are the error, ask LLM to check why error could happen.
bootsmann · 22m ago
I don’t believe that the time a dev spends on prompting an LLM over reading an API reference saves a significant chunk of the TCO for the lines of code they write.
riku_iki · 19m ago
I personally observe very opposite: it safes a lot of time.
jihadjihad · 2h ago
> To fix this bug, I need to understand the code.
Almost every day on this site for the past few months has been an instance of Mugatu's "I feel like I'm taking crazy pills!" moment.
rafterydj · 59m ago
Hah! Especially seeing the same articles, and pro/con discussions feels like a form of the preceding lines:
_"There's only one subject on HN for Christ's sake. _Tips For Agentic AI Use_,_Gemini CLI_, _Building X with Claude_, they're the same thing!"_
agentultra · 2h ago
Wasn’t the point of vibe coding to write throwaway code you will never maintain or care about?
Why do people think it means we can write enterprise applications without understanding the code/specifications?
adamddev1 · 1h ago
Let's see how many forget how to write and think through their own code while primarily vibe coding.
prisenco · 44m ago
"Nothing is more permanent than a temporary solution."
Analemma_ · 1h ago
That was the theory, but it ran straight into the reality that most of the time “throwaway prototyping code” gets shipped straight to production and never updated, because it’s addressing real needs right now and there’s no time to fix it because a dozen other feature requests and support issues have arrived in the meantime.
The quip that “there’s nothing more permanent than a temporary solution” has been a truism of software engineering since long before AI arrived on the scene, vibe coding is just making the problem much worse.
juancn · 16m ago
From TFA:
Imagine the 3 AM on-call alert. The engineer trying to fix it might be navigating a section of the codebase they've never seen before, generated entirely by an AI. In this scenario, you can't afford to vibe it out or gamble precious minutes while an AI agent attempts a fix. You need ground truth, and you need it fast.
This is where it breaks down for me. If you trusted the AI to do the code, why don't you trust it with the on-call?
Why automate the fun part and keep a human for the shitty part?
I don't really get the reasoning behind all the hype, or better said: I kinda do, but it's more of a knee jerk reaction or essentially FOMO.
What makes me think this is a bubble is the amount of emotion behind the decision making process (plus the fact that almost nobody is making a dime with this so far).
bicx · 2h ago
I have a basic rule: understand and agree with every line of code in a PR I’m responsible for generating (manually or via agent). This simple act prevents 99% of AI-related bullshit code.
rbongers · 43m ago
>The discipline required to use AI tools responsibly is surprisingly difficult to maintain
I don't find that this requires discipline. AI code simply requires code review the same as anything else. I don't feel the need to let AI code in unchecked in the same way I don't feel the need to go to my pull request page one day and gleefully hit approve and merge on all of them without checking anything.
hinkley · 48m ago
Half the problem will be lack of a coherent commit history, to piece together what the goal of certain changes might have been. Large check-ins lose resolution here which magnifies the number of possibilities.
When you’re trying to preserve features but fix bugs this information saves a lot of time and helps prevent regressions.
Dwedit · 2h ago
Throwaway prototypes have their uses. Go ahead and vibe-code the throwaway prototype.
Sharlin · 1h ago
There’s nothing more permanent than a throwaway prototype.
turnsout · 1h ago
Nice in theory, but I once made a throwaway prototype which the client used as the foundation for their mobile app. It was translated into 26 languages and deployed across the globe. I had to work with their mobile engineers who asked why some of the views were so knotty and complex. They were complex because I was quickly patching and tweaking things between user interviews until the end of the project! The code was a mess.
Once the business sees that the prototype more or less works, it's incredibly difficult to get them to spend money on a "sane" clean-sheet rewrite.
idiomat9000 · 1h ago
My nightmare is a product from search. You search and AI spins up a super slow just in time created online service of what it assumes you need. Like click button, agent creates code, compiles and adds while you wonder why its still spinning ..
evanjrowley · 1h ago
Up until now I considered the enterprise nightmare of vibe debugging to be a data/governance problem involving something like:
Dev: enables verbose/debug logging
App: encounters error, creating big log file
Dev: uploads entire logfile, containing secrets, to 3rd party LLM and asks "read this log and identify the problem"
meanwhile...
LLM: leaks prompt, logs, and secrets to hackers
LLM: uses prompt for training data, then provides secrets as responses to other users
astrobe_ · 43m ago
"Isn't it just temporary, and AI will get better?"
There are 2 instances of the word "understand" in the first paragraph, 3 if you count the beginning of the second.
In my book, "understanding" is a synonym for "intelligence" - the roots of the word are "read between the lines", where something else that just knowledge is, the ability to use and manipulate knowledge [1].
But the thing is, despite this tech being classified as "artificial intelligence", it does not understand a thing - or so little.
So, if we extrapolate Betteridge's law of headlines, no it is not temporary for this type of technology. But I think connecting it with formal computations - inference engines for formal logic, calculators [2], etc. could be amazing.
[2] https://arxiv.org/abs/2406.03445 - amazing result, and maybe will find out that it is exactly what we do "under the skull", but doing arithmetic with Fourier transforms is not the best use of a microprocessor.
bestouff · 2h ago
Self-inflicted nightmare.
deadbabe · 44m ago
I just imagined a future where not only are programs entirely vibe coded and vibe debugged, but even the end users interact with them entirely through vibing. Wow.
nutjob2 · 1h ago
The better programmer you are, the better the software you're going to get using LLMs. But the worst programmers are leaning on LLMs the most.
The paradox is that the better LLMs get, the more serious the bugs will be because the software will seem ok, only to blow up after people have developed a false sense of security.
VCs hope that with AI they can have a larger portfolio, shipping more things, so that by sheer luck, one is a success. That's why many employees are critical of the AI hype while VCs and C-level love it. The whole discussion about maintainability doesn't even register on the radar, employees vs. VCs and C-level are operating at a different definition of "failure".
You don’t. You either don’t get that, or you do but would rather people not know that you really just wanted to destroy a competitor and snake some of their customers.
I’d like to see the proof for TDD; last I heard it slowed development with only minor reliability improvements.
Most people prefer to play around and make several crappy attempts and combine them until the whole is somewhat solved, then go over and polish it a little, and maybe then add tests and fix the behavior in place.
For this last group, TDD it's jarring, unnatural and requires a lot of willpower to follow.
It's not bad in itself, it's just not for everyone.
What it boils down to: - TDD in the hands of a junior is very good. Drastically reduces bugs, and teaches the junior how to write code that can be tested and is not just a big long single method of spaghetti with every data structure represented as another dimension on some array.
- TDD in the hands of a midlevel can be a mixed bag. They've learned how to do TDD well, but have not learned when and why TDD can go bad. This creates design damage, where everything is shoe-horned into TDD and the goal of 90% line coverage is a real consideration. This is maximum correctness but also potentially maximum design damage.
- TDD in the hands of a senior is a power tool. The "right" tests are written for the right reasons with the right level of coupling and the tests overall are useful. Every really complicated algorithm I've had to write, TDD was a life saver for getting it landed.
Feels a lot like asking someone if they prefer X or Y and they say "X" is the industry best practice. My response universally is now an eye brow raise "oh, is it? For which segments of the industry? Why? How do we know it's actually a best practice? Okay, given our context, why would it be a best practice for US". Juniors don't know the best practices, mid-levels apply them everywhere, seniors evaluate and consider when best practices are not best practices.
TDD slows development when tests are written in a blind way with an eye on code coverage and not correctness and design. TDD speeds up development in being a good way to catch errors and is one of the best ways to ensure correctness.
The worst actors find ways to make other people responsible for fixing their bugs.
I’ll take your comment as testing is good and constraining your workflow to TDD is worthless.
In general, doing things work, planning to do things don't.
The former is desirable, not common. The latter is common, not desirable.
YMMV though.
My personal experience (and I think the experience of many who do it full time) is that it makes things faster.
How did I test and debug? Run my code and printf.
I've had a few AI generated PRs come my way and the code-review process is, shall we say, not fun. It takes me a lot more time to review these PRs, there is way more back-and-forth between me and the 'developer', and it takes much more time to get the PR merged. That's not saying anything about the increased difficulty in modifying this code in the future.
I have a feeling these claims of being more productive don't account for the entire development cycle.
Easy does not necessarily mean more productive when you're trading ease for something else. In the case of coding, you're trading ease for things like understanding and maintainability.
Sure AI increases developer output, which is sometimes correlated with productivity -- but often times not. Insofar as AI is accelerating positive outcomes (we were able to write some tricky code that was blocking us), it's also accelerating the negative outcomes (we used the LLM to write 40k lines of code in an hour and no one know what any of it does). One of these things is "productive" the other is just performative work.
If "being more productive" is using an ai to write an email which is then summarized by AI on the receiving end, or students using AI to write papers which are graded by AI, or developers using AI to write code which is then reviewed by AI, then AI isn't actually making anything better.
If you’re throwing the LLM at APIs you don’t know, how could you possibly verify it is using them properly?
Almost every day on this site for the past few months has been an instance of Mugatu's "I feel like I'm taking crazy pills!" moment.
Why do people think it means we can write enterprise applications without understanding the code/specifications?
The quip that “there’s nothing more permanent than a temporary solution” has been a truism of software engineering since long before AI arrived on the scene, vibe coding is just making the problem much worse.
Why automate the fun part and keep a human for the shitty part?
I don't really get the reasoning behind all the hype, or better said: I kinda do, but it's more of a knee jerk reaction or essentially FOMO.
What makes me think this is a bubble is the amount of emotion behind the decision making process (plus the fact that almost nobody is making a dime with this so far).
I don't find that this requires discipline. AI code simply requires code review the same as anything else. I don't feel the need to let AI code in unchecked in the same way I don't feel the need to go to my pull request page one day and gleefully hit approve and merge on all of them without checking anything.
When you’re trying to preserve features but fix bugs this information saves a lot of time and helps prevent regressions.
Once the business sees that the prototype more or less works, it's incredibly difficult to get them to spend money on a "sane" clean-sheet rewrite.
Dev: enables verbose/debug logging
App: encounters error, creating big log file
Dev: uploads entire logfile, containing secrets, to 3rd party LLM and asks "read this log and identify the problem"
meanwhile...
LLM: leaks prompt, logs, and secrets to hackers
LLM: uses prompt for training data, then provides secrets as responses to other users
There are 2 instances of the word "understand" in the first paragraph, 3 if you count the beginning of the second.
In my book, "understanding" is a synonym for "intelligence" - the roots of the word are "read between the lines", where something else that just knowledge is, the ability to use and manipulate knowledge [1].
But the thing is, despite this tech being classified as "artificial intelligence", it does not understand a thing - or so little.
So, if we extrapolate Betteridge's law of headlines, no it is not temporary for this type of technology. But I think connecting it with formal computations - inference engines for formal logic, calculators [2], etc. could be amazing.
[1] https://en.wiktionary.org/wiki/intelligence - well, yes, that's a bit cherry-picked.
[2] https://arxiv.org/abs/2406.03445 - amazing result, and maybe will find out that it is exactly what we do "under the skull", but doing arithmetic with Fourier transforms is not the best use of a microprocessor.
The paradox is that the better LLMs get, the more serious the bugs will be because the software will seem ok, only to blow up after people have developed a false sense of security.