A lot of coding-agent experiments start on a developer laptop, which hides quite a bit of the setup. Git already works, the developer can reach internal services, and there might be a cloud CLI configured from six months ago and a couple of environment variables nobody would remember to recreate on a clean machine.
That’s fine while somebody is sitting there.
Move the same run elsewhere and those details become actual decisions. The run now needs its own identity and some boundary around what it can reach. If it needs a test environment, the company may already have a perfectly good platform for creating one. The agent just needs a way to use it without borrowing everything the developer can access.
Most enterprises are in a similar position with the rest of the stack. CI, deployment, repositories and internal tooling are already there.
DevOps, platform engineering and Software Factories aren’t three generations of the same thing
A dependency update can pass through all three without anybody needing to decide which one “owns” the work.
The ticket might be picked up by a Factory and worked on by an agent. The environment it uses could already come from the platform team. Once the PR is opened, the existing CI pipeline runs, and later on the usual deployment process takes over. Security may have rules around what the run can access, while the application team still knows that this particular dependency needs an extra staging check because it caused trouble once before.
All of that can happen in one piece of work, which is where the idea of DevOps first, platform engineering next and Software Factories after that starts to break down.
Existing DevOps practices and delivery systems still handle build, release and operations. The platform team may already own the environment the agent runs in. What’s new is that some of the work that used to happen on either side of those systems can now be handed to an agent.
DevOps | Platform engineering | Software Factory | |
What problem is it dealing with? | Shipping and operating software reliably | Repeated engineering work across teams | Giving agents responsibility for parts of software work |
Where does most automation happen? | Build, test, release, operations | Infrastructure and common engineering workflows | Before and around the PR: planning, implementation, testing, remediation |
Who is consuming it? | Engineering and operations teams | Mostly developers, increasingly agents | Agents with humans around the decisions that still need them |
What does the interface look like? | Pipelines and operating practices | Portals, APIs, CLIs, templates | Tasks, context, tools, execution environments, checkpoints |
What remains difficult to standardize? | Engineering judgment | Application-specific needs | Intent, architecture, risk and exceptions |
Sometimes the Factory’s part is only twenty minutes of implementation before the PR goes straight back into systems the company has been using for years.
CI/CD starts fairly late
Spotify says PR frequency is up 76% as AI coding-tool use has spread across engineering. That means more work is arriving at review, CI, and integration environments that haven’t suddenly become faster.
Some of the awkward cases won’t show up in CI at all. An engineer who has worked on an old service for years might look at a green PR and know there’s a reason they don’t make that particular change, even if the reason never became a test.
There’s quite a bit of work on the other side of CI as well. Before the pipeline sees anything, someone has already worked out what the ticket means, found the relevant service, changed the code and got it into a state worth testing. That’s where a Factory can take on more than a normal CI/CD setup does. Once it has produced the PR, though, we don’t see much value in rebuilding the rest of the path around it.
GitHub can stay where it is. So can the internal platform and whatever deployment setup teams already use. A lot of companies have spent years getting those systems into a decent state; adding coding agents is enough change without turning it into an excuse for an “open-heart surgery” rewrite of the engineering stack.
Platform engineering gets more interesting once the developer is no longer carrying the missing context
One enterprise architecture team had already standardized the frameworks and technologies engineers were supposed to use. The standards existed, people knew about them, and they were documented.
Then coding agents showed up and the technology sprawl got worse.
The agents weren’t consistently getting the same context engineers had been working with. Give one a task without the relevant skills or repository guidance and it can quite reasonably reach for a framework it knows well, even if the architecture team decided two years ago that nobody in the company should be starting new services with it. Writing the decision down again doesn’t really change that.
A framework that’s genuinely prohibited probably shouldn’t depend on the model remembering a sentence in a context file. Something peculiar to one repository doesn’t need to become a company-wide policy either. And then you get the much messier stuff that was never written down in the first place.
A team that has owned the same service for a few years will have plenty of that. One migration gets done in an odd order because doing it the obvious way caused an incident once. There’s an old dependency people avoid upgrading unless they have a reason.
Two bits of code look unnecessarily similar to anyone seeing the repository for the first time, but the duplication is deliberate. Nobody necessarily sits down and records these things because the people doing the work already know them.
An agent can read the code, the ticket and whatever documentation is available and still miss something the team would have picked up almost automatically.
LinkedIn has had to deal with the same problem at a much larger scale. Real engineering work there can touch thousands of microservices, internal frameworks, data infrastructure, observability systems and tools that don’t exist anywhere outside LinkedIn.
The company built a shared layer that exposes internal tooling and contextual playbooks to coding agents. More than 1,000 engineers were using it six months after launch, with over 500 playbooks created.
Company-wide procedures have an obvious central home, while instructions for one service can stay with the team that owns it. If a repository-specific skill gradually ends up copied into eight other repositories, somebody can decide later whether it has become a platform capability.
A developer portal hides another part of the problem. An engineer clicks Create environment and doesn’t care very much about the provisioning workflow underneath it. An agent doesn’t gain much from learning where that button is either.
What it needs is a way to call the thing behind the button with the right identity and without accidentally inheriting every permission available to the developer who started the task.
Developer laptops make this particularly easy to overlook since Git works because somebody authenticated it months ago and the cloud CLI is already configured.
There might be an environment variable sitting around from another piece of work that happens to make a test pass. None of that causes much friction when the engineer is there and can fix things as they come up.
Move the work into the background and you have to choose more of this deliberately: which credentials belong to the run, what network access it gets, what is installed in the environment and what survives when the run ends. Failures are also less mysterious when the setup can actually be reproduced somewhere other than one person’s machine.
We’ve taken a similar view with models and coding harnesses in Orq. Those are likely to change relatively often. A team might use one harness now and move to another later, another workload may have to use a model running inside the company’s own environment.
We don’t want a harness change to also mean rebuilding permissions, evaluations and the audit trail around the workflow.
The platform team probably shouldn’t own the whole factory
A payments team wants agents to handle dependency updates. The platform group can give those runs somewhere to execute, a controlled identity and a standard way into CI without knowing very much about payments.
One package might be upgraded every month and never cause trouble. Another sits close to payment authorization and has a history the platform team knows nothing about. The tests around the first could be excellent, while everybody on the payments team knows the second needs a staging check that never became part of the normal pipeline.
Environment provisioning is easy enough to put on the platform side. Things like that staging check are much harder to centralize, and you’ll probably find plenty of those cases once the workflows are actually running.
Production logs may be appropriate context for one workflow and unavailable to another. Changes touching authentication may stop before merge while routine maintenance can go further. If every product team has to wait for the platform group to understand its service before changing any of this, the platform group becomes the queue.
If the same failure keeps coming back every Tuesday, reviewing another bad PR eventually stops being the useful thing to do. The agent could be missing a tool, the architecture guidance may be too vague, or something important might never have made it into the environment the run is using.
When is this actually a Software Factory?
If an engineer gives a coding agent a task and stays with it the whole time, there usually isn’t much of an operational problem yet. They can answer questions, stop a bad approach, add missing context and decide when the result is good enough to hand over.
It looks different once a few jobs are running without that person sitting beside them.
One finishes normally. Another has spent two hours making small variations on the same broken approach. A third stopped because the ticket never made clear which service owned the behaviour it was supposed to change.
Orq’s existing Observability trace view provides this kind of run-level visibility, showing the agent, tool, retrieval and model activity inside an execution.
Teams start needing more than a collection of coding assistants. Review gets noisier as more work comes back, different teams end up with different setups, and security starts caring about what unattended runs can call. Local developer environments also become a poor place to hide all of that once the work is supposed to keep going in the background.
The first useful workflow may be much smaller than the whole SDLC. Work that comes back regularly and has a fairly obvious way to check the result is easier to hand over first. Vulnerability patching can fit that description, and some maintenance bugs can too.
Other work is a bad candidate even if an agent is capable of attempting it. A bug in an old service may still depend on somebody who remembers why a particular part of the system was built that way five years ago.
What actually changes?
A lot of the existing stack can keep doing what it already does. CI can still run the tests, the internal platform can still create environments, and deployment doesn’t suddenly become a different problem because an agent wrote the code.
What changes is everything the developer had been carrying implicitly around those systems. That might be service knowledge that only exists in someone’s head, credentials that happen to be configured on one laptop, a staging check everyone on the team knows about but nobody ever added to the pipeline, or an old dependency people have learned not to touch.
Those details are easy to leave informal when a developer is sitting in the middle of the workflow and can fill in the gaps as they appear. Once the work is running without them, more of that context has to become explicit somewhere.
If you’re working out how to make that shift without rebuilding the rest of your engineering stack, book a demo of Orq’s Software Factory and we can show you how the pieces fit together.
