# How to Check AI-Built Software When You Don't Write Code > You can't read the code, but you can still tell whether an AI agent's work is good. Ask for evidence, set pass/fail checks, and try the edge cases yourself. 15 October 2026 · Plain English · How-to · 6 min read · https://bridge-terminal.com/atlas/blog/check-ai-built-software-without-code/ ## The short version - You can judge AI-built software without reading code. Ask for evidence such as test results and screenshots instead of accepting a message that says the work is done. - Anthropic's guide for Claude Code says the agent stops when the work looks done, so write down beforehand what done means, as checks that clearly pass or fail. - Have the work checked by a reviewer that did not write it, and ask it to flag only problems that affect correctness or your stated requirements. - Try the awkward cases yourself: wrong inputs, empty fields, a logged-out user, a slow connection. Work that looks finished but isn't usually breaks there. - If nobody can show you that a change works, it is not ready to release, however confident the agent sounds. You can check AI-built software without reading a line of code. Instead of judging the code, judge the evidence: what was tested, what the result was, and what the screen looks like now. Settle what "done" means before the work starts and ask for proof afterwards. That is usually enough to tell good work from work that only looks finished. This guide is for founders, product owners, analysts, testers and managers who brief AI coding agents such as Claude Code or OpenAI Codex, or who oversee people who do. ## Why "it's done" is not enough An AI coding agent is a program that reads a project's files, makes changes and runs commands to finish a task you describe. It can work for long stretches on its own, and it has one habit you need to understand. Anthropic's best-practice guide for Claude Code says it directly: "Claude stops when the work looks done." Without a check the agent can run, the guide goes on, "looks done" is the only signal available, and "you become the verification loop: every mistake waits for you to notice it." The same guide lists a common failure it calls the trust-then-verify gap: the agent "produces a plausible-looking implementation that doesn't handle edge cases." An edge case is an unusual situation, such as an empty field or a very long name. The guide's advice is short: "If you can't verify it, don't ship it." So if you don't code, don't ask "is this code good?" Ask "what proof do I have that this does what I asked?" ## Step 1: Define "done" before the work starts The best checks are written before anything is built. In the brief, describe the result you will accept, not only the feature. A vague brief: "Add a discount code box to checkout." A brief you can check: - A valid code takes 10% off the total, and the new total shows before payment. - An expired code shows "This code has expired" and changes nothing. - A made-up code shows "Code not recognised". - Using the same code twice in one order is refused. - Before and after screenshots of the checkout page come with the work. Each line either happens or doesn't, and that is what makes it useful. Anthropic's guide recommends giving the agent "something that produces a pass or fail": example inputs with the answers you expect, for instance, or a screenshot to compare against a design. With a check like that, the agent can run it itself and keep going until it passes, instead of waiting for you to find the problem. For bigger features, the guide suggests letting the agent interview you first, asking about edge cases and trade-offs, and then write a spec (a written description of what will be built). The most useful specs, it says, state what is out of scope and "end with an end-to-end verification step that proves the feature works." You don't need technical knowledge for this. You only answer questions about how the business should behave. ## Step 2: Ask for evidence, not a summary When the agent reports back, a confident summary is not proof. Ask for the things that are. Anthropic's guide recommends having the agent "show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result." It notes that reviewing evidence is faster than running the check again yourself, and "it works for sessions you weren't watching." What to ask for, in plain words: - **Test results.** A test is a small automatic check that runs the software and compares what happens with what should happen. Ask which tests were run, how many passed, whether any failed and whether any were skipped. - **Screenshots.** For anything on screen, ask for screenshots of the finished result. Include error messages and empty screens, not only the case where everything goes right. - **A list of what changed.** Ask which parts of the product were touched. If you asked for a discount box and the list includes the sign-in page, ask why. - **What was not done.** Ask directly: "What did you leave out, and what are you unsure about?" ### Warning signs in a report - "Should work now", with no test results. - Tests were switched off, skipped or deleted so that everything passes. - An error was hidden instead of fixed. One of the guide's example instructions tells the agent to "address the root cause, don't suppress the error." - Changes far outside what you asked for. ## Step 3: Get a second opinion from something that did not write the code People find it hard to review their own work, and agents do too. Anthropic's guide notes that in a fresh session (a new conversation that has not seen the earlier work) Claude "won't be biased toward code it just wrote." It suggests a reviewer that "sees only the diff and the criteria you give it." A diff is the list of exact changes. You don't have to run the review yourself. You only need to make sure one happens and read its verdict. The guide adds a caution: a reviewer told to find gaps "will usually report some, even when the work is sound." If you act on every comment, you end up with over-engineering: extra layers, defensive code and tests for cases that can't happen. Tell the reviewer to flag only problems that affect correctness or your stated requirements, and treat the rest as optional. ## Step 4: Try it yourself, the awkward way Testers already do this, and everyone else can too. Use the feature the way a careless, impatient or unlucky customer would: - Type the wrong thing: letters in a phone field, a date in the past, a very long name. - Leave fields empty and press submit. - Use it logged out, or as a user with fewer permissions. - Press the button twice quickly. - Try it on a phone and on a slow connection. - Go back, refresh, and check whether your data is still there. These are the edge cases where a "plausible-looking implementation" tends to fail. When you find a problem, report it the way the guide suggests for bugs: the symptom, where it likely happens, and what "fixed" looks like. "After the session times out, logging in fails; fixed means I can log in again without clearing my browser" is more useful than "login is broken." ## How do I judge quality beyond "does it work"? Working is the minimum. A few more questions, all answerable without code: - **Security.** Did anything touching sign-in, payments or personal data get its own security check? Ask what was checked, not only whether it was. - **Speed.** Is there a target ("search results in under a second"), and was it measured? - **Undoing a release.** If this release goes wrong, how do we go back, and has that been tried? Was the data backed up first? - **Consistency.** Does the new screen look and behave like the rest of the product? If nobody can answer one of these, you have found a gap. ## What your role becomes When AI agents do the building, a non-technical owner stops checking the work line by line. The job becomes setting the standard and checking the proof. In practice that means three things: 1. Write briefs with pass/fail acceptance criteria. 2. Don't accept "done" without evidence. 3. Keep the decisions that carry real risk, such as go-live, spending and deleting data, in human hands. Some tools build these habits into the process. [Atlas](https://bridge-terminal.com/atlas/) is a software team of AI engineers built on Claude Code. It won't let work be marked done until a screen has its test cases and screenshots. Each build is reviewed when it is finished and is either marked releasable or gets fix tasks sent back to the engineer who built it. Go-lives, spending and deleting data are never decided for you. Whatever tool you use, the habits above still apply. ## Summary You don't need to read code to hold AI-built software to a high standard. Decide what "done" means before the work starts. Ask for test results and screenshots instead of reassurance. Make sure something other than the author reviews the work. Then try the awkward cases yourself. If nobody can show you that a change works, it isn't ready, however good the summary sounds. ## Questions people ask ### How can I tell if code written by AI is any good if I can't code? Judge the evidence rather than the code: test results, screenshots of the finished screens, and a list of what changed. Set pass/fail acceptance criteria before the work starts, then compare the evidence with them. ### Why does an AI coding agent say a task is finished when it isn't? Anthropic's guide for Claude Code says the agent stops when the work looks done. If it has no check it can run, such as tests or a screenshot to compare against a design, looking done is the only signal it has. ### What should I ask an AI coding agent to show me before I approve a change? Ask which tests ran and whether any failed or were skipped. Ask for screenshots, including error messages and empty screens, a list of what changed, and what it left out or is unsure about. ### Should a different AI review the code the first one wrote? Yes. A reviewer in a fresh session is not biased toward code it just wrote. Ask it to flag only problems that affect correctness or your requirements, because a reviewer told to find gaps usually reports some even when the work is sound. ## About Atlas: Atlas asks for the proof before it calls work done In Atlas, a screen can't be marked done until it has its test cases and screenshots. Each build is reviewed when it is finished and is either marked releasable or gets fix tasks sent back to its builder by name. The Tests screen holds the case library, the test runs, the screenshots and a step-by-step replay, so you can check the evidence without reading code. — https://bridge-terminal.com/atlas/ ## Sources - [Best practices for Claude Code (Anthropic)](https://code.claude.com/docs/en/best-practices) - [Atlas: an AI engineering team built on Claude Code](https://bridge-terminal.com/atlas/) _Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._