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!"_

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

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.

The dirty secret of a huge amount of "production code", i.e. code that is in production right now servicing enterprise needs, is that it's written with the care and understanding of typical throwaway code. It's not a new problem. Ball of mud architectures are everywhere, prototypes becoming permanent are common, understanding is low (especially if the original author has left or switched teams), but teams muddle through with the super powers of being able to ship ongoing patch fixes, code review, automated testing, and sometimes even writing code with professional care and forming little oases of quality.

I'm mildly optimistic that vibe coding won't make the problems that much worse and can actually lift the standards of quality in some cases. In my own personal careless / throwaway bash scripts, I've been using AI for them more and more, but I also notice that it puts more care into them than I otherwise would have with respect to things like error checking, friendlier help and other options, progress echos, and comments. AI tools still have a ways to go on larger projects though, and hallucinations seem particularly bad when it comes to foreign library bindings...

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.

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.

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

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.

Sure. But, and I will die on this hill, it's not vibe coding if you're looking at and understanding the code.

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.

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.

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.

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.

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

TDD works if know what 100% of the inputs/outputs look like, AND you know the implementation will be complex, terse, whatever. Write tests, then twiddle a bunch of regex until the tests pass. This situation rarely comes up in real software jobs, but when it does, yeah use it!

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/

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.

There’s nothing more permanent than a throwaway prototype.

queue the South Park "They took meh jeb!"

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.

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.

The underlying model architectures have issues that perpetuate as models get better. We're still using transformers and RL.

  * Optimized for task completion, with limited attention resources for global alignment (RL/RLAIF reward loops/hacking)
  * These systems run outside of chat now.  file systems, CLIs, DBs, browsers → real-world side‑effects that you cannot train for. Hallucination becomes a problem of contradiction in the real world, and alignment is something an agent will struggle with as it's optimized to complete tasks. Which is why you see things like databases being dropped today. 
  * These are baked-in problems, not even considering the the adversarial nuances of things like prompt injection.

As AI advances, so do these issues.

Maybe it's cliche from an AI safety perspective. But I can never get over https://en.wikipedia.org/wiki/Instrumental_convergence as we see micro instances of it in our day-to-day with today's agents. Again, an issue that has existed from the dawn of these types of models. https://www.youtube.com/watch?v=s5qqjyGiBdc&t=1853s