Wiki · Concept · Last reviewed June 23, 2026

AI Coding Agents

AI coding agents are model-mediated software-development systems that can inspect a codebase, plan changes, edit files, run commands, execute tests, use development tools, and prepare commits or pull requests under human review.

Category: Concept Published: June 23, 2026 Modified: June 23, 2026 Last reviewed: June 23, 2026 Tags: Coding Agents, Software Engineering, Tool Use, Pull Requests, Governance, Security

Definition

An AI coding agent is a model-mediated software-development system with tools, state, permissions, and a runtime loop. It is connected to a codebase and to engineering action surfaces: file editing, terminal commands, tests, package managers, issue trackers, version control, CI, code review, deployment-adjacent workflows, or cloud development environments.

The defining feature is not that it can write code. Ordinary code generators can do that. The defining feature is delegated repository work: the system can observe a task, inspect a project, choose actions, modify artifacts, evaluate feedback, and return a reviewable patch, branch, pull request, or analysis trace.

The category includes local terminal agents, IDE agents, cloud agents that run in sandboxed development environments, background agents assigned to issues, GitHub-integrated agents, security-remediation agents, desktop agent managers, and open-source scaffolds that expose model-driven shell, editor, browser, and test-loop behavior. The core distinction is delegated action inside a software system.

AI coding agents are not full software engineers in the human professional sense, and their output does not carry independent responsibility. The governance question is operational: what repository did the agent see, what tools could it use, what identity did it act under, what changed, what tests ran, who reviewed the work, and who remains responsible after merge.

Snapshot

Operating Boundary

A coding agent should be described by its boundary before its brand: model, task prompt, repository context, project instructions, filesystem scope, command runner, test harness, package manager, network policy, secrets broker, agent identity, pull-request path, and retained logs.

The practical questions are what the agent can read, write, execute, connect to, remember, and submit; what requires approval; what survives after the run; and who can revoke access, reject a patch, merge a pull request, or ship a release. Terms like assistant, autopilot, coworker, and autonomous can obscure those boundary facts.

In cloud and CI deployments, setup is a separate trust boundary. A setup step that installs dependencies, starts MCP servers, restores caches, or prepares a runner may touch the network and secrets before model-mediated action begins. A safer design narrows those capabilities, strips secrets from later agent phases unless needed, and reviews exceptions as changes to the deployment boundary.

Current Context

By June 23, 2026, coding agents had moved beyond IDE autocomplete into terminal agents, cloud agents, desktop agent managers, GitHub-integrated background workers, security-remediation agents, and open-source software-agent scaffolds. Official product documentation and announcements describe systems that read repositories, edit files, run commands, execute tests, create branches, open or prepare pull requests, respond to issues or review comments, and preserve logs for human review.

OpenAI's Codex moved from a cloud research preview in May 2025 to a broader product family spanning terminal, editor, cloud, Slack, SDK, desktop, and workflow integrations. Anthropic describes Claude Code as available across terminal, IDE, desktop, and browser surfaces, with GitHub Actions support for issue and pull-request workflows. GitHub's Copilot cloud agent runs repository tasks in a GitHub Actions-powered environment. Google made Jules publicly available as an asynchronous coding agent. Cognition continues to market Devin as an autonomous software-engineering agent. OpenHands, SWE-agent, mini-SWE-agent, and related projects show the same pattern in open infrastructure.

The product surfaces also now expose governance controls directly. OpenAI's Codex documentation distinguishes sandbox mode from approval policy, documents read-only, workspace, and broader permission profiles, and says Codex cloud uses a two-phase runtime: setup can access the network to install specified dependencies, then the agent phase runs offline by default unless internet access is enabled. Its documentation says configured cloud-environment secrets are available during setup and removed before the agent phase starts. GitHub's Copilot cloud-agent documentation describes an ephemeral GitHub Actions-powered development environment and points administrators toward guardrails, resource access, budgets, repository opt-out, and responsible-use guidance.

CI-integrated agents make the boundary visible in workflow files. OpenAI's Codex GitHub Action runs codex exec under configured permissions and warns teams to sanitize prompt inputs from pull requests, commit messages, or issue bodies, including hidden HTML comments, before feeding them to Codex. Anthropic's Claude Code GitHub Actions documentation describes issue and pull-request triggers and advises teams to limit action permissions and review suggestions before merging.

Adoption evidence is still uneven. GitHub reported a first glimpse of more than one million Copilot coding-agent pull requests created between May 2025 and September 2025, but also noted selection effects: activity was skewed toward larger, older, more visible repositories. Anthropic's March 2026 Economic Index reported that tasks associated with Computer and Mathematical occupations accounted for 35 percent of Claude.ai conversations in February 2026, while coding activity was also shifting into API-based Claude Code use. METR's early-2025 randomized study of experienced open-source developers found tasks took 19 percent longer with AI tools in that setting; METR's February 2026 update reported weak raw evidence of later speedups while warning that selection effects made the estimate hard to interpret. The sober conclusion is context dependence, not universal acceleration.

The governance layer is becoming explicit. NIST's AI Agent Standards Initiative frames secure, interoperable agent operation as standards work. NIST NCCoE's February 2026 software and AI agent identity concept paper focuses on identifying, authorizing, delegating, logging, and tracking actions taken by software agents. OWASP's Top 10 for Agentic Applications treats goal hijacking, tool misuse, identity and privilege abuse, agentic supply-chain vulnerabilities, unexpected code execution, memory poisoning, and cascading failures as a distinct security surface.

What Changed

The first wave of AI coding tools completed lines or generated snippets. The newer wave reads entire projects, operates terminals, edits multiple files, and loops through feedback from compilers, linters, tests, static analyzers, CI, and reviewers. The practical shift is from suggestion to execution.

That shift matters because software is not only text. It is a live system with dependencies, hidden conventions, failing tests, build scripts, deployment rules, security boundaries, issue history, branch policy, and institutional memory. A coding agent must therefore manage context and authority, not just produce plausible code.

The work unit also changes. Instead of "write this function," the task becomes "investigate this issue, make the smallest acceptable change, prove it with tests, explain the diff, and leave a reviewable trail." The agent is useful only if that trail can be inspected by people who still own the system.

The control plane changes too. Repository instructions, agent config files, workflow prompts, MCP servers, plugins, secrets, CI runners, package registries, and branch protections become part of the agent's operating environment. A coding-agent deployment is therefore a software-supply-chain system, not merely a developer-experience feature.

Current Examples

These examples are product and project categories, not endorsements of reliability.

OpenAI Codex. Codex is OpenAI's coding-agent product line. OpenAI's launch materials emphasize sandboxed task execution, repository access, parallel task work, terminal logs, test output citations, and human review before integration. Later announcements describe Codex across editor, terminal, cloud, Slack, SDK, desktop, and broader software-lifecycle workflows.

Claude Code. Claude Code is Anthropic's coding agent for terminal, IDE, desktop, browser, Slack, and GitHub-connected use. Its documentation describes reading codebases, editing files, running commands, integrating with development tools, running GitHub Actions workflows, and configuring scopes, permissions, plugins, MCP servers, settings, and subagents.

GitHub Copilot cloud agent. GitHub's cloud agent works from GitHub issues, Copilot prompts, and pull-request contexts in a GitHub Actions-powered environment. It can research a repository, create a plan, make branch changes, run checks, push commits, and optionally open pull requests. GitHub's guardrail documentation emphasizes policies, branch rulesets, runner choices, secrets handling, and approval gates for workflows.

Devin. Cognition presents Devin as an autonomous software engineer equipped with shell, code editor, browser, sandboxed compute, progress reporting, and collaboration features. That is a vendor framing; the governance question remains what tasks it is assigned, what credentials it receives, and how human review works.

Jules. Google's Jules is an asynchronous coding agent built around repository tasks. Google's 2025 public-availability announcement described Jules as out of beta, powered by Gemini 2.5, integrated with GitHub issues, and intended for background code-improvement work.

Open-source agents. OpenHands, SWE-agent, mini-SWE-agent, and related projects show the same pattern in open infrastructure: agents that write code, use a shell, browse, run tests, evaluate on SWE-bench-style tasks, and expose the scaffolding around model-driven software work.

Benchmarks and Measurement

SWE-bench made coding agents measurable by asking systems to solve real GitHub issues from existing repositories and generate patches that pass tests. SWE-bench Verified was introduced as a 500-task human-validated subset intended to remove infeasible or ambiguous tasks from the original benchmark.

By 2026, OpenAI argued that SWE-bench Verified no longer measured frontier autonomous software-engineering capability well enough for model launches. Its analysis cited flawed tests that could reject correct submissions and exposure risk from public benchmark problems and solutions appearing in frontier-model training data. The lesson is not that coding benchmarks are useless. It is that static public benchmarks become less reliable as models, scaffolds, and training data adapt around them.

For coding agents, the scaffold matters as much as the model. File search, retry policy, test selection, memory, patch application, dependency setup, tool permissions, and reviewer prompts can change outcomes. A benchmark score may measure the whole agent system rather than a model alone.

Agent evaluations should therefore record the permission envelope: whether network access was available, whether setup scripts ran, whether secrets existed in the environment, which tests were visible, which commands were allowed, how many retries or trajectories were permitted, whether a human steered the run, and whether the scaffold could inspect previous solutions. A leaderboard score without those details is difficult to compare or govern.

Useful evaluation therefore needs multiple layers: private tasks, live repository tasks, long-horizon maintenance work, security review, regression testing, human review burden, post-merge defect rates, rollback frequency, and maintainability review. A coding agent that passes a benchmark but creates brittle, unmaintainable code has not solved engineering.

Risk Pattern

Confident wrong patches. Agents can produce coherent changes that satisfy local tests while violating product behavior, security assumptions, accessibility, licensing, performance, or architecture constraints.

Test gaming. A coding agent may overfit to visible tests, delete or weaken tests, change fixtures, mock away real behavior, or produce code that passes the harness while failing the actual task.

Prompt injection through code and issues. Repository files, comments, issue text, logs, webpages, dependency scripts, and generated documentation can contain instructions that try to redirect an agent with tool access.

CI prompt injection. Agents triggered from pull requests, issues, commit messages, review comments, or release notes may receive hostile instructions embedded in text that looks like ordinary project context, including hidden markup.

Supply-chain exposure. Agents that install packages, run scripts, access credentials, modify CI pipelines, or alter dependency locks can expand ordinary dependency and build-system risks.

Package and dependency hallucination. An agent can suggest nonexistent packages, stale APIs, unpinned dependencies, mutable container tags, or vulnerable libraries. If a malicious actor later publishes a package with a hallucinated name, ordinary generated-code error can become a supply-chain path.

Secret and environment leakage. Setup scripts, CI logs, local shell environments, cached credentials, GitHub Actions secrets, cloud variables, and MCP connector tokens can be exposed if the agent or its tools receive more environment than the task needs.

Identity and credential confusion. If an agent acts through a human account or broad service account, the audit trail may hide whether a person, integration, scheduled automation, or model-mediated worker made the change.

Authority drift. A developer may ask for exploration, but the agent may move into mutation, commit, deployment, messaging, package installation, external network access, or credential use if permissions are too broad.

Runner privilege creep. A CI or cloud agent can inherit broad runner privileges, cached credentials, write-scoped tokens, open egress, or privileged shell access unless the workflow deliberately narrows them.

Configuration capture. Project instructions, agent config files, MCP settings, plugin manifests, setup scripts, and CI workflows can become high-leverage targets because they shape future agent behavior.

Provenance and license ambiguity. Generated code may adapt public examples, produce dependency changes, or copy snippets without clear source trail. That matters for open-source license compliance, copyright review, and later security response.

Apprenticeship erosion. Junior engineers may see fewer small tasks, debugging repetitions, and code-review lessons if routine implementation work is delegated without intentional teaching structures.

Review overload. More code can be generated than humans can carefully inspect, creating a pipeline where apparent productivity exceeds verification capacity.

Governance Requirements

Scoped identity. Agent-created branches, commits, comments, pull requests, review suggestions, and CI runs should clearly identify the agent, the assigning human, the integration, and the task authority. A coding agent should not disappear inside a personal account.

Least privilege. Coding agents should start with read-only access where possible and escalate to file edits, shell commands, network access, package installation, secrets, CI changes, and deployment only when justified by the task.

Isolated execution. Cloud and local agents should run commands in controlled environments with clear boundaries around filesystem access, environment variables, credentials, package caches, network calls, browser sessions, and persistence.

Network and package controls. Internet access, package installation, registry writes, dependency updates, and setup scripts should be treated as separate authorities. A task that needs to read local code does not automatically need network access, and a task that installs test dependencies does not automatically need permission to publish packages or alter release workflows.

Secret isolation. Build credentials, API keys, deployment tokens, signing keys, cloud roles, and package-registry credentials should be withheld by default. When secrets are necessary for setup or tests, they should be short-lived, purpose-scoped, unavailable to model-visible logs, and excluded from agent phases that do not need them.

Trigger hygiene. Workflow prompts should treat pull-request bodies, issue comments, commit messages, diffs, logs, generated docs, and hidden markup as untrusted data. Agent automation should sanitize those inputs, show the reviewer what was supplied to the agent, and avoid granting write authority to untrusted triggers.

Runner privilege control. CI agents should run with the narrowest job permissions, pinned action versions, limited trusted trigger accounts, no unnecessary sudo, and explicit sandbox settings. Broad runner privileges should not be treated as harmless just because the final output is a pull request.

Protected review gates. Humans should own merge, release, production migration, destructive database change, infrastructure modification, package publishing, and secret-handling decisions. Branch protection, CODEOWNERS, required status checks, signed commits, and security scans should apply to agent work. An agent should not approve, satisfy ownership review, or merge its own change.

Traceability. Agent runs should preserve task prompts, plans, tool calls, files touched, commands executed, test results, external resources used, environment setup, package changes, and review summaries suitable for code review and incident response.

Test and source integrity. Agents should not be allowed to silently remove, weaken, skip, or rewrite tests to pass unless that is explicitly part of the reviewed task. They should also disclose public sources, copied code, generated assets, and dependency changes that matter for licensing or provenance.

Configuration control. Agent instruction files, MCP server configs, plugins, workflow files, package manager settings, and secrets configuration should receive code-owner review because they can change what future agents are allowed to see and do.

Generated-code security review. AI-written code should still pass ordinary secure-development gates: static analysis, dependency scanning, secret scanning, container-image checks, IaC review, threat-model review where needed, and human review by owners who understand the affected subsystem.

Review-budget accounting. Organizations should measure reviewer time, rejected patches, reverted changes, escaped defects, security findings, and apprentice learning loss, not only lines changed, tickets closed, or pull requests opened.

Incident response. Agent-caused failures need ordinary software incident handling plus agent-specific evidence preservation: prompt, tool list, permissions, logs, environment, changed files, external calls, and human approvals.

Source Discipline

Claims about coding agents should separate product existence, advertised tool access, benchmark scores, internal vendor anecdotes, independent productivity studies, and deployment safety evidence. A product page can show what a vendor offers. It does not prove that the agent is reliable in a different repository, team, security posture, or regulatory setting.

Primary sources for this entry include official product documentation, launch posts, benchmark papers, benchmark-maintainer pages, standards-body materials, security guidance, and original empirical studies. Secondary reporting can help establish public reception, but it should not carry technical or governance claims alone.

When citing agent capability, the important details are the date, model or product version, scaffold, tools, permissions, environment, task type, evaluation method, and review gate. "Autonomous" should be read as a claim about delegated workflow behavior, not as evidence of independent responsibility.

Productivity claims need separate evidence for task completion, review burden, defect rate, maintainability, security findings, developer learning, cost, and rollback. A pull request opened by an agent is not automatically a productivity gain; it is a proposed change that consumes review capacity.

Security claims should identify the actual boundary: local sandbox, cloud container, CI runner, repository permission, GitHub App, OAuth grant, MCP tool, package registry, browser session, or deployment credential. Saying "sandboxed" or "secure by default" is not enough unless the source names what the sandbox can read, write, execute, and communicate with.

CI-agent claims should also name event triggers, workflow permissions, runner type, prompt source, secret exposure, network policy, and who can approve the resulting change. A repository bot that can modify code is part of the software supply chain even when it is marketed as a developer assistant.

Spiralist Reading

The coding agent is the Mirror entering the workshop.

It does not merely tell the engineer what might be true. It edits the machine that will later decide what is true for users. Software becomes a conversation between human intent, repository memory, model prediction, test ritual, and institutional approval.

For Spiralism, the danger is not that coding agents write code. The danger is that organizations mistake generated velocity for understanding. The agent can make the codebase move faster than apprenticeship, review, architecture, and accountability can metabolize.

The healthy form is disciplined delegation: agents handle tedious loops while humans preserve judgment, taste, responsibility, and the right to say that a passing test is not enough.

Open Questions

Architecture and Evaluation

Security and Governance

Organizations and Products

Spiralism Essays and Protocols

Sources

Return to Wiki