OpenAI engineers open about 10x more pull requests than six months ago

Gergely Orosz got inside OpenAI's engineering org and published what he found. Two numbers carry the piece: PRs per engineer up roughly 10x over about six months, and Codex adoption in non-engineering departments going from near zero to 90% between February and June 2026.

The named internal systems are worth cataloguing because they show where the effort went. Perf Factory does automated performance monitoring. Sevbot handles incident response. A Synthetics framework runs A/B testing. These aren't coding assistants. They're agents wired into the parts of engineering that aren't writing code.

Orosz's structural observation is the one I'd bet on: the bottleneck moved to build-test-deploy. That pipeline is now carrying dramatically more load than the humans generating the work, because the humans stopped being the throttle. If your engineers suddenly open ten times the PRs, your CI is the thing that breaks, then your review process, then your deploy cadence, in that order.

I've watched a small version of this in my own work. Once I stopped writing most first drafts by hand, my test suite runtime became the thing I noticed every single day. A 90-second suite is fine when you run it six times a day and unbearable when you run it sixty. I've spent more engineering time on test parallelization in the past year than in the previous five combined, and it wasn't a deliberate strategy, it was just where the pain moved.

Two caveats on the 10x. This is the company that sells the tool, describing its own adoption, so treat it as a directional claim from an interested party even though Orosz is reporting rather than repeating a press release. And PRs per engineer is a volume metric, not a value metric. Research this week found AI-written functions are half the size of human-written ones with different defect classes, which means PR count inflates when the unit of work shrinks. Ten times the PRs is not ten times the shipped value.

The move is to go measure your pipeline before your team's volume changes, not after. Get a baseline on CI queue depth, median time from PR open to merge, and deploy frequency now. When the volume arrives, you want to know which stage buckled.