Most teams don’t meet coding agents through some grand platform rollout. One engineer starts using them seriously, gets much better at it than everyone else, and eventually people notice they’re handing over chunks of work that everyone else is still doing interactively.
Usually, they aren’t using a secret model.
They’ve accumulated instructions that work, MCP connections, examples they trust, and a feel for which jobs are worth giving the agent in the first place. Give somebody else the same coding agent without that setup and the results can look quite different.
That gap says quite a lot about where coding agents become difficult in practice. Writing code is only part of it. The agent also has to find its way around an enterprise codebase with old architecture, internal tooling, half-current documentation and years of engineering decisions that were never made with agents in mind.
What is an AI coding agent?
An AI coding agent takes a software task and carries some of the work between the initial request and the result.
With a coding assistant, the developer normally keeps the session moving. You ask for a function, inspect what comes back, run it, bring the error to the model and decide what happens next.
An agent can take over more of that middle work. Give it a dependency upgrade and it might inspect where the package is used, change the version, run the build and then follow compatibility failures into other files without waiting for somebody to feed each error back into the conversation.
That still leaves plenty of room for people. A team might approve the plan before implementation starts, review the pull request afterwards and keep deployment entirely manual.
Fully autonomous software development is one possible end of the spectrum rather than a requirement.
How do AI coding agents work?
The underlying loop isn’t especially exotic. A model gets access to ordinary software-development tools, takes an action and uses the result to work out what to do next.
Go back to the dependency upgrade. The agent changes the package version and runs the build. The new release removed an API, so the build fails. It reads the failure, finds the affected call sites and updates them. Another test now breaks somewhere else.
The ticket never contained that sequence. Most software tickets don’t. Part of the agent’s job is filling in those intermediate steps as the consequences of its own changes appear.
None of this happens with the model alone. It still needs repository and file access, a shell, build tooling, tests and source control. Some workflows add a security scanner or an internal system exposed through MCP. A lot of that tooling is deliberately boring, and it should probably stay that way.
There’s little reason to ask a model whether code compiles when the compiler already has a much better answer.
The agent still has to decide what to do with those results. A test fails, a scanner returns a finding or the build complains about an API that no longer exists. Something has to interpret that information and choose the next action.
The repository can still point the agent in the wrong direction
Things get more chaotic once the question changes from “does this code work?” to "is this how we want software to be built here?”
We recently heard about this from enterprise architects who already had policies covering which frameworks and technologies engineers were allowed to use. Their coding agents didn’t necessarily have those policies, which meant an agent could choose a library that worked perfectly well while still moving the codebase in a direction the platform team had explicitly decided against.
The repository is usually the most obvious place to ground an agent, but repositories contain history as well as intent. Some of the patterns inside them are there precisely because nobody has finished migrating away from them yet.
Documentation has the same messiness. An old migration plan doesn’t disappear when the migration is abandoned, and a technically accurate architecture document may still be irrelevant to a package upgrade. Sometimes the most useful context is much narrower, like the package policy that tells the agent which dependency families the enterprise actually wants engineers to use.
The same principle applies to agent instructions since there’s little reason to load every internal guide into every task.
Orq.ai Skills initially expose only their names and descriptions, then load the full methodology and examples when a Skill becomes relevant to the work.
Good agent work isn’t necessarily small work
Vulnerability remediation is a useful example because quite a lot has already been decided before the agent starts.
A scanner has found something. There’s a concrete issue to investigate, a package or piece of code to remediate and a set of checks that can be run afterwards. The implementation might touch a surprising amount of code, but the destination is relatively well understood.
Compare that with a feature that looks tiny on paper. Perhaps the code change is small, but nobody has settled an important product behaviour or architecture decision. The agent has much more room to make an assumption nobody agreed to and then implement that assumption perfectly well.
So task size alone doesn’t tell you much.
The laptop is doing more work than you think
Run an agent on an engineer’s machine and quite a lot has already been solved without anybody thinking of it as infrastructure.
They’re authenticated, the repository exists, internal tools probably work, environment variables were configured at some point and the engineer may already know that one internal guide is three years out of date. Some of those details were set up months before anyone used a coding agent. Others exist only in the engineer’s head.
A background agent doesn’t inherit them automatically.
Some current coding-agent tooling makes that setup explicit.
For example, orq launch starts a coding agent with its model traffic routed through the workspace Gateway and temporarily gives the session access to the workspace’s MCP tools and Orq.ai Skills. Those pieces are removed again when the session ends rather than becoming permanent machine configuration.
At that point, something that looked mostly like a coding problem starts turning into an environment problem as well. A test repair may need little beyond the repository and build tooling. Another task may genuinely need staging access or an internal service. Giving every job one enormous environment solves the setup problem in a fairly crude way while also giving routine work access to things it never needed.
The setup itself also becomes something teams want to share.
We’ve seen a few engineers get much further with coding agents because they’ve built better Skills, MCP connections and working practices around them. Giving everybody access to the same agent doesn’t distribute any of that. As Orq.ai co-founder Sohrab Hosseini put it when we discussed the problem, “How do we distribute skills properly?”
Once those pieces are shared, they have to be maintained as well. Skills, examples and internal instructions get old. A stale wiki page might confuse one engineer once. Feed the same outdated material into a recurring workflow and the decision can start appearing across repository after repository.
Access gets tangled up in the same discussion. An agent fixing tests in one repository doesn’t need every permission held by the engineer who launched it. One repository might be writable while another only needs to be available as a reference. A credential may only need to exist while the task is running.
Keep the boring engineering
Some of the most useful parts of an agent workflow are the bits that don’t look particularly intelligent.
CI can report a broken build and a linter doesn’t need an agent to interpret every rule.
Agents also have a habit of exposing engineering rules that were never really written down. Maybe every senior engineer knows that an old internal package shouldn’t be used anymore, even though nothing actually prevents it. People learned that rule through reviews, conversations and years in the codebase.
The agent doesn’t inherit the folklore.
That can make repeated review comments unexpectedly useful. Sometimes the agent needs better context. Other times the team discovers that what looked like human judgment was actually a rule that could have been checked automatically all along.
Completion rate can be misleading
A task can reach “completed” while still being a bad trade.
That problem shows up in broader developer research too. Stack Overflow's 2025 Developer Survey found that 66% of respondents using AI tools cited solutions that were “almost right” as a frustration, while 45% said debugging AI-generated code could take longer.
The agent may have made repeated model calls, rebuilt the project several times and returned a pull request that an experienced engineer still had to untangle. A dashboard that records only success or failure doesn’t tell you much about whether the workflow actually saved engineering time.
Some of that picture can come from the coding-agent runtime itself. A session routed through the Orq.ai Gateway records which model served each call, along with token usage, cost and latency. That can help explain a run that became unexpectedly expensive or spent too long making model calls.
It still doesn’t tell you the whole engineering outcome.
A more useful view includes where people had to step in, whether the agent got stuck retrying the same approach, what it could see when the run went wrong and what happened when the pull request reached somebody who actually knew the codebase.
If engineers regularly rewrite the result in review, then the work was completed twice.
That’s quite different from a workflow where the agent fails early because it doesn’t have access to something it needs. Both may show up as poor performance, but they’re not the same engineering problem.
When individual setups stop scaling
Coding-agent adoption tends to begin with individual developers because that’s the easiest place to start. One person tunes some instructions. Somebody else builds a useful Skill. Another engineer connects the internal tool their agent keeps needing.
Eventually those setups become useful enough that other people want them, and the questions stop being purely about the coding agent. Somebody now has to decide where background jobs run, who maintains the context, how internal tooling follows the workflow rather than a particular developer and what access an agent gets while it’s working.
Software Factory infrastructure is one way enterprises are starting to deal with that shared layer. It doesn’t require throwing away the engineering stack that already exists either. A ticket can still start in Linear or Jira. The repository can stay in GitHub or GitLab, and existing CI can keep doing the work it already does.
What changes is the machinery around agent execution. Instead of every developer recreating the environment, context and access on their own machine, those things can become part of the workflow itself.
That also gives teams somewhere to improve the setup once rather than fixing it developer by developer. Update a Skill, tighten an access rule and the next run can inherit the change without everyone rebuilding the same environment themselves.
If your team is reaching that point with coding agents, book a demo to see how Orq.ai can help bring model access, context, tools and observability into a shared workflow.
