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.
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.
@roguetink Your teams can now use the Prelint CLI to understand how your docs drift and collide and have your agents work on them.
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.
It does.
The honest answer is, it's a two step process:
1/ Connect your GitHub repo. You will get a lot of value just from our decision review that works great even just with access to your code - it puts a spotlight on all implicit decisions the agents make on your behalf, on every pull request.
2/ Data sources (JIRA, ADRs, meeting notes, slack, micro-decisions through CLI and Claude sessions) - these all compound and over time make your workflow more accurate. Without it, (1) will still work great, but if you ask the CLI "give me all decisions on billing" it won't have the same depth with less source material.
The interesting bet here isn't catching bugs. It's catching code that works but quietly contradicts a decision the team made six months ago, and nobody has a linter for that. How much ADR discipline does a team need before Prelint has enough to check against?
Zero. If you don't have ADRs Prelint is a great tool because you can use it as the ground truth, or if you need to export or access your decision records you can use Prelint's CLI.
When Prelint flags a conflict, can you jump straight to the exact source and version behind that decision? That would make it easier to tell a real conflict from stale context.
Thanks for the question Flavio!
Kind of. We do a bit more heavy lifting than only quoting, but generally yes. When you have a long decision tree (eg documents in multiple languages, in tables, combined with a high verbosity call) we do some paraphrasing in squashing in non-critical areas. We also have a supersession and expansion model where some decisions expand on others without duplicating their content, so sometimes it's a small graph rather than one specific source.
@wojtekszkutnik when it paraphrases part of that decision graph, how do you stop the paraphrase from becoming the new source of truth instead of the original evidence?
Congrats on the launch! I feel like the opposite is often the case where the ADR/docs etc are out of date and stale. How do you trust the materials it is basing the drift detection on?
Thanks Haritha! We don't and we often flag these. It's always a dial - we don't want to be noisy and a lot of these improvements should happen in the context of other changes rather than trigger an alarmy straight away. In these cases, when the agent uses the CLI it understands the decisions are superseded even if technically they are still in the docs.
These cases are then visible both in the CLI and the interface.
the "decision ledger vs check code against docs" framing is what actually clicks for me. i keep a section in my own CLAUDE.md that's a manual, extremely low-tech version of this, not architecture notes, just "already tried this, here's why it didn't work" so the agent doesn't quietly rebuild the same mistake three months later. what i can't do by hand is catch the drift in real time instead of noticing the pattern repeating after the fact.
question on an existing repo: does the ledger backfill decisions from git history, or does it only start learning from the point you connect it?
Thanks Raffay! It analizes the HEAD but not the git history at the moment - I have no data how helpful that would be yet so I don't want to make any assumptions - it's on the list of experiments we'll try at some point possibly.
Do try splitting your decision docs into ADR files with dedicated IDs for decisions - there's two benefits to this: agents and Prelint love quoting specific identifiers and it makes them greppable if you don't use a tool like Prelint - sometimes agents need to retrieve something quickly and if you have hundreds of ADRs including titles in filenames it's a more efficient lookup. Occasionally Prelint will do that too so even then it helps.
@wojtekszkutnik the greppable-IDs point makes sense, hadn't thought about that angle since i've just been writing prose paragraphs, not files with actual identifiers. going to try splitting mine out. good luck with the launch