The governance gap in AI-assisted dev workflows is genuine. Whether a startup can own it is a different question.
There's a thread on r/programming that keeps coming back to me. The title is something like 'After two years of vibe coding I'm back to writing code myself.' 619 upvotes. 242 comments. And buried in those comments are engineers describing a specific kind of shame: they shipped AI-generated code they didn't fully understand, their manager couldn't tell from the diff, and now something is broken in production and nobody knows why.
That's a real problem. Not a manufactured one, not a VC-narrative one. Real.
Here's what I genuinely think is true: the way AI code enters production today is basically vibes-based governance. A developer accepts a Copilot suggestion, or pastes something from Claude, makes a few tweaks, and pushes it. The PR looks like any other PR. The diff is green. The reviewer clicks approve because nothing looks obviously wrong. Nobody knows that 60% of the logic was generated by a model that confidently hallucinates.
Git, GitHub, GitLab, your CI system — none of them capture that. There is no field for "where did this code come from." There is no required-reviewer rule that activates specifically when a model wrote the thing. The entire SLSA and software supply chain compliance world is still catching up, and it's catching up fast enough that engineering managers at fintech and healthtech companies are going to need answers soon.
The opportunity here is to build the system of record for AI code provenance before that becomes table stakes. A GitHub App that tags AI-assisted commits, attaches prompt context, shows a provenance panel in the PR UI, and blocks merges if AI-heavy changes don't get explicit human sign-off. That's a genuinely useful thing that doesn't exist today. And the buyer is identifiable: it's the engineering manager who will be in an audit room someday explaining why AI-generated code bypassed review. That person has budget and motivation.
The go-to-market also makes sense. GitHub Marketplace gets you discovery from 100 million users. A free tier for open-source repos creates bottom-up adoption. The compliance angle unlocks outbound sales to regulated verticals at $28/user/month, which at 80 engineers per org is real money. The LTV math is decent. The unit economics are strong.
So yes, I understand why this scored a 7. The problem is real, the gap is real, the buyer is real.
The fatal flaw isn't theoretical. GitHub has already started showing AI-generated code badges in Copilot Business. They've decided the transparency play is worth doing. They have the provenance data from Copilot API calls. They have CODEOWNERS and branch protection, which means they already know how to enforce workflow gates. They have a $10 billion market cap reason to protect platform stickiness.
Put those together and the question isn't whether GitHub will build AI provenance enforcement. They will. The question is when. The analysis here says 12-18 months. I think that's optimistic about how long you have, not pessimistic. GitHub Actions effectively killed the indie CI market. GitHub Advanced Security absorbed CodeQL's startup ecosystem. Microsoft has run this exact playbook before, and they'll run it again.
When they do, the core MVP — tag AI commits, show provenance, block merges — becomes a free setting in a tool your customers already pay for. No amount of SLSA export or fancy dashboards overcomes "it's already in GitHub."
That's the first thing that keeps me up about this.
The second is the classification problem, and I actually think it's more fatal than the GitHub risk because it's intrinsic to the idea.
What counts as "AI-generated code"? When a developer accepts a Copilot autocomplete for a variable name, is that commit AI-tagged? When someone asks Claude for an algorithm, rewrites it from scratch, keeps the general structure? When a function starts as 100% AI output and gets edited down to 20% of the original? The honest answer is: there's no clean definition, and once developers know there's a threshold, they'll route around it. They always do.
This isn't a UX problem you can paper over with a confidence score. At scale, your compliance audit trail becomes a false confidence machine. Managers think they have governance. Motivated developers have learned to minimize their AI signal. The tool gives the illusion of oversight while the actual risk stays invisible. That's potentially worse than no tool at all.
Beyond the fatal flaws, there are two risks that don't show up in the obvious analysis.
First: IP and data liability. This tool stores prompt excerpts from AI conversations in PR comments visible to entire engineering teams. If a developer's prompt contains proprietary code snippets or client data, you become the breach surface. This isn't a GitHub problem. It's not a Snyk problem. It uniquely attaches to a tool that captures and stores AI conversation context. One enterprise customer whose confidential data shows up in a PR comment visible to 80 engineers, and you have a legal situation that a startup cannot survive.
Second: the regulatory urgency might be fake. The entire "why now" thesis depends on SLSA compliance and EO 14028 becoming real enterprise buying triggers. But EO 14028 has been in effect since 2021, and most mid-size fintech companies still aren't SLSA-compliant on their human-written code. Your sales conversation becomes "we should do AI provenance" and the engineering manager says "we haven't even done SLSA for normal code yet." The compliance urgency that was supposed to force the conversation stalls before it starts.
If regulatory pressure stays slow, you're selling a governance nice-to-have into orgs that are already over-tooled. That's an extremely hard position at $28/user/month.
I don't think this is a dead idea. I think it's a race with a specific clock on it, and most approaches lose the race.
Here's what I'd change:
The validation test is legitimate and cheap. Do that first. If the signal is there, go build it. Just know exactly what you're racing against.