A software factory delivers customer outcomes through software in an industrial manner: with repeatable processes, quality controls, and continuous improvement. Rolling out coding agents to engineers accelerates one part of that process. It does not settle how your organization ships and operates the software they produce.
When coding alone gets faster, the bottleneck moves downstream: more changes to verify, more vulnerabilities to remediate, more production failures to investigate, and growing AI coding costs to control. Autoheal lets your team build worker agents in the cloud that take on this work autonomously under policy, then turn what they learn into better skills for future runs, including coding. Engineers review and approve those improvements. That is what makes the factory self-improving.
Here are 4 reasons why a software factory needs more than coding agents.
1. Your agents need shared engineering context
A repository and a task prompt are a starting point. A compliance review worker agent also needs the applicable requirements and the application version being tested. An incident investigation worker agent needs service relationships, ownership, and recent changes.
Autoheal’s engineering context graph brings together services, architecture, ownership, SDLC history, skills, and memories, scoped to the project and run. Factory workers and coding agents need access to the knowledge relevant to their work without rediscovering it in every session.
2. The work has to run beyond a coding session
An incident is filed in ServiceNow. A CI pipeline runs. A Jira ticket is created. Each event triggers a factory worker agent in the cloud, without an engineer opening a chat and prompting every step.
That work needs a multiplayer execution environment that’s not tied to a single engineer’s laptop, credentials scoped only for the task at hand, and a way to survive interruptions. Autoheal’s cloud runtime provides isolated sandboxes and durable workflows in the customer’s cloud. Agent definitions live as code in git; agent runs can pause for approval and resume afterward.
Your team builds worker agents for its own needs, whether that is a legacy migration, a compliance review, or an investigation across home-grown systems. Each run consumes time and tokens before the desired accuracy is achieved, so the agent architecture needs to fit the task.
Our experiments in From tokenmaxxing to tokenoptimizing show why. A main-agent/sidekick architecture cut coding costs by 25% but took three times longer, a poor trade-off for interactive coding. On a benchmark of eight production incidents, our purpose-built incident-response harness using the same architecture and budget reminders achieved higher accuracy at one-third the cost and half the time of the most accurate solo frontier model configuration.
The above results show how important it is to tune worker agents for high-volume runs and measure accuracy, latency, and cost together.
3. Every action needs enforceable boundaries
An agent investigating an incident may need permission to read logs but require approval to increase the replica count of a Kubernetes workload. Writing that distinction in a prompt does not enforce it.
Autoheal’s security and governance layer checks tool requests against agent identity, credentials, scope, and policy. The tool gateway allows the request, asks for approval, or denies it, and records an audit trail.
Within those boundaries, workers act autonomously. Platform engineers decide which systems agents can access and which actions need a human decision.
4. Downstream failures must improve future coding
A merged PR does not tell you whether a coding agent did a good job. Code reviews, CI failures, and production incidents reveal problems the original session may never see. The factory needs to turn that evidence into changes the next coding agent can use.
In Using production outcomes to improve coding agents, we analyzed 30 days of our own engineering activity and generated six skills covering logging and testing. We evaluated them on 11 difficult tasks from our repository, with three attempts per task. The share of tasks passing all three attempts rose from 27% with existing context to 54% with the new skills, while cost and time barely changed.
The experiment also found that removing existing context improved consistency to 36%. More instructions are not automatically better; they need testing as models and codebases change. Even though this was a small internal benchmark, the method is concrete: rewind a repository to before a past PR, ask the agent to perform the task, and grade the result with deterministic tests. That makes a proposed skill change testable.
For example, a missed transitive dependency should improve both the vulnerability remediation procedure and the coding skill used when adding dependencies, with CI enforcement where possible. Fixing the patch alone leaves the next agent free to repeat the mistake.
Autoheal’s Evaluator examines both worker and coding agent sessions as well as downstream outcomes. The Healer proposes changes and checks them against historical benchmarks. Engineers review and approve updates in git.
Publishing the updated skill is only part of the job. The coding agents working on the next change have to load and use it.
What should you build, and what should you buy?
Your team builds and continuously refines the factory worker agents. Autoheal is responsible for the four infrastructure layers and their integrations. Your engineers still define scoped context, governance policies, and what counts as a good result.
You may already have CI/CD pipelines, isolated runners, and secrets management. Building on those investments can make sense if you have engineers to maintain the integrations, recover interrupted runs, and enhance the platform as tools and harnesses change. The reason to buy is to take that infrastructure work off their backlog.
Test the build vs buy decision with a workflow your team knows well and limited permissions. Compare the factory worker with your strongest engineer prompting a coding agent through the same task. Measure result quality, engineer time, elapsed time, and cost per successful task, including setup and maintenance alongside licensing, model, and cloud costs. Agree on when the agent should stop and ask for help.
Then trace one failure through a reviewed skill update. Check that both the factory worker and the coding agent use it on later runs, and whether it prevents the same mistake.
Our bet is that Autoheal gets you to dependable software delivery with less infrastructure to build and maintain.
