Stripe is shipping a thousand AI-generated pull requests per day. A thousand. And the quality is comparable to what their senior engineers produce. Before you close this tab thinking it’s hype, let me tell you why this actually works. Because it’s not about the model. It’s not about some secret prompt. It’s about two things that most teams are too lazy to build.
And honestly? The playbook isn’t even new.
To understand why this matters, you need to know what most teams get wrong
So here’s what happens at 90% of companies trying to use AI for code. They grab Copilot or Claude or whatever, point it at their codebase, and say „write me a feature.“ The agent spits out something that looks reasonable. Maybe it even compiles. They push it, it breaks something in staging, someone spends two hours debugging, and then the team lead writes a Slack message that says „AI isn’t ready yet.“
I’ve seen this play out so many times it hurts.
The problem was never the AI. The problem is that these teams have no guardrails. No documentation. No automated checks worth a damn. They’re basically hiring a contractor, giving them zero context about the project, and then being shocked when the code doesn’t fit.
Stripe didn’t do that. They built the system first. And that system is why a thousand PRs a day actually works.
The agent gets the same onboarding as a new hire
Every big company has a biased way of doing things. I don’t mean that negatively. I mean they have opinions. Architectural decisions. Style preferences. Patterns they like. Anti-patterns they’ve been burned by. At Stripe, all of this lives in an internal knowledge base.
Now here’s the thing. When you join Stripe as an engineer, you don’t just start writing code on day one. You read the docs. You look at past decisions. You understand why the system looks the way it does before you change anything. The best engineers I’ve ever worked with do this instinctively. They dig into context before they touch the keyboard.
Stripe’s AI agents do the exact same thing.
The agent accesses the internal knowledge base through APIs, through MCPs, through CLIs. The same interfaces that human engineers use. It pulls in relevant context before it generates a single line of code. It knows which patterns are preferred. It understands why certain architectural choices were made. It reads the history before it writes the future.
And this is the part nobody talks about. This flow is universal. It’s not some Stripe-specific innovation. Any engineer at any company follows this exact process. Or at least they should. You get hired, you read the docs, you talk to the team, you understand the codebase, and then you start contributing. The AI agent just does it faster and more consistently.
The tooling isn’t exotic either. MCPs give the agent structured access to documentation. CLIs let it query internal services. APIs expose the knowledge base programmatically. If your company already has good internal docs, you’re halfway there. If you don’t, well, you’ve got a much bigger problem than AI adoption.
Everything after code generation is deterministic. Everything.
Okay so here’s where it gets interesting. And this is the part where most teams completely fall apart.
Writing code with AI is non-deterministic. You give it the same prompt twice and you might get two different implementations. That’s fine. That’s the nature of generative models. You can’t fully control what comes out. Stop trying.
But everything after the code is written? That can be deterministic. And at Stripe, it is.
Strict linting. The code either passes or it doesn’t. No „close enough.“ No „well it’s mostly consistent.“ It passes or it fails. Tests run automatically. If something breaks, the PR doesn’t move forward. Coverage thresholds are enforced. Not suggested. Enforced. Security audits run on every single PR. Static analysis catches vulnerabilities before a human ever looks at the diff.
And here’s the critical piece that makes the whole thing actually work. If any check fails, the PR doesn’t get thrown away. It goes back to the agent. The agent reads the failure output, understands what went wrong, and fixes it. Then the checks run again. This loop continues until everything is green.
Only then does a human review it.
graph TD
A[AI Agent Generates Code] --> B[Run Linting]
B -->|Pass| C[Run Tests]
B -->|Fail| A
C -->|Pass| D[Check Coverage]
C -->|Fail| A
D -->|Pass| E[Security Audit]
D -->|Fail| A
E -->|Pass| F[Human Review]
E -->|Fail| A
style A fill:#fff9c4
style F fill:#c8e6c9
style B fill:#e1f5ff
style C fill:#e1f5ff
style D fill:#e1f5ff
style E fill:#e1f5ffThink about what this means for the human reviewer. By the time they open that PR, the code already passes linting, all tests pass, coverage is above threshold, and security scans are clean. They’re not wasting time on formatting issues or obvious bugs. They’re reviewing architecture, logic, intent. The high-value stuff. The stuff that actually requires a human brain.
The non-determinism of code generation gets tamed by the determinism of verification. That sentence is worth reading twice.
This process is older than most of y’all’s careers
Here’s the part nobody wants to hear. This workflow is not new. At all.
Successful engineering teams have followed this exact process for decades. The playbook has always been the same. Understand the codebase before you write code. Write your code. Run it through automated checks. Fix whatever fails. Submit for human review.
The classic sign of a bad engineering team is that they skip all the automated stuff and dump everything into code review. Now you’ve got engineers arguing about formatting in PR comments. You’ve got reviewers catching bugs that tests should have caught. You’ve got people pushing code that doesn’t even pass the linter. Everyone wastes time. Morale drops. Velocity tanks.
I’ve been on teams like that. You probably have too. Ten comments on a ten-line pull request about bracket placement. Zero comments on a thousand-line PR because nobody has the energy to review it properly.
The best teams I’ve worked with? Their guardrails were so tight that by the time a PR hit review, the only questions left were about design and intent. The linter handled style. The tests caught regressions. Coverage gates ensured nothing shipped untested. Security scanners flagged vulnerabilities automatically.
These teams didn’t need AI to be fast. They were fast because the harnesses did their job. Engineers spent their review time on what actually mattered. Teaching each other. Sharing context. Discussing trade-offs. Building culture.
The most important benefit of code review has always been engineers teaching one another best practices and solidifying the culture of the team. You can’t do that if you’re spending forty minutes fighting a war over tabs versus spaces that should have been solved by the linter three years ago.
Stripe took that same playbook and handed the code writing step to an AI agent. That’s it. The rest of the process stayed exactly the same. And that’s exactly why it works.
Build the guardrails before you build the agent
If you want to leverage AI agents on your team, don’t start with the agent. I’m serious. Don’t even look at models yet.
Start with the guardrails.
Do you have strict linting enforced in CI? Not „recommended.“ Enforced. Does your build fail if linting doesn’t pass? Do you have comprehensive test suites that actually run on every PR? Is coverage tracked and gated? Do security scans run automatically?
If the answer to any of those is no, fix that first. Because if your guardrails aren’t strong enough to catch a bad PR from a human engineer, they’re definitely not strong enough to catch a bad PR from an AI agent. The agent will produce code faster than any human on your team. If your checks are weak, you’ll just accumulate tech debt at a rate that would make your CTO cry.
And the documentation piece matters just as much. If your institutional knowledge lives in people’s heads instead of in a searchable knowledge base, the agent has nothing to work with. It will generate code that works in isolation but doesn’t fit your system. It won’t follow your patterns because it doesn’t know your patterns exist.
Writing docs is boring. Setting up linting rules is tedious. Building comprehensive test suites takes forever. Configuring security scanners is nobody’s idea of a good time. But these are the exact investments that separate teams that can ship a thousand PRs a day from teams that will drown in AI-generated slop.
The teams that built these systems years ago, long before AI agents were even a thing, are now the ones reaping the rewards. They didn’t build the guardrails for AI. They built them for quality. The AI agents just happen to benefit from the same infrastructure that made their human engineers productive.
The harshest reality that I think a lot of y’all don’t have internalized: if your engineering team can’t ship high-quality PRs consistently without AI, adding AI won’t fix that. It’ll make it worse. Faster. The AI revolution isn’t about the AI. It’s about whether you built the foundation to support it.
So build the guardrails. Write the docs. Enforce the checks. Then plug in the agent and watch it fly.