Launching today
AI writes your code at 10× speed. Prelint makes sure it's the right code - it reviews every PR against your ADRs, docs and past decisions, and catches product drift before it ships. On teams using several AI reviewers, ~40% of the issues fixed before merge are caught by Prelint.
Free Options
Launch Team / Built With
Really interesting approach. How do you handle situations where multiple product specs or architecture decisions conflict with each other? Is there a way for Prelint to detect outdated or contradictory documentation before reviewing a PR? That could be incredibly valuable for larger teams.
Prelint
Thanks Przemek! This is usually how people find us in the first place - struggling with lots of contradicting docs (we had one case when a client had their contradicting specs written in multiple languages!).
Out of the box, Claude Code is pretty bad at understanding which docs are rotten context and which are still relevant information. We work with it on a couple fronts:
We automatically detect and override clean "supersessions" - decisions that have been clearly overridden and just not cleaned up over time - from docs, meeting notes etc
We provide tools for managing more complex contradictions - your coding agent or engineer can document a decision using our CLI, and there is a visual interface for finding and managing these for non-technical people.
We see ourselves helping in two ways: if you're Prelint-native, you can the ontology of your business that we generate to feed your AI work (and export it to any format when needed). If you work with your own external decision structure, Prelint helps you clean it up and enforce it.
Multiple AI reviewers catching different things makes sense, no single model sees everything a fast-moving codebase actually needs.
Prelint
Thanks, Peter! The reviewer is the first surface we deployed (it's a touchpoint that agents and humans alike already understand so it was a very convenient start) but we see ourselves as a decision ledger that your agents can query through our CLI and also non technical humans can work with.
Of course for some projects you can run a Claude skill and you can be just fine but the moment you deploy agents at scale (especially larger headless fleets) every % of efficiency counts and with the projects that currently use Prelint we often detect as much as 40% more relevant issues than if you just run Claude locally. In my experience even 5% moves the needle so it's a pretty big win.
And it's much more than a local prompt - our biggest strength is the pipeline that understands your docs and addresses duplicates and inconsistencies - this problem is a bit more complicated than it looks given that the same sentence written in different contexts (eg the CEO vs intern) can have very different gravity and meaning. So giving agents access to these "product breadcrumbs" explaining the "why" yields much better results. Running a Claude prompt works for the first 10% of the issues and is quite trivial but that's not what we do here - hence the much better results.
I like that this treats ADRs as living context instead of dusty docs nobody rereads. Question: does it flag drift retroactively too, or only on new PRs going forward? That distinction matters a lot for legacy repos.
Prelint
Thanks, Jamie! Yes it does. In such a case we won't proactively fix it (your agents are quite good at it) but the agents see it through or CLI and sometimes reviews of code/doc changes that touch these parts.
When we first started working with ADRs and agents, the biggest change I had to make in my mindset was that canonically people treated ADRs as immutable and you would create new ADRs on top. This doesn't really work with agents because you get a lot of context poisoning - agents are not very good at understanding which file was superseded and which still stands.
Many teams use Prelint to uncluttered their repos from docs that decayed over time - one of our customers had their docs written in several languages and Prelint normalizing it to English was already a big help.
I tried catching this manually with a "does this match my architecture doc" checklist in code review. It worked until velocity picked up and reviewers started rubber-stamping. Would love to know how it handles reviewer fatigue over time.
Prelint
Good point Ayesha! I actually feel Claude skills and these kinds of checklists are great for the first 40% part of the process - fast and cheap, and filters out the first issues. Prelint is great at the latter 60%.
Internally our team merges on average about 50 pull requests per day - one of the partners told us that we are one of the fastest teams working with them - and Prelint is actually one of the tools that make it happen. One of the biggest issues with merging so many PRs in parallel is that you have so many small decisions that can easily overlap and a human or mechanical reviewer won't catch them - this is where Prelint shines.
Technically correct code that builds the wrong product describes AI-assisted development pretty well. "Code became cheap" mantra doesn't mean we ship better products; it means the bar for what's worth building dropped. In practice this results in more of what users never asked for, faster.
You say "the agent can self-correct before a human ever looks" - what does that look in practice? Is it an automated loop, or does it require human involvement?
Prelint
Thanks, Mateusz!
We started inside pull requests mostly because it's the touchpoint that both agents and humans understand out of the box and we think it's a unit of change that is about to stay with us but - in all honesty - we see our job way beyond that. Prelint is turning into a "decision ledger" for companies where your agents still do get feedback on their code changes in pull requests but we now also provide a CLI that your agents can query to explore your company's ground truth.
The thing I'm missing with agentic coding is a view across agents. You know the feeling when you have six terminals open and jump between them to approve some decision. PRs are the obvious surface for your product, but a PR is diff-shaped and your product is decision-shaped. One decision may span multiple PRs.
A "decision ledger" that aggregates Prelint's findings across every open PR - approve, reject, or promote to spec, in one place - is the thing I'd actually keep open all day.
Looking forward to seeing where Prelint goes!
Prelint
@mateuszkonThis + multiplayer mode which I think is the next big topic for many tools. There are some early stage tools like Superconductor that do a great job exploring this
I like that Prelint checks against ADRs specifically. Most reviewers just look at the diff, not whether it fits the actual architecture.
Prelint
Thanks, Kimberly!
Yes Prelint is quite good at enforcing ADRs (we have some customers that use Prelint as their ground truth, some that use ADRs in their repos and some that have pretty complex MCP tooling around their ADRs).
We see ourselves more as a "decision ledger" than strictly a reviewer.
Prelint