An LLM-aware static analyzer sounds obvious in hindsight. Whether it's buildable is a different question.
There's a post on r/webdev that keeps coming up when people talk about AI coding risk. An Amazon service went down because an AI coding bot introduced a bug that passed code review, passed existing scans, and then quietly broke production. 255 upvotes. 47 comments of engineers going "yeah, this happened to us too."
That thread is both the strongest proof-of-demand for this idea and a preview of its core problem.
The pitch is a static analysis tool trained specifically on bugs that LLMs tend to produce. Not SQL injection in general. Not XSS. The specific failure modes that come up when Copilot or Cursor generates code: hallucinated library calls that look plausible, brittle conditional chains that work in happy-path testing and break on edge cases, overconfident null handling, unsafe defaults that no human would have written but an LLM confidently outputs.
Existing tools like Semgrep and Snyk are pattern-matching engines. They're looking for known vulnerability signatures against CVE databases. They're genuinely good at what they do. But they weren't designed to recognize that `requests.get(url, verify=False)` showing up in AI-generated code is part of a broader pattern of the model defaulting to "make it work" over "make it safe." The semantic context is different even when the surface-level code isn't.
The technical approach here is to fine-tune something like CodeBERT on a labeled corpus of AI-generated bugs, integrate it into CI as a GitHub App, and surface findings with an exploitability score and a remediation playbook that's specific to the failure mode, not just a generic CWE reference.
The data flywheel is real if you can bootstrap it. Every confirmed true-positive a customer finds becomes a labeled training example. After 18 months with 100+ paying teams, you have a proprietary dataset that Semgrep can't buy and can't build without equivalent deployment. Rule-based competitors literally cannot replicate corpus-trained detection, because the corpus requires deployment at scale, and deployment requires demonstrating detection superiority over the tools people already have installed.
That's a real moat. The question is whether you can survive long enough to build it.
Here's the part that should keep any founder up at night: you need labeled data to be better than Semgrep's rules, but you can't get labeled data without deployment, and you can't get deployment without being demonstrably better than Semgrep. It's a circular dependency with no obvious entry point.
The proposed escape hatch is to manually audit public repos that are known to use heavy AI-assisted development, find bugs Semgrep misses, package those as a report, and cold-email AppSec engineers at fintechs. It's actually a good idea. It's manual, it doesn't scale, and it's the right first move. You're not selling software yet, you're selling proof.
But the launch risk is real. AppSec teams have extremely low tolerance for false positives. A noisy v1, shipped before the corpus is mature enough to support the precision claims, can permanently kill your reputation in a space where reputation is everything. Security engineers talk to each other. One bad launch at a respected company and you're done before the flywheel has a chance to spin.
Is "LLM-origin bug" actually a coherent category?
Most AppSec practitioners will argue, reasonably, that SQL injection is SQL injection. It doesn't matter if a human wrote it or Copilot wrote it. Semgrep's existing rules catch the exploitable subset either way. The differentiation claim depends on there being a class of bugs that is meaningfully distinct by virtue of being AI-generated, and that claim is contested.
If the AppSec community decides this is just relabeling existing bug classes with a new narrative, the entire positioning collapses. That's not a technical risk. It's a narrative risk, and it's the kind of thing that's invisible until a credible security researcher writes a blog post about it.
There's also the generative side closing in. Copilot Autofix and Cursor's upcoming security features are catching bugs at write time, not audit time. If the generation-side tools get good enough at this, the audit-side market for AI-origin bugs may shrink before it finishes forming. The timing window might be 18 months, not a durable business.
The OWASP Slack appsec-ai channel has 3,000+ members. r/netsec and r/appsec combined have 50K+ subscribers with high practitioner density. The 47 commenters on that Amazon outage post are real, findable people who have already told you they have this problem.
The validation test proposed here is specific enough to be credible: manually find 3 LLM-origin bugs in a company's public repo that Semgrep misses, send it to their AppSec lead, offer a free audit of their private repo in exchange for 30 minutes. If 5 engineers pay $500 for a manual audit report within 30 days, you've proven the problem is real and distinct.
That's a reasonable way to start. It won't feel like a startup for a while. It'll feel like consulting. But the corpus you're building during that phase is the actual product.
This is not a pure vibe-coding project. The technical surface is manageable (Next.js, Supabase, Python backend, tree-sitter for AST parsing, GitHub App SDK) but the domain expertise requirement is high. You need someone who can credibly talk to AppSec engineers, who understands the difference between static analysis approaches, and who can publish technical content that practitioners respect.
The first 10 customers aren't won with a product. They're won with a blog post titled something like "The 10 security bugs that Copilot keeps introducing and why Semgrep misses them," posted in the right communities with working proof-of-concept examples. If that post doesn't get traction, the product probably won't either.
Opportunity score of 7/10 with a "vulnerable" survival verdict feels about right. The market is real. The timing is real. The moat, if you can build it, is real. But the path from zero to moat runs through a minefield of false-positive reputation damage, Semgrep shipping a community LLM ruleset before you're established, and a contested narrative about whether any of this is actually a distinct problem category.
The founder who wins here publishes the proof first, before the product ships.