TDD fizzled because not enough emphasis was put on writing high level tests which matched user stories and too much emphasis was put on it as a tool of design.

"Extreme programming" methodology said you should not do TDD if you don't already know how to implement the code. In that case you should instead experiment until you know, and then throw away the experiments and write the code test-first.

Maybe it should be done that way with AI: experiment with AI if you need to, then write a plan with AI, then let the AI do the implementation.

Yeah, your colleagues opinion is kinda inline with how it was usually pitched - at least around 2010 when I learned about it to a degree that it wasn't just a fuzzy concept to me.

One of the goals I remember was to think from the outside to the inside: you first create a test which asserts your most outter API as a unit test with inputs as you want to use it.

Now you keep adding functionality until it passes, creating new tests whenever you make a new boundary/function/API

This supposedly makes it easier to design it well, because you don't have to keep everything in scope and instead only tackle one layer at a time - like an onion from the outside to the core. And you always design the APIs as they make sense, not as is technically easiest because you can just define it however you want, and then think about implementing it.

E.g. https://www.infoq.com/presentations/tdd-ten-years-later/

Mmmm… read the book on Extreme Programming.

The idea is that you let the code drive the system and do not optimize prematurely. Sometimes developers design parts that are not needed, and often not in the first phase.

It is a way to evolve a system unbiased. Of course there is a trade-off. If the refactoring/change is very expensive, like a database schema change in production, it is good to spent a lot of upfront design. Takes experience to see where you can relax and where you need to be careful.

Most people do not spend thousands of hours building something "not knowing what they're building."

On the contrary, in my experience it's much more important to "play" with a concept and see it working. Too many engineers think they're going to architect a perfect solution without ever getting code on the page.

A slapdash prototype is worth the weight of 100 tests and arch diagrams.

Note: I'm not saying the latter is not important. My comment is, it's ok (and encouraged) to do potentially throwaway work to understand the domain better.

Do you mean people that build something without a plan? Some people have an idea (or vision) but not a plan and they figure things out along the way. Other want to / need to plan everything ahead of time first.

In my anecdotal case: I behave like the former in some cases (crafting) and the latter in others (travel planning)

I wouldn't say one way is always better than the other.

This is what Naur, 1985, Programming as Theory Building is about!

https://pages.cs.wisc.edu/~remzi/Naur.pdf

The act of programming is building the theory of what the program does, so that you acquire new knowledge of doing things. It's not just text production.

>"[...] not any particular knowledge of facts, but the ability to do certain things, such as to make and appreciate jokes, to talk grammatically, or to fish."

Which is why re-building a program from scratch is so tempting: you've figured out the theory as you went along, now you can build the real thing.

>they're jsut regurgitating other designs from their training data

I'm deep into the crank/lone genius territory with my BitGrid project, doing things with code that nobody else would be silly enough to waste time on. If it's just copy/pasting code from some latent space, I have no idea where it's getting it.

When's the last time you wrote code to directly handle all the bits to multiply two floating point numbers? I've never done it.