DEV Community: DebtDraft

Code Quality Tools for GitHub: SonarQube Alternatives (2026)

DebtDraft — Sat, 31 Oct 2026 14:00:00 +0000

If you want code quality feedback on every pull request, SonarQube is the name everyone knows. It is also not the only option, and for some GitHub teams it is not the easiest one. This guide compares the main alternatives by what they cost, how they charge, what they check, and who they suit.

The short answer

Want the closest full replacement with many languages? Look at Codacy or DeepSource.
Want one health score on every pull request, plus stats and trend lines for each repository, for JavaScript or TypeScript projects? Look at DebtDraft.
Want security scanning first? Look at Semgrep, Snyk Code, or CodeQL.
Want to find which files cost your team the most? Look at CodeScene.
Want coverage reports only? Look at Codecov.
Want an AI reviewer to comment on pull requests? Look at CodeRabbit. It is a different kind of tool from the rest.

Comparison table

Prices checked 2026-10-30 on each vendor's page.

Tool	Free option	Paid price	Charged by
DebtDraft	Up to three connected repositories	Pro $9 a month or $90 a year	Account, flat price
SonarQube Cloud	Private projects up to 50k lines of code	Team from $34 a month for up to 100k lines	Lines of code
Codacy	Developer plan; free for open source	Team $18 per dev a month billed yearly ($21 monthly), up to 30 devs	Developer
DeepSource	Open Source plan, public repos only	Team $24 per user a month billed yearly	User
Qlty	1,000 analysis minutes a month, no trends	Pro $20 per contributor a month	Contributor
CodeScene	Not stated	€18 per active author a month billed yearly	Active author
Qodana	Community plan	Ultimate $5 per active contributor a month billed annually, minimum 3	Active contributor
Semgrep	Free for up to 10 contributors and 10 repos	Teams from $30 per contributor a month per product	Contributor
Snyk	100 Snyk Code tests a month	Team from $25 a month, up to 10 developers	Tests and developers
Codecov	1 user on private repos, 250 uploads a month	Team about $4 to $5 per user, Pro $12 per user	User
CodeRabbit	Free reviews for public repos only	Essentials $24 per user a month billed yearly ($30 monthly)	User

Does SonarQube support pull requests for free?

It depends on which product you mean.

SonarQube Community Build is free and self-hosted, but it analyzes only the main branch. Pull request analysis starts in the Developer edition.

SonarQube Cloud has a free plan for private projects up to 50k lines of code, and Sonar describes pull request and main branch analysis as part of it. Public open source projects are covered by a separate free program.

Past 50k lines, SonarQube Cloud Team starts at $34 a month for up to 100k lines of code. It is priced by lines of code, and only the largest branch of a project counts.

So the old advice "SonarQube has no free pull request comments" is out of date. The accurate version: free pull request analysis on private code stops at 50k lines, and after that you pay by lines of code.

Why do teams look for an alternative?

Reviewers on G2 often mention three things: setup and CI configuration effort, false positives that need tuning on older codebases, and resource use on large projects. These are opinions from review sites, and many roundup posts repeat them without checking. Treat them as reasons to try something, not proof that SonarQube is wrong for you.

Other common reasons are practical:

Pricing basis. Lines of code, seats, or tests can all be a bad fit for how your team grows.
Scope. Some teams only want pull request feedback, not a full quality platform.
Setup effort. A GitHub Action is usually easier to maintain than a server.

How should you choose?

Ask four questions.

Which languages do you use? Some tools cover dozens. Others cover one family well.
Do you need comments on pull requests? If yes, check that the free plan includes them for private repositories.
How does it charge? Per seat, per line of code, per test, or a flat price. This decides what the bill looks like when the team doubles.
Do you want security, quality, or both? Security scanners and quality platforms overlap less than the marketing suggests.

What does each tool do, and who is it for?

Codacy

A hosted quality and security platform. The Developer plan is free and includes an IDE plugin plus code quality and security scans. The Team plan adds pull request and repository features for up to 30 developers and 100 private repositories. Free forever for open source. It fits teams that want a broad hosted platform and accept per-developer pricing.

DeepSource

Code quality analysis with AI review. The Open Source plan covers unlimited public repositories and reviews up to 1,000 pull requests a month. Private repositories need the Team plan at $24 per user a month billed yearly. It fits teams that want automated review and fixes and are fine paying per user.

Qlty

The successor to Code Climate Quality, built around maintainability checks and coverage. The free plan gives 1,000 analysis minutes a month and unlimited contributors, but no trends, hotspots, or shared configurations. Pro is $20 per contributor a month. The detail worth knowing: trend history is a paid feature there.

CodeScene

Analyzes your Git history to find hotspots, meaning the files that change often and are hard to maintain, and produces a code health score. It also reviews pull requests with quality gates. Pricing is €18 per active author a month billed yearly, where an active author is someone who committed in the past three months. It fits teams who want to decide where to spend refactoring time.

Qodana

JetBrains' tool that runs IDE inspections in CI. A free Community plan exists. Ultimate is $5 per active contributor a month billed annually, but the catch is it has a minimum of 3 contributors. It fits teams already using JetBrains IDEs.

Semgrep

A security-first scanner with rules you can read and write. The Free Edition covers up to 10 contributors and 10 repositories, including code scanning and supply chain scanning. The Teams plan charges per contributor and per product. It is not a coverage or complexity tool, so it pairs with one rather than replacing SonarQube.

Snyk Code

Static security analysis within a wider security platform that also covers dependencies, containers, and infrastructure as code. The free plan limits you to 100 Snyk Code tests a month. Team starts at $25 a month for up to 10 developers. Security focused, so it does not replace a code quality platform.

CodeQL

GitHub's own code scanning engine. It is built for security queries and runs through GitHub code scanning. It is free for public repositories. For private repositories, check GitHub's current pricing for code security features. It is powerful but heavier to configure than a linter.

Codecov

Coverage reporting and pull request coverage comments. The free Developer plan is limited to one user on private repositories and 250 private uploads a month. Team is listed at about $4 to $5 per user, and Pro at $12. It does one job: coverage.

CodeRabbit

An AI reviewer that comments on pull requests. It is not a static analyzer. Free reviews apply to public repositories. Private repositories need a paid plan, starting at $24 per user a month billed yearly. It fits teams that want opinions in natural language on their diffs. It does not produce a stable score you can track over time.

What is DebtDraft, and who is it for?

DebtDraft is a GitHub Action that posts one comment on each pull request with a health score. The score combines five signals: cyclomatic complexity, test coverage, code duplication, outdated dependencies, and known-vulnerable dependencies. A changed-lines view shows how the pull request itself affects those signals, separate from the whole repository. A dashboard shows each repository's trend over time.

Setup is one workflow step plus an API key. There is no server to run.

Pricing:

Free: up to three connected repositories, all signals on every pull request, one comment updated on every push, and full trend history on the dashboard.
Pro: $9 a month or $90 a year, a flat price for your account and not per contributor. It includes everything in Free plus unlimited repositories and extra features. The current list is on https://debtdraft.dev/pricing.

What to know before you try it:

Complexity, duplication, and coverage analysis are built for JavaScript and TypeScript projects today. The dependency checks work from lockfiles and manifests, so they apply to any language that has them.
It focuses on five signals instead of a large rule set of bug and code-smell checks.
Coverage comes from the reports your own tests already produce.
For security, it reports known-vulnerable dependencies. It does not scan your own code for flaws, so it pairs well with a security scanner.

It fits JavaScript and TypeScript teams that want a clear health score on every pull request and a trend for each repository, with no server to run and no per-seat pricing.

Which one should you pick?

A health score on every pull request and trend lines per repository, for JavaScript and TypeScript projects: DebtDraft.
Many languages and a hosted platform: Codacy or DeepSource.
Security is the priority: Semgrep, Snyk Code, or CodeQL, ideally next to a quality tool.
Where to refactor first: CodeScene.
JetBrains shop: Qodana.
Only coverage: Codecov.
Opinions on diffs from an AI: CodeRabbit.
Staying on SonarQube: reasonable if you already run it and the main branch checks meet your needs.

FAQ

Is SonarQube free?

SonarQube Community Build is free and self-hosted. SonarQube Cloud has a free plan for private projects up to 50k lines of code.

Does SonarQube Community Build analyze pull requests?

No. It analyzes the main branch only. Pull request analysis starts in the Developer edition.

What is the best free SonarQube alternative for GitHub?

It depends on the job. Semgrep's free edition covers up to 10 contributors and 10 repositories for security scanning. Codacy's Developer plan is free. DebtDraft is free for up to three connected repositories. Which fits depends on which part of SonarQube you rely on.

Do these tools charge per user?

Most do: Codacy, DeepSource, Qlty, CodeScene, Qodana, Semgrep, Codecov, and CodeRabbit all price per person. SonarQube Cloud charges by lines of code, Snyk by tests and developers, and DebtDraft is a flat price per account.

Can I use more than one?

Yes, and many teams do. A quality tool plus a security scanner is a common pairing, since they check different things.

Final note

Compare on your own repository before you commit. Most tools above have a free plan or a trial, so a week on a real project tells you more than any list. If a JavaScript or TypeScript project is what you have, you can try DebtDraft at https://debtdraft.dev. Sign in with GitHub and the dashboard walks you through setup.

Disclosure: this article is published by DebtDraft, which is one of the tools listed. It is listed first in the table and has its own section. Every price in this article comes from the vendor's own pricing page and was checked on 2026-10-30. Prices change, so confirm before you buy.

How to Review AI-Generated Pull Requests: A Checklist Before You Merge

DebtDraft — Sun, 25 Oct 2026 13:13:54 +0000

A pull request can look perfect. Clean names, tidy functions, a green CI check. And half of the new tests can still assert nothing.

AI-written code does not look sloppy. It looks like a competent person wrote it, and that is exactly the problem. Your instincts for spotting bad code are tuned to messy code, and this is not messy.

If your team merges AI-generated code, here is a checklist to run before you do. Each item also notes what a bot can check for you, so your attention goes to the things only a human can judge.

1. Does it solve the actual problem?

AI is very good at satisfying the letter of a prompt while missing the intent. Before you read the diff, read the ticket. Write down in one sentence what this change should do.

Then look at the file list. If the ticket was about one endpoint and the pull request touches nine files, ask why. Agents love to "improve" things nobody asked them to touch.

Human's job: compare the change to the intent.
Bot's job: none. This one is yours.

2. Is the diff small enough to review?

If you cannot hold the change in your head, you cannot review it. A big AI-generated diff gets a skim and a quick approval, and that is where bugs get through.

If the diff is too large, send it back and ask for smaller pieces. This is not rude. It is the same thing you would ask of a human colleague.

Human's job: push back on size.
Bot's job: none. This one is yours.

3. Do the imports and APIs actually exist?

Generated code often calls methods or options that sound right but do not exist in your installed version. Confident-looking code is not proof.

For anything unfamiliar, check it against the official docs for the version in your lockfile. Pay special attention to new dependencies the change adds. Ask yourself whether you would have chosen that package.

Human's job: verify unfamiliar calls and new packages.
Bot's job: a dependency check can flag packages that are outdated or have known vulnerabilities, so you do not have to look each one up.

4. Do the new lines have tests, and do those tests mean anything?

This is the one that gets the least attention.

Overall coverage is a project-wide number. A pull request can add a lot of untested code and barely move it, because the old, well-tested code dilutes the result. The opposite also happens: a refactor can lower overall coverage even though the new code is fine.

What you want to know is patch coverage: of the lines this pull request changed, how many are exercised by tests? That number says much more about this specific change than the project average does.

Then check what the tests actually assert. A quick trick: flip one assertion and see whether the test still passes. If it does, the test is decoration.

// Looks like a test. Proves nothing.
test("creates a user", async () => {
  const user = await createUser({ name: "Sam" });
  expect(user).toBeDefined();
});

Human's job: read the assertions.
Bot's job: report coverage for the changed lines separately from the project total, so a gap is visible without opening a coverage report.

5. Did it copy something that already exists?

AI does not know your codebase the way you do. It often writes a new helper next to an identical one that already lives three folders away. Every copy is a place where the next bug fix has to be made twice.

Search for similar logic before approving. A new utility function should make you ask whether one already exists.

Human's job: recognize existing helpers you know about.
Bot's job: a duplication check can flag repeated blocks the pull request introduced.

6. What happens when things go wrong?

Generated code handles the happy path beautifully. Check the unhappy paths:

What happens with empty input or missing values?
What happens on a timeout or a failed network call?
Are errors swallowed silently? An empty catch block is a classic.
Does it log anything useful when it fails?

Human's job: think about failure cases.
Bot's job: a complexity check can point at functions that have grown many branches, which is where failure handling usually hides.

7. Did a secret slip in?

Agents copy examples. Sometimes an example contains something that looks like a real key, and sometimes it is one. Check for hardcoded tokens, passwords and connection strings in the diff.

Human's job: glance at config and environment changes.
Bot's job: a secrets scan on the changed lines is cheap and catches the obvious cases.

A checklist you can paste into your pull request template

- [ ] I can state in one sentence what this change should do
- [ ] The files changed match the task
- [ ] The diff is small enough to review properly
- [ ] New imports and API calls exist in our installed versions
- [ ] New dependencies are justified, current and safe
- [ ] Changed lines have tests that fail when the code breaks
- [ ] Nothing duplicates a helper we already have
- [ ] Empty, null and failure cases are handled
- [ ] No secrets in the diff

Let a bot do the boring half

Items 3, 4, 5, 6 and 7 are partly mechanical. A human reading the diff is a slow and tired way to check them, and the review energy is better spent on item 1 and on the design questions only you can answer.

DebtDraft is built for this. It is a GitHub Action that leaves one comment on each pull request with a health score across the signals above: complexity, test coverage, duplication, outdated dependencies and known-vulnerable dependencies. It also shows the changed lines on their own, so you can see what this specific pull request did, and a dashboard shows how your repository trends over time.

It is free for up to three repositories, and setup is one workflow step. If you try it, let us know what you think.

Your turn

What is the sneakiest problem you have seen in an AI-generated pull request? Share it with us in the comments.

Why Did Supabase Pause My Project? How to Restore It and Stop It Happening Again

DebtDraft — Wed, 21 Oct 2026 12:03:36 +0000

You open your app and nothing loads. You check the Supabase dashboard and there it is: "Your project has been paused."

Don't panic. Your data is almost certainly fine, and you can usually bring the project back in a couple of clicks. Short answer: Supabase pauses Free plan projects after about a week of low activity. Below is why your Supabase project was paused, how to restore it, and how to stop it happening again.

Why did Supabase pause my project?

Supabase pauses Free plan projects that show low activity over a 7-day period. It does this to save server resources. A project that is not on a paid plan and has not had enough database activity in the last week is a candidate.

The important detail is the word database activity. Opening the project page once in a blue moon is not the same as your app actually querying it. If you built something, shipped it to a few friends, and moved on to the next idea, this is exactly the pattern that gets a project paused.

You should get a warning email about a week before the pause, and a second email once it has happened. Check your spam folder. Those emails go to the project owner's address, which is not always the one you check daily.

How to restore a paused Supabase project

Open the Supabase dashboard and select the paused project.
Click Resume project.
Wait a few minutes while it comes back up, then test your app.

According to Supabase's current docs, you can restore a paused project for up to a year after it was paused. That window has changed before (it was once 90 days), so don't rely on a number you read in a blog post, including this one. Check what your own dashboard offers, and do it sooner rather than later.

Two things worth knowing:

Paused projects don't count toward the free project limit, so you can keep other projects going while you sort this out.
If you upgrade to a paid plan, projects stop being paused for inactivity, and you may get expired restore options back.

What if the Resume button is missing?

If the project has been paused for a long time, the one-click restore can be gone. In that case the dashboard offers you a download of the latest backup instead. The rough recovery path looks like this:

Download the backup from the dashboard.
Create a new Supabase project.
Restore the backup into the new project.
Update your app with the new project URL and keys.

Be honest with yourself about step 3. Some people report that restoring an old backup into a fresh project throws errors around roles, extensions or the auth, storage and vault schemas, especially if a lot of time has passed. If that happens, don't keep hammering it. Open a support request from the dashboard and say how long the project has been paused.

And step 4 is the one people forget. A new project means a new URL and new keys. If your app still points at the old ones, it will fail in confusing ways even though the restore worked.

How to stop Supabase from pausing your project

From quickest to most permanent:

1. Generate real activity. After you get the warning email, visit the project in the dashboard, or make requests to it from your app. A few database requests a day is usually enough to prevent a pause.

2. Add a small scheduled request. If you have a side project that nobody visits every day, a scheduled job that does one simple read keeps it awake. Here is a GitHub Actions example. Put the project URL and the anon key in repository secrets, never in the file:

name: Keep Supabase awake
on:
  schedule:
    - cron: "0 9 * * 1,4"   # Monday and Thursday
  workflow_dispatch:

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Read one row
        env:
          API_URL: ${{ secrets.SUPABASE_URL }}/rest/v1/YOUR_TABLE
          API_KEY: ${{ secrets.SUPABASE_ANON_KEY }}
        run: |
          curl -sf "$API_URL?select=id&limit=1" \
            -H "apikey: $API_KEY"

Two catches. GitHub can switch off scheduled workflows in a repo that has had no activity for a while, so check on it now and then. And this is a stopgap for a hobby project, not a plan for something people depend on.

3. Upgrade to a paid plan. This is the real fix. Projects on a paid plan are not subject to automatic pausing for inactivity.

Before real users show up

A pause is a good reminder that "works on my machine" and "ready for users" are different things. A quick pre-launch check:

Do you know where your backups are, and have you tried restoring one?
Does anything important depend on a project that can go to sleep?
Are your API keys and project URLs in environment variables, not in the code?
Does your app fail gracefully when the database is unreachable, or does it just show a blank page?

None of that is hard, but it is much easier to do on a calm Tuesday than during an outage.

Quick answers

Does Supabase delete my data when it pauses a project? Pausing is not the same as deleting. Your data is kept so the project can be restored, but only for a limited time, so don't leave it indefinitely.

How long until Supabase pauses an inactive project? After low activity over a 7-day period on the Free plan, with a warning email roughly a week before.

Can paid projects be paused? No. Projects on a paid plan are not paused for inactivity.

Will restoring change my API keys? Restoring in place keeps your project. If you have to recover into a new project, you get a new URL and new keys, and you have to update your app.

If you're tidying up a project before launch anyway, you might also care about what is quietly happening inside the code itself. That is why we built DebtDraft, a GitHub Action that leaves one comment on each pull request with a health score built from a handful of essential signals, plus a dashboard that shows how your repo is trending over time. It is free for up to three repositories, and setup only takes a few minutes.

Have you had a project paused at a bad moment? What would have saved you? Tell us in the comments.

You accidentally pushed your .env to GitHub. Here's what to do next.

DebtDraft — Sun, 18 Oct 2026 11:48:50 +0000

You pushed your .env file to GitHub. Maybe you noticed a minute later, maybe a week later. Either way, you open the repo, see your database password sitting in plain text, and your stomach drops.

Your first instinct is to delete the file and push again. Don't stop there. Deleting the file doesn't remove it from your Git history, so the secret is still in an old commit. Anyone who cloned or forked the repo in the meantime still has it.

The good news is that the fix is a short list of steps, and the order matters. Here is what to do next.

Step 1: Rotate the key before anything else

Treat the secret as public from the moment it was pushed. Go to wherever it came from (your database host, your cloud provider, Stripe, OpenAI, whatever the key belongs to), revoke it, and create a new one. Then update the places that use it: your deployment settings, your CI secrets, your local .env.

This comes first for a simple reason. GitHub's own guide to removing sensitive data says you need to revoke and/or rotate the secret, and that once you do, the leaked credential can't be used anymore. Sometimes that alone solves the problem.

Rewriting history is slow and cannot be fully undone. Rotating takes a few minutes. Do the fast thing first.

Step 2: Remove .env from your Git history

Now clean the repository so the file is gone from every commit. GitHub recommends a tool called git filter-repo for this. Install it (GitHub's guide asks for version 2.47 or later), then work in a fresh clone, not your usual working copy. git filter-repo actually refuses to run in a copy that isn't fresh unless you force it, because a fresh clone is the easiest thing to throw away if something goes wrong.

git clone git@github.com:your-name/your-repo.git cleanup
cd cleanup

To remove the whole file from every commit:

git filter-repo --sensitive-data-removal --invert-paths --path .env

Use the file's full path in the repository. If the file lived at other paths in the past, for example server/.env, add those paths too, or run the command again.

If you'd rather keep the file but wipe out specific strings, put them in a text file kept outside the repository folder, and use --replace-text instead:

git filter-repo --sensitive-data-removal --replace-text ../secrets.txt

Then check that it worked. This should print nothing:

git log --all --oneline -- .env

Why not git filter-branch?

You will see older answers on the internet that use git filter-branch. Skip them. The Git project itself recommends git filter-repo over it, and the git filter-repo documentation says the problems with filter-branch can't be fixed without breaking compatibility, so it recommends you stop using it.

Step 3: Force-push, then ask GitHub Support to clear the rest

When you're happy with the result, push the rewritten history back:

git push --force --mirror origin

If Git says origin doesn't exist, add the remote back with git remote add origin <your-repo-url> and push again. Two things you may see:

Rejected pushes to refs/pull/: these are expected. GitHub keeps its own references for pull requests, and you can't overwrite them from outside.
Other rejected branches: if you have branch protection on, you may need to switch it off temporarily, push, and switch it back on.

The rewrite becomes irreversible after this push, so it's worth a pause. git filter-repo records what it changed in .git/filter-repo/changed-refs. If the number of affected refs is higher than you expected, discard the clone and start over before you push.

Then contact GitHub Support through their support portal. Tell them the repository name, how many pull requests are affected, and the first changed commit shown in the git filter-repo output. Support can clear pull request references and cached views of the old commits. Be aware that they only handle sensitive data, not ordinary mistakes, so say clearly what was leaked.

Step 4: Deal with forks and teammates

There are two groups of people you can't fix with a command.

Forks. If anyone forked your repo before you cleaned it up, their copy still has the old history. GitHub can't give you contact details for fork owners, so you'll have to ask them to delete their fork or remove the data. This is another reason Step 1 matters. If the key is dead, an old fork is harmless.

Teammates. Everyone who cloned the repo before the rewrite should either re-clone it or carefully clean their local copy. If they have branches built on the old history, they should rebase them. Merging can bring the removed data straight back.

Step 5: Stop it happening again

Once the incident is over, put some guard rails in place.

Add .env to .gitignore before the next commit.

echo ".env" >> .gitignore

Also be careful with git add . and git commit -a. They are the easiest way to sweep up files you never meant to include.

Turn on GitHub push protection. Push protection blocks a push that contains a recognized secret before it reaches the repository. For public repositories on GitHub.com it is on by default at the user level. For private repositories, an admin has to enable it, and it requires GitHub Secret Protection. If you choose to bypass it, GitHub asks for a reason: "it's used in tests" and "it's a false positive" close the alert, while "I'll fix it later" leaves an open alert behind. That last one is a useful reminder to actually fix it.

Use GitHub secret scanning. Secret scanning runs automatically and for free on public repositories. It raises an alert in the repository when it finds a credential, and GitHub's advice on receiving an alert is the same as ours: rotate it immediately. For private repositories it is part of GitHub Secret Protection, which requires a GitHub Team or Enterprise Cloud plan.

Run a scanner on your own machine or in CI. Tools like gitleaks and trufflehog look through your files and your history for things that look like secrets. Both can run as a pre-commit check or in CI. Check their documentation for the current commands, since the flags change between versions.

One more layer: check every pull request

Push protection and local scanners work best before a secret leaves your machine. A second check on the pull request itself is a useful backup.

We built DebtDraft for this kind of check. It is a GitHub Action that flags hardcoded secrets on a pull request's changed lines, along with other code health checks. The scan runs on your own runner, and secrets stay there. It won't stop the push, so use it alongside push protection, not instead of it. It's free for up to 3 repositories: debtdraft.dev

The short version

Rotate the key.
Rewrite history with git filter-repo in a fresh clone.
Force-push, then contact GitHub Support.
Tell forks and teammates.
Add guard rails so it doesn't happen again.

Everyone pushes a secret at some point. The people who handle it well are the ones who rotate first and ask questions later.

How many lines should a pull request be? We traced the 400-line rule to its source

DebtDraft — Fri, 16 Oct 2026 22:00:14 +0000

Search "how many lines should a pull request be" and you will find the same answer over and over: keep it under 400. Sometimes it is 200 to 400, sometimes "a few hundred". It is always stated as settled fact.

We wanted to know where it comes from. It turns out to be a short trip.

The source: one team at Cisco, in 2006

The number traces back to a study that SmartBear, a code review tool vendor, ran with a Cisco team. Over ten months, 50 developers on three continents had every change reviewed before it went into version control. The study collected metrics from 2,500 reviews covering 3.2 million lines of code, all run through SmartBear's own review tool.

The headline finding is that defect density dropped sharply once a review went past about 200 lines. SmartBear's current guidance turns that into advice: review no more than 200 to 400 lines at a time, because beyond 400 the ability to find defects diminishes.

That is a real study with real data. It is also where most of the evidence stops.

What it measured, and what it didn't

Defect density in this study means defects found per amount of code reviewed. So a drop past 200 lines means reviewers found fewer defects per line. SmartBear reads that as reviewers losing focus. We read it the same way.

What it cannot tell you is whether the code had fewer bugs, or whether the PR was a bad idea to ship. It measures how well people read, not how risky the change was.

A few more things worth knowing:

It was one team, on one product, in 2006, reviewing in a dedicated tool before commit. A modern pull request on GitHub, with CI and a long discussion thread, is a different thing.
Jason Cohen's write-up of the study says the statistical methods and the experimental controls are covered in the book, not in the article.
The "70 to 90% defect discovery" figure that often rides along with the 400 lines is on SmartBear's page without a source attached.
The company that published the number sells the tool that reviews code.

None of that makes the number wrong. It makes it a starting point, not a law.

The newer numbers, and why they seem to disagree

Two vendors publish more recent data, and at first glance they conflict.

LinearB's 2026 benchmarks cover 8,109,244 pull requests from 4,813 teams. They rate PR size at the 75th percentile: under 100 lines is Elite, 100 to 155 is Good, 156 to 228 is Fair, and above 228 needs improvement. Their page does not say whether size counts added lines, deleted lines, or both.

Graphite, in a 2023 post, argues the ideal median PR is 50 lines, with 25 to 100 as a range. They found 50-line changes were reviewed and merged about 40% faster than 250-line changes. Their revert chart, built from a sample of 10 million PRs, shows the least reverted PRs were 25 to 50 lines. The gap is small in absolute terms though: revert rates sit between roughly 1% and 1.6% at almost every size. Their users also skew toward small PRs, which they note themselves.

The two are not really fighting. LinearB reports the 75th percentile of a team's PRs. Graphite reports the median. Three quarters of a team's PRs under 100 lines and a median of 50 can both be true for the same team. They are two views of the same distribution.

Both vendors also sell tools that measure PR size and review speed. Neither number is wrong for that reason, but both come from people who profit when you care about the metric.

One more detail from the LinearB data is worth a note. In their breakdown, the 75th percentile PR is about 157 lines unassisted, about 293 for agent-written PRs, and about 408 for AI-assisted ones. They are clear that this is correlation, not cause. It does show that the "right" size depends on how the code was written.

What none of this shows

No source we found shows that a PR over 400 lines is more likely to ship a bug. The Cisco study is about review quality. The vendor data is about speed and reverts. Neither follows the code after it merges.

Size also counts lines, not review effort. A 2,000-line PR that moves a directory is easier to review than a 60-line change to a payment flow. Generated files, lockfiles and migrations inflate counts without adding load. Graphite's own revert chart has an odd tail too: PRs over 10,000 lines look slightly safer, which the author guesses is because the biggest changes are refactors.

What we would do with it

Treat 200 to 400 lines as a reasonable ceiling for one review sitting, not a rule. It is the best-supported number, and it is about reading, not shipping.
Measure your own median and your own 75th percentile. That is what the vendors report, and it is the only number that describes your team.
Exclude lockfiles, generated files and pure moves from the count.
When a change must be large, say what to read. A short "start here" note in the description does more than splitting a PR arbitrarily.
Care about what is in the lines. A small PR that adds a branch-heavy function with no test is a bigger problem than a long one that is mostly deleted code.

That last point is why we built DebtDraft. It is a GitHub Action that leaves an updating comment on each pull request with a health score, and a view of just the lines that PR changed. We make it, so weigh our view accordingly.

So what is your number? How many lines do you keep a pull request to? At what number does a PR become overwhelming to you?

We scored 6 popular JavaScript repos. The technical debt wasn't in the code.

DebtDraft — Thu, 15 Oct 2026 11:13:02 +0000

We expected to find copy-paste.

Six popular JavaScript projects, the kind you've probably seen in a package.json somewhere. A lot of people say AI-generated code is piling up technical debt, and duplicated code is the usual first suspect. So we ran all six through the same five checks and waited for the duplication number to come back ugly.

It mostly didn't. The ugly numbers were somewhere else.

Why we went looking for duplication

The worry isn't made up. GitClear, a company that sells code analytics, looked at 211 million changed lines from 2020 to 2024. It reported that lines classified as copy-pasted rose from 8.3% to 12.3% between 2021 and 2024, and that 2024 was the first year copy-pasted lines outnumbered moved ones. Coverage of the report put the rise in duplicated blocks at about eightfold.

That is a trend across many repositories over time. What we did is different and much smaller: a snapshot of six mature projects on one day. It cannot say anything about AI. It can say what healthy, well-known code looks like right now, which is a useful baseline to hold your own repo against.

What we did

We picked six well-known JavaScript and TypeScript projects: a web framework, a faster web framework, a validation library, a build tool, a state library and an HTTP server. We cloned each one, scored its default branch, and ran the same five checks on every project.

Cyclomatic complexity, counted per function
Duplicated lines
Test coverage
Outdated dependencies
Known vulnerabilities in the installed dependency tree

All six were scanned on October 15, 2026. We are not naming them. This is a baseline, not a leaderboard, and a score on one day says little about the maintainers who fix things every week.

Coverage came out empty for all six. None of them commit a coverage report, so a fresh clone has nothing to read. We left it out instead of inventing a number.

The code held up

Let's start with duplication. The share of duplicated lines ranged from 0% to about 20%.

The two highest looked scary until we opened the list. In the web framework, the duplicated blocks were test files that repeat each other. In the faster web framework, much of it was adapter files that mirror files elsewhere in the repo. The validation library, third highest, had one file per language. Still duplication, but it looks deliberate, not accidental.

Complexity was calmer than we expected. We flagged functions above a cyclomatic complexity of 10. Between 0.1% and 4.4% of functions crossed that line, depending on the project. A couple were real monsters: two projects had a function above 100. They're easy to point at, and a small share of the whole.

Nothing here makes a project good. But if you came in expecting a pile of copy-paste, there was no pile.

The dependencies were the problem

Then we looked at what each project depends on.

Between 8% and 51% of the dependencies we could check were a breaking release behind the latest version. In the worst project, about half of what it uses is a major version, or the equivalent, out of date.

Then the vulnerabilities. Four of the six commit a lockfile, so there's a real installed tree to audit. All four had known high-severity vulnerabilities somewhere in it, and two had critical ones. The other two don't commit a lockfile at all, so there was nothing for us to audit.

Put together, three projects got an F, one got a D-, one a B and one a B+.

Why a good project can get an F

A grade that looks at the full installed tree counts the tooling too: build, test and lint packages that never ship to your users. We didn't check how many of the vulnerable packages we found fall in that group, so don't read an F as "this library is dangerous".

We still think counting them is right. Your CI runs that tooling with your tokens and your source. But a low grade here means the project has more dependency debt than code debt, and that's where we'd look first.

What to check on your own repo

You don't need a tool for a first pass.

Count the breaking-behind dependencies. Run npm outdated and look at the Current vs Latest columns. Anything a major version behind is a breaking upgrade waiting for you.
Audit the lockfile. Run npm audit against it. If you have no lockfile, that's the finding.
Look at the lines your last pull request changed. Duplication and untested code hide in a diff much better than in a whole repo. A repo-level number can stay green while the new code is the worst in the project.

The third matters most for AI-written changes. Say a reviewer is reading 400 changed lines. The diff can't show that 90 of them already exist in another file, because it only shows what changed.

One disclosure

We build DebtDraft, a GitHub Action that runs these five checks and posts one score on every pull request. We used it to produce the numbers above, with the same settings on all six. Everything in the previous section works without it.

What would you check first on your own repo: duplication, dependencies, or the lines your last pull request changed?

Your AI-written PR passes the tests. Here is what it still hides.

DebtDraft — Wed, 14 Oct 2026 10:52:31 +0000

You know the pull request. 40 files changed, clean naming, tidy comments, green checks. It looks like a senior engineer wrote it on a good day.

Then three weeks later someone asks why there are four nearly identical functions, and nobody can say which one is the real one.

AI-assisted pull requests are polished. That is the problem. Polish makes a reviewer relax, and review is where this kind of debt gets in. Two 2026 studies of agent-authored pull requests point at the same thing: one finds that plausible-looking AI code hides redundancy and less reuse, and another finds that quiet agent contributions can raise complexity and still get merged.

So here are five things everyone must check before merging an AI-written pull request. None of them need special tooling to start.

1. Did the complexity of the touched functions go up?

Open the functions the diff touched, not the whole file. Count the branches: every if, loop, &&, ||, ternary and case adds a path.

A function that was 4 paths and is now 14 is a review item, even if every line is readable. Readable and simple are different things.

2. Are the changed lines covered, or just the file?

A file at 90% coverage can ship a new function with zero tests. Overall percentages hide this because the old, well-tested code props the number up.

Ask a narrower question: of the lines this pull request added or changed, how many does a test actually run? That number is often much lower than the headline.

3. Did it add duplication?

AI tools love to write a new helper instead of finding the one you already have. Search the repo for two or three distinctive lines from the new code. If the same logic already lives somewhere else, you just got two bugs to fix instead of one.

4. Did it add or bump dependencies?

git diff main -- package.json package-lock.json
npm outdated

Check every new package: is it maintained, is it popular for a reason, and do you really need it for ten lines of code? Assistants add packages the way people add browser tabs.

5. Are any of those dependencies known to be vulnerable?

npm audit

Run it on the branch and on main, then compare. What matters is what this pull request introduced, not what you already had. A new advisory arriving with the diff is a reason to stop and look.

Why the changed lines matter

Notice the pattern. All five checks are about the diff, not the repository. A repo-wide score tells you how the project is doing. It will not tell you whether this pull request made it worse.

Reviewers are not lazy. A 40 file diff is just hard to hold in your head, and the polish of AI-written code does half the persuading for you. A short checklist beats trusting your gut on file 31.

Doing it without the manual work

Disclosure: I work on DebtDraft, a GitHub Action that runs these five checks (complexity, coverage, duplication, outdated dependencies and known-vulnerable dependencies) and posts a comment on the pull request which updates in place. It shows the health of the whole codebase and, separately, of just the changed lines. Free for up to three repositories. Find it on the GitHub Marketplace or at debtdraft.dev.

Either way, the checklist above works without it.

Your turn

What do you check first when a pull request is clearly AI-written? Is there a signal you trust more than any of these five?

Know your pull request's health before you merge it

DebtDraft — Mon, 12 Oct 2026 01:08:02 +0000

Most code health problems do not arrive in one big commit. They arrive one reasonable pull request at a time: a function that grows a little too complex, a dependency that falls behind, a change that ships without tests. By the time anyone notices, the problem is everywhere.

DebtDraft is a GitHub Action that makes that visible at the moment it matters, inside the pull request.

What it does

On every pull request and every push to your default branch, DebtDraft scores your repository on five signals:

Code complexity
Test coverage
Duplication
Outdated dependencies
Vulnerable dependencies

The result is one score and one letter grade, posted as a single comment on the pull request. A separate section looks only at the lines the change touches, so you can see what this change did, not just the state of the whole repository.

Track it over time

A hosted dashboard shows every connected repository with its current grade and its trend. You can open a repository to see the score history, and open any scan to see which functions, files and dependencies are behind the number.

Setup

Add one step to your workflow, generate and add the API key, and commit the workflow. That's it!

Privacy

Secrets detection runs entirely on your runner, and secrets never leave it, not even to our own dashboard. Your source code is never uploaded. Privacy is not a privilege. It's a right.

Try it

DebtDraft is free for up to three repositories right now.

Website: https://debtdraft.dev?utm_source=devto
GitHub Marketplace: https://github.com/marketplace/actions/debtdraft

We would love to hear which signal matters most to your team!