What Is Agentic Coding and How Does It Actually Work
Learn what is agentic coding, how it differs from autocomplete, and how multi-agent orchestration works in practice through concrete examples.
You ask an agent for a database migration. It finds the pattern the project already uses, writes the file, runs the tests. A schema check fails. It edits the migration and tries again, and at no point in that sequence did you type another prompt.
That is agentic coding: the agent read one result and chose the next step. Each individual action still looks like ordinary development work.
By the end of October 2025, researchers estimated signs of coding-agent adoption in 15.85% to 22.60% of 129,134 GitHub projects, with file-level and commit-level traces counted separately (arXiv study summary). Those are the first-version figures from "Agentic Much? Adoption of Coding Agents on GitHub" (Robbes et al., arXiv 2601.18341, January 2026). The April 2026 revision puts adoption at 22.20% to 28.66% of 128,018 projects.
Where you stop typing
Start with a task that carries its own check. Add a validator, keep the tests green.
- It searches for the request handler and its tests.
- It edits the validator and adds a test.
- It runs the focused test command.
- The command reports a failure.
- It reads the failure and changes the code.
- It runs the test again.
- It reports the result or asks you a question.
Everything hangs on the gap between steps four and five. Prompt-driven, you read the failure and type the next instruction. Here the agent reads it and keeps going.
The transcript shows the order plainly:
$ test command
FAIL: expected 400, received 200
agent: inspecting request validation
agent: editing validator
$ test command
PASS
A big patch can skip that loop entirely, and its size proves nothing. The read-decide-act cycle is what makes the work agentic.
Autocomplete predicts text near your cursor and stops there. Chat answers, then waits for you. An agent acts on the repository and reads what came back.
| Mode | First action | What happens next |
|---|---|---|
| Autocomplete | Predicts code | Accept or reject |
| Chat | Answers you | Ask again |
| Agentic coding | Acts on the repo | Reads the result, acts again |
You still review the plan, edits, evidence, and task scope.
What AuricIDE adds when one agent becomes several
One agent gives you one loop to watch. With several agents, each process can be in a different state. One may be editing while another runs tests. A third may need permission. Separate terminals reveal those states one window at a time.
In AuricIDE, you pin repositories as tiles. Each tile gives you a fixed place to start work. Launch an agent CLI there, and AuricIDE runs it as a separate local process. Its output stays attached to that agent. When the process ends, AuricIDE keeps its real exit code. One failed process does not take the other agent processes with it.
The tiles sort themselves by what needs you first. An error comes before blocked input. Blocked input comes before a stalled process. That order turns several terminal streams into a response queue.
- Error: open the failed process and read its output.
- Blocked on input: answer its permission or clarification request.
- Stalled: check whether it is waiting, disconnected, or stuck.
The ranking does not make the choice for you. It tells you where to look first.
Agents also need the same task facts. AuricIDE keeps project data in one file inside the project folder. It tells git to ignore that file, so the record stays on your machine. The MCP server gives agents tools for reading and updating the record. A client lists the available tools, then calls one (MCP tools specification). MCP can give each agent the same ticket facts. Your process must still assign ownership and resolve conflicting edits.
AuricIDE can run different CLI tools. Their wrappers are called harnesses. To add one, open Settings → Agent and import a dynamic provider. The imported JSON names the executable and its arguments. AuricIDE validates the file and registers the provider without a rebuild. The original CLI harness still runs underneath.
You can also arrange launch presets as a chain. Each step has its own prompt. When one step ends, the next receives a cleaned tail from its terminal output. The handoff is plain text, so different CLIs can read it. If a step fails, AuricIDE stops the chain. Later steps do not build on that failed result.
What the loop costs
An agent can react to a failed test. It cannot prove that the test checks the intended behavior. A command may pass while the change breaks an API contract. The agent can read that success and continue.
Unclear product rules cause another problem. Suppose an API receives an invalid value. Should it return an error, preserve the old behavior, or normalize the value? Code and tests may not answer. The agent can choose a consistent option that still misses the intended contract.
Permission prompts can pause a healthy-looking process. You must notice the request and answer it.
A zero exit code proves one command finished, and nothing more than that. An edit can compile cleanly and still break a caller. A test can pass because somebody quietly moved the assertion to accept the wrong answer.
Chains lose detail as well. The handoff is filtered rather than forwarded whole. A cut tail can drop an earlier decision, or the very command that failed. Plain text is what lets different CLIs talk to each other. It is also what leaves the handoff without any structure to lean on.
Keeping the data next to the project cuts the same way. AuricIDE puts it in a SQLite file inside the project's own folder, which is not where such files usually go. Tauri-based desktop applications commonly keep local databases in OS-specific application-data paths, including C:\Users\<Username>\AppData\Roaming\... on Windows and ~/.local/share/... on Linux (Tauri SQLite storage guide). A separate guide describes this local SQLite pattern as serverless and zero-configuration, with prepared statements, transactions, and connection pooling for offline-first desktop work (Tauri SQLite integration guide). Move the project and its record moves with it. Handy, right up until you realise the file is now something your backups have to know about.
The overhead has to earn its place. A one-line change with an obvious test is usually faster by hand. Agentic work pays off on tasks with a clear target, real feedback, and enough independent work to be worth supervising.
The rule that holds in any tool
Watch who picks the next action once a command returns. Read the result and type again, and the loop is yours. If the agent reads it and moves, the workflow is agentic.
That line is also where you decide to step in. Product choices, unclear contracts and anything risky stay with a person. What you hand the agent is a check it can read: a focused test, a lint rule, a build.
Running several agents adds a second lesson. More loops mean you need visible state and an order to respond in. Shared facts about the task, and someone who owns each piece. No interface or protocol makes that need go away.
So start narrow: one task, one clear check. Then watch the first command that fails. What happens next tells you whether the agent can carry on alone.
AuricIDE is an open-source desktop IDE for running CLI coding agents as a coordinated fleet: auric-ide.tech.