00Field guide / AI coding agents
AI Coding Agents: From Code Generation to Accountable Delivery
An AI coding agent can inspect a repository, plan work, edit files, run tools, and respond to failures. The useful question is not whether it can generate code. It is whether a team can understand, constrain, and verify what it changed.
01Definition
A coding agent acts on a software system; an assistant mainly advises a person.
Autocomplete predicts the next fragment. A conversational assistant proposes code for a person to copy. A coding agent can inspect the working tree, choose files, invoke a compiler, observe a failing test, revise the candidate, and preserve work across several steps. That action loop is what makes an agent powerful, and what turns authority, state, and verification into product requirements rather than optional features.
The label does not guarantee autonomy or quality. Some agents handle one bounded ticket; others coordinate long-running work across frontend, backend, data, security, and operations. The meaningful comparison is the work boundary they can hold, the capabilities they receive, the evidence they produce, and the conditions under which a result may advance.
- Repository context instead of isolated snippets
- Tool use with explicit scope and limits
- Iterative work that reacts to observable outcomes
- A candidate that can be identified and reviewed
02Contract
A serious run starts with an executable definition of success.
A prompt can describe intent while leaving scope, permissions, constraints, and acceptance ambiguous. A run contract makes those dimensions explicit before implementation begins. It names the repository paths in scope, the actions the agent may take, the checks that must run, the spending and retry limits, and the authority required for deployment or publication.
This matters because an agent should not be allowed to redefine success after seeing its own output. If a migration must be reversible, a checkout flow must preserve guest behavior, or a credential must never reach a subprocess, those conditions belong in the contract and in checks that can fail.
- Intent and non-goals are written separately
- Acceptance exists before the candidate
- Irreversible actions require named authority
- Open requirements remain open in the final record
03Control
Useful autonomy is bounded by capabilities, not hopeful instructions.
Prompt language alone is not a security boundary. The runtime must decide which files, commands, networks, credentials, models, budgets, and destinations are available. A frontend specialist does not need a production database credential. A test runner does not need arbitrary internet access. A coordinator that can schedule work does not automatically gain permission to merge or deploy it.
The safest design grants each step the minimum capability it needs and produces a receipt for what was exercised. This makes failures diagnosable and prevents a convenient shared environment from becoming an invisible all-access role.
- Least-authority tools and credentials
- Deny-by-default network policy
- Separate execution, acceptance, and release authority
- Receipts that prove actions without retaining secrets
04Verification
The authoring agent cannot be the final judge of its own candidate.
An agent can explain why its patch should work, but that explanation is not independent evidence. Build, behavior, browser, accessibility, security, and acceptance checks need to run against the exact candidate bytes. Each verdict should identify its subject, method, inputs, limitations, and authority so evidence from an older or different tree cannot be reused accidentally.
Failure is still an outcome. Retaining a failed gate is more useful than retrying until the history looks clean, because it shows where the system's reasoning or execution boundary broke. Human acceptance remains a separate gate for product judgments that automation cannot honestly settle.
- Candidate-bound checks
- Gates are mutation-tested so they can demonstrably fail
- Failures remain visible
- Human judgment is not relabelled as automated proof
05Fit
Use agents where the work is verifiable, not merely impressive in a demo.
Coding agents are a strong fit when the repository exposes reliable feedback: typed interfaces, deterministic tests, reproducible builds, reviewable diffs, and clear policy boundaries. They are weaker when the objective is primarily taste, the environment cannot be reproduced, or success depends on unstated organizational context.
A practical adoption path begins with bounded work, measures independently accepted outcomes rather than self-reported completion, and expands authority only when the evidence supports it. The goal is not maximum autonomy. It is faster engineering with a clearer chain from intent to candidate to verdict to decision.
- Start with bounded consequential tasks
- Measure acceptance, rework, latency, and cost separately
- Expand scope after observed evidence
- Keep rollback and human control operational
Design partners
Treat the agent as an engineering system, not a magic text box.
Bound the agent’s work, then check what it produced. TraceAxiom Verify is a GitHub Action, in development and not installable yet, that runs a pull request’s tests on base and head, checks its claims, and posts one verdict with its reasons.
Join the waitlist