Coding agents can now finish a task and open a pull request with little supervision, and teams have started running several of them at once. Writing the code has stopped being the hard part, and the work has moved to everything after it: confirming that a change actually works, and getting it into production without someone hand-writing cloud configuration for every change. AI-authored pull requests already wait 4.6 times longer for a first review (LinearB, across 8.1 million pull requests), and 45% of deployments carrying AI-generated code run into problems (our infrastructure playbook).

An AI software factory takes a task, gives an agent an isolated place to build it with the databases and queues the change needs, lets you confirm the result in a running environment, and provisions and deploys the change to your own cloud, working as the machinery around the coding agent that carries generated code to something a team can ship without reading every line. Without it, agents get bolted onto the tooling a team already has, and the failures show up further down the line.

What one task looks like

A team wants users to be able to save items to a wishlist, so an engineer files a ticket, an agent picks it up, and it starts working in an environment of its own. Alongside the endpoint, the feature needs somewhere to store wishlists and an event to fire when an item is added, so the agent declares both in the application code:

import { SQLDatabase } from "encore.dev/storage/sqldb";
import { Topic } from "encore.dev/pubsub";

const wishlists = new SQLDatabase("wishlists", { migrations: "./migrations" });

export const itemAdded = new Topic<ItemAdded>("wishlist-item-added", {
  deliveryGuarantee: "at-least-once",
});

The factory reads those declarations and brings up a Postgres database and the topic inside the agent's environment, so the agent can run its migration, call the endpoint, and watch the row persist and the event publish while it works. By the time it opens a pull request, the change already has a running environment attached. A reviewer opens the URL, adds an item, and sees it save; if anything looks off, the trace shows the request path and the published event. They merge on the strength of having seen it work, not on having read a thousand lines. Merging provisions the same database and topic into the team's own AWS or GCP account and rolls the change out, and the person in the loop spent a few minutes confirming behavior instead of an hour reading a diff.

What a factory adds around the agent

The wishlist agent ran in an environment of its own, which a factory gives each agent so twenty can run at once without a migration from one breaking another's test run, and the parallelism that makes agents worth running falls apart without that isolation. In that environment the agent built against a Postgres database and a working event stream instead of mocks, catching the bugs that live in the database and the calls between services that unit tests leave untouched, and this matters most for 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).

The reviewer then confirmed the feature in a running environment with traces instead of reading the diff, which keeps agents from shifting the pile-up from writing code to reviewing it, and when the change merged its cloud configuration came out of static analysis of the code the same way every time, inside limits the platform team had set once, so nothing reached production on an IAM policy an agent improvised.

What this changes for the team

For the people involved, the day moves from writing code to specifying and confirming it. Engineers spend more of their time on clear tickets and on reviewing behavior, several agents work through the backlog at once instead of one change moving down a single branch, and a review becomes a matter of opening a running environment, checking the feature does what the ticket asked, and merging. The platform team sets the guardrails once and stops being pulled into every change, so work that used to bottleneck on a few people spreads across as many agents as the backlog needs. A backend team that gets there spends less of its week on the wiring between services and the plumbing of each environment, and more of it on what the product should actually do. How engineering teams work in an AI software factory goes through the day-to-day in depth.

Running many agents at once does not mean handing them production, because an agent proposes and builds a change while a person still opens the environment, confirms the feature works, and merges, so nothing ships without a human approving it. The agent does not write the cloud configuration either; it comes out of static analysis of the code the same way every time, within the permissions and deployment policy the platform team set, so whatever autonomy an agent has is bounded by rules a person wrote and can change at any point.

Where Encore fits, and when it is worth it

You can use any coding agent; Encore does not replace it or integrate with it directly, and sits underneath as the layer that ran everything else in that walk-through: it declares infrastructure in code through its open-source SDK, gives each change a preview environment with the databases and queues it needs, validates it in a running environment with tracing, and provisions into your own cloud under central guardrails. The SDK is open source and the declarations live in your own repository, the resources are provisioned into your own account, and it runs alongside Terraform, so a team adopts it one service at a time and keeps the VPCs, clusters, and databases it already runs.

None of that is worth setting up for a team running one agent now and then, or one whose changes rarely touch a database or a queue, where a preview environment and the pipeline you already have will cover you. A factory pays off once agents are producing more changes than the team can comfortably review, or once standing up infrastructure for each experiment is the thing slowing the agents down.

Getting started

The smallest way to try it is to onboard one service by declaring its infrastructure in code and let an agent build a change against it, which Encore's docs walk through. For the full build-out, see how to build an AI software factory, and for how the pieces fit together, AI software factory architecture; best AI software factory platforms covers the wider landscape, and AI software factory vs CI/CD covers how it relates to the pipeline you already run.