What Is an AI Coding Agent? (Not a Chatbot, Not Autocomplete)

Ask ten developers what an AI coding agent is and half of them will describe Copilot. That confusion isn't harmless. It leads teams to hand a bug ticket to an autocomplete tool and get frustrated when nothing gets scoped, fixed across every affected file, or tested, because autocomplete was never built to do any of that. It leads engineering managers to ask, reasonably, what can I actually leave unsupervised, about a tool that was never designed to run unsupervised for more than a single suggestion at a time. And underneath both of those is a real, unanswered question: what's the actual difference between a chatbot that answers a question in a chat window and an agent that reads your repository, plans a fix, writes the code, and writes the test proving the fix works, without you re-prompting after every step. An AI coding agent is not a smarter autocomplete and it is not a chatbot with better answers. It's a system with tool access, a task loop, and enough judgment to decide what to do next on its own. Most of what gets marketed as an AI coding agent today is neither.

Why chatbots and autocomplete tools aren't agents

Open ChatGPT or Claude.ai and paste in a stack trace, and you'll get a plausible-looking answer in seconds, sometimes the correct one. But everything about that exchange is bounded by the chat window: the model has no access to your repository unless you paste files in manually, no way to run your test suite to check whether its suggested patch actually resolves anything, and no persistent task state once you close the tab. It reasons about the problem you described, not the problem as it actually exists in your codebase. Ask it to fix a timezone bug in your invoicing module and it will write a plausible fix for a hypothetical invoicing module, because it has never seen yours. That single-turn, context-free reasoning is genuinely useful for explaining a concept or drafting a snippet. It is not the same capability as a system that opens your repo, locates the actual function, and verifies a fix against your actual test suite.

Cursor and GitHub Copilot solve an entirely different, narrower problem: reducing keystrokes while you're already looking at the right file. They're excellent at that job, predicting the next few lines based on surrounding code, autocompleting a function signature, suggesting a test based on the function directly above it. What they don't do is decide where to look. If a timezone bug affects three call sites across two files, an autocomplete tool has no mechanism for finding the other two once you've fixed the one your cursor happens to be sitting in. It doesn't scope the problem before touching code, it doesn't run a build to confirm the fix compiles, and it never decides on its own that the task also needs a regression test. It responds to wherever you already are. It has no opinion about where you should be looking next, because it isn't tracking a task, it's predicting text.

This is exactly where the confusion starts for developers coming from a Copilot-first habit. You're used to a suggestion appearing inline, accepting it, moving on, and the tool never touching a second file on its own. So when someone tells you Claude Code runs an AI coding agent, you reasonably expect a fancier version of that same inline suggestion, just smarter. Then you paste in a vague bug report expecting a patch for the one line you're staring at, and instead the tool starts asking what the actual scope should be, reading files you didn't mention, and proposing changes across three locations you didn't know were connected. That's not the tool being slow or overcomplicating things. That's the actual behavioral signature of an agent versus an autocomplete tool, and it's worth recognizing on sight instead of assuming something's gone wrong.

An AI coding agent is the thing both of those are missing: a system with tool access (it can read files, run shell commands, edit code, execute tests) wired into a loop (it takes an action, observes the result, decides the next action) with enough judgment to know when a task is finished versus when it needs to hand off to a different specialist. That loop is what lets an agent scope a bug before touching code, implement the fix across every affected call site, run the test suite to confirm nothing broke, and write a new test that would have caught the bug in the first place, all from one instruction. The chatbot answers a question. The autocomplete tool completes a line. The agent owns the task from report to verified fix.

That's also the trust question newcomers keep asking, phrased different ways: what can I leave unsupervised, what happens if it's wrong, do I need to babysit every step. The honest answer is that trust in an agent isn't about blind faith, it's about whether the loop includes verification. A chatbot's answer needs to be manually checked against your code, every time, because nothing in the exchange confirmed it. An autocomplete suggestion needs to be manually reviewed before you accept it, every time, because nothing ran it. An agent that plans, implements, and then writes and runs a test that fails on the old code and passes on the new code has produced its own evidence. That's the actual boundary: not what looks impressive in the response, but whether the tool checked its own work before handing it back to you.

Apex, Spine, and Proof: what a real agent team looks like

Tonone's Apex is built specifically for the first judgment call in that loop: deciding what a task actually requires before any code gets touched. Give Apex a one-line bug report and it doesn't start writing a patch. It runs apex-recon first, reading the relevant part of the codebase to find where the bug actually lives, what else touches that code path, and whether existing tests already cover it. Only after that recon does apex-plan produce a scoped plan, typically with more than one depth option so you decide how much to invest before a single line changes. This is the step that both the chatbot and the autocomplete tool skip entirely. Neither reads your repository before answering; both jump straight to output. Apex's job is to make sure the thing being built is scoped against what's real, not against a guess about what a typical codebase looks like.

Tonone's Apex reads the actual codebase with apex-recon before it scopes any fix, so the plan is grounded in what's real, not a guess about what a typical invoicing module looks like.

Once a plan is approved, Spine is the specialist that implements it. Spine owns backend and API work: it applies the fix across every call site apex-recon flagged, not just the one line a bug report happened to mention, and it does so inside the existing service architecture rather than bolting on a workaround. Where an autocomplete tool would patch the function your cursor is sitting in, spine-service looks at the service boundary the bug belongs to and implements the fix at the right layer, whether that's the shared parsing utility three call sites depend on, or the endpoint that calls it.

The step every non-agent tool skips is verification. Proof is the specialist that writes and runs the regression test, using proof-e2e to encode the exact failure condition, in the example below, invoice totals computed at a timezone offset that previously produced the wrong number, as a test that fails on the old code and passes on the fix. That test doesn't just confirm the fix once; it stays in the suite and catches the same class of bug if it's ever reintroduced. A chatbot's answer disappears when you close the tab. An autocomplete suggestion disappears the moment you accept or reject it. A regression test is permanent, which is exactly why the agent that writes one is doing meaningfully different work than the tools that don't.

A first agent session, worked end to end

Here's what that looks like in practice. Priya, a backend engineer three days into her first Claude Code project, gets a support ticket: "Invoice totals are off by a few cents for some EU customers." No file names, no stack trace, no repro steps. That's a realistic first bug report, and it's also a good test of whether an AI tool is actually an agent or just a fast typist.

She runs /apex-plan with the ticket text as the only input. Apex runs apex-recon first and finds the actual shape of the problem: a formatInvoiceDate utility in lib/billing/invoice.ts that converts UTC timestamps to local time using a fixed offset table instead of a timezone-aware library, three call sites (generateInvoice, emailReceipt, and the admin dashboard's InvoiceRow component), and zero existing test coverage on any of them. Recon also bounds the actual customer impact: invoices generated between 8 PM and midnight local time for the roughly 14% of customers on UTC-negative offsets, with totals off by amounts between $0.01 and $4.32 depending on how many line items rolled past midnight.

$ /apex-plan "Invoice totals off by a few cents for some EU customers"

Apex, recon complete
  lib/billing/invoice.ts: formatInvoiceDate() uses fixed UTC offset table
  Call sites: generateInvoice, emailReceipt, InvoiceRow (admin dashboard)
  Test coverage: none on any of the 3 call sites
  Impact: ~14% of customers (UTC-negative), invoices generated 8pm-midnight local
  Discrepancy range: $0.01 - $4.32 per invoice

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
S, Patch the reported call site only
  Fix generateInvoice's date conversion. Leave emailReceipt and
  InvoiceRow on the old offset table.
  Time estimate:   ~30m
  Risk:            Low effort, but 2 of 3 call sites stay broken.

M, Fix the utility, update all 3 call sites, add regression coverage
  Replace fixed-offset logic in formatInvoiceDate with timezone-aware
  conversion. Update all 3 call sites. New test for the midnight
  rollover case.
  Time estimate:   ~2h
  Risk:            Low. Contained to the invoicing module.

L, Audit all date handling app-wide
  Same fix, plus scan for the same fixed-offset pattern elsewhere
  (shipping estimates, subscription renewal dates).
  Time estimate:   ~1d
  Risk:            Medium. Touches modules outside billing.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Recommendation: M. Escalate to L only if the same offset pattern
shows up elsewhere during Spine's implementation.
Next: approve a tier, then Apex dispatches Spine + Proof.

Priya approves the Medium option. Apex dispatches Spine, which replaces the fixed offset table in formatInvoiceDate with a timezone-aware conversion, matching the library the rest of the billing module already uses, and updates all three call sites recon flagged, not just the one named in the original ticket. Then Apex dispatches Proof, which writes a regression test in the invoicing test file: it asserts the correct total for an invoice generated at 11:47 PM in America/Los_Angeles time, a case that fails against the old fixed-offset code and passes against Spine's fix. Priya reviews the diff, sees a scoped change to one utility and three call sites plus one new passing test, and ships it.

The whole loop, recon, plan, approval, implementation across three files, and a new regression test, ran inside one conversation. Priya never had to tell Apex which files to check, never had to ask Spine to look at the other two call sites, and never had to write the test herself. That's the difference a newcomer feels immediately: not smarter code completions, but a task that got owned end to end instead of answered once and handed back half-finished.

AI coding agent vs chatbot vs autocomplete

Put side by side, the functional gaps are concrete, not philosophical. Each row below is a capability a newcomer specifically needs to judge whether a tool is an agent, a chatbot, or an autocomplete layer wearing agent branding.

Tonone's agents run a plan, implement, verify loop, apex-plan scopes it, a specialist like Spine implements it, and proof-e2e verifies it with a test that outlives the conversation.

Install and try

Tonone is free and MIT-licensed. Install it once and Apex, Spine, Proof, and the rest of the team are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself.