We did it! Prelint hit #1 on Product Hunt this week - thank you for every upvote, comment and DM Now let me return the favour:
I honestly didn't imagine a launch where we'd have a customer registering every couple minutes - or that I'd spend part of it exchanging comments with one of the world's most popular YouTubers. Wild week.
I replied to every comment on our launch - solo builders, CTOs, investors all interested in the same problem from different angles. Here is how it started in February:
Prelint exists because of one code change. An agent ignored our event-driven architecture and implemented a feature completely bypassing it. The code was technically correct, passed all tests. And nobody made that decision - it was just quietly baked into our product.
That's product drift. It's almost never one big bad call - it's micro-decisions nobody notices for 6 weeks. A change in permissions, a "simplified" billing edge case, a dependency nobody approved. Usually it's good code, wrong product.
So here's my launch offer - not a discount - it's my time.
If you're rolling out coding agents and agentic workflows at your company right now, comment or e-mail me at wojtek(at)prelint.com. I'll share the exact agentic workflows and tooling we use internally to manage 50 production changes a day as a small team and I'll honestly tell you which parts you can solve in-house before you need a tool like ours. These conversations were the best part of the launch and I want more of them :)
Also - if you want to see what your agents have been deciding on your behalf, connect a repo at prelint.com Code PH100 gets you 100$ in free review credits this month - it's full speed AI, but with lane assist.
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.
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.
Hey, I've been using Prelint for the last couple months - I really like that it reviews the product reasoning behind a PR. And it's smart about scaling effort - most small, low-stakes PRs just get a quick approval, while it goes deep on ones that actually touch permissions or auth, even if the diff is tiny. It can be a bit too nitpicky at times, but that's a much better failure mode than rubber-stamping things through.
Quick question - do you charge for one-line PRs, or are those free/exempt from billing?
Congrats on the launch - rooting for you!
Prelint
Thanks for the question Alex!
We already do not charge for PRs that contain some non-decision changes (like specific technical files etc) but we're actively working on improving it. In general, in a vast majority of cases you wouldn't be charged for one-liners. Also example we'd love not to charge for re-reviews if the changes are very tailored fixes addressing specific issues. For this we're introducing more tiered vertical agents compared to the current "single run" mechanics. We should have it live in August.
Prelint
@wojtekszkutnik 🤦♂️ true.. fair point, and thanks for the advice and the offer! I might take you up on that.
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 ;-)
@wojtekszkutnik the context-dependent authority framing is better than what I had in my head, and the document-type split for decay makes obvious sense once you say it out loud. meeting notes carrying their own expiry is a free signal that code files just do not have.
one case I would be curious how you treat: a claim that cites prior authority rather than exercising it. someone writing as we agreed, we are going event-driven is not making an authoritative decision, they are asserting that one already happened. if the referenced decision was thin, or never really happened, a confident back-reference launders it into settled fact. that is not tone and it is not a quote either, so it might slip between your two checks...
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.
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.