Very much agree on coverage. We're actually doing something in that area: https://codespeak.dev/blog/coverage-20260302

For now, it's only about test coverage of the code, but the spec coverage is coming too.

I think you guys are doing pretty much everything right.

When you translate spec to tests (if those are traditional unit tests or any automated tests that call the rest of the code), that fixes the API of the code, i.e. the code gets designed implicitly in the test generation step. Is this working well in your experience?

Yes it is passable.

Good enough that I don't review it.

Granted, it is a personal project that I care only to the point that I want it to work. There are no money on the line. Nothing professional.

I believe that part of the secret is that I force CC to run the whole est suites after it change ANY file. Using hooks.

It makes iteration slower because it kinda forces it to go from green to green. Or better from red to less red (since we start in red).

But overall I am definitely happy with the results.

Again, personal projects. Not really professional code.

Another trick that I use.

I force the code to be almost 100% dependency injection-able.

It simplifies a lot writing tests and getting the coverage. And I see the LLM being able to handle it very very well.