AI didn't make engineering discipline obsolete. It made it the whole job.

First published in September 2025. Rewritten in September 2026 with our own data: a survey of 335 open-source repositories.

Here is how a feature gets built at a growing number of companies now. Someone writes a design doc: what the feature does, where it lives, what it must not touch. The architecture doc already says how the system fits together. Then an agent turns the design into an implementation plan, a list of small, checkable tasks, and works through it one task at a time. The next feature starts the same way, from the same documents.

This isn’t a fringe workflow. It’s what the companies that build coding agents now tell you to do:

Birgitta Böckeler put it most plainly on martinfowler.com: “The spec becomes the source of truth for the human and the AI.”

The docs became the program

Look at what that changes. For twenty years a design doc had one reader, the next engineer, and it was allowed to go stale because that engineer could ask someone. Now its main reader is an agent that implements whatever it says, every time, and asks nobody. The documents in your repository have become the instructions your code is built from.

The adoption curve is steep:

Every practice got more load-bearing

There’s a comforting story that goes with all this: AI writes cleaner code than most humans, so the old disciplines matter less now. I think it has it exactly backwards. Almost no engineering best practice exists to help you write code. They exist to help you change code later, safely, without holding the whole system in your head:

What AI changed is the volume of change. If best practices are the machinery for managing change, and AI multiplied change, every one of them became more load-bearing, not less. The industry data agrees:

GitClear’s connectivity number is the one I keep coming back to. In their words: “New code is less and less woven into the existing codebase.” Refactoring, the work that keeps a codebase’s shape coherent, has collapsed to under 4% of changed lines. That isn’t a story about bad code line by line. It’s a story about system-level properties degrading while everyone’s attention stays at the line level.

So we measured it ourselves

When I first wrote this post, every number in it was somebody else’s. So this time we looked at the repositories this matters most for: 335 active open-source projects whose own documentation describes their architecture. For each one we read the last 30 merged pull requests, and the files, build and config on the default branch.

Put those together. In repositories that went to the trouble of writing down their architecture, AI agents are already in roughly one pull request in three. Repos with an AGENTS.md or CLAUDE.md see even more: 38% of their merged pull requests involve an agent, against 18% in repos without one. Nearly two-thirds hand their agents documents to build from. And of those, 92% run nothing that checks an architecture rule. The agents are building from the docs, and nothing checks that the code still matches them.

The practices that scale themselves, and the one that doesn’t

Most of the classic practices have a guardian that scales automatically. Style has linters. Correctness has tests and CI. Even readability has help now, since coding assistants are genuinely good at naming and idiom. Crank the volume up and these hold the line, because the enforcement is mechanical and per-file.

But look at what’s left unguarded:

The practice with no guardian is architecture: what your docs say the system is, which component depends on which, whether boundaries hold, whether the shape is drifting. In a docs-first workflow that is also the practice the agents lean on hardest, because the architecture doc is what they read before they touch anything.

When the docs are the program, drift is a bug

A stale doc used to cost a confused new hire an afternoon. Now it costs every agent run that reads it, and agents do what the docs say. ETH Zurich’s study of AGENTS.md files found that “instructions in the context files are well followed by coding agents.” An engineer who documented a 108,000-line codebase for agents reported what happens when those instructions go stale:

Böckeler saw it in her own tests: given notes describing classes that already existed, the agent “took them as a new specification and generated them all over again, creating duplicates.” And keeping the instructions current measurably matters: in a study of AI IDE rule files, compliance rose “from 49.14% to 72.13%” after the rules were updated (arXiv 2606.12231). Meanwhile, in a sample of 100 context files, 24% had been generated once and never reviewed again (arXiv 2606.15828).

And the docs are drifting faster than anyone is watching them:

The mechanism is simple. A diff shows you lines. It does not show you that those lines made a sentence in your own README false, or created the first-ever edge from your core into a plugin. That information lives in the relationship between this change and everything around it: other files, other documents, every change before it. It is structurally absent from the thing your reviewers are reading. Here is a real one:

This is not a story about careless review. That pull request was reviewed and approved by people who are good at their jobs. The information simply was not in front of them.

The bill comes due quietly

The failure mode isn’t dramatic. Nothing crashes. The docs drift one clean-looking PR at a time, the agents keep building from them, and the codebase accumulates coupling, cycles and duplicated responsibilities until the symptoms surface as things nobody connects back to architecture: builds got slow, onboarding takes months, every estimate has a fudge factor.

So what do you actually do?

Keep every practice you already have, and keep writing the design docs, specs and plans: that is the right way to work with agents. But be honest about the gap. If the docs are what your agents build from, the docs have to stay true, and in 92% of the repositories that hand their agents docs, nothing checks that they do.

Closing that gap doesn’t mean hiring architects to trace dependencies by hand, and it certainly doesn’t mean slowing your team down to pre-AI speed. It means giving the one unguarded practice the same thing every other practice already has: an automatic, per-PR guardian.

That’s what Striff is. It reads the architecture your docs already describe, turns every checkable sentence into a rule, and evaluates each one at both revisions of every pull request. A rule can be as plain as where a class lives or as sharp as “the domain module must not depend on infrastructure”: if your team wrote it down, the pull request that breaks it is told which sentence it broke, quoted from the file it lives in. Every pull request also gets a diagram of what changed.

The bar is deliberately high, and the consequence is that it is quiet. That is the same bargain your linter makes: you trust it because it does not shout. Your linter guards style, your CI guards correctness, and the documents your agents build from finally get a guardian of their own, at whatever speed your team ships.

Install the GitHub App and open your next pull request.