Catalog / Software Engineering & IT Operations / CODE-002

Autonomous coding agents (issue-to-pull-request)

Assign a ticket or issue to an AI agent that works in a sandbox, edits the repository, runs tests and opens a pull request for human review.

Parts needed to run it yourselfAgents & automationCoding assistantLanguage model

Backlogs are full of small, well-specified tickets (bug fixes, dependency bumps, test gaps, minor features) that nobody has time for. Coding agents take such a ticket, work asynchronously in an isolated cloud or container sandbox, read the repository, edit code, run build and tests, and open a pull request. Humans review and merge. The benefit is throughput on routine work, not removal of engineers.

Problem & value

  • Today: developers context-switch to small tickets; chores and tech debt accumulate. IDE assistants (CODE-001) help while a person is typing but still need a person driving.
  • AI value: work is delegated and runs in parallel and in the background (also overnight); the developer reviews a finished PR instead of writing it. Best for tasks with clear acceptance criteria and good tests.
  • Evidence: vendors document the workflow (assign issue, agent pushes to a draft PR, requests review) [1][2]. The SWE-bench family measures how often agents resolve real GitHub issues; scores are strongly dependent on harness and model, Verified is considered saturating, and harder variants (e.g. SWE-bench Pro) are used now [3]. Benchmark success does not equal production ROI; measure on your own backlog.

Variants

  • Cloud agent in the forge: issue assigned to an agent inside GitHub/GitLab, runs in CI-like sandbox.
  • Terminal/CLI agent run headless: triggered from CI, cron or chat (e.g. nightly chores, flaky-test fixes).
  • Maintenance bots: narrow agents for dependency upgrades, vulnerability fixes, migrations (CODE-021, CODE-014).
  • Enterprise / regulated: self-hosted agent platform in own VPC with audit trail and policy gates.
  • Private / open source: maintainers use agents for triage-and-fix of small issues; contributors disclose AI use.

How it works

  1. ticket / issue (+ instruction files, MCP tools)
  2. task planning (read code, search, locate relevant files)
  3. sandbox (container/VM, restricted network, scoped token)
  4. edit
  5. build
  6. run tests/linters
  7. self-correct loop
  8. commit to branch, open DRAFT pull request with summary
  9. CI + automated review (CODE-003) + human review
  10. reviewer comments
  11. agent pushes follow-up commits
  12. human merge
  • Agent loop: a reasoning code model calls tools (shell, file edit, search, browser, MCP servers) repeatedly until tests pass or it gives up; context management and repo maps matter as much as the model.
  • Instruction files: AGENTS.md and similar files tell the agent build commands, conventions and no-go areas.
  • Human-in-the-loop: ticket selection (what may be delegated), PR review and merge, secrets and production access never granted. Branch protection ensures the agent cannot merge its own PR.

Data preparation

Agents work from the issue text, the repository, the CI setup and the test suite. These live in Git hosting, the ticket tool (Jira, GitLab, GitHub Issues) and the CI system. Typical gaps decide success more than the model: vague or incomplete tickets, no or flaky tests, builds that only run on one developer machine, missing setup documentation, undocumented conventions, secrets in the repo and overly broad tokens.

Preparation steps: (1) write acceptance criteria into tickets using a template (goal, affected area, definition of done); (2) get a reproducible build and a fast test suite running in CI, fix or quarantine flaky tests; (3) provide a devcontainer or setup script so the sandbox can install dependencies; (4) write AGENTS.md or CLAUDE.md with commands, architecture and do-not-touch areas; (5) scan for secrets and give the agent a least-privilege token without production access. Collect a set of 10 to 20 past, solved tickets as evaluation tasks, see PREP-018; harvest them from closed issues and merged PRs (PREP-020). Keep agent feedback from reviewers, see PREP-021.

Effort share: medium, around 20 to 30 percent, mostly test and build hygiene that pays off for human developers as well.

Implementation paths

Which path for whom

  • SMB: A - hosted agents from established vendors (Copilot coding agent, Claude Code, Devin, Jules) run in managed sandboxes, so no own agent infrastructure is needed.
  • Enterprise: B - an own agent harness on cloud APIs in EU regions gives control over sandbox, network egress, permissions, audit trail and costs, and connects to internal trackers and CI.
  • Developer: B - open agent frameworks and BYOK CLIs let you choose models per task and control token spend directly.
  • Forge-integrated: GitHub Copilot cloud/coding agent [1][2], GitLab Duo Agent Platform, Atlassian Rovo Dev, Azure DevOps and Jira integrations.
  • Dedicated agents: Anthropic Claude Code (incl. GitHub Actions / web), OpenAI Codex (cloud and CLI), Google Jules, Cursor background agents, Devin (Cognition), Factory, Amp (spun out of Sourcegraph in Dec 2025), Augment.
  • EU options: JetBrains Junie (JetBrains, Czechia), Mistral Code / Devstral-based tooling (France), Tabnine (EU deployment options); check regional hosting of the sandbox, not only the model.
  • Choose A when: code already lives on GitHub/GitLab, tests exist, and you want results in weeks.

Path B — Build on cloud APIs

  • Models: frontier code/reasoning models via Anthropic, OpenAI, Google (EU regions through AWS Bedrock Frankfurt, Azure EU, Vertex EU) or Mistral (EU provider).
  • Frameworks: Claude Agent SDK, OpenAI Agents SDK, LangGraph, OpenHands SDK [4]; MCP for tool access [5].
  • Sandboxes: ephemeral containers via GitHub Actions runners, E2B, Daytona, Modal, or own Kubernetes with gVisor/Firecracker.
  • Choose B when: you need custom triggers (ticket labels, ChatOps), own policy gates or non-GitHub forges.

Path C — Self-host (open source)

  • Agents: OpenHands [4], SWE-agent / mini-SWE-agent [3], Aider, Cline/Roo Code, Goose, OpenCode.
  • Open-weight models: Devstral (Mistral), Qwen3-Coder, GLM, Kimi K2, DeepSeek-class coder models, served via vLLM or SGLang.
  • Hardware: small models (~24–32B, Devstral Small class) run on HW2/HW3 but are weaker on long tasks; large open coder models need HW4 (multi-GPU node). Sandboxes need CPU and RAM per parallel task.
  • Choose C when: source code may not leave the premises (defence suppliers, banks) and a platform team exists.

Path D — Custom training

Rarely worthwhile for SMBs. Large organisations fine-tune or RL-train on their own repos and CI traces (trajectories of successful PRs) to cut cost or learn internal frameworks. Needs thousands of verified tasks with executable tests.

State of the art (2026)

  • Agents handle multi-file bug fixes and small features autonomously; frontier models score very high on SWE-bench Verified, so attention moved to SWE-bench Pro, long-horizon and multi-language benchmarks [3]. Treat published numbers with caution: harness, scaffold and contamination change results considerably.
  • Trends: parallel background agents, agents driven from chat/issue trackers, MCP as standard tool interface, agent instruction files as de-facto standard, automated PR review of agent output.
  • Limits and failure modes: vague tickets produce plausible but wrong changes; agents game or weaken tests; weak at large architectural change, ambiguous requirements and flaky environments; reviewer fatigue on large PRs; hallucinated or malicious packages (slopsquatting); prompt injection via issue text, web pages or tool output.

Shared resources & combinations

  • Same stack (llm-code + llm-reasoning + agent-framework): CODE-001 IDE assistants, CODE-014 bug fixing, CODE-021 upgrades/refactoring, CODE-005 legacy migration, CODE-004 test generation.
  • Combine with: CODE-003 (AI review of agent PRs), CODE-004 (tests as the agent's feedback signal), CODE-006 (documentation updates in the same PR), AGENT-003 (computer-use for UI verification).
  • One shared sandbox/CI platform and one model gateway can serve all of these.

Effort, cost & KPIs

  • Path A: days to weeks; per-seat or usage-based (premium requests, agent compute minutes).
  • Path B: 1–3 months for triggers, sandbox, secrets handling, audit logging.
  • Path C: 3–6 months plus GPU and platform operations.
  • Cost drivers: tokens per task (long agent loops), sandbox compute, reviewer time. Failed runs still cost.
  • KPIs: PR acceptance/merge rate, share merged without major rework, review time per agent PR, CI pass rate, escaped defects, cost per merged PR, cycle time of delegated tickets, security findings in agent PRs.

People & change

Involve management (budget, risk appetite, AI policy, GUIDE-007), the development lead as process owner, IT and information security early because agents execute code and hold repository tokens (GUIDE-013), the DPO for AVV and any personal data in repos or tickets, and legal for licence and liability questions. Developers need a say in which task types are delegated.

Works council: depends. Agents log who assigned which task and with what outcome, which can make individual behaviour or performance visible; the Federal Labour Court treats objective suitability as enough for co-determination under section 87(1) no. 6 BetrVG. Section 90(1) no. 3 requires timely information because work processes change, and section 80(3) lets the works council call in an AI expert. Agree that agent metrics are measured per team and never used for individual appraisal (GUIDE-004). Public sector: staff council.

AI literacy: support staff's AI literacy under Art. 4 AI Act with hands-on training on writing good tickets, reviewing agent pull requests critically and recognising typical failures (GUIDE-006). Start with a pilot on low-risk tasks (dependency updates, small bugs, tests) in one team and go/no-go by KPIs (GUIDE-009). Address fears of replacement honestly: agents take over routine tickets, humans decide on architecture, review and merge. Never allow auto-merge to production without human approval.

Risks, regulation & compliance

  • EU AI Act: typically minimal risk (a developer tool, no Annex III use). Art. 4 AI literacy applies to staff. If the agent writes code for a high-risk system (e.g. medical, vehicle), the system's own conformity duties and documentation apply to the final product, not the tool. If you provide an agent product to others, check GPAI/Art. 50 duties. No Art. 5 prohibited practice is involved.
  • GDPR: repositories, tickets and logs may contain personal data (names, customer data in fixtures); the vendor receives it as processor, so a DPA, EU region and no-training terms are needed; keep production data out of sandboxes.
  • Security: agents with shell and network access are an attack surface: least-privilege tokens, egress allow-lists, no secrets in the sandbox, protected branches, mandatory human approval of CI workflow runs, dependency allow-listing, and treating issue text from untrusted authors as untrusted input.
  • IP and licensing: possible reproduction of licensed code; use licence scanning (SCA) and record AI authorship. Also CRA (Cyber Resilience Act) secure-development duties for products with digital elements stay with the manufacturer.
  • Mitigations: draft PRs only, CODEOWNERS review, audit log of prompts/commits, SAST and tests as gates, task allow-list.

Getting started

  1. Pick a repository with good tests and CI; write an AGENTS.md with build/test commands and conventions.
  2. Choose 20 small, well-specified tickets (chores, small bugs) as a pilot set.
  3. Enable one Path A agent with least-privilege access, protected branches and no production secrets.
  4. Review every PR as if from a junior developer; log merge rate, rework and cost.
  5. Expand to more ticket types only when merge rate and defect data justify it; add AI review (CODE-003).

Sources

  1. GitHub Docs — Asking GitHub Copilot to create a pull request — https://docs.github.com/copilot/how-tos/use-copilot-agents/coding-agent/assign-copilot-to-an-issue
  2. GitHub Docs — Using Copilot cloud agent on GitHub — https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/use-cloud-agent-on-github
  3. SWE-bench project and leaderboards — https://www.swebench.com/
  4. OpenHands (open-source coding agent platform) — https://github.com/All-Hands-AI/OpenHands
  5. Model Context Protocol specification — https://modelcontextprotocol.io/
  6. Claude Code documentation — https://docs.claude.com/en/docs/claude-code/overview
  7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  8. Regulation (EU) 2024/2847 (Cyber Resilience Act) — https://eur-lex.europa.eu/eli/reg/2024/2847/oj