Reviewing code is one of the most important tasks for millions of software engineers every day, and the practice itself dates back decades.

Today, however, software engineering is changing. More developers than ever are becoming more productive thanks to AI coding assistants like ChatGPT and GitHub Copilot. New tools can generate whole apps and websites. With the higher volume of human and AI-authored code to review, traditional code review practices need to change.

In this report, we analyze more than 5 million pull requests from over 35,000 engineers to examine the current state of code review. Here’s what we found:

1. Small companies ship code 3x faster than larger orgs, and the reason is code review

The median engineer at a small company (≤20 engineers) takes about 4 hours to merge an open pull request. In contrast, developers at larger companies (50+ engineers) take around 13 hours, meaning they move 3x slower.

This is despite the fact that, by most conventional standards, larger companies are better at code review.[1] So what’s going on?

It turns out that small companies are 4.5x more likely to skip code review altogether—meaning they skip what is often the longest part of the PR lifecycle. Large companies have more stringent code review processes, with each additional round of review contributing to a longer total time to merge.

[1]Engineers at larger companies are 12% more likely to follow best practices regarding PR size, keeping them under 50 lines of code, and 45% more likely to have these PRs reviewed within 90 minutes.

2. At startups: TypeScript is the new JavaScript

TypeScript’s popularity has grown in all but the largest companies, while JavaScript usage has declined. In the last two years, TypeScript usage has increased 21% at companies with ≤50 engineers, while its prevalence at companies with 100+ engineers has actually declined by 14%.

As a general rule, larger companies tend to merge more code written in traditionally established languages like Java and Python. They also merge more PRs modifying config files and IaC (infrastructure as code)—reflecting increased backend complexity as companies scale.

Code review time trends differently depending on what language the PR is written in: Bazel, Java, and JavaScript code takes roughly 35% longer to go through code review than TypeScript, Python, or Ruby.

3. Companies that use monorepos take 64% longer to merge their PRs—taking up to 18,000 additional hours each year

That’s six years’ worth of engineering time, giving credence to concerns around long build and merge times when employing monorepos. Last year, the median developer waited 64% longer to merge their code at monorepo companies compared to their peers working across many repos (16.4 hours versus 10 hours). This difference held, even when normalizing for pull request and company size.

Is this a resounding blow for the Googles and Microsofts of the world? Likely not. The primary motivations behind adopting a monorepo aren’t usually tied to speed of individual merges; instead, it’s about “strategically organizing code across several large repositories that each address a set of diverse (yet somewhat related) concerns.” May the lively Hacker News discussions live on.

4. The ideal PR is 50 lines or smaller

We often hear smaller PRs are better, but just how small should a PR be? If you’re optimizing for speed, the golden number converges to around 50 lines—the typical reviewed PR of this size takes about 100 minutes to go from publish to merge. Compare that to the median reviewed PR over 50 lines, which takes 19 hours to merge!

Not only that, but you might already be writing smaller PRs than you thought you were. Half of all PRs written today are already under 50 lines (excluding bots of course). Time for a pat on the back!

5. CI run time takes twice as long at large companies compared to small companies

If you’re a software developer, you’ve probably had the experience of waiting for CI to finish running before carrying on with your work. If you’re a software developer in an engineering org of 50+, you may be nearly twice as familiar with this experience as your peers at smaller companies (≤50 engineers).

The median pull request triggers a respectable 22 minutes of CI run time. But the picture isn’t as rosy as it seems. The top quartile of CI runs still take 76 minutes or more at small orgs, and nearly doubles to 130 minutes at large orgs.

One explanation may be that larger companies have more comprehensive review and testing practices (triggering longer, more numerous CI runs)—something to keep in mind for developer experience teams.

6. Larger companies are more than twice as likely to employ a merge queue

Merge queues automate the merging process, keeping developers unblocked and the main branch green. Not every repo uses one; traditionally, there’s a real tradeoff between speed (being able to merge your pull request the moment you are ready) and integrity (preventing semantic conflicts that can break main).

The conventional wisdom is that until your repo is seeing a certain level of merge activity, the risk of slower releases is not worth the integrity guarantee. Among companies with ≤100 contributors, only 21% have a merge queue enabled. But as companies grow to 100+ engineers, the scale tips, and merge queue usage more than doubles to 50%.

For those who dread the tradeoff, there is good news; advancements like parallel processing and smarter CI runs allow companies to turn on merge queues at earlier stages.

Download this report

💾 Click here to download the report in PDF format.

Methodology

Our analysis considered a total of ~6 million pull requests merged on GitHub in the last year. “Qualified” pull requests are defined as pull requests that:

• Were merged on GitHub between July 1, 2023 and June 30, 2024

• Were authored by “active committers” (1 median PR merged per week)

• Belong to a GitHub organization with at least 2 active committers

• Belong to a GitHub organization for which we have synced pull request metadata

We proxied companies by GitHub organization. Company size (i.e., number of developers) was proxied by the number of distinct contributors across all repositories in the company’s GitHub organization during the same period.

1) Small companies ship code 3x faster than larger orgs, and the reason is code review

Metrics (e.g., time to merge, percent of pull requests under 50 lines, percent of pull requests reviewed within 90 minutes) were first aggregated as a per-developer median, then grouped by the size of the engineering org (≤20 or 50+).

2) At startups: TypeScript is the new JavaScript

We expanded the time window to consider pull requests merged on GitHub between January 1, 2022 and June 30, 2024. Companies for which we do not have at least 2 years of synced pull request metadata starting from January 1, 2022 were excluded.

Files were labeled by language based on their file extensions. We calculated the popularity of a language by measuring the percentage of pull requests that modified each language’s file extensions.

3) Companies that use monorepos take 64% longer to merge their PRs—taking up to 18,000 additional hours each year

We categorized companies as “monorepo” or “polyrepo” based on the percentage of qualified pull requests merged in a single repo. We define “monorepo” companies as companies that merge ≥80% of all qualified pull requests into one repo.

To calculate time to merge, we first aggregated the per-developer median time from publish to merge for the developer’s pull requests. Then we aggregated the median time to merge across developers.

4) The ideal PR is 50 lines or smaller

Across qualified pull requests, we calculated the median time from when a pull request was published to when it was merged. Pull request size is based on the number of lines modified in the pull request (i.e., sum of lines added and lines deleted).

5) CI run time takes twice as long at large companies compared to small companies

We define CI run time per PR as the aggregate total time spent running CI across all CI runs and status checks. (For example, if a single PR triggers 2 distinct checks, both from 12:00pm to 12:20pm, then we count 40 minutes of CI run time for that PR.)

We considered PRs merged in the last 5 months.

6) Larger companies are more than twice as likely to employ a merge queue

We included companies that have enabled the Graphite merge queue, GitHub merge queue, or a third-party merge queue app.