My colleague's article, "From Syntax Tinkering to Systems Thinking", makes the case that the heart of the work has moved up the stack, from syntax to systems. This post is the tooling side of that shift. If the work that matters now lives above syntax, the tools that only check syntax can't reach it.
Every team has a style guide. Somebody wrote it, and nobody has opened it since. Meanwhile, the formatter, linter and type checker run on every commit. One of these is enforced. The other is a museum piece.
The difference isn't discipline.
One of them can run, the other can't.
A linter enforces what a parser can see. Use === not ==. No unused variables. Imports in order. The rules that decide how your team actually builds software sit on a spectrum that starts there and runs far past it.
At one end, rules a linter could almost handle. "Error messages follow the format [module] verb: reason". A regex gets you most of the way.
In the middle, rules where you can check the shape but never the substance. "Every permission check has a test that proves it blocks." A tool can confirm the test exists. It can't confirm the test exercises the denial.
At the far end, pure judgment. "Confirm the bug is actually a bug before you fix it." "List every caller before you move the code." No parser is ever going to do that.
The far end is where most of the rules worth having live. It's also where they go to die: in onboarding docs, review checklists, and the heads of the two people who remember why.
The doc decays, because a doc is a thing you have to remember to read.
Here's what changed. An LLM reads prose and applies it like a rule. The style guide stops being a document and becomes a runtime. You write "server actions must be async functions, not arrow functions" in plain markdown, hand the folder to the agent, and it flags the violation on the pull request. No custom ESLint plugin. Just the rule in English, and something that reads it.
A style guide you can run does things the static version never could.
It reviews. The agent comments on every PR where the code drifts from a rule.
It migrates. A deprecated pattern links to its replacement, and the agent rewrites it on touch. HTTP 301 for code: old location, new location, permanent redirect.
It counts. Ask how many files still use the old pattern and you get a number. The guide is its own dashboard.
The trap is writing the whole thing upfront. That's what killed the last one: three hundred rules nobody reviews, the wiki page again but longer. It should grow from friction, not a committee. The agent watches merged PRs and proposes a rule when reviewers correct the same thing three times. It works the other way too: mid-review, you ask whether the correction you're about to write belongs in the guide instead of this one PR. When it does, the rule goes in the same PR as the fix, checked in alongside the code and live for the next diff.
It isn't free. The agent isn't deterministic the way a linter is. It misses things, reads an edge case differently than you would, applies a rule one way on Monday and another on Thursday. You trade certainty for reach. The payoff: rules no parser could ever express, enforced on every PR, no plugin required.
The old style guide was a promise the team made and quietly broke. A rule nobody enforces is a suggestion. A rule the agent runs on every diff is the style.
