This started as a research question. The common pitch is that AI coding agents drift from the architecture conventions you write in prose (CLAUDE.md, AGENTS.md) so you need a deterministic lint rule to hold the line. I wanted to know if that was true so I built a pre-registered benchmark to test it. On the boundary I tested, the agents did not drift. So I stopped that research line and published the null result.
But I kept the useful half. Before this, whenever I wanted an architecture rule enforced, I wrote it by hand and read each linter's docs to wire it up. That's tedious and most teams just leave their conventions in someone's head. So I flipped it around.
Archprint reads your repo's real import graph, finds the boundaries your code already follows and generates lint rules from the ones that hold up. Each candidate is gated on a statistical confidence bound so it only proposes a rule your codebase demonstrates strongly enough for its size. Every rule comes with the evidence: how many files conform, how many break it, how confident the inference is.
It's honest about what it enforces on its own. The mechanical rules (no import cycles, production not importing tests, no console in library code, no undeclared deps, public-API barrels, DB or UI imported into a server entry) auto-generate. The ones that guess a "layer" from folder names are held for human review because that guess can be wrong and one wrong enforced rule is worse than none.
It emits into the tools you already use: ESLint (including a shareable preset), dependency-cruiser, and ts-arch.
Before releasing, I ran scan and recommend across 92,861 real public TypeScript repositories. Zero crashes. The full install, wire, and uninstall round-trip ran clean on a large representative sample.
Try it:
`npm install --save-dev archprint
npx archprint scan .`
Tool: https://github.com/Tommkruix/archprint
Benchmark: https://github.com/Tommkruix/agentrulebench
Early days. I'd love feedback, especially on any rule it gets wrong on your repo.
Top comments (1)
I like that lint rules are decisions, not preferences, because it explains why the tool is worth building at all. Inferring the rules from what's there is a lot faster than writing them from scratch, but what happens after that first pass is hard. A rule set derived from existing code only ever encodes what the code already does, so the drift you're trying to catch is the one case it can't see. The useful move is usually to take the inferred rules and add the ones the codebase currently violates on purpose, because those are the decisions someone made and never wrote down.