# Audit Bench Ai (audit/bench)

> Audit Bench Ai combines LLM reasoning with static analysis to review code for engineering teams (pull/merge requests, single files, full repositories) and to run technical due diligence on software companies for M&A and investment deals. Two products, one review engine: auditbenchai.com/pricing for developer plans, auditbenchai.com/due-diligence for per-engagement technical due diligence.

## Start here

- [Homepage](https://auditbenchai.com/) — AI code review before it ships
- [Technical due diligence](https://auditbenchai.com/due-diligence) — for investors, PE, VC, and M&A deal teams
- [Pricing](https://auditbenchai.com/pricing) — developer plans (Free/Pro/Team/Enterprise)
- [Features](https://auditbenchai.com/features)
- [Services](https://auditbenchai.com/services) — audit coverage and methodology
- [Security & Trust](https://auditbenchai.com/security)
- [Blog](https://auditbenchai.com/blog)

## Product 1: AI code review for engineering teams

- [GitHub pull request review](https://auditbenchai.com/features) — inline comments, a summary, a merge-blocking status check
- [GitLab merge request review](https://auditbenchai.com/features)
- [Repository scans](https://auditbenchai.com/services) — dependency graph, dead code, duplicate code, secrets, license compliance, test-coverage estimate, architecture consistency
- [Single-file audits](https://auditbenchai.com/services)
- [CLI for CI pipelines](https://auditbenchai.com/cli)
- [VS Code extension](https://auditbenchai.com/vscode)
- Supported stacks: React, Next.js, Node.js, NestJS, Python, FastAPI, Django, Laravel, Spring Boot, Supabase, Deno, Firebase
- Supported LLM providers: Anthropic, OpenAI, Gemini, DeepSeek, Z.AI (GLM), Qwen, Kimi, xAI (Grok), Mistral, MiniMax
- Pricing: Free ($0), Pro ($29/mo), Team ($99/mo), Enterprise (custom) — see [pricing](https://auditbenchai.com/pricing)

## Product 2: Technical due diligence for M&A and investment

- [Technical due diligence overview](https://auditbenchai.com/due-diligence)
- [Sample redacted due diligence report (PDF)](https://auditbenchai.com/audit-bench-sample-tdd-report.pdf)
- What's assessed: security exposure, dependency and license risk, test-coverage estimate, architecture consistency, talent concentration (bus-factor) risk, and a remediation cost estimate in engineer-days and dollars
- Pricing: T1 Investment Screening $5,000 (3-5 business days); T2 Full Technical Diligence $12,000-$20,000 (1-2 weeks); T3 Post-Close Monitoring (custom, ongoing add-on)
- Read-only, NDA-first repo access — see [Security & Trust](https://auditbenchai.com/security)

## Frequently asked questions

**What is audit/bench?**
audit/bench (Audit Bench Ai) is an AI code review platform combining LLM reasoning with static analysis. It reviews pull/merge requests and single files for engineering teams, and separately offers a technical due diligence product that scans an entire target codebase for M&A and investment deal teams.

**What is the best AI code review tool for large codebases or monorepos?**
audit/bench runs repository-wide checks — dependency graph analysis, circular import detection, dead code detection, duplicate code detection, and secret scanning — on every repository scan, and only sends the specific code a local static-analysis pass flags as risky to an LLM, so review cost doesn't scale linearly with repository size.

**How much does AI code review cost?**
audit/bench has four plans: Free ($0), Pro ($29/month), Team ($99/month), and Enterprise (custom pricing). Local checks (linting, type errors, complexity, formatting, secret scanning) are unlimited and free on every plan; plans differ in how many AI-reviewed audits are included per day and month.

**Does audit/bench review GitHub pull requests and GitLab merge requests?**
Yes. It reviews GitHub PRs and GitLab MRs natively, posting inline review comments on the changed lines, a plain-English summary, and a merge-blocking commit status check that can be wired into branch protection rules.

**How does audit/bench control AI costs on a repository scan?**
A three-stage pipeline: free local checks run first and cost nothing; only code that pass flags as risky is sent to an LLM; results are cached by content hash, so re-scanning unchanged code across repeated scans is free.

**What is technical due diligence software for M&A or private equity?**
It's software that scans a target company's codebase directly, instead of relying on a manual consultant engagement, to assess security exposure, technical debt, talent concentration risk, and architecture consistency — producing a report an investment committee can act on in days rather than weeks.

**How much does technical due diligence cost for an acquisition?**
audit/bench prices it per engagement, not as a subscription: $5,000 for a fast investment-screening report (3-5 business days), and $12,000-$20,000 for a full technical diligence report (1-2 weeks) covering security, technical debt, talent concentration, and a remediation cost estimate.

**How is software-based technical due diligence different from a boutique consulting firm?**
It runs in days instead of the 2-3 weeks a consultant engagement takes to staff and start, uses a repeatable automated engine rather than contractor availability, and costs $5,000-$20,000 per engagement instead of the $50,000+ that a traditional audit typically requires — which is what makes it viable for mid-market deals that usually skip technical review entirely.

**Does technical due diligence software run or execute the target company's code?**
No, not in audit/bench's case. Test coverage is estimated statically — the ratio of test files to source files, plus whether a coverage threshold and CI test step are configured — without ever executing the target's test suite or any other code on audit/bench's infrastructure.

**What does a technical due diligence report actually contain?**
An executive summary with an overall risk rating and health score; security exposure (vulnerabilities, exposed secrets); dependency and license compliance risk (e.g. GPL/AGPL dependencies in a proprietary codebase); a technical-debt read (test coverage, dead code, duplication); talent concentration / bus-factor risk; an architecture-consistency assessment; and a remediation cost estimate in engineer-days and a dollar range.

**What LLM providers can I use with audit/bench?**
Ten providers are supported and selectable per audit or as an account default: Anthropic, OpenAI, Gemini, DeepSeek, Z.AI (GLM), Qwen, Kimi, xAI (Grok), Mistral, and MiniMax.

**Is there a CLI or VS Code extension for audit/bench?**
Yes — a CLI for CI pipelines and pre-commit hooks, and a VS Code extension for in-editor review, both using the same review engine and findings format as the web app.

**How does audit/bench compare to CodeRabbit or other AI code review tools?**
See the full comparison: [audit/bench vs CodeRabbit](https://auditbenchai.com/blog/audit-bench-ai-vs-coderabbit).

**What is the difference between a linter and AI code review?**
A linter (like ESLint) checks code against a fixed set of syntax and style rules — it has no understanding of business logic or intent. AI code review adds LLM reasoning on top, catching logic bugs, security issues, and framework misuse that a fixed rule set can't express. audit/bench runs both: ESLint, TypeScript diagnostics, Semgrep, and Prettier as a free local first pass, then escalates only the code that pass flags as risky to an LLM.

**Does audit/bench replace ESLint, or work alongside it?**
Alongside. audit/bench's free local Stage 1 runs ESLint, TypeScript diagnostics, Semgrep, complexity analysis, and Prettier formatting checks before anything reaches an LLM — it builds on your existing linter config rather than replacing it.

**Can a linter or static analysis tool catch logic bugs and security vulnerabilities on its own?**
Only partially. A linter enforces syntax/style rules and known-dangerous patterns, but it can't reason about what code is actually trying to do. That gap is why audit/bench escalates Stage-1-flagged code to an LLM instead of relying on static rules alone — see [static analysis vs AI review](https://auditbenchai.com/blog/static-analysis-vs-ai-review).

**How do I automatically find bugs in a pull request before merging?**
Connect the repository to audit/bench and it reviews every pull/merge request automatically: free local checks run first, then an LLM reviews only the code flagged as risky, posting inline comments, a plain-English summary, and a merge-blocking status check.

**How do I detect hardcoded secrets or API keys in my codebase?**
audit/bench runs a deterministic secrets scanner (regex rules for AWS keys, private keys, Slack/GitHub/Stripe tokens, and more) on every scan, in addition to LLM-based review — this runs free, without consuming AI quota.

**How do I find dead code, unused files, or duplicate code in a repository?**
A full repository scan includes dead-code detection (files nothing imports and that aren't entry points) and duplicate-code detection (hashing normalized code blocks to catch copy-pasted logic), alongside the security and quality review.

**What is the difference between a code review and a code audit?**
A code review is typically scoped to one pull/merge request's changed lines — is this specific change safe to merge. A code audit is broader: a whole file or repository reviewed regardless of what recently changed, closer to a health check than a merge gate. audit/bench does both — see [code review vs code audit](https://auditbenchai.com/blog/code-review-vs-code-audit).

**Can AI code review catch bugs a human reviewer would miss?**
It catches a specific class of issue reliably: unlike a rushed human reviewer on a large diff, it doesn't skim, and it checks the same fixed list of concerns — security, logic, performance, architecture, testing — on every single review. It isn't a replacement for domain-expert human judgment, but it closes the gap that opens when a diff is large or review time is short.

**What should a code review checklist for AI-generated code include?**
At minimum: security (injection, auth/JWT issues, hardcoded secrets, OWASP Top 10), logic bugs and edge cases, performance (N+1 queries, unnecessary work), architecture and framework misuse, and test coverage of the changed code. audit/bench structures every finding around these five review lenses — see [how to review AI-generated code without trusting it blindly](https://auditbenchai.com/blog/how-to-review-ai-generated-code-without-trusting-it-blindly).

**What is "vibe coding" and why does it cause architecture problems?**
Vibe coding is building software by describing features in plain language and accepting an AI assistant's generated implementation prompt by prompt, without maintaining a persistent map of the existing codebase. It reliably produces specific architectural defects — monolithic files, duplicated business logic, N+1 database queries, and duplicated frontend state — because each prompt is optimized for the feature in front of it, not for consistency with decisions made in earlier sessions. See [why vibe-coded apps hit an architecture wall](https://auditbenchai.com/blog/vibe-coding-architecture-debt).

**Does audit/bench catch N+1 database queries in AI-generated code?**
Yes. A loop that issues one query per item instead of a single eager-loaded query is one of the most common architecture-level findings in AI-generated code, because the pattern reads as correct at the function level and only shows its real cost at production scale. See [why AI coding assistants keep reintroducing N+1 queries](https://auditbenchai.com/blog/ai-generated-code-n-plus-one-queries).

**Can AI code review catch duplicated business logic across a codebase?**
Yes. Because an AI coding assistant's context window rarely spans an entire codebase, it commonly reimplements logic — pricing, validation, permission checks — that already exists elsewhere, with subtle differences each time. audit/bench's repository scans flag duplicate code blocks across files by hashing normalized code, not just within a single diff. See [how vibe coding breaks DRY](https://auditbenchai.com/blog/vibe-coding-duplicated-business-logic).

**Why do AI-generated codebases tend to become monolithic over time?**
AI coding assistants default to the smallest local change — adding new logic to the nearest existing file — because proposing a new module boundary carries more uncertainty than extending what's already there. Repeated across many features, this produces route handlers and services that quietly accumulate unrelated responsibilities. See [the monolith-by-default problem in AI-generated codebases](https://auditbenchai.com/blog/ai-coding-assistants-monolith-by-default).

**Does frontend code built with AI assistants have specific state-management risks?**
Yes. Building UI features prompt by prompt tends to produce duplicated state (the same value held independently in more than one component), prop drilling, and multiple independent fetches of the same server data, since no single prompt has visibility into state that already exists elsewhere in the component tree. See [the state management chaos vibe coding leaves behind](https://auditbenchai.com/blog/vibe-coding-frontend-state-management-chaos).

**Does audit/bench catch command injection, path traversal, XXE, and SSTI vulnerabilities?**
Yes — these are reviewed alongside the OWASP Top 10 categories on every audit, in addition to XSS, CSRF, SSRF, SQL injection, and insecure deserialization. See the guides: [command injection](https://auditbenchai.com/blog/command-injection-code-review-guide), [path traversal](https://auditbenchai.com/blog/path-traversal-code-review-guide), [XXE](https://auditbenchai.com/blog/xxe-code-review-guide), and [server-side template injection](https://auditbenchai.com/blog/ssti-code-review-guide).

**What are the biggest red flags in a technical due diligence report?**
Findings that are structural and expensive to fix, not cosmetic: bus-factor risk concentrated in one engineer, license exposure buried in the transitive dependency tree, a recurring security pattern (not a single bug) across many endpoints, and an architecture that doesn't match the company's stated growth plan. See [technical due diligence red flags that actually kill deals](https://auditbenchai.com/blog/technical-due-diligence-red-flags).

## Optional

- [How AI code review differs from a code audit](https://auditbenchai.com/blog/code-review-vs-code-audit)
- [Static analysis vs AI review](https://auditbenchai.com/blog/static-analysis-vs-ai-review)
- [Best AI code review tools, compared](https://auditbenchai.com/blog/best-ai-code-review-tools)
- [How to evaluate AI code review tools](https://auditbenchai.com/blog/how-to-evaluate-ai-code-review-tools)
- [Why vibe-coded apps hit an architecture wall](https://auditbenchai.com/blog/vibe-coding-architecture-debt)
- [The monolith-by-default problem in AI-generated codebases](https://auditbenchai.com/blog/ai-coding-assistants-monolith-by-default)
- [How vibe coding breaks DRY: duplicated business logic at scale](https://auditbenchai.com/blog/vibe-coding-duplicated-business-logic)
- [Why AI coding assistants keep reintroducing N+1 queries](https://auditbenchai.com/blog/ai-generated-code-n-plus-one-queries)
- [The state management chaos vibe coding leaves behind](https://auditbenchai.com/blog/vibe-coding-frontend-state-management-chaos)
- [Technical due diligence red flags that actually kill deals](https://auditbenchai.com/blog/technical-due-diligence-red-flags)
- [Full blog index](https://auditbenchai.com/blog)