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.
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?
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!
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?
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.
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.
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.
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?
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!
@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 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.
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.
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!
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.