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 use 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 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
the thing I'd worry about is ADR rot. checking a PR against decisions that are themselves six months stale just enforces the wrong thing, confidently. does it ever flag the ADR as the problem rather than the code...
Prelint
Good point, Alex. Not only I agree with this, we're also building the product that actually helps with it.
We address this in a couple ways: proactively, whenever changes are introduced or mentioned, our system understands the authority of the claim being made and either supersedes the previous decisions, or flags it to the humans and AIs - it happens in three surfaces - PRs that touch the docs or code, CLI where the agents can actually see not only the ADR but also the "product breadcrumbs" that led to this decision. So if there's multiple "decisions" touching an ADR, we will squash and decay the irrelevant ones and provide a "when and why" for ones that make contradicting claims.
@wojtekszkutnik the squash and decay step is where I would be most careful. the decisions mentioned least are often the ones you least want faded out: security boundaries, compliance constraints, the load-bearing thing nobody touches precisely because it works. frequency is a weak proxy for whether something still binds.
authority is the other one. if you infer it from the text, confident phrasing wins, and agents phrase everything confidently. if it is grounded in something structural instead, codeowners, who authored the original ADR, who approved the merge, that is much harder to spoof by just writing assertively. curious which way you went...
Prelint
@alex_watson2110 all very valid points and exactly the reason why we're building Prelint :)
It quickly turns very complex - decisions often live in Claude sessions now or Slack threads. And usually attaching authority to a person is not enough, our CTO in a conversation with our intern usually has a very authoritative role, but on a product call with me it often turns speculative and I'm the authoritative voice that makes the product and business calls. So there is a lot of subtlety in the process.
Also: simple time decay mechanics on files don't work but when you deal with meeting notes it's a very different story - business documents very often have some idea of timelines or expiration dates. So depending on the kind of information we're ingesting, we pick very different tools.
As a rule of thumb we don't use tone of voice as any authority signal. We do check if something is speculative or a quote (eg someone copy-pasting some stats) but you can't game it just by being very confident in what you write ;-)