AI has made writing code faster than it’s ever been. Pull requests that used to take a day now take an hour. Entire features get scaffolded in the time it takes to write a Jira ticket by hand. If you work in engineering, you’ve felt this shift already, and if you haven’t, you will soon.

I’m not writing this to argue against AI-generated code. I use AI daily, I’ve built automation at my own company that lets AI open pull requests, create Jira tickets, and run tests with minimal input from me. I think the speed is real and the productivity gains are real.

But speed creates a problem that most engineering teams haven’t fully reckoned with yet, and it’s not a technical problem. It’s a compliance problem.

The gap nobody’s pricing in

SOC 2 and PCI DSS both require documented human review of code changes before they reach production. This isn’t a suggestion buried in a footnote. PCI DSS 4.0 Requirement 6.2.3.1 is explicit that code reviews have to be performed by someone other than the originating code author, and it stopped being a “best practice” and became mandatory in March 2025. SOC 2’s change management criterion, CC8.1, expects the same thing: evidence that a human looked at a change, understood it, and approved it, before it shipped.

That requirement was written for a world where code was written by people. It didn’t anticipate a world where 80 or 90 percent of pull requests might be authored by an AI agent, reviewed by another AI agent, and merged with no human in the loop at any point.

Right now, a lot of fast-moving companies are living in that second world while still being audited against rules built for the first one. And the honest truth is: an auditor looking at that setup today has every reason to flag it. Not because AI-written code is inherently worse than human-written code, but because “who is accountable when this breaks” becomes a much harder question to answer when no human ever actually looked at it.

Why I don’t think the answer is banning AI

The easy, lazy response to this is to say AI-generated code is the problem and human review is the fix, full stop. I don’t think that’s right either.

AI-generated code isn’t automatically riskier than human-written code. In a lot of cases it’s more consistent, better tested, and free of the fatigue-driven mistakes humans make at 6pm on a Friday. The risk isn’t the source of the code. The risk is the absence of a checkpoint, a moment where a specific, accountable person looks at a change and says, deliberately, this is safe to ship.

That checkpoint is what compliance frameworks are actually protecting. Not human authorship for its own sake, but a documented moment of judgment that someone can be held to.

What I think this actually requires

If I building this into a security program today, I wouldn’t try to force full manual review of every AI-generated line. That’s not realistic at the volume most teams are shipping at, and it would just make people route around the process, which is worse than not having the process at all.

I’d build it in tiers. Low-risk changes, styling, internal tooling, non-critical paths, get a lightweight check. Anything touching authentication, payments, customer data, or infrastructure gets a mandatory, named human reviewer, no exceptions, with the approval tied to an identity and timestamped for audit purposes.

I’d also push automated scanning earlier and harder than most teams currently do. If a human isn’t reading every line, then SAST, dependency scanning, and vulnerability detection need to be non-negotiable gates, not optional ones, because they’re often the only check a piece of AI-generated code will get before a human’s eyes see it, if they see it at all.

And I’d be honest with leadership about the tradeoff. Full AI autonomy on code shipping is fast. It is also, right now, a real and specific audit risk for any company handling regulated or sensitive data. That’s not a hypothetical. It’s a conversation worth having deliberately, with eyes open, rather than discovering it during an audit or, worse, during an incident.

The uncomfortable part

The uncomfortable part of this, for me, is that reintroducing human review where a team has gotten used to full AI autonomy is an expensive, unpopular decision. It slows things down. Nobody enjoys hearing “we’re checking these” after they weren’t being checked. Companies solving genuinely hard problems don’t want to hear that go-to-market or shipping cadence needs to be interrupted by process.

But that expense doesn’t disappear just because it’s inconvenient. It shows up later, either as an audit finding, a client walking away after seeing your compliance posture, or in the worst case, an actual incident traced back to something a human would have caught and an AI reviewing another AI’s output didn’t.

I’d rather have the expensive conversation early. That’s the job, as I see it. Not slowing teams down for the sake of it, and not pretending speed has no cost either. Finding where the line actually needs to sit, and being willing to say so even when it’s not the answer anyone wants to hear.