This is getting ridiculous: I shipped 490 pull requests in June

In March I published The AI-Native Engineering Playbook. It ended with a stage I called Fly, where a four-person team starts to function like a twenty-four-person team because every engineer runs several Claude Code sessions in parallel, and I wrote "more on that in future posts" and left it there. So this is that post, and I expected it to be a fairly comfortable victory lap where I show the framework working and we all carry on.

Instead I'm sitting here at the end of a month trying to digest what actually happened. In June I merged 490 pull requests into our production repo at work, and the four-engineer team I lead merged 844.

When I wrote the Playbook we were shipping 200 to 300 PRs a month as a team, and I was already very happy about that. I figured we would settle somewhere around there, I would keep coaching teams toward it, and life would go on. What happened instead is that the parallelism and the AI-native workflows kept compounding, and the numbers have now reached a level where I've started questioning what I'm actually doing, why everyone isn't working this way, what this means for how organizations should be structured, and occasionally whether I'll still have a job in a few years. Like most software engineers I've been processing some version of an identity crisis since the ChatGPT moment, wondering what happens to the craft when everyone gets a magic wand, and every stage of the ramp since then has surprised me in some way. This is the first time it has tipped over into ridiculous.

The obvious first objection is that I've been playing in a sandbox, so let me deal with that before anything else.

These are peer-reviewed pull requests, merged by colleagues into the production repository of a platform at a European cybersecurity company, with continuous production releases, live enterprise partners, and paying customers with real support expectations. The median merged PR was 122 lines across three files, which is a completely normal size for a change, so the count is not made of micro-commits dressed up as pull requests. It's a business, with all the boring constraints a business has, and we're still doing this.

I know that working in many parallel sessions produces more PRs than doing the same work slower and more deliberately would, so I had the whole month challenged: every June PR classified in context, grouped where several PRs were really one piece of work, and tagged where a PR existed only to fix something a sibling PR had just shipped. The 844 merged PRs came out at roughly 739 traditionally sized pieces of work, and about 620 after removing rework, which averages to around 155 per engineer for the month, with my own share well above the average. So you can divide by 1.5, or by 2 if you want to be harsh, and the comparison doesn't really change, because published benchmarks put the median developer at 5 to 6 merged PRs a month and elite performers at 9 to 11.

The closest public reference I've found is Anthropic reporting that their own engineers now ship about eight times more code than before Claude, with over 80 percent of it written by Claude. My own history says more to me than any benchmark, though: across a twenty-year career, a genuinely great month for me meant somewhere between 20 and 40 merged PRs. This June it was 490.

Rereading the Playbook four months later, the thing I'd add is throughput. I described what each stage looks like, but I never said what each stage ships, and the difference between the stages is easier to feel with numbers attached. In merged PRs per engineer per month, roughly:

• Crawl is a traditional competent team, with ChatGPT open in a tab for advice and some copy-pasting back and forth. This is where the published industry benchmarks live: 5 to 10, with the elite end around 11.

• Walk is when everyone has had their Claude Code moment, meaning an agent editing files in your repo, one session and one task at a time. The published studies of AI-assisted coding measure this stage, and they find gains between 10 and 60 percent, so call it 10 to 20.

• Run is when the processes go AI-native: specs and decisions in markdown in the repo, meetings run for the transcript, the agent owning the git workflow. This is where we were when I wrote the Playbook, at 30 to 80.

• Fly is parallel orchestration as the default way of working, which lands somewhere around 100 to 200 or more, and June says a single engineer can go well past that.

I also owe the Playbook a correction. I described Fly as running four to six parallel sessions with three or four PRs cooking at any time, and four months later the actual numbers are that I have 30 to 40 sessions open, of which I actively manage 10 to 15 through a working day. I managed to underestimate the ceiling in the post that was supposed to be the ambitious one.

I find it hard to describe what working like this feels like, because the word productivity doesn't capture it. Writing code stopped being my day-to-day work years ago, so that part isn't new, but what the profession has turned into during this last year is something else again, and I have to reach for comparisons. It's a hyper-focused state that resembles playing a real-time strategy game, or maybe element-bending: organizing and redirecting a flow of energy, except the energy is LLM tokens and what comes out the other end is working software. Call it AI bending. And when I come out of that state I honestly haven't registered how many PRs were created along the way, so the month-end count manages to surprise me every single month. At one point I suspected the real explanation was that I was overworking, so I pulled back and measured it, and June turned out to be a completely normal full-time effort. That might be the most ridiculous part of all of it.

June makes me an existence proof that a single engineer can merge hundreds of real PRs a month, and my team is the same proof at team scale. So how much more do we actually deliver? My honest estimate is three to four times the value of an average team, and we routinely put things into production in days or a week that would take most teams weeks or months. A few teams I know of have reached the Run stage by now, but I haven't seen one that's flying yet, and being able to write that sentence is strange in itself. At the same time it's clearly not the ten or twenty times that the raw volume would suggest, and the gap between those two numbers is the most useful thing in this post for anyone running an engineering organization.

The best analogy I've found is construction equipment. The step from Walk to Run is like discovering excavators: four people with excavators will out-build fifty people with jackhammers and pickaxes, and once you've seen it you also realize the right team size is four rather than twenty. The step from Run to Fly is more like handing those four people Iron Man suits, because now the interesting question is no longer how fast you can dig the foundation you were assigned, but whether you should be out building new cities. And that second question is the one most organizations have no slot for. If the people in the suits are only allowed to work on the one approved building, can't change its color because that belongs to another department, and can't talk to the people who will live in it, then they can fly all they want inside those walls. That's roughly where we are: flying, genuinely, but inside a greenhouse.

We are blocked a lot of the time. We want to ship faster and we're often not allowed to, and we want to take on more and the organization around us isn't set up to absorb it. Almost none of the bottlenecks are technical. It's nearly always that somebody at some point decided a process has to work a certain way, nobody quite remembers why, and nobody has the capacity or the authority to change it. Some of that conservatism is legitimate, since the stakes are real and there are things you must not break, but it prices iteration and learning at close to zero, and it means that when a team builds what was essentially a five-year roadmap's worth of product in a matter of months, the organization around it still needs a year or two to digest that.

There's also a second kind of blocker that I didn't expect, and it took me a while to put words on it. Working at this pace means some of what we ship, especially internal tooling, is rougher than people are used to, because it was built in an hour instead of over a couple of days. And what happens when someone hits a rough edge is interesting: most people go quiet. They don't tell us something is broken, they just stop using the thing and quietly find another way, and at most we hear the frustration secondhand later. From where we sit that silence is the expensive part, because the conversation they didn't start is exactly the cheap one: if we know you use this tool for that particular report, we won't just fix the bug, we can build a well-tested path for exactly your workflow and have it in production within days. That capacity exists now and mostly sits unused, because people are still calibrated to a world where asking another team for something means waiting a quarter. Even colleagues who know perfectly well that we're fast haven't internalized what the new iteration speed makes possible, so we have to proactively invite people in, one workflow at a time. In one sense that's just normal product development, but the mismatch is new: the development speed moved by an order of magnitude and the expectations around it barely moved at all.

So for now the energy goes where it can go, which is inward. We go back over quality, fix paper cuts, and take care of the details nobody ever has time for, and that is probably part of why our PR count looks the way it does; the philosophy behind working this fast was never volume for its own sake but maximizing learning and minimizing uncertainty through very fast iteration. But I want to be clear that the inward turn is a workaround, not the goal. What I actually spend my thinking time on is the organization level: what processes, product structure, and division of responsibility would look like in a company deliberately constructed around teams that fly, instead of one where such a team politely circles inside the greenhouse. That's a work in progress and I don't have silver bullets yet. What I can already tell you is that when a team reaches the Fly stage your bottleneck moves somewhere your org chart doesn't expect, and it happens faster than you think.

Everyone I talk to agrees that AI matters, but almost everyone means using AI to write code faster, running one or maybe three sessions at a time. And the pattern goes beyond engineering: plenty of non-engineers with full Claude Code access barely open it, even though someone in marketing or sales or internal services could save hours every week with nothing more exotic than browser automation running inside Claude Code, and they keep using the old software instead. Some engineers who do use it daily are perfectly content keeping Jira and the old processes wrapped around it. The parallelism part, which is where the economics actually change, somehow doesn't land, and I keep wondering why.

What makes it stranger is that access is the solved half of this: a Claude Code subscription costs a company about as much as a phone plan, so essentially nobody is limited by AI capacity anymore. People and teams are limited by their ability to actually use the capacity they already pay for, and that includes me — I'm nowhere near maxing out my own plan.

Which brings me to the question I keep circling: how teachable is this? June proves the destination exists, since a normal team on a normal production platform, following what I outlined in the Playbook, ends up here. What I don't know is whether existing teams can generally be coached into it, or whether you need to rebuild teams around people who already work this way. My sample so far says it transfers. There's my own team, which I coach daily. There's a team at another cybersecurity firm that I coached for a few months and that was very happy with where it took them. And there's a team at another organization that I'm starting with now. That's three data points, and I would like many more. I've also started sketching a Claude Code skill that walks a team through going AI-native, essentially the Playbook as something you install rather than something you read.

That is the real reason I'm publishing this. It feels like a turning point, and I'm trying to understand it, and I would rather do that together with other people than alone at the end of another ridiculous month.

If you're running fast and hitting the same organizational walls, I want to compare notes. If you're stuck at the Walk stage and suspect there's more, I want to hear what's stopping you. If you think I've got any of this wrong, I would genuinely like to be argued with. Reply here, send me a DM, or reach me through my site. And if you want the full written-down version of how we work, it's free in two courses, one for engineering teams going AI-native and one for individual engineers scaling their parallel throughput.

I've been writing about this transition for a couple of years now, and this is the first post I've finished without quite knowing what it means. That's exactly why I want to hear from you.