Many people write that the “bottleneck” in agent‑based development is the people who review the code. I believe this is more of a marketing statement than an engineering one. A person can perform code reviews quite quickly. Certainly faster than the code goes through the CI/CD pipeline and is deployed to the staging environment. As automation increases, the human code review process boils down to:
running one’s eyes over non‑obvious places in the code whose verification has not yet been automated,
check how the automation of deterministic development rule checks worked.
It takes me no more than 5-15 minutes per pull request. I see the “bottleneck” in a completely different place.
Now agents are writing code very quickly. This speeds up development.
They also write tests quickly and in large numbers. Tests are good — they fix contracts, ensure compliance with development rules, and confirm that the code does what we need it to do. We make agents test the code, and they do it easily and quickly. We rejoice: the amount of code is growing, the system is becoming larger, and it doesn’t lose its reliability.
It would seem that nothing can go wrong. But it can and definitely will go wrong.
There are too many tests. Over the course of a couple of years of my project’s existence, the software engineers have written about 3,000 tests. Half of them were written by me over the course of a year. I did a lot of refactoring (I put the application in order), updated library versions with broken backward compatibility, and needed a lot of tests as a guarantee that I hadn’t broken the application’s functionality.
Then spring 2026 came, and the agents got to work. The number of tests increased from 3,000 to 7,200 between March and November. Complex integration tests became almost free for us, and we ended up with a very large number of them.
The tests started consuming too many resources. The test bench encountered: OOMError, memory exhaustion in the database, exhaustion of lock and database connection limits. And the more tests we had, the slower they ran. If in spring a full test run took 10–15 minutes, in autumn it slowed down to 45 minutes.
The faster the agents wrote code and tests, the slower they started writing code — due to the need to run tests 3–5 times per task, the task completion time increased from 30–60 minutes in spring to 1–4 hours in autumn. In a year, there will be many times more tests, and it’s already clear that task completion will slow down significantly.
We had to think about how to reduce the time spent on tests without losing the point of having tests. After all, the simplest way not to waste time on tests is not to run them. But then what’s the point of them?
You can try the following ways to speed up the tests:
- Prohibit the agent from testing obvious things. I call such tests pointless. These include tests:
of the fact that migration scripts have been applied,
of the fact that a new value has been added to an enum,
of the fact that the list of dependencies in the project has been changed,
etc.
- Prohibit the agent from writing duplicate tests.
Duplicate tests do the same thing. But the first test checks the createdAt field, while the second checks the createdBy field of the same structure (object, table). Such checks should be combined into a single test. If you look for it, you can easily find a test audit skill that you can add to your agent as a separate skill and, as a rule, for writing tests and performing code reviews.
Raise the context of your application only once for all tests. There are many articles about this, for different frameworks — it won’t be difficult to figure it out.
Use the database on the host for tests, not in the test containers.
We save: on Docker memory (relevant for Macs), on the time it takes to start the test containers, and on the time spent recreating the database schema from scratch for each test.
We lose: the certainty that the project will be able to start on a clean database at any time. It’s also inconvenient if the database schema differs in different git branches — when switching between branches, you’ll need to prepare the database for tests manually or write complex automation for this.
Deploy the database schema only once for all tests.
In tests, clean the database not via [delete from ...], but by rolling back the transaction. The transaction starts before the test, and after the test, it’s rolled back. This takes 3–4 milliseconds (almost for free). But it doesn’t work for all test frameworks. The code under test may perform its transactions on a different database connection. In this case, the transaction started by the test won’t roll back the changes made to the database by the code under test. Also, this doesn’t work well with parallel test execution and mutual lock tests.
Disable triggers before clearing the tables in the test database. For me, this reduced the time required to run all tests by 15 minutes.
When writing code, run only those tests that check the code affected by the task.
Running 10–20 integration tests instead of 7,200 takes the agent 3–5 minutes.
- In the pipeline, tests can be sped up by playing around with the CPU core power‑saving mode.
Good luck, and remember: the faster the tests run, the faster the development progresses.
Top comments (0)