Prelint
Prevent product drift in AI-written code
Start new thread

Let's talk.

by•

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 Code PH100 gets you 100$ in free review credits this month - it's full speed AI, but with lane assist.

114 views

Add a comment

Replies

Best

Congrats on the launch!!

I like this approach. Offering your time and sharing your real workflow is much better than just promoting the product. Those conversations usually lead to a more helpful feedback and stronger relationships with potential customers.

Yes sir! And you end up with people who will go out of their way to help you rather than unsubscribe after a third follow-up.

Congrats Wojtek.

Drift is honestly one of the most common problems for any company building with AI agents right now, and it's interesting seeing the different approaches people are landing on to deal with it.

We went at it from the architecture side instead of a review layer: make it structurally hard for an agent to bypass the single source of truth in the first place.

Thanks Martin! My religious view on it is you have to go about it both ways: LLMs are probabilistic machines that are always wrong a small percentage of times - it's a feature not a bug. Even if you provide them with perfect prompts and context. So imo the job of the SDLC process is getting the changes as far as possible before a human interaction - sometimes it means production, other times it means a human reviewing the feedback of the coding agent and all the review bots and making educated decisions. .

The detail in your founding story I'd put on the landing page is "passed all tests". That isn't an aside, it's the whole mechanism.

Tests encode does it work. They don't encode is this how we do it here. Architecture lives in people's heads, in review habits, and in the one senior person who says we don't do it that way. It's the single class of constraint nobody ever wrote down machine-readably, because until recently everyone writing code had absorbed it by osmosis. Agents don't violate it out of carelessness. They violate it because it was never written anywhere they could read.

Martín's point about making it structurally hard to bypass the source of truth is right, and I don't think it's an alternative to a review layer so much as the other half of it. Structural prevention covers the constraints you thought to encode. The drift that actually hurts is the one nobody had articulated as a rule yet, because if you could state it cleanly you'd already have enforced it. The two fail in opposite directions, which is an argument for both rather than either.

The six weeks is the part I'd sit with. By week six the decision is load-bearing, and the fix has stopped being a revert and become a migration. The cost isn't the wrong call. It's the interval before anyone notices a call was made at all.

Thanks Dale! We see that sometimes, there's even decisions that are structurally sound, but being introduced at the wrong surface, in the wrong moment, or requiring a human follow-up and you end up with a good decision with disastrous consequences.

  That's a harder class than the one I described, and I suspect it's the one nothing catches today.

The requiring a human follow-up case is the sharpest of the three. A change that's only correct if somebody does something afterwards carries a dependency on a person, and nothing in the repo records that dependency. Review sees correct code. Tests see passing tests. The obligation lives in the head of whoever wrote it, and if they change team it evaporates quietly while the code carries on looking fine.

Which suggests the useful flag isn't this is wrong so much as this creates an obligation. Different signal, different reader, and a much lower false positive rate, because you're not asking a model to judge whether a decision was good. You're asking whether the change assumes a follow-up, which is a smaller and far more checkable question.

Wrong surface and wrong moment I find harder to imagine detecting at all, since it needs context about what else is in flight rather than anything visible in the diff. Do you come at that from the change itself, or from the ordering across changes?

Well done and team 💪

 🤜🤛 onwards and upwards!