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
Prelint
Hi Product Hunt, I’m Wojtek, one of the founders of Prelint.
Coding agents now produce more code than most teams can properly review. The obvious risk is bad code, but the more dangerous risk is good code that quietly builds the wrong product.
We saw this repeatedly in large production projects when we started using agents. A change would clear technical review, pass CI, yet still skip the transactional outbox pattern, introduce an unapproved dependency, change a permission rule or invent a business requirement. Nobody had made that decision, but it was now part of the product.
Prelint catches these decisions before they ship. It reads each change alongside your specifications, tickets and existing product context, then explains what the agent decided, what the consequences are and how difficult the choice will be to reverse. Your team can approve, correct or replace the decision, and Prelint carries that context into the next piece of work.
If you work with ADRs, our clients say it is the best tool they found for enforcing them with agents. On teams running Prelint alongside other AI reviewers, ~40% of the review comments that actually get fixed come from Prelint.
We started in GitHub and now support CLI and MCP, allowing agents to check product decisions while they work instead of waiting for a human to discover the problem at the end.
Prelint is not another technical code reviewer. These tell you whether the code works. Prelint tells you whether you should be building it.
If coding agents are contributing to your product, sign up at https://prelint.com, connect a GitHub repo and see what they've been deciding on your behalf. Then tell us what you like and what you'd love to see on top of it!
Use code: PH100 to get 100$ in additional free credits
I work with a team that ships fast with AI-generated code and our biggest headache isn't bugs, it's silent architecture drift nobody notices until a rewrite six weeks later. Curious if it flags that kind of slow-motion divergence too.
Prelint
Thanks, Nancy! Well, in our case we try to flag it when it happens, not six weeks later 🙃
Prelint works really well with enforcing design patterns and architecture drift - the original reason we started building it was one case where an agent built some code that was working correctly but completely ignored our event-driven architecture so that was actually the original pain point we started with.
Congrats on the launch! I’ve run into this exact issue with AI agents: the code works, but it still builds the wrong thing. What kind of specs work best with Prelint?
Prelint
Thanks Philip! Good question. Prelint is good at a couple things:
If you have structured ADRs in your repo it will enforce them with code and docs changes (eg Markdown in docs/adrs/)
If (like most projects) your specs and docs are a mess between Slack, Google Docs, docs-in-code, undocumented decisions in code, Prelint ingests all your data sources and builds a decision ledger based on that - it surfaces all the collisions, supersessions (eg someone writing a specs 3 months ago but then contradicting it on a call one month after) - it's used in our reviewers but we also have a CLI that your coding and non-coding AIs can use to find the ground truth about the product and the business
We're also pretty good at understanding implicit decisions made in your code - eg we will understand if you're HIPAA or SOC compliant even if you don't state it directly, same with infrastructure as code - we understand the patterns even if you don't document them
If you decide on ADRs in your repo (which is one of the best starting points - if you don't have them, Prelint can help you structure and enforce them, and if you have them, it will work out of the box), a couple tips:
- forget everyone telling you ADRs are immutable, update ADRs when the decision changes - you don't want context poisoning from superseded statements
- keep in repo as markdown, one decision per file
- keep them to one paragraph but capture rejected alternatives and context - we had many architectural decisions grounded in very specific context (dependencies, library-specific bugs etc) and it really helped
- README markdown index in adrs folder
You can use something like these instructions for your coding agent:
@wojtekszkutnik That actually makes a lot of sense. Most of my projects are definitely in the second category, with decisions scattered across chats, docs and the code itself rather than clean ADRs. The decision ledger sounds really useful for exactly that. I’ll try the setup you sent on one of my repos and let you know how it goes. Thanks for the detailed answer!
My honest question: how much setup does this need before it's useful? A lot of "review your PRs against your docs" tools sound great until you realize the doc structure has to be near-perfect first.
Prelint
Thanks for the thoughtful question, Ramish! My honest answer: it has a big impact from the start but it compounds over time.
We're a different animal to most reviewers - we think of ourselves as a "decision ledger" ultimately more than "check code vs docs" - I honestly think most technical code reviewers that can do it will get commoditized by the next generations of the frontier models - same as all the "company brain" startups.
With us the main advantage is that it's not a "local skill run" that semantically checks your code against context but we construct a whole "decision ledger" describing your businesses ontology.
Why it's helpful from the start:
There are a lot of things that our pipeline understands from your code, built in docs and behaviors - eg we will understand your compliance requirements even if you don't specifically mention HIPAA, SOC or ISO, we extract code design patterns that we later enforce.
Prelint also understands the gravity and authority of statements - so compared to a simple grep job it can weigh decisions made in different contexts differently - eg it will put a different weight on decisions made by agents vs humans.
We do provide some technical code feedback too, but the experience you get from the start is a bit different from other "review" startups - in some cases it's less "we'll compare your code to your ticket and see if it matches" - this is a prompt not a startup in my opinion and more "what did decisions did the agent make on my behalf that would ring the bells if I ever knew about them?"
Why it compounds:
As you work with Prelint we naturally absorb everything happening in your company - Slack conversations, meetings - and build an understanding of the product being built based on microinteractions
Your users and agents can expand our decision ledger through our CLI and visual interface - so every time a small coding session slightly changes the direction, we will first flag it, but also allow the agent and human to elaborate on the decisions being make and include it as part of the ledger
The stat about catching 40% of pre-merge issues on teams already running multiple AI reviewers is the part I'd want to see broken down further. What kinds of issues specifically? Style violations are cheap to catch. Actual drift from architectural intent is a completely different, much harder category and I'd bet that's where the real value is.
Prelint
Thanks Madison! We practically don't catch "style violations" - we're centered around architecture drift, breaking design patterns, and very often the agents just plain going in a product direction that makes sense in their limited context but not in the context of the company the humans are trying to build.
The 40% number is the kind of stat I want to stress-test rather than just admire. Is that measured across teams with mature, well-maintained ADRs or does it hold up even when documentation is patchy, which is the more common situation? I ask because a lot of tooling in this space performs great in the demo and struggles the moment real docs are inconsistent or out of date. Would genuinely like to see that breakdown.
Prelint
We're challenging it as hard as you are Almuddin! Thanks for the comment.
Honestly, it depends on so many factors - size of the team, documentation quality and segmentation but sometimes even the industry of the company. Many of our customers at the moment are in very vertical industries where the ontologies and guardrails to enforce are especially tight. I wouldn't expect this to be the same for a B2B SaaS startup and a complex AI energy company
40% is a world-class number that I doubt any tool can hold across all startups out there and that's not the goal. When I originally launched Prelint, I though 10% would be an amazing result - back then my thought was, with headless fleets, if you move the needle even just a little bit, it pushes the human interaction forward so your agents can get the changes across a couple more hurdles before you need to look at them.
Now that we see it in the real world, the goal is less "be the best product review tool" and more "build a decision ledger" so we expand way beyond code review touchpoints. Many agents interact with our CLI querying the "product breadcrumbs" we create based on the products so in this case a lower review-stage impact could be even better from the product side - it would mean our CLI did a great job so at the PR-stage the product is already in better shape.
I'd be curious how noisy this gets in practice. Docs and ADRs drift out of date constantly, how do you keep the source of truth from becoming stale itself?
Prelint