By The Scale Problem Every Growing Team Hits
Your TypeScript codebase just crossed 100,000 lines. ESLint violations are multiplying. Developers are sprinkling // eslint-disable comments everywhere to keep moving. Your CI is failing. Code reviews catch some issues, miss others. The core engineering team is drowning in requests to “just disable this rule for this file.”
This is how code quality dies at scale—not with defiant developers ignoring standards, but with a thousand invisible exceptions that seemed reasonable at the time.
Twitch engineers recently revealed how they manage a million-line TypeScript monolith with 300 developers without this quality collapse. Their solution—lint snapshots—inverts how most teams think about code standards enforcement.
The Real Problem: Invisibility, Not Defiance
“At scale, standards don’t fail because people ignore them,” says Josh Ribakoff, a former Twitch engineer who led the initiative. “They fail because exceptions become invisible.”
Here’s what happens in practice: Editor integrations auto-insert eslint-disable comments. Developers copy-paste code, propagating outdated exceptions. Refactors lose context about why rules existed. Temporary workarounds become permanent fixtures. Moreover, core teams can’t see which exceptions were reviewed versus which slipped through accidentally.
Most teams treat this as a people problem—developers don’t care about quality, need more training, need stricter enforcement. However, it’s actually a visibility problem. Traditional tools don’t surface exceptions for review at the right time.
Lint Snapshots: Treating Violations as Artifacts
Twitch’s solution inverts the traditional approach. Instead of scattering eslint-disable comments throughout the codebase, they treat violations as tracked artifacts.
Here’s how it works:
- Run ESLint but ignore all
eslint-disablecomments - Capture violations into a snapshot file at the repository root
- Strip line numbers (prevents churn from code changes)
- Assign snapshot ownership to the core team via CODEOWNERS
The clever part: Any change that adds or relocates an exception automatically triggers core team review. Developers maintain velocity—they can add exceptions when needed. Furthermore, the core team gets visibility—they must approve those changes.
Exceptions become explicit conversations instead of buried comments. As one Hacker News commenter noted, “This is brilliant. It’s not about being the code police, it’s about making trade-offs visible.”
Why This Matters More in 2026
Three trends are converging to make code quality at scale even harder—and lint snapshots more critical.
TypeScript’s Performance Breakthrough
TypeScript 7.0 delivers 10x faster builds compared to version 6.0. Fast multi-threaded compilation, parallel project builds, and reimplemented incremental checking make builds “instantaneous” for small changes even in massive codebases.
The bottleneck just disappeared. Consequently, large TypeScript monoliths are now more viable, not less. Teams that considered splitting their codebase purely for build performance can reconsider.
AI-Generated Code Explosion
Here’s the uncomfortable reality: 41% of all code is now AI-generated, according to MIT Technology Review. And it’s creating quality problems.
Google’s 2024 DORA report found that a 25% increase in AI tool usage correlated with a 7.2% decrease in delivery stability. Similarly, the State of Software Delivery 2025 report found the majority of developers now spend more time debugging AI-generated code.
Most damning: A SonarSource study from August 2025 tested every major LLM and found they all generated a high proportion of BLOCKER-level vulnerabilities—the most severe security rating.
AI makes writing code easier. It makes maintaining code harder. Therefore, code quality challenges are accelerating, not slowing down.
The Monolith Comeback
Stop me if you’ve heard this before: “Our monolith is slowing us down, we need microservices.”
Turns out that was often the wrong diagnosis. A 2025 CNCF survey found 42% of organizations have consolidated services back from microservices into larger deployable units. Additionally, Gartner reports 60% of teams regret microservices for small-to-medium applications.
The kicker? 90% of microservices teams still batch deploy like monoliths, negating the supposed architectural benefit.
Amazon Prime Video famously moved their monitoring system back to a monolith and cut infrastructure costs by 90%. Microservices benefits only appear with teams larger than 10 developers. Below that threshold, monoliths consistently perform better.
The industry isn’t regressing. It’s course-correcting.
When to Adopt Lint Snapshots
This pattern isn’t just for Twitch-scale teams. Consider lint snapshots if you have:
- TypeScript codebase over 50,000 lines
- Team larger than 10 developers
- Monorepo or monolith architecture
- Growing count of ESLint exceptions
- A core team responsible for code standards
The implementation effort is light. It works with your existing ESLint setup. No major tooling investment required. You can start incrementally, applying snapshots to critical rules first.
Expect to see this pattern evolve: a formalized ESLint plugin, integration with GitHub and GitLab review flows, adoption by monorepo tools like Nx and TurboRepo, extension to other linters beyond ESLint.
Monoliths Aren’t the Enemy
Here’s the bigger lesson: Stop treating monoliths as legacy architecture that must be escaped. Well-managed monoliths beat poorly-managed microservices.
The question isn’t “should we split our monolith?” It’s “can we manage our monolith well?”
Lint snapshots are one answer. TypeScript 7.0’s performance gains are another. Project references, incremental builds, and proper tooling are others. The tools exist. The patterns exist.
Most teams jumped to microservices for the wrong reasons—cargo-culting Netflix and Amazon’s architectures without their scale or team size. The 42% who switched back aren’t admitting defeat. They’re choosing pragmatism over ideology.
Code quality at scale is hard. But it’s solvable without abandoning monoliths, blocking development velocity, or drowning in manual code reviews. You just need better visibility into exceptions—which is exactly what Twitch figured out.
