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.
@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...
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...
@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.
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?
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.
Congrats on shipping this! Product drift is such a sneaky problem, the code works fine but the product quietly became something else. Does Prelint only catch drift in new pull requests, or can it also scan an existing codebase for decisions that already slipped through?
Thanks for the question, Dogan!
We do scan your existing repo and your agents do see contradictions, collisions and product breadcrumbs through the CLI.
Congrats on the launch! "Product drift" is a great name for a problem I didn't have a word for. The code compiles, tests pass, and it still quietly isn't the thing you asked for. Catching that at lint time is the right layer. Does it work across any codebase, or are you starting with specific languages?
Thanks, Ben! Prelint works quite well with most modern popular languages, we've seen teams getting great results also with some hardware projects, we also have some happy customers reporting very good results with infrastructure in code.
I can imagine Fortran would be tricky though
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.