> 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…
Vibe Debugging: Enterprises' Up and Coming Nightmare
11–20 of 69 posts
Re: Vibe Debugging: Enterprises' Up and Coming Nightmare
#12Re: 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…
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
#14Wasn’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?
Re: Vibe Debugging: Enterprises' Up and Coming Nightmare
#15The 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> 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.
Re: Vibe Debugging: Enterprises' Up and Coming Nightmare
#17Throwaway prototypes have their uses. Go ahead and vibe-code the throwaway prototype.
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.
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.
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…
The former is desirable, not common. The latter is common, not desirable.