If LLMs are good enough to write code, they are good enough to write tests. In fact, they can be quite creative at finding test scenarios which exercise the code in unexpected ways.
The usefulness of testing is basically orthogonal to the advent of language models. This question boils down to whether you think the agents are "cheating" through changing the invariants encoded by the tests to something that no longer matches your project's requirements. To this, I would suggest that you read the code they produce, tests included, and not sign off on stupid changes to cheat on tests. This is not a common thing I've caught agents doing, FWIW.
Another option is to gate success behind a bunch of black-box tests that the agent has permission to execute but not read or write. You'd likely have to write those black-box tests yourself, though.
I'm implementing a similar process right now (calling it cleanroom for now):
Given a specification as a source of truth:
1. the lib agent can write lib code, but cannot look at test code.
2. the test agent can write test code, but cannot look at lib code.
3. the QA auditor can run tests and can look at lib and test code, but cannot modify either. It determines blame and then delivers feedback to lib or test agent in a way that doesn't reveal details about the code they are not allowed to look at.
You spend more tokens using this process (since multiple agents have to read the spec and similar files), BUT you get better results. The project is here:
Having written literally hundreds of unit tests in C++ and Python, my preference is to write them myself. You're in charge, not the LLMs.
If LLMs are good enough to write code, they are good enough to write tests. In fact, they can be quite creative at finding test scenarios which exercise the code in unexpected ways.
The usefulness of testing is basically orthogonal to the advent of language models. This question boils down to whether you think the agents are "cheating" through changing the invariants encoded by the tests to something that no longer matches your project's requirements. To this, I would suggest that you read the code they produce, tests included, and not sign off on stupid changes to cheat on tests. This is not a common thing I've caught agents doing, FWIW.
Another option is to gate success behind a bunch of black-box tests that the agent has permission to execute but not read or write. You'd likely have to write those black-box tests yourself, though.
I'm implementing a similar process right now (calling it cleanroom for now):
Given a specification as a source of truth:
1. the lib agent can write lib code, but cannot look at test code.
2. the test agent can write test code, but cannot look at lib code.
3. the QA auditor can run tests and can look at lib and test code, but cannot modify either. It determines blame and then delivers feedback to lib or test agent in a way that doesn't reveal details about the code they are not allowed to look at.
You spend more tokens using this process (since multiple agents have to read the spec and similar files), BUT you get better results. The project is here:
https://github.com/mcdirmid/cleanroom
I haven't formally released anything yet. I'm still benchmarking to show how and why it is better (and what the cost is).