The Developer Experience Gaps of Linting on Continuous Integration

Many engineering teams begin their static analysis journey by integrating a linter into their Continuous Integration (CI) pipeline. It seems like the obvious first step: catch problems before merge, keep quality high. Yet, after a honeymoon period, the cracks begin to show — such as noisy results, poor visibility, and slow feedback loops, which lead to developer confusion and stuck pull requests.

Sometimes the accumulated pain results in the linter being yanked from the CI workflow, throwing the proverbial baby out with the bathwater. In other cases, the value of the linting is enough to keep it around, along with a low simmer of developer frustration.

Note: Throughout this article, we use the term “linter” to refer to any static analysis that scans code to produce issues. This includes tools that identify potential correctness issues, duplication, and code smell detection, as well as vulnerability scanners (often referred to as SAST or static analysis security testing).

Challenges of running linters on CI

The developer experience (DX) of linting on CI often leaves much to be desired. After talking with hundreds of developers about these problems, some common themes emerge:

• Noisey results come in many forms – All static analysis has false positives, or cases where a rule incorrectly flags valid code. However, in the context of a developer workflow, any unwanted finding is noise, whether it’s an inaccuracy in a rule or simply just a deluge of reported violations about pre-existing conditions.

• Exit code zero is just one bit of data – At their heart, continuous integration systems are designed to run pass/fail jobs. When a check fails, developers get a red X and a link to a plain text log file to dig out the root cause. Static analysis findings come in many shapes and forms, ranging from critical security vulnerabilities to project conventions and best practices. Stripping them down to a single bit of signal limits their potential.

• Applying fixes is a slow feedback loop – When an issue is found, it’s rarely accompanied by a fix suggestion. Regardless, the developer must return to their IDE, apply the correction, and restart the CI workflow. (Hopefully, they can quickly run the exact same linting rules locally that are running on CI.) This context switching swiftly adds up, especially for code that “works”.

As a result, when developers run linting in their continuous integration, they naturally gravitate towards constraints that help to make running the pipeline manageable:

• They often limit linting to the primary language of the project, despite the high impact of a bug in a supporting technology, such as a shell script, Dockerfile, YAML configuration file, or Terraform module.

• They are cautious about turning on new rules due to the flood of findings that typically results when enabling new checks on large codebases.

• They often avoid rules for best practices because they are frequently situational, and the time budget for dealing with failed CI workflows needs to be focused on security and correctness issues.

These constraints are common-sense strategies to limit front-line developer pain, but they also prevent teams from fully leveraging static analysis for code quality. What if we could address the root causes, remove these constraints, and unlock all the value that today’s linters have to offer modern development teams?

How can we do better for developers?

Qlty was designed to solve those pain points, transforming linting from a nagging chore into a streamlined, developer‑first workflow.

Accelerating feedback with linting in every developer tool

The sooner developers get feedback, the better. Qlty ensures consistency and speed:

• Developer tool integrations: Get the same results everywhere – locally via the Qlty CLI, in your IDE, as Git pre-commit/pre-push hooks, and finally in the cloud after code is pushed.

• Blazing speed: Leveraging concurrency, caching, and Git-aware execution, Qlty runs linters significantly faster. For example, it can run RuboCop up to 3x faster than direct execution, providing near-instant feedback locally.

• Simplified toolchain management: Developers don't need to manually install and manage dozens of linters across different machines and operating systems; Qlty handles it with our declarative system for installing and updating analyzers.

Universal linting: Embrace the long tail of tools

Modern applications are often polyglot, and it’s common for a single web application to rely on a dozen languages and technologies. Yet, static analysis tools are usually language-specific, resulting in coverage gaps.

We used the power of our plugin system to make it easy to find and run the best code quality tools from every developer ecosystem:

• Broad technology support: Qlty integrates over 70 static analysis tools covering 40+ languages and technologies out-of-the-box, including Infrastructure as Code like Terraform.

• Comprehensive analysis: Beyond basic linting for bugs, these static analysis plugins identify security vulnerabilities, maintainability issues such as duplication, and help enforce coding conventions.

• Unified experience: Receive all code quality findings through a single, consistent user interface, dramatically reducing the effort needed to learn the intricacies of each linter’s output.

Cutting the clutter: Focus on what’s new

Remember the frustration of wading through hundreds of findings related to pre-existing code just to find the one or two issues relevant to your changes? This noise is a significant source of "warning fatigue" and makes it risky to enable new, valuable checks.

To truly enable teams to adopt code quality checks fearlessly, we combine Git-aware intelligence with advanced customization controls:

• Suppress pre-existing issues: It intelligently analyzes only the changes in a commit or pull request, reporting only newly introduced issues using advanced fingerprinting. This makes feedback actionable and prevents developer fatigue.

• Safe adoption & upgrades: Teams can confidently introduce new linters, enable stricter rules, or add custom checks (like ast-grep) without unleashing a flood of legacy violations, smoothing the path for continuous improvement.

• Multiple reporting modes: Not all static analysis issues should be treated equally. With Qlty, every issue can be configured to block (fail the PR), comment (report but not fail), or monitor (track internally but not report on the PR) based on the rule, location, and other factors.

From red X to rich context: Seamless GitHub integration

A simple pass/fail signal (the "red X") forces developers into a painful debugging loop: click the link, scroll through logs, find the issue, switch to the IDE, fix, commit, push, and wait... again.

Qlty embeds itself within the GitHub Pull Request experience:

• Feedback where it matters: Issues appear as contextual review comments directly on the affected lines of code within the PR's "Files changed" view.

• Integrated triage: Developers can manage findings directly in GitHub, marking issues as "won't fix" by resolving the comment thread. Role-based controls enable authorized users to approve pull requests as needed.

• One-click fixes: Say goodbye to the round trip to the IDE for simple fixes. Qlty presents available tool-generated autofixes as code suggestions within the PR. AI Autofixes dramatically expand this capability, significantly increasing fix coverage and turning tedious corrections into a single click.

Elevate your code quality experience

While adding linters to CI is a common starting point, settling for its inherent limitations in developer experience means leaving significant value on the table. By directly addressing the core frustrations – noise, poor visibility, slow feedback, and lack of integration – Qlty offers a more cohesive, intelligent, and developer-friendly approach. It transforms static analysis from a CI gate developers must grudgingly pass into an integrated tool that actively helps them write better, safer code, faster.