How do you check the quality of code that AI wrote?

You get a link. You open the app on your phone, book a test job, and it works. The person who built it says it was made with AI in two weeks. Now you have to decide: is it good enough for real customers?

You do not need to read the code to answer that. You ask for proof. Good code made by AI looks the same as good code made by people: it has tests that run, it keeps passwords and customer data locked away, someone who did not write it has checked it, and it works for a real user on the live address. If the builder can show you those four things, the AI part does not matter much. If they cannot, the demo tells you very little.

What the demo shows, and what it hides

Above the water: what the demo shows

Below the water: what it hides

• Tests
• Data rules
• Keys and passwords
• Outside libraries
• Error logs

A demo shows the happy path: one person, clicking the right buttons, in the right order. AI tools are now very good at that part. Veracode’s 2026 report says modern models write code that runs “nearly 100% of the time”.

The problems sit under the screens. The same report found that only 56% of AI-written code samples passed its security tests, “barely changed” from 55% a year earlier. The most common real failure is not clever hacking. It is a missing rule about who may see which data. In February 2026 a social site whose founder said “I didn’t write a single line of code” left its whole database open, with about 1.5 million login tokens readable by anyone (Wiz, February 2026). The same kind of missing rule hit apps on Lovable in 2025.

Benchmark scores do not settle it either. METR had real project maintainers review AI fixes that had passed the well-known SWE-bench test. About half of them would not have been merged.

So the question is not “does it work?” It is “how do you know?”

The report card

Six rows. For each one: what good looks like, one question you can ask, and one warning sign.

1. It works for a real user, not only in the demo.

• Good: the main paths (sign up, book, pay, cancel) have been clicked through on the live address, on a phone, by a person or by a test robot.
• Ask: “Show me it working on the live site, on a phone.”
• Warning sign: “It works on my machine.” In my own team, a check that read the files said 189 pages were fine; a real browser found 99 of 104 pages drawn wrong (how we check that AI agent work is really finished).

2. It has tests, and the tests can fail.

• Good: automated tests run on every change, and you can see the report. Anthropic’s guide for its own coding agent says it plainly: “If you can’t verify it, don’t ship it”.
• Ask: “Can I see the tests pass on the latest version? Who wrote them?”
• Warning sign: the same AI wrote the code and every test. OWASP, the best-known web security group, says such a test suite “provides no independent assurance”.

3. Passwords and keys are not in the code.

• Good: secrets live in protected settings or a vault, and a secret scan has been run (OWASP).
• Ask: “Where are the passwords and keys stored?”
• Warning sign: a pause. GitGuardian counted 28.6 million new secrets leaked on public GitHub in 2025, and found commits co-written by one AI coding tool leaked them at about twice the normal rate.

4. One customer can never see another customer’s data.

• Good: every database table has an access rule, and there is a test that tries to read someone else’s data and fails. Anthropic tests exactly this kind of rule: “user A can never read user B’s data”.
• Ask: “Is there a test for that?”
• Warning sign: “the database handles it”.

5. Someone who did not write it has reviewed it.

• Good: a human reviewer, and often a second AI reviewer that did not write the code. All four big vendors now say this. GitHub: “Supplement Copilot’s feedback with a human review”. Anthropic’s guide: a fresh reviewer “won’t be biased toward code it just wrote”.
• Ask: “Who reviewed it, and what did they find?”
• Warning sign: nobody found anything. A real review almost always finds something.

6. Someone will see the errors before your customers do.

• Good: errors go to a log, someone gets an alert, and backups are tested. Australia’s cyber security centre says to test restoring a backup when it is first set up, every year, and after big changes.
• Ask: “Where do errors go, and when did you last restore a backup?”
• Warning sign: no date.

How my team checks AI code

1. Builder agentShows evidence.
2. Machine checksTests, types, scans.
3. Reviewer agentDid not write it.
4. Tester agentLive site, as a user.
5. Design and ticket checkScreens against both.
6. A person says yesThe tools advise.

My agent team writes most of its code with AI, so we built the checks into the line, not at the end:

1. The builder agent must show evidence. Test output and screenshots, not “done”.
2. Machine checks run on every change: tests, type checks, a linter, dependency and secret scans.
3. A different agent reviews every pull request. It did not write the code and has no memory of writing it.
4. A tester agent walks the app as a user, on the live address. Then it accepts or rejects. In one build it accepted 213 changes and sent 146 back (the full story).
5. Screens are checked against the design and the ticket. Two different checks found 11 of 12 real problems; each one alone found fewer (checking an app against its Figma design).
6. A person says yes. The tools advise; a person decides (Anthropic, GitHub).

This is the same check I run when an owner brings me an app someone else built with AI. The steps are in how I work.

Twelve questions to ask whoever built your app

1. 1. Can I see the automated tests pass on the latest version?
2. 2. Who wrote the tests, and were the login and data tests checked by a person?
3. 3. Who reviewed the code, other than the person or tool that wrote it?
4. 4. Where are the passwords and keys stored?
5. 5. Can one customer ever see another customer’s data? Is there a test for it?
6. 6. Were all outside code libraries checked, and do they all really exist? (AI sometimes invents library names that do not exist; attackers register them.)
7. 7. Was a security scan run, and what was fixed?
8. 8. Where do errors go, and who gets the alert?
9. 9. When was a backup last restored as a test?
10. 10. Does it work on a phone, and is it fast? (Google’s target: the main content shows within 2.5 seconds.)
11. 11. Does every screen match the design and the written ticket?
12. 12. Is the version I am looking at the live one?
13. vaisoftlab.com

If a data leak happens, Australian businesses covered by the Privacy Act must tell the affected people and the OAIC when serious harm is likely (OAIC). Question 5 is the cheapest way to never need that rule.

The numbers, by year

Share of new code written by AIWhat each company or survey says, 2025 to 2027.

1. Google, late 202550%
2. Google, April 202675%
3. Anthropic, July 2026 (merged code)~80%
4. Developers in Sonar’s survey, January 202642%
5. The same developers expect, 202765%Dashed: a forecast.

Sources: Google Cloud Next, 22 Apr 2026; Anthropic, 21 Jul 2026; Sonar State of Code survey, 8 Jan 2026.

AI code that passed security testsVeracode’s tests of AI-written code samples.

1. 202555%
2. 202656%

Source: Veracode GenAI Code Security Report, 30 Jul 2025 and 28 Jul 2026.

• 2025. Veracode: AI code passed security tests 55% of the time. CodeRabbit, which sells an AI review tool, counted about 1.7 times more issues in AI pull requests than in human ones.
• 2026. Google: 75% of its new code is AI-generated “and approved by engineers”, up from 50% the autumn before. Anthropic: AI writes about 80% of its merged code, and “human accountability is still central”. Security pass rate: 56% (Veracode).
• 2027 (forecast). Developers in Sonar’s survey expect AI to write 65% of committed code, up from 42%. My guess: the share keeps rising, and the checks above become the normal price of using it.