Backlog Automation
Coding Agents vs. Coding Assistants
The practical difference between a coding assistant you drive turn-by-turn and a coding agent that executes a scoped task end to end.
RepoFixer Team · · 2 min read

"AI coding tool" has become a label broad enough to cover autocomplete, chat panels, and fully autonomous pipelines, which makes it a bad word to build expectations around. Two categories underneath that label are worth telling apart: coding assistants and coding agents.
Coding assistants: you drive, it helps
A coding assistant sits inside your workflow and responds to what you ask it, one step at a time. You write a prompt, it suggests a completion, a diff, or an explanation, and you decide whether to accept it, edit it, or ask again. The unit of work is a single exchange, and the human is in the loop for every one of them.
This model is good at exactly what it sounds like: speeding up the parts of coding where a second opinion or a fast first draft helps, with a human making every decision about direction.
Coding agents: a scoped task, executed end to end
A coding agent takes a larger unit of work (a ticket, not a prompt) and works through the multiple steps needed to complete it without a human driving each one: understanding the ticket, examining the relevant code, making the change, and verifying it against the project's own build or test process.
The tradeoff is structural, not just about capability. Because a human isn't approving each intermediate step, the guarantees have to come from somewhere else: the scope of what the agent is allowed to touch, the isolation of where it executes, and a mandatory review step before the result ships. Take any of those away and "coding agent" starts to mean "unsupervised code changes," which is a different and much riskier thing.
Where RepoFixer sits
RepoFixer is built as a coding agent system, not a chat assistant embedded in the marketing site. It takes a ticket (created directly or synced from Jira), researches and scopes it, executes the change on an isolated server (via Cursor and/or Claude, depending on what's enabled), and opens a pull request. No human drives the middle of that process turn-by-turn.
What keeps that safe to run against a real repository is not a claim about the agent being unusually careful. It's the isolation model (a worker that authenticates with its own bearer token and never touches your database directly) and the fact that the agent's output is a pull request, not a merge. An engineer reviews it exactly like any other change. See the platform overview for how this fits into the rest of RepoFixer's lifecycle, from project intake through ongoing maintenance.
The question worth asking about any "agent"
If a product calls something an agent, it's worth asking two questions before trusting it with a real repository: what is it actually allowed to touch, and what happens between its output and something shipping. "It's an AI agent" answers neither. The isolation model and the review step do.