What happens during a code review?

Most software bugs do not come from reckless coding. They come from a developer who understood their own code perfectly but never had a second set of eyes on it before it shipped. A code review is that second set of eyes, and what happens in those 30 to 90 minutes determines whether a problem gets caught in a private conversation or discovered by a paying customer at 11 PM on a Friday.

This article explains what a code review actually looks like, step by step. If you are a non-technical founder, understanding this process helps you ask better questions of any agency or team you hire. A team that skips or rushes code review is a team that is borrowing time from your future.

A code review works because the person who wrote the code and the person reading it have different blind spots. The author knows exactly what the code was supposed to do. The reviewer only knows what the code actually does. That gap is where bugs live.

Here is the sequence. A developer finishes a feature and submits the changes for review before they go into the main codebase. A second engineer reads those changes line by line, running three parallel checks: does this behave correctly for every scenario, does it open any security holes, and does it fit the architecture of the rest of the product?

The reviewer leaves comments directly on specific lines of code. Some comments are blockers: this will break in production, do not ship this. Others are suggestions: this works, but here is a cleaner approach. The original developer addresses every comment, and only then does the code move forward.

A 2023 study by Cisco found that developers who go through code review ship 15% fewer post-release defects compared to teams that skip it. That number understates the real value. The bugs caught in review are not random typos. They are the structural problems, the edge cases nobody thought about, the security assumptions that do not hold. Those are the bugs that cause outages and data leaks, not just error messages.

At Timespade, every pull request goes through review before it touches the main branch. No exception for small changes, no exception for deadline pressure. The 28-day MVP timeline works in part because catching a bug in review takes 10 minutes. Catching the same bug after it ships to users takes hours of firefighting, a deployment rollback, and a conversation with a frustrated customer.

A reviewer reading code is not just scanning for typos. The job splits into four distinct areas, each requiring a different kind of attention.

Security is the one founders care about most once they understand it. A reviewer checks whether the application properly verifies that a user is allowed to do what they are trying to do, whether user-submitted data is handled safely before it touches the database, and whether sensitive information like passwords or payment details is stored and transmitted correctly. A 2023 IBM report found the average cost of a data breach reached $4.45 million, and a large portion of those breaches traced back to code that nobody reviewed carefully enough.

Performance problems are invisible during development and catastrophic at scale. A reviewer checks whether any piece of code will slow down dramatically once real users start hitting it. The classic failure pattern: a developer writes code that queries the database once per user in a list. Fine for 10 users in testing. At 10,000 users, the app makes 10,000 database calls every time a list loads and the whole product grinds to a halt. A reviewer catches this before it becomes your problem.

Maintainability is what determines whether your product stays affordable to build on. Code that only one person understands becomes a liability the moment that person leaves or gets sick. A reviewer checks whether the logic is clear enough that another developer could read it six months from now and understand what it does without asking anyone.

Then there is correctness for edge cases. The developer wrote the code to handle the normal path. What happens when a user submits an empty form? What if two users try to book the same slot at exactly the same time? What if the payment provider's server is down for 30 seconds mid-transaction? Reviewers think through these scenarios deliberately, because the developer was focused on making the happy path work.

The research on this is specific, and the answer surprises most people who have not seen it.

SmartBear's analysis of review sessions across thousands of developers found that the optimal review pace is 300 to 500 lines of code per hour. Reviewers who go faster than that miss significantly more defects. A change set of 200 lines (a typical small feature) should take 30 to 45 minutes. A complex change of 500 lines might take 90 minutes.

The same research found that reviews longer than 60 minutes in a single sitting get less effective as reviewer attention fades. Large changes should be broken into smaller pieces and reviewed across multiple sessions. A reviewer spending three hours in one sitting is not doing three times the work of a reviewer doing three one-hour sessions. They are probably doing half the work.

This has a direct implication for how fast a product can ship. A team with two engineers can review each other's work. A solo developer has nobody to review their code, and every solo project accumulates problems that only surface later. That is part of why Timespade works as a team model: the project manager, senior engineer, and QA all play different roles in verification. A solo freelancer simply cannot replicate that, no matter how talented they are.

There is also a cost argument here. Finding a bug in code review costs about $20 worth of developer time. Finding the same bug after it has shipped costs $500 to $1,500 to diagnose, fix, redeploy, and communicate to users (based on industry estimates from the NIST cost-of-quality framework). The review is not overhead. It is the cheapest insurance a product team can buy.

As of late 2024, AI tools for code review have gotten genuinely useful, but they are not a replacement for a human. They are a pre-filter.

Tools in this category can scan a set of code changes in seconds and flag common security vulnerabilities, style inconsistencies, and straightforward logic errors. GitHub's 2024 developer survey found that developers using AI-assisted tools during code review caught 20% more routine issues per session. For a fast-moving team, that means fewer low-level comments cluttering the review and more time for the reviewer to focus on the architectural decisions and edge cases that AI does not catch reliably.

What AI cannot do well yet: it does not understand your specific product. It can tell you that a function looks suspicious in isolation. It cannot tell you that this function is called from three other places in the codebase and a change here will break the checkout flow in a way that only happens when a user has a cart with both physical and digital items. That contextual judgment still requires a human who knows the product.

AI review tools also have a consistency problem. They flag the same issues every time, which sounds like a feature until you realize it means they miss the novel problems. Most serious bugs are novel. They are not in the training data. The security vulnerability that takes down a product is usually one that no AI model has seen in exactly that form before.

The practical approach for a team in late 2024: run AI-assisted review as a first pass to catch the mechanical issues quickly, then have a human reviewer focus their attention on the business logic, security assumptions, and edge cases that require product knowledge. That combination is faster than pure human review and more thorough than AI alone.

At Timespade, AI-assisted review tools are part of the workflow on every project. They handle the repetitive checks so the senior engineer's review time goes toward the decisions that actually require judgment: whether the architecture will hold at scale, whether the security model is correct for the specific product, and whether the edge cases a founder has not thought about yet are handled. That is the review process a non-technical founder cannot see but absolutely feels the benefit of when the product runs cleanly from day one.

If you want a team that builds products this way, a good starting point is a free discovery call where you can walk through your idea and understand exactly how the build process works. Book a free discovery call