Software teams typically plan around the people available to do the work.
If the engineer who knows a service is busy, the ticket waits. And If maintenance keeps losing to feature work, it rolls into the next sprint.
Hiring another engineer doesn't help much this week.
Coding agents make that last assumption less reliable.
In a Software Factory, coding agents sit inside a wider workflow for planning and returning work to the engineering team.
Coding assistants didn't change who carried the ticket
The gap between engineers using the same coding tools is larger than you’d expect.
Some know which architecture docs Claude needs and when a run is going somewhere unhelpful.
Someone else can use the same model and get little more than a faster way to write the code they would have written themselves.
We’ve seen the same problem in enterprises rolling coding agents out across engineering teams.
A few people get very good at them while the rest don't necessarily pick up the same practices.
And the work is still attached to the developer.
The developer still carries the workflow:
Investigate the ticket
Check the output
Correct it
Run the next step
If they aren't available, the work still waits.
Give the factory a vulnerability patch
A vulnerability scanner raises an issue. The dependency is known. The repository has tests.
The team has patched this sort of thing before. That's a much easier piece of work to hand over than “redesign authentication.”
The invocation itself can be straightforward. An Orq agent can be given a task through the API and execute it with its configured tools and context.
curl -X POST https://api.orq.ai/v3/router/responses \ |
Illustrative agent key and task. The request format follows Orq.ai’s Agents API.
The API call only starts the run.
For the factory to actually complete the patch, the agent still needs the repository, the right tools and context, and somewhere to run the tests.
The factory can pick up the patch, inspect the repository, and run the tests while an engineer is somewhere else.
Perhaps a pull request is waiting when they return.
Or it isn't.
The repository has a build step nobody documented.
One of the tests doesn't run in the environment the factory has. The apparently simple dependency change touches something unexpected.
Now an engineer comes back in.
A factory can plug into the issue trackers and repositories engineering teams already use: work can arrive through Linear or GitHub Issues and return as a pull request instead of forcing the team into a second development workflow.
Several pieces of work can be in flight this way. One run is implementing and another has stopped. That changes the allocation question too.
Not just which engineer has capacity, but whether this is work the factory already knows how to execute. The limit shows up with work that wasn't ready in the first place.
Say the ticket asks for a new API, but the team hasn't agreed on the interface.
Giving the task to three agents doesn't exactly help and you’ve just ended up with three implementations of an unresolved design decision.
Meta ran into this at scale. AI-assisted code changes rose 220% while user-facing improvements increased by only 36%, with more incidents and engineering time spent firefighting.
The pull request queue may be the first warning
Say implementation gets much faster.
Review doesn’t.
That’s already showing up in agentic development.
Atlassian analyzed 3,400 repositories and found that repositories adopting Rovo Dev merged 19% more pull requests per month than comparable repositories.
More implementation throughput means the rest of the delivery system has to absorb more work too.
The team starts getting more pull requests than its experienced reviewers can comfortably handle. A shared test environment becomes busy. Some changes come back because the ticket left out an acceptance criterion that everybody assumed was obvious.
We'd look at the time around the run rather than celebrating the number of runs completed.
GitHub’s enterprise-developer research found that developers were already spending about as much time waiting for builds and tests as writing new code. Faster implementation makes the next bottleneck easier to see, but it won’t remove that time entirely.
Then there are failures that repeat.
Take a small frontend change that keeps failing because the repository uses a test command the factory doesn't know about.
An engineer fixes the pull request.
The next similar change does exactly the same thing.
Fixing another PR is probably the wrong job now.
Change the instructions, give the factory the missing context, or fix whatever part of the workflow keeps producing the error.
When the same failure keeps returning, the setup needs attention too: different skills, tools, architecture context, or something else.
Look at the run budget first
Rather than asking how close we are to “autonomous development,” start with a simpler breakdown of where engineering time goes.
Think about vulnerability patching, straightforward bugs, nastier bugs that need experienced engineers and the frontend work that keeps coming back every week.
The buckets are the point.
Maybe patching is ready for the factory. Maybe easy bugs are next.
Leave the nasty ones alone for now.
A significant share of enterprise engineering capacity can disappear into keeping existing systems running. McKinsey describes one bank where nearly two-thirds of developer time was spent maintaining and managing dependencies across three complex core systems.
Enterprises traditionally split IT spending between change and run: building new systems versus keeping existing ones operating.
If the factory takes some of that repetitive work, you don't need a story about replacing the engineering department to get something useful out of it.
If the factory takes some of that repetitive work, its value doesn’t depend on replacing the engineering department. Engineers can spend less time carrying routine tickets and more time deciding how software should be composed along with what context the factory needs.
A dependency patch that used to need an experienced engineer every week may no longer need one.
The migration still does.
See how Orq.ai is building Software Factories for enterprise engineering teams.
