An AI coding agent that can only run unit tests is guessing about the part of the system where most backend bugs are, in the database and the calls between services. A working database and queues to build against let it catch those bugs before a person sees the change, which matters because 45% of deployments carrying AI-generated code run into problems (our infrastructure playbook) and infrastructure code cannot be fully checked until it runs, in many teams first in production. That infrastructure has to be fast, isolated per agent, and safe.

Why mocks are not enough

Mocks only check that code calls an interface the way a test expects, so a change can pass every mocked test and still fail against a real database, on a unique constraint or a migration that runs in the wrong order. Models are weakest on infrastructure code, where the same GPT-4 that passes 86.6% of a standard Python benchmark passes only 19.4% of the infrastructure equivalent (IaC-Eval, via our infrastructure playbook). Mocks push all of that downstream to production, where it costs the most to find, since agents produce more changes than a person will read closely.

The options

Pointing agents at a shared staging environment gives them working infrastructure but brings back the collision problem, where agents overwrite each other's data and migrations and a broken change from one blocks the others, so it does not scale past a couple of agents. Running the dependencies in containers per agent, with docker-compose or similar, isolates better but leaves you maintaining the container setup by hand and keeping it in step with production, and it tends to stop at the datastore and skip things like real message delivery, so the agent still tests against a partial system.

Declaring the infrastructure in the application code avoids both problems, since the factory can then create a fresh, isolated set of it for each agent, so the database and queues come up automatically per environment, match what production will provision, and are torn down when the task finishes. Encore's infrastructure SDK works this way, which keeps agent infrastructure practical instead of a setup you maintain by hand.

Isolation matters as much as the infrastructure

Working infrastructure only helps if each agent has its own, since shared infrastructure has the same collision problems as shared staging. With its own database and queues, created for the task, an agent can run migrations and exercise message delivery without affecting anyone else, and adding another agent then means creating another environment rather than contending for a shared one, which is how the count of parallel agents scales. Those same environments become where changes are validated, so a reviewer exercises the feature in the environment the agent used and checks traces when something looks wrong, and the work you put into building this infrastructure serves the review step too.

The quickest way to see the difference is to give one agent a working database and queue to build against and watch it catch a bug a mock would let through, which Encore's docs cover setting up. For the wider picture, see what is an AI software factory, and for how validated changes reach production, how to let agents deploy safely to AWS or GCP.