Live data from Hacker News

Vibe Debugging: Enterprises' Up and Coming Nightmare

marketsaintefficient.substack.com

11–20 of 69 posts

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#11

> 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 futur…

AI search makes me personally way more productive, e.g.: write snippet how to do X using library Y I never touched before.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#13

> 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 futur…

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.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#14

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?

Let's see how many forget how to write and think through their own code while primarily vibe coding.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#15
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.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#16
post #10

> 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.

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.

Two bad tastes that taste bad together.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#17
post #12

Throwaway prototypes have their uses. Go ahead and vibe-code the throwaway prototype.

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.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#18

> 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.

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.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#19

> 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.

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.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#20

> 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.

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 p…

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.

Post reply on HN