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.
AI agents ship code that passes every test - and quietly makes product decisions that break your product. @Prelint is the decision layer for AI-written software.
Tools like CodeRabbit check if your code is correct; Prelint checks if it does the right thing.
Live on Product Hunt today: worth a look and vote: https://www.producthunt.com/prod...
Framer AI AgentsDesign and publish professional sites with AI
Promoted
The tagline makes me wonder about the source of truth Prelint uses to detect product drift in AI-written code. Is it checking against product specs, tickets, existing code patterns, design docs, or something else? That distinction feels important, especially for teams already using AI coding tools but not always keeping requirements perfectly structured.
Thanks, Ivory! It's all of this combined, as well as Claude sessions, meeting notes, Slack threads, but also small microiterations with agents and our CLI (an agent or a human can explore "product breadcrumbs" and "clarify" whatever collisions and issues our system is flagging).
Also - a very important part of the IP is our ingestion pipeline - it's not simply "compare our code to docs" - this I believe a good prompt can do. Prelint understands the genesis of a decision - was it made by an AI or a Human as well as their authority - sometimes the same words written by a CEO and an intern have very different authority.
Report
Setup was painless and it actually flagged a comment in our PR that contradicted a decision from a doc two months back, which surprised me. Curious how it holds up on bigger repos.
Thanks for your vote of confidence, Malika! With bigger repos, it actually works even better because it has more context on historical decisions and design patterns.
Report
How does Prelint differentiate between a real product decision issue and a technical choice that only looks risky from the outside?
Thanks, Hamza! Usually a technical choice that looks risky from the outside is something that is worth acknowledging by a human. There are cases where something done by your Claude agent can be actively helpful but lead to a disaster if a human is not aware of it.
There's of course the danger of being "too noisy" - probably the #1 reason people dislike some code reviewers or feedback tools - this is mostly a configuration issue, we feel we're quite good at putting spotlight on the right things.
Report
Congrats on the launch. The line that got me is "good code that quietly builds the wrong product" — that's a failure I didn't see coming until it bit us. We build AI products too, and the agent passes every test and still changes a rule nobody agreed on. One question: how does Prelint know what the "right" product was meant to be — only from the ADRs and docs you feed it, or does it also learn from what your team approves over time?
Thanks, Saied! It's everything we can get our hands on: Slack threads, PR comments, meeting notes, Claude sessions, you and your agent can also use our CLI to clarify and work the decision records.
Sometimes it doesn't and that's the point where it's really useful to have Prelint flag it. Most drift happens not in "big decisions" that are usually super visible but in micro decisions that nobody notices for 6 weeks - violating event-driven architecture, very subtly changing permissions or some collateral events or billing rules.
Right now we have a lot of teams that appreciate Prelint surfacing all the implicit decisions that your coding agents make - sometimes they are just black and white and our role is saying "hold on!" in your name, but other times it's the right decision that can still turn disastrous if no one knows it was made.
yes true 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.
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.
Finally a reviewer that reads the ADRs. Checking PRs against past decisions instead of just correctness is where the leverage sits, most AI reviewers catch broken code, almost none catch code that contradicts a decision the team already made. The messier problem on my teams was always docs that drifted from reality, so a tool that treats them as the source of truth creates pressure to keep them current. That alone changes how teams write docs.
Yes! I had someone ask why is it not a Claude Code skill last week, and the honest answer is - it is, for the first 10% of the job it works super well.
I love that companies now build parts of the tooling in-house, we actually advise some enterprise partners on it too. I think it's validation not competition 😊 I cheer for everyone struggling with the same problem and when it escalates we're always there to provide a best-in-class solution based on all of our experience.
Also - if your company is still looking at these kinds of processes - feel free to message or DM me, I'll happily advise on in-house processes too and share our agentic workflows and if Prelint can be of help at any future time - even better.
The tagline makes me wonder about the source of truth Prelint uses to detect product drift in AI-written code. Is it checking against product specs, tickets, existing code patterns, design docs, or something else? That distinction feels important, especially for teams already using AI coding tools but not always keeping requirements perfectly structured.
Prelint
Thanks, Ivory! It's all of this combined, as well as Claude sessions, meeting notes, Slack threads, but also small microiterations with agents and our CLI (an agent or a human can explore "product breadcrumbs" and "clarify" whatever collisions and issues our system is flagging).
Also - a very important part of the IP is our ingestion pipeline - it's not simply "compare our code to docs" - this I believe a good prompt can do. Prelint understands the genesis of a decision - was it made by an AI or a Human as well as their authority - sometimes the same words written by a CEO and an intern have very different authority.
Setup was painless and it actually flagged a comment in our PR that contradicted a decision from a doc two months back, which surprised me. Curious how it holds up on bigger repos.
Prelint
Thanks for your vote of confidence, Malika! With bigger repos, it actually works even better because it has more context on historical decisions and design patterns.
Prelint
Thanks, Hamza! Usually a technical choice that looks risky from the outside is something that is worth acknowledging by a human. There are cases where something done by your Claude agent can be actively helpful but lead to a disaster if a human is not aware of it.
There's of course the danger of being "too noisy" - probably the #1 reason people dislike some code reviewers or feedback tools - this is mostly a configuration issue, we feel we're quite good at putting spotlight on the right things.
Congrats on the launch. The line that got me is "good code that quietly builds the wrong product" — that's a failure I didn't see coming until it bit us. We build AI products too, and the agent passes every test and still changes a rule nobody agreed on. One question: how does Prelint know what the "right" product was meant to be — only from the ADRs and docs you feed it, or does it also learn from what your team approves over time?
Prelint
Thanks, Saied! It's everything we can get our hands on: Slack threads, PR comments, meeting notes, Claude sessions, you and your agent can also use our CLI to clarify and work the decision records.
Sometimes it doesn't and that's the point where it's really useful to have Prelint flag it. Most drift happens not in "big decisions" that are usually super visible but in micro decisions that nobody notices for 6 weeks - violating event-driven architecture, very subtly changing permissions or some collateral events or billing rules.
Right now we have a lot of teams that appreciate Prelint surfacing all the implicit decisions that your coding agents make - sometimes they are just black and white and our role is saying "hold on!" in your name, but other times it's the right decision that can still turn disastrous if no one knows it was made.
FlowTask
yes true 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
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.
MonoCloud for Startups
Finally a reviewer that reads the ADRs. Checking PRs against past decisions instead of just correctness is where the leverage sits, most AI reviewers catch broken code, almost none catch code that contradicts a decision the team already made. The messier problem on my teams was always docs that drifted from reality, so a tool that treats them as the source of truth creates pressure to keep them current. That alone changes how teams write docs.
Prelint
@roguetink Your teams can now use the Prelint CLI to understand how your docs drift and collide and have your agents work on them.
We were using similar thing in my project but built in-house, that's actually super valuable
Prelint
Yes! I had someone ask why is it not a Claude Code skill last week, and the honest answer is - it is, for the first 10% of the job it works super well.
I love that companies now build parts of the tooling in-house, we actually advise some enterprise partners on it too. I think it's validation not competition 😊 I cheer for everyone struggling with the same problem and when it escalates we're always there to provide a best-in-class solution based on all of our experience.
Also - if your company is still looking at these kinds of processes - feel free to message or DM me, I'll happily advise on in-house processes too and share our agentic workflows and if Prelint can be of help at any future time - even better.