upvote
> My concern with TDD is that writing tests necessarily implies designing an API upon which those tests operate

It really forces you to do outside-in testing; I usually describe the kind of API I want when chatting with the agents. For example, the CLI options, the routes that might be useful for an API, etc.

> I look at the code and find a rats nest / ball of mud that will cost 10x more tokens to enhance should I ever need to add a feature.

Agreed, I don't know if there are good forcing functions to avoid complexity. The providers have a huge incentive to have you waste your tokens (for example when it re-outputs the complete file when you ask for a tiny change).

reply
In "proper" TDD you you supposed go:

- write a test for method that does not exist, it just calls the method and nothing else

- write method that does nothing

- add/extend test that uses that method <-- this very loop starts

- modify method until tests passes

- go back to loop start until you're done

I always hated it. When I work with LLM i first massage interface that tests, then tests, then implementation until all these tests pass.

> for example when it re-outputs the complete file when you ask for a tiny change).

well with sonnet 3.5 and 4.5 (can't say about 4.6) it often will get stuck in a loop trying to update just the required parts and iether waste tons of tokens doing these updates or waste tons of tokens to a point where restring file from git is required. Tokens get wasted regardless.

reply
I like tests, but I don't bother with TDD because it's so ceremonial. I design the API, or at least sketch it out (using a whiteboard or drafting some notes, and doing research). Then I iterate and refine. I only bother with tests once I can commit or when it's no longer viable to tests manually (edit-compile-run cycle). And a lot of time I follow the table pattern.

https://www.oreilly.com/library/view/simplicity/979888865170...

reply
“Test Driven Design” is another way to frame it.
reply
I see what you're saying. Modularity and interfaces are really important between the different aspects of what's being developed. And it is worth putting time into the question "if another will use this, what would they potentially use it for, and why?". It doesn't mean that it needs to be built now - but considering that and ensuring that the planned code executes against that is a good strategy.
reply