Coding Agents Optimize Around Requirements – Prelint Doesn't

01 /The Concept

Coding agents don't misread requirements. They optimize around them.

When a specification contains an ambiguity, the agent resolves it in whatever direction requires the fewest changes to the test suite. When two architectural constraints conflict, it picks the one that generates less friction in the current file. The code passes review. The tests pass. The PR merges. What nobody checked is whether the implementation is still solving the original problem.

Prelint reviews pull requests against a repository's architecture decision records, product specifications, and history of prior technical choices. It doesn't look for bugs – other tools do that. It checks intent. A database migration that quietly contradicts a documented architectural decision. An API endpoint that introduces a coupling the architecture document explicitly forbade. A feature implementation that technically satisfies the ticket but solves a marginally different problem than the one the ticket was written for.

The startup calls this product drift. Across 56,706 pull requests analyzed, document-augmented reviews improved accuracy by 2.75x compared to code-only analysis. On teams using multiple AI code reviewers simultaneously, approximately 40% of the issues fixed before merge are caught by Prelint – not because the other tools miss bugs, but because they cannot check intent.

Pricing is transactional: $1 per completed review, no subscription required, starting with $10 in free credits. Open-source repositories review for free. GitHub and GitLab both supported. The product ranked #1 on Product Hunt for the week of July 27 – August 2, 2026.

02 /Why It Matters

AI coding velocity has a specific failure mode that isn't a bug problem. When an individual developer makes a wrong architectural choice, code review – another human reading the change – has a reasonable chance of catching the divergence before it merges. When a coding agent makes the same decision at 10x the velocity, and the review process is also partly delegated to AI, the intent-check layer disappears entirely.

The result is product drift: technically correct code that is gradually building the wrong product. Drift compounds because each divergent decision becomes the context that the next decision builds on. By the time the divergence is visible – usually when a new requirement tries to extend a corrupted foundation – reversing it means unwinding multiple layers of accumulated work.

The architecture decision record is underused for exactly this reason. Engineering teams write ADRs at decision time and read them during onboarding or post-mortems. Almost no organization has a mechanism to enforce ADRs at merge time – which means the ADR is a historical document, not a live constraint. Prelint is the first tool to treat the ADR as input to automated code review, which repositions the document from artifact to active guardrail. The direct consequence: ADR maintenance becomes operationally valuable for the first time. A stale ADR means a missed catch in the review.

The Product Hunt reception – #1 for the week among a developer-heavy audience that votes on tools it would actually use – is a meaningful signal for a zero-budget developer tool. The specific claim in Prelint's data (2.75x improvement in review accuracy with documentation) is a number engineering leads responsible for code quality will immediately translate into cost and rework terms.

03 /Opportunities

The ADR gap is a documentation problem with a code-quality hook attached. Most engineering teams have architectural documentation in some form – Notion, Confluence, markdown files in the repo – but rarely enforce it at the commit layer. Prelint creates the first operational incentive to keep that documentation current: let it go stale and the review catches less. That dynamic changes the value proposition of the ADR from "good practice" to "tool that works better when you maintain it."

That repositioning opens an adjacent market. There is no widely adopted standard for writing, versioning, or querying architecture decision records. The existing tooling is thin – mostly free-form markdown or generic wiki pages. A product that makes ADR creation and maintenance as low-friction as opening a GitHub issue, while building in the Prelint review integration from the start, would occupy a new category: architecture governance tooling.

The highest-specificity near-term opportunity for builders: apply the same intent-checking layer to security policy compliance. Coding agents write code that passes static analysis but violates documented security architecture decisions – a database query pattern the security team explicitly ruled out, an authentication flow that contradicts a recorded decision about token handling. Neither a linter nor an AI code reviewer catches this, because neither has access to the security policy documentation. A security-specific Prelint, with integrations into existing policy document formats like OpenControl or OSCAL, would serve a compliance-heavy market that already faces regulatory pressure to maintain exactly this kind of documentation and has budget to enforce it.