AI Coding Workflow with Agents

Human-in-the-loop systems pause agents before high-risk actions. A coding agent creates two kinds of risk: it can run commands during its work, and it can propose source changes that become consequential once reviewed, merged, or deployed. A small patch can alter auth, expose a secret, break billing, or change deployment behavior.

AI coding agents can still write a pull request while you work on something else.

That sounds useful until the diff touches the wrong files, skips the failing test, updates a dependency for no reason, and hides a security problem behind a confident summary.

Adding an agent means adding an automated code-generation worker to your engineering workflow. If you tell it to "fix the billing webhook" and leave the task unbounded, it may return code that looks plausible but changes the wrong behavior. The engineering skill isn't "ask for code and trust the summary." It's designing a workflow where the agent can help without bypassing execution, review, or deployment controls.

Code Generation & Sandboxing and Human-in-the-Loop Agent Architecture covered the two controls this workflow needs: generated code runs in isolation, and risky agent actions require approval gates. Here, you'll apply those controls to an isolated workspace, branch, test, review, and deploy loop.

The workflow below is the operating model for the rest of the article: the agent works in a restricted execution environment and writes only to a review branch. Tests, redacted evidence, review, and merge ownership remain explicit.

What a coding agent is

First, separate two things people often blur together. A coding assistant suggests code as you type, inside your editor. A coding agent takes a scoped task, reads the repository, plans changes, edits files, runs commands, and produces a branch or pull request with little keystroke-by-keystroke input from you. The agent loop needs the strongest controls because it can change files and run commands.

A coding agent, then, is an AI system that can inspect a repository, plan changes, edit files, run commands, and produce a branch or patch.

Modern tools expose this across several surfaces, and their features change quickly. GitHub documents Copilot coding agent as working in an ephemeral GitHub Actions-powered environment where it can make changes, execute tests and linters, and open a pull request for review.^[1] Anthropic's Claude Code docs describe an agentic tool that reads a codebase, edits files, and runs commands across terminal and other surfaces.^[2] OpenAI's Codex app documentation describes local, worktree, and cloud task modes, including isolated worktrees for parallel tasks.^[3] Product surfaces differ; the stable lesson is to control execution, bound diffs, collect evidence, and keep merge authority outside the agent.

A useful workflow is plan-then-edit: let the agent inspect the necessary code, ask it for a bounded plan, correct that plan, and only then authorize an edit pass. A plan isn't proof of correctness, but catching the wrong approach before a large diff is much cheaper than untangling unrelated changes afterward.

The core loop is familiar from agent design. In coding work, every transition creates a reviewable artifact.

An agent can move through many steps, but the human still owns the merge.

How agents plan and correct themselves

A coding agent doesn't write code in a single shot the way a human might type an email. It works in a loop: read the problem, plan a step, take an action, observe the result, and decide what to do next.

This loop is ReAct (Reason + Act).^[4] The agent might read a test file, notice the failure is in a validation function, edit the function, run the tests again, see a new error, and fix that too. Each round gives the agent local feedback, which is why bounded tasks with fast tests work so well.

The thing that closes this loop is a verifier: an automatic check the agent can run after each edit to decide whether it got closer. In coding work, tests, type checkers, and linters are the cheapest, most reliable verifiers you have. A failing test that the agent can rerun turns a vague "is this right?" into a concrete pass or fail signal. No verifier means the agent is guessing, and you're reviewing guesses.

A verifier loop also needs a stopping rule. This tiny simulation takes successive test outcomes as input and returns either the first verified patch or an escalation after its repair budget is exhausted.

A second pattern, Reflection, lets an agent critique its own draft before showing it to you.^[5] After producing a diff, the agent can run a second pass to check for security risks, missing tests, or style violations. That's the difference between a single oversized agent that tries to do everything at once and a workflow where separate passes handle exploration, implementation, review, and verification.

Modern agents pull repository context through tools like the Model Context Protocol (MCP), which lets them query files, documentation, and APIs without you copy-pasting text into a chat window.^[6] The shift from writing better prompts to giving the agent better data is called context engineering. A well-scoped task with precise file ownership and a clean test suite gives the agent far more signal than a giant prompt full of instructions.

Good tasks are bounded

Bad task:

Improve the app and clean up anything you find.

That prompt invites scope drift.

Better task:

Fix the account settings save bug.

Scope:

• Own files under web/src/app/settings/ and web/src/lib/settings.ts.
• Don't edit auth, billing, deployment, or unrelated styling.
• Work without production credentials or external side effects.

Acceptance:

• Reproduce failing save behavior with a test.
• Fix the bug.
• Run pnpm test --run settings and pnpm lint.
• Summarize files changed and remaining risk.

Execution:

• Use the restricted project runner.
• Don't install dependencies, run deploys, or call production systems.

That prompt gives the agent a useful box.

Bounded tasks reduce merge conflicts and make review possible.

Split agent roles

Don't use one vague agent pass for everything.

Use roles with clear ownership boundaries:

You define the database schema and API contracts first, then assign a bounded worker to fill in the implementation while you review every change at each step. If you hand an agent a vague task like "Build me an access-control service" and disappear, it's likely to fail.

This separation matters because agents are good at producing plausible work. A reviewer agent shouldn't be asked to defend the same implementation it just wrote.

Even when one tool provides one interface, you can still run the workflow in passes:

1. Ask for a short codebase read.
2. Assign a bounded patch.
3. Ask for a review of the diff.
4. Run tests yourself or in CI.
5. Inspect the behavior before merge.

Restricted workspace to branch workflow

A controlled workflow separates two boundaries: a restricted environment for commands executed while producing a patch, and version control for reviewing the proposed source changes.

The branch is an integration boundary. It makes proposed changes inspectable before they enter a protected branch.

The review wrapper provides:

• diff inspection
• rollback path
• CI checks
• review comments
• audit trail
• privileged command separation

It doesn't stop an agent command from reading local credentials, making network calls, installing a dependency, or altering external infrastructure. That requires a restricted runner: an ephemeral workspace, least-privilege credentials, constrained network and command policy, and explicit review before privileged operations. If an agent edits directly on main, you also lose much of the integration boundary.

Execution boundary

The task contract should state what the agent may execute as well as what it may edit. For a billing webhook test fix, an agent may need to run unit tests and read local source files; it doesn't need production secrets, package publishing, infrastructure changes, or outbound calls to production systems.

This admission check is intentionally small. It takes an argument vector rather than an interpolated shell string, then admits only commands named in the task contract. In a real runner, execute the approved argument vector without shell concatenation and keep the operating-system sandbox in place.

File ownership example

For parallel agent work, write ownership down.

This style prevents agents from overwriting each other and makes it obvious when a diff goes outside scope.

Ownership can be checked before two patches are combined. This example takes proposed changed files from two workers and detects the shared file that neither handoff resolved.

Tests aren't optional

Agent-generated code often looks correct.

That doesn't mean behavior is correct.

Benchmarks such as SWE-bench evaluate agents on real GitHub issues because repository work is full of hidden context, failing tests, and edge cases that don't appear in isolated coding tasks.^[7] SWE-agent and Agentless both study how agent-computer interfaces and repair strategies affect software engineering performance on real tasks.^[8][9]

Read SWE-bench Verified numbers carefully. Verified tasks come from public GitHub history, which creates contamination risk as code enters training sets. SWE-bench Pro includes substantially different, longer-horizon tasks and a private-repository subset intended to reduce that risk.^[10] OpenAI reported in February 2026 that Verified was no longer a sound frontier evaluation for its models and recommended SWE-bench Pro for more informative measurement.^[11] The practical reading is stable: a benchmark score isn't evidence that an agent fixed your bug. Your own failing test is.

For day-to-day engineering, the lesson is simple: require evidence.

The agent's summary isn't evidence.

The diff, tests, redacted logs, screenshots, and reproduced behavior are evidence.

A reproduction should demonstrate the reported defect before the patch and the intended invariant after it. Here the same billing webhook retry creates two invoices before idempotency handling and one after it.

Command output is useful only after it's safe to attach to a pull request. This redactor takes captured test output and removes a credential value before the evidence packet is shown to reviewers.

This example catches one known credential shape for teaching purposes. Production evidence pipelines should redact against the secrets mounted in the runner, apply a secret scanner, and cap attached output before it reaches a pull request.

Review the diff like production code

Start review with these questions:

1. Did the diff solve the requested behavior?
2. Did it edit only the intended files?
3. Did it add or update tests that would fail without the fix?
4. Did it touch auth, secrets, dependencies, shell commands, file access, billing, or deployment?
5. Did it create hidden fallback behavior?
6. Did it remove error handling, logging, or validation?
7. Did it make code harder to maintain?

Then inspect dangerous patterns.

OWASP's LLM security work identifies prompt injection and sensitive information disclosure as major categories for LLM applications.^[12] Coding agents add another angle: untrusted issue text, docs, comments, and test data may influence code changes or attempt to make the agent execute a command. Treat repository text as evidence about the task, not authority to broaden permissions, expose secrets, or run privileged operations.

Instructions discovered inside a repository don't expand the task's authority. The authority check distinguishes a trusted task contract from a README instruction that attempts to authorize a privileged command.

A practical review checklist

Use this checklist on every agent-generated PR:

If a PR fails the scope check, stop early.

Don't spend an hour reviewing unrelated churn. Ask for a smaller diff.

Review intensity can be computed from proposed paths before a reviewer opens every line. This helper takes changed files as input and routes payment, auth, deployment, and workflow edits to focused review.

You can encode part of this review check as a small policy rule before a human starts deep review. The check isn't a replacement for judgment; it catches obvious scope drift and weak evidence so reviewers don't waste time on unreviewable patches.

This tiny checker catches the same issue a senior reviewer would spot first: the settings fix may be real, but the PR also touched auth and the lockfile without ownership. A lockfile change isn't automatically unsafe, but it requires an intentional dependency review rather than hitching a ride in a settings fix. The next action is extraction or rescoping, not merge.

Where agents help most

Agents are strongest when the task has clear boundaries and local feedback.

Good uses:

• add missing tests for an existing function
• fix a narrow bug with a reproduction
• migrate one component pattern
• update docs from code
• add input validation
• refactor one module with existing tests
• write first draft of a benchmark harness
• inspect a codebase and answer a focused question

Risky uses:

• rewrite auth
• change billing
• rotate secrets
• design a new distributed system without review
• update many dependencies at once
• "clean up the codebase"
• make product decisions without human context

Feedback changes the work.

If an agent can run a test and see whether it got closer, it has a useful loop. If the task needs product judgment, legal judgment, security judgment, or architecture taste, the agent can assist, but it shouldn't decide alone.

Worked example: Refactoring with agents

A multi-agent refactor should start with a messy but functional billing-webhook retry module, then run it through separate passes.

Step A - Exploration: Ask an explorer agent to read the module and list the highest-risk maintainability issues. It reports duplicated idempotency checks, one oversized handler, and missing error handling for payment-provider timeouts.

Step B - Architecture: Ask an architect agent to propose a modular structure. It suggests splitting the module into validateWebhook.ts, loadInvoiceState.ts, and handleProviderTimeout.ts, with clear interfaces between them.

Step C - Implementation: Ask a worker agent to execute the split, one file at a time, keeping existing tests green. It produces small commits with descriptive messages.

Step D - Verification: Ask a verifier agent to run the targeted tests, review the diff against the original behavior contract, and confirm the timeout failure path is now tested. It reports the exact commands and changed behavior instead of a confidence summary.

Each pass has a different role, a bounded scope, and a clear handoff. The human reviews the final diff before anything merges.

Incident story

Start with an issue:

Users sometimes see duplicate invoices after replaying a billing webhook.

A weak agent task says:

Fix duplicate invoices.

The agent might add a frontend debounce. That may reduce clicks but won't fix duplicate server-side side effects.

A strong task says:

Investigate duplicate invoice creation in billing webhook retry flow.

Scope:

• Read billing webhook handler, invoice creation, and retry tests.
• Don't edit payment provider config.
• First report likely cause and proposed fix.
• Then add a failing test for duplicate retry.
• Fix with idempotency key on server-side invoice creation.
• Run billing webhook tests.

This task guides the agent toward the real class of bug: idempotency.

It also splits investigation from implementation. The human can stop a wrong plan before code changes land.

The implementation invariant is small enough to execute locally. Invoice creation accepts a webhook idempotency key and returns the existing invoice for a retry instead of inserting a second side effect.

Team policy

Teams should write down how AI coding agents are allowed to work.

Minimum policy:

• Agents run commands in restricted workspaces without production secrets or deployment authority.
• Agents commit source changes only to branches or pull requests, never directly to protected branches.
• Sensitive files, dependency changes, and privileged commands require focused human approval.
• Every generated PR needs human review.
• CI must run before merge.
• Security-sensitive diffs need threat-specific verification.
• Agent summaries and unredacted command output aren't proof.
• Large diffs are split before review.

This isn't anti-agent.

It's how agents become useful inside real engineering teams.

A mechanical gate can reject missing evidence, but it must not perform the merge. This example returns a candidate for human review only when branch, sandbox, tests, and sensitive-review requirements are satisfied.

Practice

You're reviewing an agent PR. It claims:

Implemented requested settings fix. Tests pass.

You see:

• 18 files changed
• package lock changed
• no new test
• auth middleware edited
• settings bug fixed in one component

What do you do?

Strong answer:

1. Stop review and flag scope drift.
2. Ask for a smaller PR that only owns settings files.
3. Require a reproduction test for the settings bug.
4. Inspect why auth middleware changed before accepting any follow-up.
5. Reject the package lock change unless dependency work was in scope.

The settings fix may be real, but the PR isn't reviewable as-is.

Mastery check

Key concepts

• Task scope is a control surface, not admin overhead.
• Restricted execution limits command effects; branches, CI, and review checks control source-code integration.
• Exploration, implementation, review, and verification are safer when separated into explicit passes.
• Agent summaries are hints. Diffs, tests, redacted logs, screenshots, and reproduced behavior are evidence.
• Coding agents speed up bounded work. They don't own product judgment or merge accountability.

Evaluation rubric

• Strong: you can write a bounded agent task, distinguish execution isolation from branch review, name the first review check, and explain what evidence supports merge.
• Partial: you know agents need review, but you can't define file ownership, acceptance checks, or evidence requirements.
• Weak: you treat the agent summary or green CI alone as enough proof to merge.

Follow-up questions

• Why should an AI coding task name the files or modules the agent owns?
• What should a reviewer check first in an agent-generated pull request?
• Why are coding agents useful even when they still need human review?
• When is it safer to split one coding task into explorer, worker, reviewer, and verifier passes?

Common pitfalls

• Symptom: agent PR looks productive but touches many unrelated files. Cause: task had no explicit file ownership or non-goals. Fix: rescope the task, split the diff, and reject unrelated churn before deeper review.
• Symptom: existing tests are green, but requested bug still isn't well proven. Cause: no reproduction test was added for the actual failure. Fix: require one test that fails before the patch and passes after it.
• Symptom: auth, billing, secret handling, or deployment config changed quietly inside a normal feature diff. Cause: sensitive areas were not treated as special approval zones. Fix: stop review, isolate the sensitive change, and require focused approval.
• Symptom: reviewer can't explain why the patch is safe even though the summary sounds confident. Cause: evidence was replaced by narration. Fix: inspect the diff, rerun commands, and review behavior directly.
• Symptom: agent keeps expanding context and output without getting more reliable. Cause: workflow used one vague pass instead of bounded loops with verifiers. Fix: reduce scope, give exact files and checks, and break work into separate passes.