That is quite unreliable. I would bet that your spec will be out of sync with the program behavior in no time.
The only thing that will work is to have non-llm generated tests. But writing those require thinking, which is what we are trying to avoid. Also capturing every little behavior in tests is exhausting. If you don't like programming, you would also hate writing tests. So chances are that a major part of the program behavior does not show up in tests.
So throw it away and rewrite from scratch is a just wishful thinking that the LLM marketing wants you to commit to...
Then you version and update the spec and when you commit you reference the diff in the -m
That is quite unreliable. I would bet that your spec will be out of sync with the program behavior in no time.
The only thing that will work is to have non-llm generated tests. But writing those require thinking, which is what we are trying to avoid. Also capturing every little behavior in tests is exhausting. If you don't like programming, you would also hate writing tests. So chances are that a major part of the program behavior does not show up in tests.
So throw it away and rewrite from scratch is a just wishful thinking that the LLM marketing wants you to commit to...
I’ve successfully done exactly what is described. You have to actually implement discipline yes. That’s the key hard part.
However provided you stick to the discipline, it’s robust e2e TDD’d versioned worked through CI and in production
You get out of all these tools what you put in
3 replies →