Building in Public: I Audit AI-Generated Code So You Don't Have To
I've spent the last few weeks auditing AI-generated codebases. The results are eye-opening. Here's what I found — and why I built a service around it.
The Setup
Five weeks ago, I started SecondRead — a plain-English code audit service for founders who built their apps with AI tools like Bolt, Lovable, Cursor, and v0.
The pitch is simple: send us your GitHub repo URL, get back a report that tells you what's broken in language you actually understand. No CVE lists, no developer jargon, just "here's what will break at 100 users" and "fix this before your customers find it."
I built it because I kept seeing the same pattern: founders shipping v1s in hours, then hitting a wall when real users started breaking things. The AI tools are incredible at getting you to a working demo. They're less incredible at making sure that demo doesn't fall over in production.
What I Found Across 5 Audits
I've completed 5 full audits so far. Here's what the data says:
Every single audit found hardcoded secrets. API keys, database connection strings, even Stripe secret keys — sitting in source code, sometimes committed to public repos. This isn't a theoretical risk. If anyone inspects your app's network traffic, they can extract these.
4 out of 5 had missing CSRF protection. For non-technical founders: this means someone could trick your users into submitting forms they didn't intend to submit. On an e-commerce app, that's unauthorized purchases. On a SaaS, it's account changes made without consent.
3 out of 5 had no rate limiting. Without rate limiting, a single user (or bot) can send thousands of requests per minute. Your server slows to a crawl, real users get timeout errors, and you don't know why.
All 5 had dependency bloat. AI tools install packages to solve immediate problems, but they don't clean up. One audit found 847 dependencies — 300+ were unused. This makes updates slower, security patches harder, and your app heavier than it needs to be.
The pattern: AI-generated code works. It genuinely works for v1. But it's built for "does it run?" not "will it survive contact with real users?"
The Data Backs This Up
This isn't just my experience. The numbers are stark:
- Veracode (March 2026): 45% of AI-generated code has security issues. For Claude-generated code specifically, it's 52%.
- Georgia Tech vibe security research: 74 confirmed CVEs from "vibe coding" approaches, 14 of them critical. 35 in March 2026 alone.
- METR study: In a controlled trial with 16 developers and 246 tasks, AI-assisted code showed measurable quality concerns.
This is a real, growing problem. And the founders I've talked to know it — they just don't know what to do about it. They don't speak developer. They can't read a SonarQube report. They need someone to translate.
Why I'm Building This in Public
Two reasons:
1. The problem is bigger than I can solve alone. Every founder who shipped with Bolt, Lovable, Cursor, or v0 is potentially sitting on these issues. Most don't know it. The more visible this data is, the more founders will check their code before it costs them.
2. I want feedback. I've audited 5 codebases. I need to audit 50 to know if my findings are consistent or if I'm seeing a biased sample. If you've built something with AI tools, I want to see your code — free, in exchange for honest feedback on whether the report actually helps.
The Offer
If you've built an app with Bolt, Lovable, Cursor, v0, or any AI coding tool, I'll audit it for free. You send me the GitHub repo URL, I send you a plain-English report within 48 hours.
What you get:
- Top 3 critical issues, explained in language you can act on
- A plain-English summary you could forward to a contractor
- No strings, no upsell, no "book a call" friction
What I get:
- Honest feedback on whether this format is useful
- More data points to validate (or challenge) what I'm seeing
What's Next
I'm publishing the anonymised findings as I go. The goal is to build enough data to publish a proper "State of AI-Generated Code" report — something that helps the whole community understand what's actually happening in these codebases, not just what the tool companies' marketing says.
If you want a free audit, the link is in my profile. If you just want to follow along, I'll be posting updates here as I go.
Building in public means being honest about what works and what doesn't. So far, what's working: founders are resonating with the problem. What's not: most of them don't know this service exists yet.
Let's fix that.
SecondRead — plain-English code audits for founders who built with AI tools. Free audits available. secondread.me
The gap between “it works” and “it’s safe to put in front of real users” is probably going to become a much bigger problem as vibe-coded products mature. I’m curious whether the audit findings are starting to cluster around the same few failure modes, or if every codebase is breaking differently.