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