[siscia]

What I found more useful is an extra step. Spec to tests, and then red tests to code and green tests.

LLMs works on both translation steps. But you end up with an healthy amount of tests.

I tagged each tests with the id of the spec so I do get spec to test coverage as well.

Beside standard code coverage given by the tests.

[abreslav]

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.

[siscia]

I think you guys are doing pretty much everything right.

[abreslav]

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?

[siscia]

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.

[siscia]

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.