Introducing YCAudit: a skeptical second pass for AI-generated code
AI writes code fast and ships the happy path. YCAudit is the slow second pass: it reads a repository cold, raises findings across twelve dimensions, root-causes each one, and hands back fix specs - never silent edits. Here is the introduction.
AI writes code fast. Point a capable model at a feature and it will scaffold the files, wire the happy path, and hand you something that runs in a demo within minutes. What it does not do is the slow part: the adversarial path, the race condition, the secret that should never have been committed, the test for the one invariant that actually mattered. That work is exactly where YCAudit lives.
YCAudit is a codebase auditor. It reads a repository the way a careful senior engineer would - cold, top to bottom - and produces a ranked stack of root-caused fix specs a coding agent can apply. It is built for the world we are now in, where most of the code under review was written by a model in the first place and needs a skeptical second pass before it touches anything real.
Why a second pass
The failure modes of generated code are not random - they repeat. Models fill in credentials inline and defer the cleanup that never comes. They build a guardrail at the call site and leave the underlying function exposed. They interpolate untrusted data straight into a prompt. None of these show up in a demo, because the demo is the happy path the model already optimised for. They show up in an audit. YCAudit exists to be that audit, on every repository, before the code ships.
How a run works
A run is four linear stages with a fan-out in the middle. It never jumps straight to a verdict: it builds context first, raises findings across many dimensions, then forces every finding through a root-cause gate before anything is written down.
1. Understand
Reads the repo cold and writes a codebase brief - what the system is, its entry points, data shapes, and the seams worth probing - before a single finding is raised.
2. Review + specialty audits
A core review pass plus parallel lanes for security, performance, QA, architecture, maintainability, AI-codegen, docs, API contracts, data migration, frontend, and runtime verification each surface findings in their own dimension.
3. Investigate
Every candidate finding is run down to a confirmed root cause. The Iron Law of the pipeline: no fix without an explanation of exactly why the bug happens.
4. Spec
Each confirmed issue becomes a precise fix spec plus a reproduction script - a handoff a coding agent can apply - never an in-place edit made by the auditor.
Twelve dimensions, one report
The review stage is not a single sweep. A core pass runs alongside eleven specialty lanes, each looking at the code through one lens - security, performance, test coverage, architecture, and so on. A dimension with nothing to report says so explicitly rather than going quiet, so a clean result and an unrun check never look the same.
Specs, not silent fixes
The principle that makes the report trustworthy is what YCAudit does not do: it never edits the target. Every confirmed issue ships as a spec - the root cause, the precise change, and a reproduction script - so a human or a coding agent applies the fix with full context and the diff stays reviewable. Symptom-level patches are rejected at the spec stage. The generator already moved fast; the audit's job is to be the slow, skeptical pass that explains why something is wrong before anyone changes it.
That is the whole pitch. In the posts that follow we put YCAudit to work on real codebases - our own included - and show what a run actually produces.