AI Coder: Four Categories, and Who Accepts Their Output

What is an AI coder

The term covers tools that work in very different ways, and the research literature sorts them by how much they do on their own. Agarwal, He and Vasilescu separate two paradigms (MSR 2026). Assistants "operate synchronously within the editing workflow, offering suggestions that developers can accept, modify, or reject as they type". Coding agents "can work asynchronously, potentially completing full features or bug fixes independently". Their agents include the in-editor kind, which gets a category of its own here, and the line extends one step further, to tools that build a whole application. A survey of vibe coding by Ge and colleagues sorts commercial tools into three types and gives the builders one of their own, "End-to-End", next to tools embedded in the editor and tools run from the command line (preprint, 2025).

The word agent needs care here. Our working terminology for agent systems defines it as "A stateful program that issues calls to one or more models in a control loop, maintains context across calls, and may invoke tools to affect the world or read external state." By that definition a completion assistant is a model call without the loop, and the other three categories are agents.

The four categories

Completion assistants

A completion assistant predicts the code that comes next and shows it in place, a line or a block at a time. The developer accepts or rejects each suggestion as they type, and the developer stays the author: they chose each line, and the change goes through the team's ordinary review afterward.

In-editor agents

An in-editor agent works inside the developer's own session, in the editor or the terminal. Given a request, it reads files, plans, edits several of them, runs the build and the tests, reads the failures and tries again. The developer watches, approves some steps as they happen and reviews the diff before committing it. The same terminology explains what happens to the session itself: "Sessions are ephemeral; when a session ends, its working memory (in-context state) is lost". Unless the team keeps the transcript, the commands and the test runs with the change, the reviewer of the commit sees only the diff.

Autonomous coding agents

An autonomous coding agent takes a task, such as an issue, and works on it out of sight, in an environment of its own. What comes back is a pull request: a diff, a description of the change written by the agent, and the results of whatever checks the repository runs. The person who accepts is the reviewer who merges, and that person meets the work for the first time at the end.

Prompt-to-app builders

A prompt-to-app builder turns a description in plain language into a running application, front end, data and deployment included, and refines it as the person keeps describing what they want. It puts a working tool within reach of people without engineering training, and lets engineers try an idea quickly. In the simplest case, the person who accepts is the one who wrote the prompt, and they accept by using the application. For a prototype, that is the acceptance the work needs. Trying the application is a form of validation, the step the US Federal Highway Administration's systems engineering guide puts in the hands of the people the system is for, under a plan and with the results written down: "The system owner and system users actually conduct the system validation." (FHWA, Systems Engineering for ITS) The verification levels in between are a separate matter, covered below.

The four categories on the V-model

The V-model is the life-cycle picture used across systems and safety engineering. Design runs down the left side, from requirements to implementation at the bottom. Verification and, at the top, validation run up the right side, and in the common form of the model each test level checks the design level opposite it: unit tests against the module design, integration tests against the architecture, system tests against the system design, acceptance tests against the requirements. The same FHWA guide puts the symmetry in one line: "Components that are identified and defined on the left side of the Vee are integrated and verified on the right." (FHWA, section 3.3.9)

Placing the four categories on it shows two things.

The further a category reaches, the more of both sides it writes. A completion assistant works inside implementation. An in-editor agent takes a module-level request, writes the code and runs the unit tests. An autonomous coding agent does the same and hands back integration results from the repository's own checks. A prompt-to-app builder starts from the requirements and returns a running system. Within its span, each tool writes the definition and, where it runs tests, the check of that definition as well. The white paper AI Has Moved the Bottleneck states why that matters: "Producer-generated tests and self-review are useful. They are structurally limited because they can reproduce the same assumptions or omissions."

The point of acceptance moves up the right side, and fewer levels have a person looking in between. With a completion assistant, a person accepts at every suggestion. With an in-editor agent, at the diff. With an autonomous agent, at the merge. With a builder, by trying the finished application. The levels the tool crossed on the way get no separate human look unless the team adds one.

Who accepts the output

Feng, McDonald and Zhang describe levels of agent autonomy by the role left to the person: "operator, collaborator, consultant, approver, and observer" (2025). Their lowest level covers the completion assistant, where the agent "suggests code autocompletions", and they say where that level belongs: "This makes L1 agents well-suited for high-stakes, high-expertise workflows where autonomous agent activities can be particularly costly if inaccurate, and/or where the lack of user involvement can easily lead to accountability concerns and legal consequences." An autonomous coding agent puts the person in the approver role, which they define this way: "As an approver, the user is only required to interact with the agent when the agent encounters a blocker it cannot resolve on its own." They also name the risk that comes with the role: "How can users be engaged in agent activities to avoid meaningless rubber stamping?"

Pull requests from coding agents are where the question has been studied. Watanabe and colleagues matched 567 pull requests made with one agentic coding tool against 567 human pull requests by the same authors in the same 157 open-source projects (ACM TOSEM, 2026). They found that "83.8% of Agentic-PRs are accepted by human reviewers, although their acceptance rate remains statistically lower than Human-PRs (91.0%)." Then: "We examined all 475 merged Agentic-PRs and identified 214 Agentic-PRs (45.1%) that had modifications between initial submission and merge." Bug fixes were the most common kind. Their recommendation to the makers of coding agents matches where the V-model leads: "We recommend attaching a 'confidence card' to each PR, including the plan followed, key assumptions, considered alternatives, and known edge cases. A reviewer checklist could guide targeted human scrutiny."

A merge records who accepted and when. Peralta and colleagues looked at what happens before it, in agent pull requests from popular repositories that a person had reviewed (MSR 2026). In a sample of 364 merged pull requests inspected by hand, they found that "Most merged PRs (288 PRs, 79.1%) were merged with no observed feedback loop": the reviewer neither asked for changes nor made any. Such a merge may rest on a careful reading. What the reviewer checked is missing from the record, and for software whose failure has consequences the record is what a later reviewer, an assessor or an incident investigator will have.

The FHWA guide makes the white paper's point about human developers and testers: "The degree of independence between the developer and the tester and the level of formality in unit testing should be commensurate with the criticality of the software and the size of the project." It gives the reason in one line: "Few individuals can effectively wear both of these hats." An agent that writes the code and its tests wears both, and our white paper The Agentic Engineering Assurance Layer adds the distinction the merge button hides: "Permission is still not acceptance. An agent may be authorized to propose or execute a change without being authorized to declare that the change satisfies its engineering obligations."

What each category needs around it in consequential work

All four can be used in software whose failure has consequences. Each needs something different around it before its output can be accepted there, and the difference follows from where it sits on the V.

• Completion assistants need nothing new. The developer is the author, and the team's ordinary review and test levels apply as before.
• In-editor agents need the session kept. The transcript, the commands the agent ran and the test results belong with the change, so the reviewer of the commit sees what the developer saw.
• Autonomous coding agents need the intent written before the task, by a person, and tests at the levels that matter kept apart from the producer, as far apart as the consequence requires. The reviewer should get that evidence along with the diff and the description the agent wrote.
• Prompt-to-app builders need the levels they cross in one step checked one by one before their output carries consequence, as for the other three.

The code review checklist for agent-written changes in our companion piece turns these into questions a reviewer can ask of any single change.

Where Kealu Vector fits

The Agentic Engineering Assurance Layer is the proposed category for the layer that governs how agentic engineering work is performed and evidenced, so that humans can trust and accept the resulting work. The white paper The Agentic Engineering Assurance Layer develops it as a vendor-neutral category, and the questions raised here hold whatever tools a team uses to answer them. Kealu Vector, currently designated Vector Assurance Assist, is our early-access implementation of that category.

Frequently asked questions

What is an AI coder?

An AI coder is software that writes code with a language model, and the four categories in use today differ in how much of the engineering work they carry out before a person looks at the result: completion assistants, in-editor agents, autonomous coding agents and prompt-to-app builders.

What is the difference between an AI coding assistant and an AI coding agent?

A completion assistant suggests code for a developer to accept one suggestion at a time. An AI coding agent is a program that calls a model in a loop, keeps context and uses tools such as the editor, the terminal and the test runner to carry out a task. In-editor agents do that inside the developer's session, and autonomous coding agents in an environment of their own, returning a pull request.

Who is accountable for code an AI coding agent writes?

The person who accepts it, in the same way they would be for code from a contractor. As AI Has Moved the Bottleneck puts it, "An automated rule can execute a decision. It cannot be held accountable for the consequence." Accepting the change, and answering for it later, stays with a named person.

Which category of AI coder is right for safety-critical software?

Any of the four can contribute to it. What changes with consequence is what has to sit around the tool: intent written down before the work, checks kept apart from the producer in proportion to the risk, a person with the authority to accept at each level that needs one, and a record that survives the session.

Where do AI code checkers fit?

Checkers sit beside all four categories and report problems in what the coders produce. Our companion piece on AI code checkers maps the five kinds and gives a review checklist for agent-written changes.