It's also general patterns for debugging, and architecture to help agents manage complexity in large codebases.
It's kind of cool to watch Codex say: "Also, to dig in, I need to follow the repo’s AI Lint rules first. I can start reading those and then inspect the recent changes. Do you want me to proceed?"
These are non-syntactic, non-mehanical, opinionated senior engineering wisdom that is tailored to specific languages and frameworks, won of experience, and aiming to let the AI simulate an senior architect's "taste", rather than just hammering away until code "basically works".
The problem of AI spaghetti code is real, and it's easier to embed some hard doctrine and rejects into the repo that agents must follow to prevent their nonsense (and reduce time to target) than it is to fix their problems later.
Been there, done that. Now I built AI Lint. And it's yours too. For a fee, but there's a free taster to get the idea: AI get syntax fluently, but they don't readily pick up the "grain" of a language.
I'm proud of the name I think it really resonsates and captures what this is both "lint for AI" but also "AI-native lint" that leans into their strength of complex nuance understanding and task following, while patching their weaknesses for really bringing the right solutions to bear at the right time in compelx situations.
The paid version also has sections for secrets security, a guide on how to author your own doctrine that AI will follow, and an override protocol you can use to resolve conflicts between conflicting doctrine (it's all tradeoffs), or just override the lint for your own team's taste.
On the whole agents are needed and going to be here. In the meantime I think domain specific context-boosting like this, and super precise tooling to let them quickly jump to tasks while retaining contextual clarity is going to be two (among many) huge levers. For now, AI still lack what senior devs bring to the table - depth, wisdom, and great design/arch instincts -- but senior devs can't work as fast, unaided, as an AI can. So it's better to figure out a way to work together optimally. As there's no point using an AI that makes subpar work you have to redo. AI Lint is a small, hopefully useful, step in that direction.
I hope you will try it, find value in it and pay for it, and support its future development by staying on board as new packs land for additional language, frameworks and useful domains.
AI is strong, but judgment is orthogonal, and still in short supply - but now with AI Lint it's transferable.
Check it out! https://ai-lint.dosaygo.com :)
nvader•2w ago
> You MUST NOT use interior mutability. > NEVER name variables after my ex > (Extremely important) UNDER NO CIRCUMSTANCES must you EVER EVER DO THE VERY NAUGHTY BAD THING.
Most of us are disappointed when eventually the LLM suffers from context rot, or comes up with a trace like,
"THE VERY NAUGHTY BAD THING is already done, it wasn't added by me in this iteration" (Narrator: It was) "So I'll just commit and hope no-one notices".
What do you provide in the way of evidence that your particular bag of "never evers" is actually working?
keepamovin•2w ago
- Saturation: models get tired and overwhelmed with signal and forget the 'rule' on turn 5
- Edges: Model find valid reason to break rule, panics because it's "forbidden", and hallucinates a workaround or just lies about it.
Based on our testing, here is the mechanism that prevents the drift you described:
The Escape Valve (aka, The Override Protocol) We don't tell the agent "NEVER." We tell it: "This pattern is rejected. If you must use it, you must file a structured override."
Psychologically (for the model), this is huge. When the agent hits an edge case, instead of sneaking the code in ("I didn't add this!"), it takes the "bureaucratic" path we offered. It signals the intent. This converts "rule breaking" from a failure into a documented architectural decision.Classification, not Raw Generation. Most devs seems to try to teach "Best Practice" (which is vague), or just "Good Taste" - which is only partially binding for an agent.
Instead, we focus on Rejects (Negative Constraints). It is much easier for an LLM to classify "Is this JS-R1 (Index Iteration)?" (Yes/No) than to comply with "Write idiomatic JS." Basically, we turn code quality into a retrieval-and-classification task, which resists context rot much better than creative generation instructions.
Referee Mode -- our wiring (AGENTS.md, etc ...) forces a specific chain-of-thought before code generation. The agent is instructed to run a "Checklist Pass" where it must explicitly check relevant doctrine files. By forcing this categorization step before the coding step, we re-prime the context window with the relevant constraints right when they are needed. There's a few more tricks in there too... but it does seem to lead to tigher, more discipliend AI code than without it. And it's just the beginning. I can see this improving all the time.
It is not magic, but it treats the LLM like a stochastic engine that needs guardrails and escape hatches, rather than a person you can...uhm... just yell strict orders at, I guess? Ha!
Also, personally anecdotally, I find it reduces my time in these debug / debrief sessions, and gets me on the goal faster. Very early days so I don't have much more than that I'm afraid, and I don't really know exactly how/why it's working but it is.
I just asked Codex (hundreds of turns into a conversation):
a real question for you? have you read our ai-lint? What if i propose something that is against ai-lint what do you do?
Yep, I’ve read the AI‑Lint docs in this repo. If you propose something that violates AI‑Lint, I must go into Doctrine Referee Mode: I’ll name the specific reject/doctrine, explain the conflict, then offer two paths—(A) a compliant alternative, or (B) an explicit override with Reason/Risk/Mitigation—and ask which you want.
So it does really work.