Somebody has told you your app needs a code review, or a developer you are talking to has asked for access to the repository. Both requests are ordinary. Neither one tells you what the person is about to do with the code, how long they will have it, or what arrives at the end.
The pages that rank for this question answer the developer’s version of it. Wikipedia, GitLab and Google’s own engineering handbook all describe a reviewer who already works on the codebase, already has access, and is looking at one proposed change. That is a real and useful description of the practice. It is also not the situation you are in if you built the app with an AI tool, paid someone else to, and now want a person to read the whole thing.
A code review is one or more people examining source code and reporting what they found. AxonBuild’s outside whole-app review uses a reviewer who did not write the code. That review starts with access, follows the running product into the code, and ends with a conversation about specific paths.
Everything below about how a review runs comes from published engineering handbooks and platform documentation, read on 15 August 2026 and linked where it is used. The findings come from AxonBuild’s own audit corpus, with the cohort and the denominator attached to each one. Nothing here is a hands-on test of a review tool.
What a code review actually is
GitLab’s definition is the tightest one on the subject: “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Wikipedia’s is wider, and covers the version that happens outside a merge: “Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or more people examine the source code of a computer program, either after implementation or during the development process.” Wikipedia is an encyclopedia summary of the practice rather than a primary study, and it is quoted here for the definition, not for authority on method.
Both definitions assume a peer. That single word carries most of what makes the standard description feel far away from your situation: a peer works on the same codebase, was around when the change was written, and can be asked what they meant.
Google’s engineering handbook states the goal a reviewer is working toward: “The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time.” That page also sets the bar for approval, and the bar is deliberately not perfection. Reviewers are told to favor approving a change “once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.” CL is Google’s word for one proposed change.
GitLab names four ways teams actually do this: pair programming, over-the-shoulder reviews, tool-assisted reviews, and email pass-around. All four describe two people who work together.
So there are two different things wearing the same name.
The first is the team ritual. A developer writes a change, opens a pull request, a teammate reads the difference between the old code and the new code, and the change is approved or sent back. The unit under review is the difference. Everything the standard advice says follows from that.
The second is an outside read of a whole app. Nobody on the reading side wrote any of it. There is no difference to look at, because everything is new to the reader. That is the one you are buying if someone offered to look at your app, and none of the nine results ranking on 15 August 2026 describes it, because their readers never need it.
What happens in a code review, step by step
A code review runs in five stages: access, orientation, the read, verification, and the conversation at the end. Google tells its own reviewers that one business day is the maximum first-response time for an internal change request. That expectation does not establish the turnaround for an outside reader encountering a whole application for the first time.
The same five stages describe what happens during a code review of a single pull request and what happens when someone reads an entire app. What changes is how much of each stage there is.
| Stage | What the reviewer does | What you do | What sets the pace |
|---|---|---|---|
| Access | Gets a copy of the code, and read access to anything the code needs to make sense (the database schema, the deploy configuration) | Grant read access, name the production URL, say which parts you care about | How long the access takes to arrange, which is usually the slowest human step |
| Orientation | Opens the running app first, then finds the code behind the screens that matter: signup, payment, anything that shows one customer’s data | Nothing, beyond answering what the app is for | How many distinct features the app has |
| The read | Reads the paths that move money, data or access, line by line, and follows each one from the screen to the database | Nothing | Number of files on those paths, not total lines in the repository |
| Verification | Checks that a suspected problem is actually reachable by a real user, rather than guarded somewhere the reviewer has not looked yet | Nothing | How many candidate findings survived the read |
| The conversation | Reports what was found, where it lives, and what it lets a user do | Ask what each finding means for your app and decide what happens next | How many findings there are and how much explaining each one needs |
Orientation is the stage that separates a useful read from a useless one. A reviewer who opens the repository and starts at the top of the file list is reading in an order that has nothing to do with your app. A reviewer who signs up as a customer, places an order, and then goes looking for the code that handled the money is reading in the order the risk actually sits in.
Verification is the stage most people do not know exists, and it is what makes the difference between a list of possibilities and a list of facts. Plenty of code looks wrong in isolation and is fine because something upstream already blocked the bad input. The opposite happens too. The finding only counts once the reviewer has traced the whole path and can say what an actual user of your actual app can do.
What does a code reviewer actually look at?
A code reviewer checks eleven things, in the order Google’s engineering handbook sets them out: design first, then functionality, complexity, tests, naming, comments, style, consistency, documentation, every line, and context. On an AI-built app the eleven headings stay the same, and several of them mean something different in practice.
Design comes first on purpose. “The most important thing to cover in a review is the overall design of the CL.” The last two headings, every line and context, are where an outside read of a whole app differs most from the team version.
That guide was written for a reviewer looking at one change inside a codebase they already know. Every heading still applies when nobody on your team wrote the code. The third column below is the translation.
| Google’s heading | What it means on a team | What it means when nobody on your team wrote the code |
|---|---|---|
| Design | Does this change fit the system it is going into | There is no house standard to fit. The reviewer checks whether the generated pieces agree with each other, for example whether the payment path and the login path use the same idea of who the customer is |
| Functionality | Does the code do what the author intended, for the people who will use it | Nobody wrote down the intent. Intent gets taken from the running app, and the check becomes whether the code does what the screens promise |
| Complexity | Is it more complicated than it needs to be, or built for a need nobody has yet | AI-generated apps are usually over-built in one direction and bare in another. The reviewer looks for code that exists but nothing calls, and for a failure path that was never written at all |
| Tests | Are there tests, and are they well designed | First question is whether any test would fail if the behavior broke. A green suite that asserts nothing is common enough that passing tests are not treated as evidence |
| Naming | Did the developer use clear names | Names drift between generation sessions. Two names for the same thing usually means two versions of the same logic exist and only one of them is maintained |
| Comments | Do comments explain why, rather than what | Generated comments describe the line underneath them. They get read as claims to check against the code, not as documentation |
| Style | Does the code follow the style guide | The lowest-value heading here. There is no style guide, and a formatter settles it in seconds |
| Consistency | Is this consistent with the rest of the codebase | Becomes a security question. If one endpoint checks that you own the row you asked for, the reviewer checks whether all of them do |
| Documentation | Was the documentation updated | Usually there is none. The equivalent check is whether the deploy configuration supplies what the code expects at boot |
| Every line | ”In the general case, look at every line of code that you have been assigned to review.” | Nobody assigned anything, and reading every line of a whole app line by line is not how the time is best spent. The reviewer sets the boundary instead, and it should be the paths that move money, data or access |
| Context | Google tells reviewers “It is often helpful to look at the CL in a broad context.” | The whole app is the context, and the running app is the only reliable statement of what it is supposed to do. This is why a reviewer asks for a working URL and not just a repository |
If you want one question to judge a reviewer by, ask which paths they intend to read and why those ones. Someone who has thought about your app will answer with its parts: the checkout, the invite flow, the admin screen. A vaguer answer about the repository as a whole usually means the boundary has not been set yet.
What changes when nobody wrote the code
Four things go missing at once when the code was generated rather than written by a colleague, and every one of them changes what the reviewer has to do.
There is no author to ask. On a team, half the ambiguities in a review get resolved by a one-line question in a comment thread. Here, the only witness is the running app.
There is no record of what was asked for. No ticket, no design note, nothing that states what the feature was supposed to do. Intent has to be inferred from behavior, which means the reviewer has to use the product before reading it.
There is no difference to read. The unit under review on a team is what changed. Here everything is new to the reader, so the reviewer chooses the boundary, and that choice is most of the value.
And the tests, where they exist, prove less than they look like they prove. A generated suite tends to assert that the code did what the code does, which is a statement about the code rather than about your customers. The same gap shows up feature by feature, because the difference between something being present in the code and being actually wired up to run is invisible from the screens, and telling those two apart is a large part of what the reviewer is doing.
A demo shows you the part that works, because showing the part that works is what a demo is for.
Three findings from AxonBuild’s own audit corpus make the point better than an abstract description. The corpus is a fixed set of 26 AI-built apps audited in June and July 2026, and one of those 26, a food-delivery marketplace, rendered the same stored order total three different ways across three screens: as US dollars on one, as that value multiplied by 600 and labeled in Central African francs on another, and as a raw franc figure on a third. Customers, sellers and order history disagreed by roughly 600 times on how much cash to collect at the door. No screen crashed and no error appeared anywhere, which is why the app demoed without a hitch.
The same app never decremented stock on checkout and had no database constraint stopping the number going negative, so a store holding one unit could accept an unlimited number of orders for it. That is not a bug you find by clicking around, because you have to place two orders for the last item and then go look at what the database did. It is exactly the kind of thing a person reading the checkout code finds in a few minutes. The same corpus app also let an ordinary signed-in user promote their own account, which is a separate finding told in full elsewhere.
A second app in the same corpus, a health-data API, exposed an endpoint that took the address of an upstream server from a request header, fetched whatever was at that address with no allow-list, followed redirects, and returned the response body, all without requiring a login. Nobody clicks that in a demo, because no screen in the product touches it. It is reachable by anyone who reads the routes, and reading the routes is the first thing a reviewer does.
Findings of this kind are not rare in the corpus and they are not evenly spread. Across the fixed 21-app third-party group inside that same June and July 2026 cohort, reliability and correctness scored 31.4 out of 100 on average, the worst of the twelve areas assessed. The cohort definition, the denominators and the method behind those numbers are published separately, and the areas the data says AI-built apps actually fail in are not the ones most owners expect. None of the three findings above sits inside a single change, which is the same ground covered by why a correct-looking change still passes review: each one is a disagreement between parts of the app that were generated at different moments, so it only appears to someone reading across the whole thing.
How long should a code review take?
Published code review timings all measure a single pull request. Google sets one business day as the maximum for a first response, and the tidyverse guide puts most pull requests between 5 and 30 minutes of reading. Reading a whole app has no published number, and any duration quoted before the app is seen is a guess.
Four sources cover the ground, and each one is measuring something slightly different.
| Source | What the number measures | The number |
|---|---|---|
| Google’s engineering practices | Time to a first response, not time to finish | ”One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).” |
| The tidyverse code review guide | Reading time for one pull request, by size | ”Small PRs take anywhere from 5-15 minutes… Medium PRs take up to 30 minutes… Large PRs can take up to 1 hour, and occasionally even longer.” |
| Wikipedia’s code review article | Reading rate | ”Optimal code review rates range from 200 to 400 lines of code per hour.” |
| SmartBear, reporting a 2005 to 2006 analysis of Cisco’s peer review process | Reading volume and session length | Under 200 lines per review and not exceeding 400; inspection rates under 300 lines per hour give the best defect detection; total review time under 60 minutes and not exceeding 90 |
Every row shares three assumptions. The unit being timed is a pull request. Whoever is reading already knows the codebase around it. And the session is short enough to hold in one sitting, with the Cisco numbers stating outright that detection collapses past 90 minutes. Nobody in that literature is describing four hours with an unfamiliar app.
So the honest answer to your version of the question has a shape rather than a number. A reviewer reading a whole app can divide the work into focused sessions, but the evidence above does not set their length or count. The total depends on how many distinct paths move money, data or access rather than on how many lines the repository contains. An app with one signup, one checkout and one admin screen is a different job from an app with three user types and a public API, even if the line counts match.
For an outside whole-app read, ask the provider to state the first-response and completion expectation after access works and the material paths are known. Treat that timing as the provider’s commitment for this app, not as Google’s internal standard.
What access you provide, and what comes back
As of 15 August 2026, none of the nine pages ranking for this question answers the access question, and it is usually the first thing an owner actually worries about. On GitHub, first check whether the repository belongs to an organization or a personal account. The access models are different.
For an organization repository, GitHub’s documentation describes the Read role as “Recommended for non-code contributors who want to view or discuss your project”. Someone with Read can pull and fork the repository, open issues, comment, and submit reviews on pull requests. They cannot push to the repository, merge pull requests, manage repository access, or manage repository settings.
A private repository owned by a personal account has no read-only collaborator role. A collaborator receives write access, can push changes, and can create or merge pull requests. Do not treat that invitation as read-only access.
Two practical notes on top of what the doc says. Read access to the code is not access to your live database or your production keys, and a reviewer does not need either. If someone asks for production credentials to do a code review, that is a question worth asking about rather than a normal request. And a review is more useful with the deploy configuration visible, because a large share of real problems live in the gap between what the code expects at boot and what the environment actually supplies.
What comes back is the part where descriptions get vague, so here is a plain one. What arrives from a code-level read is a set of specific findings, each attached to a place in your app: the path, what a real user can do there, and why. A finding that cannot be pointed at is not a finding.
Having someone outside read the code for you produces a conversation about specific paths in your app rather than a document. That distinction matters more than it sounds like it should. A document invites you to file it. A conversation about three named paths ends with you knowing which one to deal with first, which is the only outcome that changes anything. When you are choosing who does the reading, the question that separates people is whether they will walk you through a finding until you can explain it back.
What a code review will not tell you
A code review reads code. That boundary is worth stating plainly, because the word review gets attached to several different pieces of work sold at very different prices.
Your live hosting surface stays outside it. Firewall rules, DNS, storage bucket permissions set in a console, and anything else configured outside the repository are invisible to someone reading the code, unless you hand those over separately.
A review is also not a penetration test. Nobody is attacking your running system. The reviewer reasons about what the code allows; a penetration tester demonstrates it against a live target, under an agreement that says they may.
And it certifies nothing. No code review makes an app compliant with anything, and a reviewer who implies otherwise is selling you something the work does not contain. What a code-level review does and does not cover is worth reading before you agree to anything, and so is the list of five different things sold under the word audit, because the price differences between them are large and the labels are not.
And a clean read is not a guarantee. It means one person, reading with a stated boundary, did not find a problem in the parts they read. That is genuinely worth having and it is not the same as safe. Any reviewer who tells you otherwise has just told you something useful about the reviewer.
Common questions about code reviews
How long should I wait to hear back after sending my code?
Google’s one-business-day statement applies to the first response between its own engineers on an internal code-review request. For an outside whole-app review, agree a separate first-response point and completion basis with the reviewer; a first response may confirm access and identify the paths to be read without implying that findings are complete.
Do I have to give someone access to my code?
You have to let the reviewer see the code, because a code review with no code is a conversation about screenshots. For an organization repository, GitHub’s Read role lets someone pull and fork the repository and comment without pushing or merging. A private repository owned by a personal account has no read-only collaborator role. Its collaborators receive write access and can push or merge. You do not need to give production database credentials or live API keys to have your code read.
Can an AI do the code review instead?
An AI tool can do part of it, and the part it does is the mechanical part: scanning for known patterns, flagging things that look like a known class of mistake, and catching typos and obvious omissions at a speed no person matches. What it does poorly is the verification stage, where the question is whether a suspicious-looking path is actually reachable by a real user of your specific app. Whether an AI can do this review itself, and which of the tools that automate part of this are worth having, are separate questions worth answering on their own.
Is a code review the same thing as an audit?
No, although the words get used interchangeably by people selling both. Code review usually describes reading source code for correctness, clarity and safety. Audit is a much looser label that covers everything from an automated scan to a regulated certification, at prices that differ by more than an order of magnitude. The five different things sold under the word audit is the comparison to read before you agree to buy one.
What is the difference between a code review and testing?
Tests check that the code does what someone decided to check. A review reads the code that nobody thought to check. The two catch different things: a test proves a specific behavior held on a specific run, while a reviewer can see a path that has no test at all and never will, because writing one requires knowing it exists. On AI-built apps the gap is wide, which is why a green test suite proves less than it looks like it proves.
Does a code review fix anything, or just find things?
A review by itself finds things. Fixing is separate work, and whether the same person does both is a matter of what you agreed before they started. Be clear about this early, because a list of findings with no plan for who acts on them is a common and frustrating outcome. If the reviewer is also going to fix, agree which findings before the reading starts.
Can a code review be done without the person who wrote the code?
Yes, and if an AI tool wrote your app that is the only version available. It costs something: the reviewer cannot ask what a piece of code was meant to do and has to infer intent from the running product, which is slower and occasionally wrong. It also gains something, because a reviewer with no memory of writing the code has no assumptions to defend. Checking an app somebody built for you, or taking over code somebody else generated, both run this way as a matter of course.
What should I ask for before someone reviews my code?
Ask four things: which paths they will read and why those ones, what access they need and in what form, when you get a first response, and what arrives at the end. The first answer is the one that tells you the most, because a reviewer who has thought about your app will name parts of it, while one who has not will talk about the repository in general. If you cannot read code yourself, add a fifth: ask them to walk you through one finding until you can explain it back in your own words.
Not sure what your app needs yet?
See how we follow one real problem from the behavior through the code and decide what should happen next.
