Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe Debugging: Enterprises' Up and Coming Nightmare

marketsaintefficient.substack.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#51

Post by rnxrx »

There's a point in the article that mentions allowing the model to ask questions. I've found this to be especially helpful in avoiding the bad or incomplete assumptions that so often lead to lousy code and debugging.

The (occasionally) surprising part is that there are times where the generated clarifying questions actually spawn questions of my own. Making the process more interactive is sort of like a pseudo rubber duckie process: forcing yourself to specifically articulate ideas serves to solidify and improve them.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#52

Post by justonceokay »

itsdrewmiller wrote: post #9

> 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 always love to compare Peter Norvig’s sudoku solver implementation [1] versus Ron Jeffries TDD approach [2].

Norvig starts with the theory building and creates a constraint solver in about 50 lines of code. Jeffries starts with TDD, assumes an implementation, has to change that implementation, therefore has to change the tests, and after a series of five blog posts kind of fizzles out on it.

To me it just highlights that defining the problem is with so much more than defining the tests, as you can’t write a test for a problem you haven’t defined yet. In this way the tests are an imposition. In short to me it shows that TDD only really works if you already knew how to buold the project to begin with.

[1] https://norvig.com/sudoku.html [2] https://ronjeffries.com/xprog/articles/oksudoku/

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#53

Post by incone123 »

reactordev wrote: post #24
manoDev wrote: post #22

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

queue the South Park "They took meh jeb!"

'cue'

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#54

Post by tovej »

manoDev wrote: post #22

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

While this may help VCs get richer, this is definitely putting software quality and software safety at risk.

If an AI-boosted startup makes it, the tech debt inside the company will be worse than in a "traditional" one. That seems like a net negative for society in the long run.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#55

Post by jayd16 »

bsoles wrote: post #44
itsdrewmiller wrote: post #9

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

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.

I guess you could say TDD is the waterfall of coding styles.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#56

Post by skipkey »

AstroBen wrote: post #45
dogleash wrote: post #31

Earlier quoted context omitted.

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.

TDD is really commonly misunderstood to be a testing strategy that helps reliability- it's not. It's supposed to guide your software design

But that’s just it-as a design aid it can really go off the rails, but as a testing strategy it’s really useful in one domain. Defect fixing. If I can convince a junior engineer that when he gets a bug report to first write a test that shows the problem and then fix it, using the test to prove it’s fixed, it provides immense benefits.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#57

Post by rootnod3 »

MoreQARespect wrote: post #20
rootnod3 wrote: post #19

Earlier quoted context omitted.

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.

And with LLMs you'd have to measure how close the prompt is to a user story then. And how close its output is to the user story.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#58

Post by dogleash »

skipkey wrote: post #56
AstroBen wrote: post #45

Earlier quoted context omitted.

TDD is really commonly misunderstood to be a testing strategy that helps reliability- it's not. It's supposed to guide your software design

But that’s just it-as a design aid it can really go off the rails, but as a testing strategy it’s really useful in one domain. Defect fixing. If I can convince a junior engineer that when he gets a bug report to first write a test that shows the problem and then fix it, using the test to prove it’s fixed, it provides immense benefits.

> If I can convince a junior engineer that when he gets a bug report to first write a test that shows the problem and then fix it, using the test to prove it’s fixed, it provides immense benefits.

That's just writing a regression test and making sure it catches the regression. What does that have to do with TDD? Does the philosophy of TDD lay claim to any test written before the bugfix, regardless of how much or little someone subscribes to TDD overall?

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#59

Post by gotoeleven »

chickenzzzzu wrote: post #21
RandallBrown wrote: post #18

Earlier quoted context omitted.

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.

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.

[flagged]

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#60

Post by 0x696C6961 »

chickenzzzzu wrote: post #21
RandallBrown wrote: post #18

Earlier quoted context omitted.

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.

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.

Try working on a project with lots of contributors.
Post reply on HN