Nobody reads code anymore. Write for the linter.

When was the last time anyone on your team actually read the codebase? Not skimmed the diff, not glanced at the PR title. Sat with the file. Some teams still do it. Some say they don't have time. Some never really did. Here is what we landed on after running aislop scan on 25 real projects. Internal tools. Client repos. Open source apps. Median score before any cleanup, 15 out of 100. After one aislop fix pass, 32. After aislop fix --claude, 47.

The headline is 15. That's what every one of these codebases looked like when we showed up. All of them had passing tests. All of them were shipping. None of them had been read in any real way.

How review used to work

Five years ago, reading the codebase was a weekly thing. A senior handed a junior a subsystem and said "go read this." A bug report meant cloning the repo and following the call graph for an hour. Code review meant opening the file, jumping to definitions, scrolling through what lived next door.

That's gone. The agent spits out a thousand lines in a minute. The human skims two hundred before the next standup. The PR description is the artifact most reviewers actually read. The diff gets a glance.

That 981 line component buried in folder seven of one project? It got reviewed and approved. Somebody clicked merge. Nobody sat with it.

The damage nobody noticed

Four of the 25 projects had real TypeScript damage when we arrived. Compile errors sitting in committed code for weeks.

Nobody noticed because nobody ran tsc locally. CI either didn't have a type check, or had it muted. The agent wrote. The agent committed. CI ran whatever still passed. Ship.

If a human were reading the code, those errors would have been caught. The IDE underlines them in red. The deployment would have screamed. They sat there because the loop had degraded. The TypeScript compiler is the first reader. Nobody was listening to it.

The new reader

The new reader is deterministic. It does not get tired. It does not skim. Every line, every time.

In our stack the reader is aislop scan on top of TypeScript, biome, oxlint, and knip. Forty plus rules across six engines. None of them have an off day.

The reader produces a number. Zero to a hundred. That number is the new pull request artifact. The PR description says what changed. The score says whether the code itself got better, worse, or stayed flat.

Comments tell the same story. A comment above const MAGIC = 0.87 explaining the value used to be written for the next human in the file. There is no next human in the file. The comment is now aimed at the toolchain, which only reads directives. @deprecated. biome-ignore. ts-expect-error. Everything else gets removed by ai-slop/narrative-comment because nothing was reading it anyway.

What changes for code itself

Code has to become self describing. The linter cannot read intent. The human will not. Names carry the weight comments used to.

If your function is more than 80 lines, your agent is doing something wrong. That's what complexity/function-too-long catches. If your file is more than 400 lines, same story. complexity/file-too-large is the linter saying "this would have been split if anyone were reading it."

Type narrowing replaces narrative. A type Status = 'pending' | 'success' | 'error' tells the next reader more than a JSDoc paragraph, and it tells them in a language the reader actually parses.

Optimize for the reader you actually have

The reader is a linter. The linter has rules. Make the code pass them.

Name things so the agent summarizing the file gets it right. Keep files small enough that the next agent reasoning about them has a chance. Skip the narrative comments. Nothing reads them.

Lean into the score. It is the artifact of a working pipeline. One number that says whether the next person in the file, or the next agent, is starting from clean ground or from rubble.

See your score

Run it. You will see the number the linter has been trying to tell you about.

if you want the next release in your feed.