From AI copilot to background agent: why 'spec to pull request' is primarily a workflow problem
The promise shifts from autocomplete to autonomous work
AI coding started for many teams as faster autocomplete: a suggestion in the editor, a function in a chat window, or a refactor that still required heavy guidance. That remains useful, but it is not the biggest shift. The next step is the background coding agent: a system that not only proposes a piece of code, but picks up a well-defined task, opens the repository, gathers context, runs tests, and prepares a pull request.
That sounds as though it is primarily a model problem: wait for a smarter model and everything else will sort itself out. In practice, that is too simplistic. The bottleneck is often not one extra clever prompt, but the environment in which the agent has to work. A messy repo, missing documentation, implicit conventions, local dependencies, and unclear acceptance criteria make even a capable agent uncertain. The result is then not a productive speed-up, but extra review work.
That is why the better question is not: which AI tool writes the most code? The better question is: how do you make your engineering process suitable for work that can be prepared by an agent and reviewed by humans?
What makes a background agent different from a copilot
A copilot typically works alongside the developer. The human holds the task, sets the direction, and decides what happens at each step. A background agent works more like a temporary junior executor within a strict framework. You give an assignment, the agent explores the codebase, modifies files, runs checks, and returns a proposal. Ideally that proposal is not loose code in a chat, but a pull request that fits into the normal review process.
This changes the form of collaboration. The developer less often writes instructions line by line and more often writes a compact work order with context, constraints, and acceptance criteria. That requires a different discipline. A vague instruction like 'make this better' is rarely enough. A good instruction describes which problem needs to be solved, which files or modules are relevant, which tests are affected, which style rules apply, and when the result is acceptable.
The value therefore lies not only in code generation. The value lies in converting recurring engineering tasks into small, controllable workflows. Think of straightforward bug fixes, test extensions, dependency updates, documentation corrections, minor UI adjustments, or preparatory refactors. Those are exactly the tasks that cost teams many context switches, yet are often well-defined enough to be scoped clearly.
Context engineering becomes the new bottleneck
For background agents, context is not a side issue. Context is the working material. An agent needs to know how the project is structured, which conventions the team uses, how the application runs locally, which tests matter, which parts are sensitive, and which decisions have already been made. Without that information the agent will guess. And guessing in a production repository is expensive.
Context engineering means making that information structurally available rather than trying to cram it into a prompt each time. This can be done through repo documentation, task templates, architecture decision records, test instructions, code owners, example PRs, setup scripts, and fixed descriptions of domain rules. The goal is not more text, but better discoverability of the right information at the right moment.
A practical starting point is an agent instruction file per repository. In it you record how the app is started, which commands are safe, which tests must at minimum be run, which directories should be avoided, and how a pull request should be described. Then add task types: 'bug fix', 'add test', 'update copy', 'verify API contract'. The clearer the task shape, the smaller the chance that the agent will work outside the intended scope.
Repo setup is less boring than it sounds
Many teams underestimate repo setup because developers already know the local quirks by heart. One service needs to start first, another requires a specific version, a third needs a seed script or a local configuration that is nowhere fully documented. For a human that is annoying but manageable. For a background agent it is a hard blocker.
Docker or a similar container setup helps, but is not automatically sufficient. Some projects require multiple services, browser-dependent tests, specific system packages, private dependencies, or a pre-configured machine state. In those cases a reproducible development environment matters more than the choice of agent. If the environment does not start reliably, the agent cannot deliver reliable work.
Teams that are serious about spec-to-PR workflows would do well to treat setup as production work. Make a clean installation repeatable. Document which commands are needed. Ensure that test data is safely and predictably available. Automate wherever possible. An agent-ready repo is often also a developer-ready repo: new team members get up to speed faster, CI becomes more stable, and hidden knowledge disappears from individual laptops.
Security: give agents fewer permissions than humans
A background agent needs access to be useful, but unrestricted access is a poor starting point. As soon as an agent can use repositories, issue trackers, chat channels, CI pipelines, or internal tools, you need to think about permissions. Not because every agent is dangerous, but because automation can make mistakes at scale.
The foundation is scoped access: grant only the permissions required for the task type. An agent writing tests does not need access to production secrets. An agent updating documentation does not need deploy rights. Secrets must be limited, temporary, and auditable. Also log which actions the agent performs, which files were modified, and which commands were run.
Human review also remains essential. A pull request from an agent should not automatically be treated as less or more trustworthy than work from a colleague. The question is: is the change small enough, tested enough, and clear enough to assess? If the answer is no, the assignment was probably too broad or the context insufficient.
Measure mergeable pull requests, not generated lines of code
The worst KPI for AI coding is the number of generated lines of code. More code is not automatically progress. Sometimes the best contribution is a small change, a better test, or the removal of unnecessary complexity. For background agents a better metric is: how many pull requests are small, understandable, tested, and mergeable without excessive review burden?
Also look at cycle time per task type, percentage of failed runs, reasons why tasks get stuck, amount of human correction, and reusability of context. If agents frequently stall on missing dependencies, you have a setup problem, not a model problem. If reviewers spend a lot of time on unclear intent, you have a spec problem. If agents touch too many files, tasks are too large or permissions too broad.
Therefore start with low-risk work. Have agents add tests for existing bugs, resolve minor documentation issues, prepare simple lint fixes, or make isolated component changes. Collect patterns. Refine templates. Build a library of good assignments. Only then move towards more complex tasks.
A practical adoption framework for AI teams
Anyone wanting to introduce background agents does not need to start with a large transformation programme. Start with one repository and one task type. Choose something that is valuable but carries limited risk. Document the ideal assignment, the necessary context, the setup steps, and the minimum acceptance criteria. Let the agent try several variants and evaluate not only the end result, but also where the process gets stuck.
Then establish a fixed workflow: select a task, write a spec, attach context, run the agent, check tests, open a pull request, conduct review, and write lessons learned back into the instructions. That last step is crucial. Without a feedback loop every run remains a one-off attempt. With a feedback loop your repo becomes progressively better suited for agentic work.
The sober conclusion: the winner is not the team with the most AI tools. The winner is the team that can package work well. Clear specs, reproducible environments, safe access, automated tests, and sharp review turn a background agent not into a silver bullet, but into a genuinely useful lever. That is exactly what Funnel Adviseur looks at when it comes to automation: not the tool as a gimmick, but the process around it that determines whether automation delivers returns.
