"Can't this development be cheaper if we use AI?"—we hear this question more and more after delivering estimates. It is a reasonable question. However, the answer is determined not by "whether the work can be delegated," but by "whether there is a safe place to run the delegated work."
A case study illustrating this difference clearly was recently made public. DoorDash operates an internal agent platform called Flux, which has agents processing 130,000 engineering tasks per month. It handles over 25,000 automated code reviews per week, over 10,000 "playbook" executions per week, and has over 300 types of playbooks registered.
The numbers are eye-catching, but what is instructive about this case is not its scale. A 30-person company cannot do the same thing, nor does it need to. What is valuable to learn from is what they prepared before operating at that scale.
Why move what was running on laptops outside?
Flux's starting point is explained as the limitations of running agents directly on developers' laptops. Three key issues were identified:
First, resource constraints. As long as they run on local machines, there are strict limits on how many can run concurrently and how long they can remain running.
Second, security. An agent running on a laptop inherits all the permissions held by that developer. If local credentials connect to a production database, the agent can reach it too.
Third, visibility. From the outside, it is impossible to see who is running what on their machine or which systems were touched.
These three problems arise regardless of company size. In fact, they are often more severe in smaller organizations where developers hold broader privileges and auditing mechanisms are leaner. The excuse of "we only have three people, so we're fine" does not hold.
Three core architectural components prepared
The architecture disclosed for Flux can be broken down into the following three elements:
1. Isolated runtime environments. Agents run inside isolated sandboxes powered by Firecracker microVMs. They established upfront the baseline assumption that whatever an agent executes, its impact cannot escape the sandbox.
2. Scoped entry and exit points. Access to internal systems routes through an MCP gateway. Rather than handing credentials directly to agents, the gateway determines which systems may be accessed and to what extent, while logging everything that passes through. They leverage the trend of MCP becoming the standard entry point for connecting internal systems directly as a control point.
3. Reusable procedures. What the figures of over 300 playbooks and over 10,000 invocations per week demonstrate is that instead of writing ad-hoc prompts every time, they repeatedly execute established procedures. Execution can be initiated from multiple entry points, including Slack, GitHub, and CLI.
Conditions required for "cheaper with AI" to hold true
Keeping all this in mind, we can answer the opening question as follows:
Agents excel at repetitive, standardized tasks. In DoorDash's published usage, the highest volumes are code reviews and playbook executions—neither of which involves "thinking from scratch every time." It is essential to align expectations early: this is not about making brand-new architecture designs or implementing features with undefined requirements cheaper.
Furthermore, whether it becomes cheaper depends on having the right runtime environment. Running agents without isolated environments, scoped access controls, or audit logs increases review and incident response overhead. It creates a dynamic where verification hours consume the engineering hours saved on implementation.
In custom development, this directly ties to contract terms. Choosing locally executed agents for projects where code cannot leave the premises is precisely one variation of deciding "how to provide the execution environment." Should you set up an isolated cloud environment, keep everything local, or is neither viable? There are three options, determined by project constraints.
Where small and medium-sized organizations should start
You do not need to build all three from day one. There is a proper sequence:
- Start with logging. Who ran which agent, against which repository, and when? Simply recording this drastically changes investigation times if an incident occurs. No dedicated platform is required.
- Next, scope down permissions. Separate the credentials provided to agents from the developer's personal credentials into dedicated, scoped ones. Check here whether production database write privileges have accidentally slipped in.
- Isolated environments can come last. Starting with containers or clean VMs is more than enough. This is not about building your own microVM infrastructure from scratch.
Reversing this order usually stalls progress. If you start with infrastructure development, it takes months to get running, while agents continue to run unchecked on laptops in the meantime.
What to do next
First, check which system credentials internal staff hold while running coding agents. If they hold local permissions that reach production environments, the agent has that access too. This is not a novel AI problem; it is simply an existing privilege management issue surfacing in a new form.
Next, list the tasks assigned to agents and categorize them by whether they follow the exact same procedure every time. If a significant number share the same procedure, those are prime candidates to standardize into playbooks. Standardizing stabilizes results and reduces review overhead. Conversely, if only unique, variable tasks emerge, your organization is not yet at the stage to invest in dedicated infrastructure.
At GleamHub, we offer development, AI, and automation consultations covering AI agent integration into workflows, execution environment and permission design, and scoping in-house versus outsourced work. The viable architecture depends on your current development setup and data confidentiality, so please reach out for personalized advice via our Contact Us page.
