Prelint, built by Prelint, Inc., is a review tool that verifies, pull request by pull request, whether code was actually built the way the team agreed. AI coding agents have increased the volume of code being written, and with it the chance that a change quietly diverges from the specs and ADRs (architecture decision records) without anyone noticing. Prelint targets exactly this “product drift”: it indexes the Markdown specs and decision logs that live in your repository and cross-checks them against the contents of each pull request to surface deviations. It runs after installing an app on GitHub or GitLab, and billing is usage-based per review ─ no seats, no subscription, and reviews on public repositories are free.
Key Features
- Drift detection against your specs: Prelint automatically indexes Markdown specs, decision logs, and architecture documents in the repository and checks whether a pull request strays from the documented intent. Context is prioritized in order: project-level specs, then repository-level specs, then general documentation
- Business logic and compliance deviations: It looks at whether the code contradicts agreed-upon rules for pricing, billing, and FX exposure, along with compliance decisions such as data storage, consent flows, and retention periods
- Consistency in tooling choices and domain language: It flags dependencies or infrastructure that duplicate what has already been adopted, and wording that drifts from the domain vocabulary defined internally ─ the kind of mismatch that appears when AI gravitates toward the generic approach it already knows
- A different scope from code review tools: The documentation states plainly that code style, bug detection, security scanning, and type safety are out of scope. Prelint deliberately limits itself to the product layer: specs, decisions, and scope
- Automatic on pull requests, no configuration: Install the GitHub app, pick your repositories, and drop your Markdown specs in. There is no custom CI workflow to write; opening a pull request triggers a review within seconds that leaves inline findings and a summary comment
- Re-review diffs and stacked branch support: On re-review after new commits, a “Since the last review” section tracks how each concern has changed. Stacked branches are evaluated against the correct target branch (added in August 2026)
- Q&A for stakeholders: A dedicated interface lets people ask questions about the specs without interrupting engineers
Pricing
| Plan | Price | What’s included |
|---|---|---|
| Free credits | $10 at signup | No credit card required. Equivalent to 10 reviews |
| Usage-based | $1 per completed review | Spec checks, decision compliance, inline findings, and the summary comment |
| Public repositories | Free | Reviews on public repos are not billed, and no setup is required |
Failed, cancelled, and timed-out reviews are not billed, and commits from CI bots such as Dependabot, Renovate, GitHub Actions, and Snyk do not trigger charges. Credits can be topped up from $10 up to $1,000 and never expire. The default auto-recharge adds $20 when the balance drops below $10, and monthly spending caps are available. The official site offers “$40 to $80 a month” as a rough figure for most teams.
Pricing reflects information as of August 2026. Check the official site for the latest details.
Pros & Cons
✅ Pros
- The unit of billing ─ $1 per review ─ is easy to reason about, and fixed costs do not grow as the team does. The $10 in free credits alone covers 10 trial reviews
- Specs are managed as Markdown inside the repository, so documentation rides the same review and version-control flow as code
- Getting started only requires installing the GitHub/GitLab app and placing Markdown files; no CI configuration to write
- Its scope does not overlap with existing linters or code review AI, making it easy to add rather than swap in
- Public repositories are free, so open source projects can try it in real use
⚠️ Cons
- Effectiveness depends heavily on the quality of your specs. Teams without a habit of writing specs or ADRs face the cost of producing those documents first
- The context budget is stated as 80,000 characters, so repositories with large volumes of documentation need a plan for what gets priority
- It does not check code style, bugs, vulnerabilities, or types, so it cannot cover reviews on its own
- Usage-based billing accumulates with use. Repositories with many pull requests and frequent re-reviews should set a spending cap up front
- The service only launched in 2026, so its long-term operational track record is still being built
Comparison with Similar Services
| Criterion | Prelint | CodeRabbit | Greptile | Qodo Merge |
|---|---|---|---|---|
| Primary scope | Compliance with specs and decisions (product layer) | Code quality, bugs, style | Reviews informed by whole-codebase context | PR summaries, review, test support |
| Basis for judgment | Markdown specs and ADRs in the repo | Diffs, static analysis, code conventions | Code graph of the repository | The diff and PR description |
| Billing model | Usage-based per review | Monthly per developer seat | Monthly per developer seat | Free tier plus paid plans |
| Public repositories | Free | Free tier available | Conditional free tier | Free use for open source |
| Style / vulnerability checks | Out of scope (stated) | In scope | In scope | In scope |
Pricing models change, so check each vendor’s official site for current details when comparing.
Who Is It For
- Teams that delegate a large share of implementation to AI coding agents and worry about what review might miss
- Product teams that write specs and ADRs but sense the implementation gradually drifting away from them
- Domains where regulation or internal rules (data handling, consent, pricing and billing logic) mean a mismatched implementation is a direct risk
- Small teams and solo developers who are not large enough to justify per-seat review tooling but want key points checked mechanically
- Open source maintainers who want contributions to stay aligned with the project’s stated design direction
Summary
Prelint reviews not whether code is good, but whether it was built the way it was agreed. Because its scope does not overlap with existing code review AI or linters, it layers on top rather than replacing them. Its usefulness scales with how well your specs are written, so the place to start is putting specs and decision logs into the repository. With $10 in free credits covering 10 reviews and public repositories free to run, the bar for evaluating it is low.