Pre-Commit vs CI Quality Gates: When Fast-Shipping Moves The Checks Upstream

Home All Posts Pre-Commit vs CI Quality Gates: When Fast-Shipping Moves The Checks Upstream

Trends,

AI in Software Engineering

22/07/2026

Pre-Commit vs CI Quality Gates: When Fast-Shipping Moves The Checks Upstream

Codacy

8 mins read

In this article:

Subscribe to our blog:

Teams that ship dozens of pull requests a week eventually run into the same wall: CI-stage quality gates turn into a queue. A developer opens a PR, moves on to the next ticket, and twenty minutes later gets pinged that a linter failed or a dependency check flagged something trivial.<br>Fixing it now means reloading context on a branch they have mentally already closed. Multiply that across a team shipping fast, and the queue becomes the bottleneck, rather than the code itself.

This article looks at when it makes sense to move enforcement earlier, into the IDE and the local Git workflow, and when CI should stay the first and only line of defense.

TL;DR

CI remains the authoritative place to validate a merge, but it doesn’t have to be the first place developers discover every issue. Moving fast, deterministic checks closer to where code is written minimizes pointless context switching and lets CI verify the changes that need full-system context.

Why CI-stage feedback starts to break down at high PR volume

The problem is that, usually, CI quality gates arrive too late relative to how a developer's attention actually works. The moment code is pushed, most engineers move to the next task, whether that is a standup, a different ticket, or a second branch entirely.

When CI fails ten or twenty minutes later, the fix requires reloading a mental model that has already been discarded.

Research from Gloria Mark at UC Irvine, whose work tracks how knowledge workers respond to interruptions, found that it takes an average of 23 minutes and 15 seconds before returning to an interrupted task after being pulled away from it. A one-line lint fix does not take 23 minutes, but interrupting a developer after they have mentally moved on still incurs a meaningful reload cost.

This is why the complaint rarely shows up as "CI is slow." It shows up as reviewers re-requesting changes on PRs that already look finished, as Slack threads asking someone to "just push the fix," and as a growing gap between when a PR opens and when it actually merges.

None of that is a tooling failure. It is a timing failure, and it compounds with every additional pull request a team pushes through the pipeline each week.

What pre-commit checks change in the development workflow

Moving enforcement earlier means running checks before code becomes a pull request at all, typically inside the IDE or as part of the local Git workflow.

The mechanical shift is straightforward: instead of a developer learning about a problem after pushing, they learn about it while the file is still open and the reasoning behind the change is still active in their head.

A misused string interpolation, an accidentally overbroad exception handler, or a hardcoded API key gets caught and fixed in the same sitting the code was written, not in a second sitting triggered by a failed build.

The practical consequence is that pull requests arrive at review already clean of the categories of problems that pre-commit checks cover.

Reviewers stop spending their attention on formatting arguments and obvious static analysis findings, and CI becomes a confirmation layer rather than a discovery layer: it still validates the merge candidate, but fewer issues show up there for the first time.

The distinction worth holding onto is that pre-commit enforcement is not meant to be a direct, smaller copy of the CI pipeline. Its value depends entirely on staying narrow, fast, and scoped to whatever the developer just changed. The moment it tries to do everything CI does, it stops being a convenience and starts being an obstacle developers route around.

When pre-commit quality gates are worth the tradeoff

Moving checks earlier is an architectural decision, not a default setting, and it only pays off when the cost of late feedback exceeds the cost of running checks locally.

Industry tracking from DX's Q4 2025 developer impact report, based on a sample of more than 135,000 engineers, found that 22% of merged code in its sample was AI-authored, and daily AI users merged roughly 60% more pull requests than light AI users.

That is not a marginal increase in review load. It means more code reaching CI for the first time, more of it generated quickly enough that a developer may not have scrutinized every line — Stack Overflow's 2025 survey found 66% of developers cite AI solutions that are “almost right, but not quite” as their biggest frustration.

A second signal worth watching is what CI failures actually contain. If a meaningful share of failed builds trace back to formatting, an obvious static analysis rule, or a secret that should never...