Linting

Linting is a long-established habit in software development. A linter reads code without running it and flags anything that breaks a set of rules, from a variable that’s never used to a construction the compiler accepts but that’s likely to cause trouble. Stephen Johnson wrote the first, Lint, at Bell Labs in 1978 and named it after the fluff a dryer filter collects. Linters now run routinely in programmers’ editors and again before code is merged, so a team’s conventions get checked every time without anyone having to remember them.

The idea transfers neatly to writing, and documentation teams, who often keep their work alongside code already, have been quickest to adopt it. Prose linters such as Vale and proselint compare a draft with a set of rules and report what they find: a banned word, an em dash where house style wants an en dash, a heading in title case, a sentence over forty words. Rules range from simple patterns (this spelling, never that one) to counts and measures such as sentence length or reading level. A linter flags rather than fixes. Some propose a correction, but the decision stays with whoever is writing.

Spellcheckers and grammar checkers have done something similar for decades, but they apply the general rules of a language. Linting comes into its own with the rules particular to an organisation: its house terms, its punctuation choices, the phrases its style guide has ruled out. It also differs from automated testing, which checks whether things work (links resolve, required fields are filled, pages build), and from a copy edit, where a person reads for meaning as well as consistency. A linter checks text against rules, and only the rules someone has written down.

Why it matters for content

Writing a rule down tightly enough for a machine to apply shows what a style guide means. “Avoid jargon” can’t be linted; a list of forty terms with their plain alternatives can. The exercise sorts guidance into three kinds: rules a pattern can check reliably, such as spellings, punctuation and house terms; rules where a pattern can only nominate candidates, such as whether a year belongs in a citation or whether “they” is ambiguous; and rules that stay with judgement, such as whether a paragraph earns its place. Sorting them often exposes guidance that different people had been reading in different ways.

Linting also moves a rule to the moment of writing. A flag in the editor costs a few seconds while the draft is open; the same point raised in review costs a round of comments, and an editor correcting “e-mail” for the hundredth time is attention spent on nothing. Severity needs as much thought as coverage, because a linter that blocks publishing on every warning trains people to switch it off. GitLab’s documentation team fails a build only on errors and leaves warnings and suggestions as information for the writer. And a linter enforces a bad rule as faithfully as a good one. If the guide is wrong, the linter carries the mistake into every page it checks.

How AI changes the picture

Language models can apply rules that patterns can’t. Asked whether “they” is ambiguous in a sentence, whether a year in a citation changes how a reader would treat the source, or whether a paragraph has slipped into a sales register, a model can give a usable answer across thousands of pages. That brings judgement-shaped guidance within reach of automated checking, provided the rule comes with a test the model can apply and examples of passing and failing cases. Without them, a model applies its own reading of the rule, which may not be the editor’s.

Generated text tends to fail in patterned ways (favourite words, stock sentence shapes, a reflexive rhythm of contrasts), which makes linting a natural first check on AI-assisted drafts. Open rule sets for spotting those patterns already exist, and a draft can be run against one before a person reads it. A clean pass is a minimum, though. A draft can avoid every listed pattern and still say nothing.

Model-based checks bring a failure mode that patterns don’t have. A pattern rule does what it says and nothing more; a model interprets the rule, and can misread it, deleting a whole sentence when asked to trim one detail or reporting a check it didn’t run. Model checks are safest when they produce visible flags and proposed changes instead of silent edits, with someone sampling what they pass as well as what they flag.