"AI coding tool" covers several genuinely different products. They are not competing for the same job, and picking the wrong category is a more expensive mistake than picking the wrong product within one.
Four categories
| Category | Examples | Designed for |
|---|---|---|
| Autocomplete | GitHub Copilot | Finishing the line you are typing |
| IDE assistants | Claude Code, Cursor | A developer working on a task, attended |
| Agent sessions | Codex, Claude Code on the web, GitHub Copilot coding agent, Devin | Handing one task to an agent, then checking and steering what comes back |
| Prototyping tools | Lovable, v0, Bolt, Replit Agent | Turning an idea into something you can look at |
| Production delivery | Coroid | Changing an existing codebase to a standard you set once |
The first two put a model next to a developer. Agent sessions move the work off the developer's machine, but a person still picks each task, steers it, tests what comes back and decides it is done. Prototyping tools build something new, fast. Coroid does none of these: it runs a process you set once on every change to a codebase you already run, whoever asked for it.
Prototyping tools
An idea turned into something you can look at
Autocomplete
Finishing the line you are typing
IDE assistants
A developer working on a task
Agent sessions
A task handed off, then checked and followed up by whoever started it
Coroid
One standard on every change, whoever asked for it
A session and a factory are different problems
Agent sessions are the closest comparison, because they also end in a pull request. The difference is what carries the process.
A session runs on the person steering it. Someone decides what to work on, writes the prompt, opens the preview, finds what is broken, writes the follow-up and decides when it is done. The result is as good as that person's attention that day, and only someone who can do all of that can run one: in practice, an engineer.
A factory runs on a process you set once. Coroid keeps the steps in the system — the specification, QA against the acceptance criteria, the review, the quality policies and the approval rules — and applies them to every change. Because the process is not the requester's job, anyone can ask.
| Agent session | Coroid | |
|---|---|---|
| Who can ask for work | Whoever can run the tool and judge the diff | Anyone in the company, in plain language |
| What starts it | A person, one task at a time | One queue fed by people, issue trackers and automations |
| Who tests the result | The person who started it | A QA agent, against the acceptance criteria |
| What decides it is done | Whoever reads the diff | Your quality policies, then a person's approval |
| The same kind of task next month | As good as whoever steers it then | The same process and the same checks |
| What is kept | A transcript | Provenance: who asked, what was decided, every run and every approval |
Sessions are good at exploration: working through an unfamiliar problem with an agent, or a change you want to shape as you go. Put the work that has to meet a standard every time through Coroid. The two meet at the pull request: with the GitHub App, Coroid can run the same checks and review on pull requests your developers open with their own agents. See Reviewing pull requests.
Prototyping and production are different problems
This is the distinction worth being clear about, because prototyping tools are very good and it is easy to assume the same approach scales to production work.
Prototyping optimises for speed to something visible. You start from nothing, there is no existing architecture to respect, no test suite to keep passing, no conventions to match, and nobody depends on the result yet. Constraints would only slow you down — and correctly, those tools impose very few.
Production work is almost entirely constraints. The code already exists and has decisions baked into it. Other things depend on it. There are tests that must keep passing, conventions that should be matched, security and compliance requirements, and a review process that has to be satisfied before anything ships.
Coroid is built around those constraints rather than around avoiding them:
| Prototyping | Coroid | |
|---|---|---|
| Starting point | A blank slate | Your existing repository |
| Destination | A running demo | A pull request on a branch |
| Verification | Does it look right | Your test suite, quality gates, independent QA |
| Governance | Minimal by design | Policies, review rules, audit trail |
| Review | You look at it | Your engineers review a diff, under your branch protection |
| Success | The idea is worth building | The change is safe to merge |
They compose well
This is not an either/or. The two fit together in an obvious way:
Prototype to decide what to build. Validating an idea, exploring a UI, getting something in front of a stakeholder this week — a prototyping tool will beat Coroid at all of these, and you should use one.
Then build it where you will maintain it. Once the idea is settled, the work moves into the codebase you actually run, with your conventions, your tests and your review process. That is Coroid's job.
The prototype answers should we build this. Coroid answers build it properly in the system we already have.
When not to use Coroid
Being straight about this is more useful than a feature list:
- You are validating an idea, not shipping it. Use a prototyping tool. Coroid produces a reviewed change to a real codebase, which is unnecessary overhead for something you may throw away tomorrow.
- You want to see something visual in minutes. Coroid produces pull requests, not live demos.
- You want a pair programmer. If you want to stay in your editor and work alongside a model line by line, that is an IDE assistant. Coroid operates on whole units of work while you do something else.
- You want to explore a problem as you go. If the change takes shape while you work on it, steer an agent session. Coroid works from a specification and holds the result to it.
- You have no repository yet. Coroid needs somewhere to work — see Connect your code.
What follows from the production focus
Several things in Coroid look like overhead until you see them as production requirements:
- Work is specified before it is built, so there is something to verify against, and anyone can ask for it without knowing how it is built.
- Verification is performed by an agent that did not write the code.
- Nothing reaches your default branch without a pull request.
- Policies and gates are enforced in the execution path, not suggested.
- Every execution is recorded — cost, model, steps and evidence.
None of that is worth paying for on a throwaway prototype. All of it is worth paying for on a system your business runs on.