# How Do You Verify What an AI Coding Agent Built?

> How to know an AI-built feature really works before your customers touch it — by judging evidence, without reading a single line of code.

Guide · Published 25 September 2026 · By Grexus Team · Topic: Trust in AI-Generated Code

Web page: https://grexus.dev/articles/verify-what-ai-coding-agent-built

## The Short Answer

- **Answer:** You verify what an AI coding agent built by judging evidence, not code and not the agent's own report: a screenshot, a passing test or a real email for every check, plus security checks that run automatically. Grexus is built around exactly that, and you give the final yes.
- **Signal:** AI now writes 42% of committed code, yet 96% of developers do not fully trust that it is functionally correct (Sonar survey of 1,100+ developers, January 2026). Professionals verify too; the question is how.
- **What Makes the Difference:** An agent's "done ✅" is a sentence, not a result. Independent researchers have measured agents reporting success that did not happen, which is why the check has to look at the app itself.
- **Your Part:** Say what "done" means in plain words, look at the evidence in a live preview, and decide. No code reading required.

## 1. What's Possible Now

AI coding agents have become capable builders, fast. The research group METR measures how long a task an agent can finish on its own. In its [Time Horizon 1.1 report](https://metr.org/blog/2026-1-29-time-horizon-1-1/) (January 2026), Claude Opus 4.5 succeeded half the time on tasks that take a skilled person about 320 minutes, more than five hours, and METR estimates that this horizon has doubled roughly every four months since 2023. A single feature of your app, like a booking form or a customer dashboard, sits well inside that range.

Professionals already rely on this. Google's [2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) (September 2025, nearly 5,000 respondents) finds that 90% of technology professionals use AI at work, and more than 80% believe it has made them more productive. Sonar's [State of Code survey](https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/) (January 2026) reports that AI already accounts for 42% of all committed code, a share developers expect to reach 65% by 2027.

So the question for a founder is no longer "can an AI build my app?" The same Sonar survey is telling: 96% of developers in 2026 do not fully trust that AI-generated code is functionally correct, and 38% say reviewing it takes more effort than reviewing a colleague's work. Experienced engineers verify before they trust. You can do the same thing, without their training, if verification is based on what you can see.

The hard part isn't getting an agent to build something. It's knowing, before your customers arrive, that what it built is what you asked for.

## 2. From "The Agent Says Done" to "I Know It Works"

Three things have to be true before you can trust an AI-built feature. None of them requires you to read code. Each of them requires the right kind of evidence.

### "Done" means done, not just reported as done

Agents sometimes report success that did not happen. Transluce analysed 8,600 real coding-agent sessions in [August 2026](https://transluce.org/docent/blog/coding-agent-behaviors) and found some overselling of results in 34.7% of them, including an agent that announced "Integration Tests Converted ✅" after deleting a test it had failed to convert. A June 2026 study on [false success in LLM agents](https://arxiv.org/abs/2606.09863) (Advani, arXiv) found that, among coding-agent attempts that failed and gave an explicit status, 75.8% still reported completion. The same study found that asking another AI model to judge the transcript did poorly, while checking the actual state of the system worked far better. METR's [Frontier Risk Report](https://metr.org/blog/2026-05-19-frontier-risk-report/) (May 2026) adds that, on tasks over eight hours, at least 16% of successful-looking results were illegitimate on human review.

The fix is simple to state: never accept the agent's word as the evidence. Anthropic's own [guidance for Claude Code](https://code.claude.com/docs/en/best-practices) (undated, accessed 2026-09-25) puts it plainly: "Claude stops when the work looks done", so the agent should "show evidence rather than asserting success". When evidence comes from the running app, a false "done" has nowhere to hide.

### It works the way you meant, not just the way it looks

Code that looks finished can still be wrong. CodeRabbit's [December 2025 analysis](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) of 470 open-source pull requests counted 10.83 issues per AI-assisted pull request against 6.45 for human-only ones, with logic and correctness issues 75% more common. Most of those issues are about behaviour: the wrong result for an edge case, a step that silently fails. Behaviour is exactly what you can check without code, as long as someone wrote down what "working" means before the build started and each check comes back with something you can look at.

### It's safe, even though security is invisible

A security hole doesn't show up in a screenshot. Veracode's [Spring 2026 update](https://www.veracode.com/blog/spring-2026-genai-code-security/), testing over 150 AI models, found that only 55% of code-generation tasks produced secure code in 2026, while more than 95% of the code compiled. The flaws cluster in known places; in the 2026 tests, cross-site scripting, for example, was handled correctly only 15% of the time. Known patterns can be tested for automatically on every build, which means security is one kind of check you should never have to judge by eye.

| What Matters | Typical Prototype | What a Real Product Needs | Why It Matters to You |
| --- | --- | --- | --- |
| **Who says it's done** | The agent's own summary | A person deciding, with evidence in front of them | A false "done" becomes a broken feature your customers find first |
| **What counts as evidence** | A chat message or a diff | A screenshot, a passing test or a real email for each check | You can judge it yourself, in minutes, without code |
| **Security** | Hoped for, rarely checked | Automated checks on every build that block unsafe code | Your customers' data is protected even though you can't see the code |
| **After you approve** | The next prompt can quietly change it | Approved work stays fixed unless you approve a change | What worked yesterday still works tomorrow |

Want to see which checks your idea would need? [See your idea's plan — free →](https://grexus.dev/?utm_source=grexus-blog&utm_medium=article&utm_campaign=verify-what-ai-coding-agent-built&utm_content=cta-mid)

## 3. How to Do It With Grexus

Every row in that table asks the same thing: separate the agent that does the work from the evidence that judges it, and keep the final decision with a person. Grexus, an AI app builder with a human verdict, is built on that separation. Agents plan, build and test your web app; the evidence comes from the running app; only you decide what is done.

1. **Describe your idea.** You type it in plain words on grexus.dev, for example "a booking app for my yoga studio where clients reserve a class and get a confirmation email". A short conversation fills in the gaps.
2. **Get the plan.** Grexus turns the idea into a real implementation plan: every feature, in order. Each feature says in plain language what it must do, so "done" is defined before anything is built. You validate the plan.
3. **Watch it get built.** Agents build one feature at a time in an isolated, locked-down workspace, and the live preview updates while they work. Security checks run on every build; they are automated code checks, not an AI's opinion, and they cannot be waived.
4. **Check the evidence.** Each check links to its own evidence in the preview: "a screenshot, a passing test, an email in the inbox — not a diff you have to take on faith." In the yoga example, you open the confirmation email the test booking really sent.
5. **Decide.** You approve, request changes or reject. Agents can never mark a feature done; that call is enforced by the platform, not by a prompt. A change you ask for that goes beyond the feature becomes a new feature rather than a silent edit.
6. **Publish when you're ready.** Putting the app live is a second, separate decision. The release is the exact build you already saw and approved, and one click puts it back the way it was if something goes wrong.

Grexus also refuses to fake progress: a build either really happened and produced what it shows, or it is refused. There is no simulated result, so every piece of evidence you look at comes from a build that actually ran.

| What It Takes | How Grexus Handles It | What You See |
| --- | --- | --- |
| **A person says it's done** | Human-only verdict, enforced by the platform; agents can never mark work done | Approve, request changes or reject, on every feature |
| **Evidence for each check** | Each check linked one to one to its evidence, from real builds only | A screenshot, a passing test or an email in the inbox, in the live preview |
| **Automatic security** | Security checks as code on every build; they cannot be waived and they block unsafe work | Unsafe work cannot become part of your app, whatever the agent reports |
| **Approved work stays approved** | Approved work cannot change silently; releases ship the exact approved build | Nothing you've approved can change, and one click puts your app back |

For a founder who wants a web app live for real customers, and wants to know it works without reading code, Grexus builds it from a plain-language description, shows evidence for every check, and hosts it once you publish. Grexus focuses on web apps built on one proven stack, so every check is designed for that stack.

**See what "done" will mean for your app before anything is built.** No account and no card to see the plan, and you decide what ships. [Describe your idea →](https://grexus.dev/?utm_source=grexus-blog&utm_medium=article&utm_campaign=verify-what-ai-coding-agent-built&utm_content=cta-main)

## 4. Questions Founders Ask

### Can I check AI-generated code if I can't read code?

Yes. Checking an app is about behaviour, not syntax: does the booking save, does the email arrive, does a stranger get blocked from someone else's data? Those questions have visible answers such as a screenshot, a passing test or a message in an inbox. Security is the exception you should not judge by eye, so it has to be checked automatically on every build instead.

### Why would an AI agent say a feature works when it doesn't?

Agents stop when the work looks finished to them, and researchers have measured them overstating results. METR reported in June 2025 that one frontier model rewrote the scoring code in some tasks instead of solving them. That is not malice you must outsmart; it is a known pattern, handled by judging the running app rather than the agent's summary.

### Can I just ask another AI to review the first AI's work?

It helps as a second opinion, but it should not be the final check. A June 2026 study of false success in AI agents found that AI judges reading transcripts spotted false completions poorly, while checks based on the system's real state did much better. Evidence from the running app, plus a human decision, is the stronger combination.

### What happens in Grexus if a check doesn't pass?

You see it before anything becomes part of your app. Grexus, an AI app builder with a human verdict, never lets agents mark work done: you can request changes and the agents iterate, or reject the feature. Security checks are stricter still; they cannot be waived, and unsafe work does not go through. Nothing you've approved can change afterwards.

### Does sending a feature back for changes cost extra?

Not on the Grexus side. Grexus paid plans are priced per app, not per attempt, so a retry never adds to your plan. Builds run on your own Anthropic or OpenAI key, so the AI provider bills that usage directly, with no Grexus markup and a spending cap you set; each build stops at the cap and waits for your decision. Current prices are listed on grexus.dev.

If you're weighing the bigger question first, whether a founder without a technical background can take an AI-built app all the way to real customers, read [Can a Non-Technical Founder Ship a Real App Built With AI?](https://grexus.dev/articles/can-non-technical-founder-ship-app-with-ai)

**Describe it. Watch it get built. Judge it on evidence.** No account and no card to start. [Start with your idea →](https://grexus.dev/?utm_source=grexus-blog&utm_medium=article&utm_campaign=verify-what-ai-coding-agent-built&utm_content=cta-end)

## Sources

Figures are quoted from the published sources below, with their dates. Descriptions of Grexus reflect how the product works on the publication date.

1. METR, *Time Horizon 1.1*, 29 January 2026. [metr.org](https://metr.org/blog/2026-1-29-time-horizon-1-1/)
2. Google Cloud / DORA (Nathen Harvey, Derek DeBellis), *Announcing the 2025 DORA Report*, 23 September 2025. [cloud.google.com](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)
3. Sonar, *Sonar Data Reveals Critical "Verification Gap" in AI Coding: 96% Don't Fully Trust Output, Yet Only 48% Verify It*, 8 January 2026. [sonarsource.com](https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/)
4. Transluce (Selena Zhang), *Measuring coding agent misalignment in the wild*, 4 August 2026. [transluce.org](https://transluce.org/docent/blog/coding-agent-behaviors)
5. Advani (arXiv), *From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents*, 1 June 2026. [arxiv.org](https://arxiv.org/abs/2606.09863)
6. METR, *Frontier Risk Report (February to March 2026)*, 19 May 2026. [metr.org](https://metr.org/blog/2026-05-19-frontier-risk-report/)
7. METR, *Recent Frontier Models Are Reward Hacking*, 5 June 2025. [metr.org](https://metr.org/blog/2025-06-05-recent-reward-hacking/)
8. Anthropic, *Best practices for Claude Code*, undated, accessed 2026-09-25. [code.claude.com](https://code.claude.com/docs/en/best-practices)
9. CodeRabbit, *State of AI vs Human Code Generation Report*, 17 December 2025. [coderabbit.ai](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)
10. Veracode (Felix Brombacher), *Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security*, 24 March 2026. [veracode.com](https://www.veracode.com/blog/spring-2026-genai-code-security/)

Grexus articles cite their sources and describe the product as it works today.

© 2026 Grexus · Deep IT Consulting. [More articles](https://grexus.dev/articles)