'The AI built it' is not enough information for someone to maintain or approve an app. Give a developer the repository state, a repeatable way to run it, the behavior you personally checked, and the decisions you need from them. A local preview is a useful demonstration, but it is not a production review.
Freeze one reviewable version
Identify the repository, branch, commit, and pull request that contain the proposed work. If the agent is still editing, wait for a stable checkpoint or open a draft pull request so the developer can inspect a specific diff. Record the target branch and whether a later agent run has changed it. GitHub's review model attaches discussion and checks to a pull request, while later commits can change what was reviewed. Do not send only a chat transcript or a screenshot of the final page.
Give the developer a working route into the app
Write down the setup steps you actually used: required runtime versions, install command, environment-variable *names* and who provides their values, start commands by component, and the local URLs. Keep credentials out of the handoff. If the README is stale, say so and include the working commands. In Canopy, you can show the saved project commands, process output, detected ports, and Preview beside the agent session. The reviewer should be able to reproduce the same state from the named branch without guessing which shell was left open.
Separate observed behavior from agent claims
List three things you personally tried in the running app, including one failure or empty state. Add a short screen recording or screenshots with the URL and date if they help reproduce behavior. For every test, say what you did, what appeared, and whether the result met your request. Then list what you did not test. An agent's 'tests passed' line is evidence of a command it reports running; it does not establish that login, payment, data handling, or deployment is ready.
Ask for decisions by risk
Give the developer specific questions: Can this code be maintained? Are data access and error paths sound? Which tests are missing? What would be required before public deployment? Request early review for authentication, payments, personal data, migrations, public APIs, and infrastructure. GitHub can require reviews, status checks, and conversation resolution on protected branches when configured; those controls help enforce the review you decide you need. A passing check and a pretty preview are still different from a human approval of the actual change.
| Evidence | Founder can supply | Developer decides |
|---|---|---|
| Product behavior | Expected journey and observed result | Whether implementation meets the request |
| Reproduction | Branch, commands, URL, visible failure | Whether setup and tests are repeatable |
| Risk | Data involved and intended users | Security, architecture, migration, and release requirements |
| Release | Desired timing and acceptance criteria | Whether the reviewed version is ready to ship |
Close the loop on the same diff
When the developer requests changes, give one agent the exact review comments and the branch to edit. Ask it to report which comments it addressed and the checks it ran. Reopen the app, verify the product behavior again, and have the reviewer inspect the latest diff. GitHub notes that new commits update the pull request and can rerun checks; the final review must cover the changed version, not just the earlier preview. Resolve comments only when the underlying concern is actually addressed.
Copyable resources
Copyable developer handoff
Fill the brackets with your own evidence and remove fields that do not apply.
Project and purpose: [one sentence]
Repository / branch / commit / PR: [links and commit]
How to run locally: [runtime versions, install and start commands, local URLs]
Configuration: [environment-variable names and owner; no values or secrets]
What I checked: [action -> observed result -> expected result, for three cases]
What I have not checked: [known gaps]
Agent changes: [files or behavior changed; link to the diff]
Developer decisions needed: [security, data, tests, maintainability, deployment]
Who approves the final version: [name or role]
Current status: [local demo / draft PR / reviewed / ready for release]Frequently asked questions
Can I hand over a deployed link instead of the repository?
A deployed link shows behavior, but a developer also needs the source version, configuration shape, change history, and a way to reproduce or inspect failures. Include both when available.
Should I paste my .env file into the handoff?
No. Record variable names, purpose, and who supplies the values. Transfer any required secrets through your team's approved secret-management process.
When should a developer review an AI-built app?
Bring one in before production-sensitive design or release decisions, especially for authentication, payments, personal data, database changes, or infrastructure. A small local prototype can be demonstrated first with its limits stated.
Does a green CI check mean the app is approved?
No. It reports the configured checks for a particular commit. The reviewer still needs to judge the intended behavior, risk, and latest diff.