Most AI coding tools are interactive. You prompt, they respond. You accept or reject. The loop is fast, the feedback is immediate, and you’re in control of every keystroke.
Background coding AI breaks that model. You’re not there. The agent decides what to work on, writes the code, runs the tests, and commits. By the time you look, the work is done.
These are not the same thing with different UIs. They’re different primitives.
What background means, operationally
An interactive tool works from what you’re looking at. A background agent works from what you’ve written down. The input shifts from your cursor position to your direction document. If you haven’t written what matters, the agent guesses. The diff looks plausible. The context it was missing becomes obvious only after you’ve merged it.
This shifts the bottleneck. With interactive AI, the bottleneck is the back-and-forth. With background AI, the bottleneck is the quality of your written priorities. Vague direction produces vague commits.
The constraint is always upstream of the session, not inside it.
What it doesn’t do
Background AI doesn’t replace review. It produces commits for you to review, the same way a contractor produces pull requests. The agent isn’t your coding self running unsupervised. It’s a fresh reader who picks up your specs cold, works them, and hands back a diff.
It doesn’t accelerate interactive work. If you’re debugging a live issue or pairing with a user on a call, you need an interactive tool. Background AI is for the work that doesn’t need you present: the backlog, the maintenance, the tests that keep getting deferred.
It doesn’t bootstrap context. The first nights are orientation. Agents read your codebase and your history. Output quality tracks accumulated context, not raw model capability. The second week ships better code than the first.
What makes it different from a script or a cron job
A script executes a fixed procedure. A background agent reads current state, decides what’s worth doing, and adapts. It reads your git log and doesn’t redo what just shipped. It reads your failing tests and fixes the failure before adding features. It reads your spec and asks which part is incomplete enough to cause problems downstream.
That’s not a cron job. It’s judgment applied asynchronously.
The judgment is bounded by your direction, by your constraints, by what the tests will accept. But within those bounds, it’s not executing a playbook. It’s working.
The actual question
The question isn’t “can AI code in the background?” It already does. The question is what you have to provide to make the output worth reviewing.
Specific priorities. Hard constraints. A codebase that can verify itself.
Write that, and the background shift produces commits you’ll merge. Skip it, and you’ll spend your mornings reverting work that almost did the right thing.
The bottleneck moved. Not from fast to slow. From interactive to written.