← Jimmy Wong

· 4 min read

AI Coding Agents for Backend Engineers: What Actually Helps ​

A year ago, most AI help in my editor was autocomplete. Now the tools are agents: they read the codebase, run commands, edit several files and check their own work. Claude Code went generally available in May 2025. GitHub Copilot has agent mode in VS Code, a coding agent that turns issues into pull requests, and a CLI. Cursor, OpenAI's Codex and Google's Gemini CLI are in the same race.

On PHP, Node.js and Terraform work, they're neither magic nor useless. Here's my honest take on where they earn their keep in backend work.

✅ Where They Actually Help ​

1. Writing tests ​

This is my favourite use. Point an agent at a service class and ask for PHPUnit or Jest tests covering the edge cases. It reads the code, writes the tests, runs them and fixes what fails. You still need to check that the assertions mean something, but the scaffolding is done in minutes.

2. Refactors with good test coverage ​

"Extract this into a value object and update every caller" is tedious for a human and easy for an agent, as long as there are tests. The test suite is what keeps the agent honest. It can run it after each step and catch its own mistakes.

3. Exploring legacy code ​

Ask "How does an order get from the controller to the queue?" and an agent will trace it through the files and explain it. On an unfamiliar codebase, that can replace an afternoon of reading. Treat the answer as a map to check, not as documentation.

4. Migration grunt work ​

Framework upgrades are mostly mechanical. I let Rector do the deterministic part:

php
<?php

use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets()
    ->withComposerBased(symfony: true, doctrine: true, phpunit: true);

Then I hand the leftovers to an agent: deprecations Rector can't fix, config format changes, and broken tests. Rector is predictable, and the agent fills the gaps. Together they're much faster than either one alone.

5. Writing Terraform ​

Agents are good at HCL boilerplate: modules, variables, outputs and IAM policies. They're also good at explaining a confusing terraform plan. I never let one run apply, though. The plan output is the review.

6. A first pass on PR reviews ​

Copilot code review, Claude Code's GitHub Actions integration and similar tools catch typos, missing null checks and inconsistent naming before a human looks. They don't replace a human reviewer, but they clear out the noise so that person can focus on design.

⚠️ Where They Go Wrong ​

Confident wrong answers ​

Agents rarely say "I don't know". They'll invent a config option, use a method from the wrong framework version or "fix" a test by weakening its assertion. The output always looks plausible, so you still need to know enough to spot when it's wrong.

Security ​

Generated code can include SQL built by string concatenation, missing authorisation checks or overly broad IAM policies. There's also prompt injection: an agent that reads a malicious README, issue or web page can be talked into doing something you never asked for. The more the agent is allowed to do, the more that matters.

Secrets ​

An agent with shell access can read your .env file and send its contents to a model provider. Most tools let you block that. In Claude Code it's a deny rule in .claude/settings.json:

json
{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"]
  }
}

Better still, don't keep production credentials on your development machine.

Over-large diffs ​

Ask for one small fix and you might get forty changed files, with renamed variables and a "tidied" config along the way. Big diffs are hard to review, and that's where bugs get in.

🛡️ My Guardrails ​

  • Small, well-defined tasks. One ticket, one concern. If I can't describe it in a few sentences, it's too big.
  • Tests first. I write or agree on the tests before the implementation. Then "done" means "green", not "looks right".
  • Review everything. I review agent output like a pull request from a new colleague: every line, before it's merged.
  • Project instruction files. A CLAUDE.md for Claude Code, or an AGENTS.md, which Codex, Cursor, Copilot's coding agent, Gemini CLI and others read. It tells the agent how to run tests, which coding standards to follow and what not to touch. AGENTS.md is now stewarded by the Linux Foundation's Agentic AI Foundation, so it isn't tied to one vendor.
  • MCP servers, used carefully. The Model Context Protocol lets agents talk to databases, issue trackers and API platforms. It's useful, but every server you add gives the agent more access. Use read-only credentials where you can.
  • Restricted permissions. Allow test and lint commands. Ask before anything that deploys, migrates or pushes.

🎯 Conclusion ​

Coding agents don't replace backend engineering judgement. They make it more important. They work best on tasks with a clear definition of "done", such as tests, mechanical refactors, upgrades and boilerplate. They're riskiest when they're working on code you don't understand. Keep tasks small, let the tests define success and read every diff.

Copyright © 2026 Jimmy Wong