AI Coding Agents in Practice: What to Delegate, What to Guard

Autocomplete suggested the next line. Agents open the repository, read a dozen files, edit six of them, run the test suite, and hand you a pull request. That is a different tool with a different failure mode, and teams that treat it like a faster Copilot get burned.

After several months of running agents against production codebases, here is the honest breakdown.

Tasks agents finish reliably

These are the jobs where delegation is straightforwardly profitable:

• Mechanical refactors across many files — renaming, extracting a helper, migrating a deprecated API call, converting a component pattern.
• Test scaffolding. Writing the boring 80% of unit tests for existing, well-named functions.
• Dependency and framework upgrades where a migration guide exists. The agent reads the guide and applies it repetitively; you review.
• Boilerplate features that mirror an existing one. "Add an export endpoint like the existing import endpoint" works well because the pattern is in the repo.
• Bug fixes with a reproducible failing test. Give it the test, let it iterate until green.
• Documentation and changelogs generated from actual diffs rather than imagination.

The common thread: a verifiable success condition. If the agent can run something that tells it whether it is done, it converges. If it cannot, it wanders.

Tasks agents handle badly

• Architecture decisions. It will confidently pick a pattern and spread it through the codebase before you notice.
• Anything touching auth, payments, or permissions. Plausible-looking security code is the worst kind.
• Performance work. Optimising without measurement produces cargo-cult changes.
• Ambiguous product requirements. It will not ask the question a junior engineer would; it will guess and commit.
• Cross-service changes where the other service is not in context.
• Data migrations. Irreversible operations should never be delegated.

The guardrails that matter

1. Branch isolation, always. Agents work on a branch, never on main, never with force push. This one rule prevents most disasters.

2. Scope the filesystem. Give access to the repository and nothing else. No home directory, no credential stores, no sibling projects.

3. Read-only by default for external systems. An agent that can query your database is useful; one that can write to it is a liability until you have watched it for a while.

4. Command allowlists. Permit test runners, linters, and build commands. Deny anything that deploys, deletes, or transfers.

5. Secrets never enter context. Use placeholder env vars locally. Assume anything in context could end up in a log.

6. A required human review gate. Agent-authored pull requests get the same review as a contractor's — arguably stricter, because the author cannot explain their reasoning next week.

Writing a brief an agent can execute

The prompt quality difference between a wasted hour and a merged PR is mostly specificity:

In src/billing/, add proration to subscription upgrades. Follow the existing pattern in applyDiscount. Add unit tests in the adjacent test file. Do not change the public API of SubscriptionService. Run npm test until green. Do not touch migrations.

That contains a location, a pattern to imitate, a verification command, and explicit boundaries. Compare with "add proration" — which produces a schema change nobody asked for.

Keeping a repository conventions file — style rules, directory meanings, forbidden patterns, how to run tests — pays for itself within a week, because every agent session reads it instead of guessing.

Reviewing agent output

Agent diffs read cleanly, which is exactly why they slip through. A review checklist we use:

• Did it change anything outside the stated scope? Unasked-for reformatting is the tell.
• Are the tests real? Tests that assert on mocks of the code under test are worthless and common.
• Are new dependencies justified? Agents add libraries casually.
• Is error handling honest? Swallowed exceptions and empty catch blocks appear frequently.
• Any security surface touched? Input validation, authorisation checks, SQL construction, file paths.
• Does the abstraction earn itself? Agents love premature interfaces.

Review the diff, not the explanation. The explanation is generated too.

Cost and throughput realities

Agent runs are meaningfully more expensive than autocomplete — long contexts, many tool calls, repeated test runs. Budget per task, not per seat, and kill long-running sessions that are looping. A run that has not converged in fifteen minutes is usually stuck on an unstated requirement.

The throughput gain is real but uneven: large on mechanical work, near zero on novel design, negative when the task was underspecified.

What this does to the job

The bottleneck moves from writing code to specifying and reviewing it. That elevates the skills that were always underrated — decomposing a problem, writing a testable contract, reading a diff critically — and devalues typing speed and syntax recall.

Junior engineers face a real risk here: skipping the writing phase can skip the learning. The teams handling this well pair agent use with a rule that you must be able to explain every line you merge.

Compare the day-to-day tools in Cursor vs GitHub Copilot, read about the culture shift in vibe coding, and see the review layer in AI code review tools. More in AI Coding Assistants.