AI Coding Agent: What Happens After the Code Is Written
Every AI coding agent roundup scores the same things: context window, multi-file edits, memory, price. Not one scores what happens after the code exists. That gap is where the real work lives: review, deployment, permissions, audit.

What is an AI coding agent?
An AI coding agent takes a goal in plain language and carries it out inside a real repository. It plans the steps, edits files, runs terminal commands, executes the tests, reads what broke, and tries again. Google defines agentic coding as "a software development approach where autonomous AI agents plan, write, test, and modify code with minimal human intervention" (Google Cloud).
The loop is the category boundary. A model that emits a function has made a suggestion. An agent that runs it, reads the stack trace, and rewrites it has produced a change verified against reality.
What the output becomes is the part most evaluations skip. A coding agent hands back a diff, and a diff is not working software. Someone reviews it, CI runs it, someone deploys it, and there should be a record of which agent did what with whose credentials. Major is built for that second half: the enterprise platform where agents build the software they run on, so the output is a deployed, permissioned, audited app rather than a branch waiting for a home.
Agent, assistant, or autocomplete?
Three modes get called "AI coding" and share almost nothing operationally.
- Inline completion: triggered by your keystrokes, no autonomy, proposes text at the cursor and stops.
- Chat: triggered by a question, no autonomy, returns code you copy, paste, and run yourself.
- Agent: triggered by a goal, plans, edits files, runs commands, checks its own output, and iterates.
For procurement, the question is who executes. In the first two modes a human runs the code and sees the failure. In the third the software does, which means it holds permission to touch a file system, a shell, and usually a git remote. That permission is what your security team will ask about, and it appears on no feature comparison.
How the agentic loop works in practice
Take a ticket that says invoice totals are wrong for yen, because the formatter assumes two decimal places everywhere.
- Orient. The agent greps for currency formatting and finds two call sites in the invoice service and one in the PDF renderer.
- Write the failing test. It asserts that a JPY total of 1,200 renders with no decimals, runs the suite, and confirms the test fails for the expected reason.
- Change the code. It swaps the hardcoded exponent for a lookup against a currency exponent table and reruns the suite.
- Read the damage. The new test passes and two older ones fail. It updates the one asserting the old wrong behavior, then stops on the other because it encodes a finance rule the codebase cannot confirm.
- Hand off. It opens a pull request with the diff, the test output, and a note naming the case it refused to touch.
Steps one through four are what gets benchmarked. Step five is where the cost lives. Who reviews that PR, and how long is their queue? Did the agent hold a token that could push to main, or only open a branch? Six months on, what shows which agent edited the money helper, and on whose instruction?
What the roundups score, and what they skip
Every criterion in the top guides sits upstream of the merge button: codebase context, multi-file accuracy, memory across sessions, language coverage, speed, pricing. "Security model" usually means whether your API keys reach the model. That is a real question and a narrow one. Review workflow, deployment path, credential scope at the moment of action, and the audit record after a change lands rarely get a row.
Google's own governance guidance is more direct than any ranking. It recommends guardrails so agents cannot push straight to production, dependency governance against typosquatted packages, human pull request review on every change, action logging for an audit trail, prompt-injection monitoring, and SAST and DAST scanning of agent-generated code. The company with the most to gain from selling agentic coding is the one saying the hard part comes after generation.
How to evaluate a coding agent
Score two halves. The generation half is well covered by the market.
- Context handling: how it picks what to read from a repo it cannot fit in context.
- Multi-file editing: whether it can change a signature and fix every call site in one pass.
- Tool access: which commands it can run, and whether you can restrict the set.
- Revision quality: how often fixing one test breaks two others.
The second half is where teams get hurt.
- Review workflow: does output arrive as a reviewable PR with test evidence, or as edits already applied?
- Rollback: how you revert a change that passed review and failed in production.
- Deployment path: what stands between a merged agent change and production traffic.
- Credential scope: what token the agent holds while acting, and whether it is scoped per action.
- Audit trail: whether you can show which agent made a change, on what instruction, six months later.
- Prompt-injection containment: what happens when an issue body or fetched doc contains instructions, given the agent reads untrusted text with tools in hand.
Where coding agents break down
They are strong on well-specified work in a codebase with tests, and weak wherever the spec is the hard part. On a large unfamiliar system they produce changes that are locally correct and architecturally wrong, because nothing in the repo encodes why.
The trust data agrees. In the 2025 Stack Overflow Developer Survey, 84% of developers reported using or planning to use AI tools, while 33% trusted their accuracy and 46% actively distrusted it. The top frustration, cited by 66%, was "AI solutions that are almost right, but not quite" (Stack Overflow). Generation throughput rose and human review throughput did not. A team that doubles its merge rate without changing how it reviews has moved the queue, not shortened it.
Build what the coding agent produces on Major
Major does not replace the coding agent in your editor. It changes what the finished artifact is. When an agent works out a repeatable workflow, it builds an app for that part on Major and then runs the app instead of reasoning through the steps again. Reason once. Run forever.
Here is a concrete version for the pull request problem above.
- Connector: GitHub, scoped to read pull requests and post review comments, with no push access.
- App: a review-queue app with a managed database that stores each agent PR, its test evidence, reviewer, status, and age. State lives in the app, not in a chat that ends.
- Agent: judges only what needs judgment, such as whether a diff touches a finance rule or a permissions file, and routes those to a named owner.
- Workflow: triggered on a GitHub pull request event, so the repeatable checks run as deterministic code on every PR.
- Notification: Slack posts the exceptions to the owning channel for human approval.
- Governance: scoped credentials through the credential proxy, role-based access on the app, and an audit log of every action. An injected prompt cannot leak a secret the agent never held.
Cost follows the same shape. The model carries the front-loaded reasoning once, and repeat runs lean on the app, so spend is front-loaded and then flat rather than climbing with every run. The model still does the judgment calls. It just does fewer of them.
Start building on Major
If your agents keep producing diffs and scripts that nobody governs, build the review queue, the reconciliation step, or the reporting job as a Major app with permissions and an audit trail attached from the first deploy.
Related articles
Frequently asked questions
- What is an AI coding agent?
- An AI coding agent takes a goal in plain language and carries it out inside a real codebase, using tools like the file system, terminal, and version control. It plans the steps, writes and runs code, reads the failures its own output produces, and corrects them. What it hands back is a diff, which still needs somewhere governed to run. Major is that destination, where generated software gets a database, permissions, and an audit record.
- What is the difference between an AI coding agent and an AI coding assistant?
- Trigger and autonomy separate them. An assistant responds to what you type, proposing completions or returning code you copy and run yourself. An agent takes a goal and executes it, editing files, running terminal commands, and checking its own output against the test suite. The practical difference is who executes the code and who observes the failure.
- Are AI coding agents safe to use in production code?
- They are as safe as the process around them. Google recommends human pull request review on every agent change, guardrails so agents cannot push straight to production, dependency governance, action logging, and SAST and DAST scanning. Prompt injection through issue text is the newest risk, because the agent reads untrusted content while holding credentials. Major routes access through a credential proxy, so a compromised prompt cannot leak a secret the agent never held.
- Can an AI coding agent deploy code by itself?
- Technically yes, if you give it credentials that reach your deployment pipeline, which is exactly why most teams should not. Google's first governance recommendation is that agents must not push straight to live environments. Decide what an agent may do at the moment it acts, rather than after the change lands. Major enforces that boundary in the platform, so deploys happen inside scoped permissions with every action recorded.
- What is the best AI coding agent?
- No single tool wins for every team, so score candidates against your codebase size, language mix, and how much autonomy your review process can absorb. Judge both halves: generation quality plus review workflow, deployment path, credential scope, and audit trail. Most rankings measure only the first half. Major is where the code those agents produce becomes governed, deployable, stateful software.