Workflow Envy

I want to be more productive without sacrificing quality. More to the point, I want to make meaningful gains in productivity without sacrificing quality. There’s the concept of Goodharting, aiming for improving the numbers but allowing the numbers to get separated from the actual goal. At work, my goal might be shipping features that align with the organization’s roadmap. If I focus on a superficial number like GitHub contributions, I might be improving the wrong thing. I could satisfy the larger, real goal (roadmap features) without the orthogonal, fake one (GitHub contributions). Correspondingly, I could satisfy the fake goal while losing site of the real one.

Recently, I heard on a YouTube video that Boris Cherny, the creator of Claude Code, lands 50-100 PRs a week. Initially, I heard “100 PRs a week,” and I was shocked. That’s a surprisingly large number. If those are meaningful PRs that move useful features forward in a customary way or better, it represents 10x engineering at least, more or less, even at the lower number. 50 PRs a week means 10/work day.

I was filled with envy reading that number. It is likely real, because the creator of Claude Code knows what he’s doing. In the past, when one learned about supposed big jumps in productivity, they were often just hype. There were real gains to be made, but it also made sense to be a little cautious, to hold off on adopting something new until it had been tried out by the truly early adopters. Maybe I’d be in the first 10% for some new tech, but I wouldn’t be in the first 1%

In software engineering, we now find ourselves a strange, fast-changing world. For decades, profound gains in productivity came slowly. There was real progress, but I never noticed it on a day to day basis. Instead, it would happen when I switched jobs, went to a conference, or started working with a new colleague. When I started working with Ruby on Rails at a then new job in late 2006, it had already been around for a couple years. It was a big shift, but it corresponded with the kind of milestone I’m talking about. Over the years, I adopted standard development practices like git, different editors, continuous integration, and many other practices that slowly made me more productive. That equilibrium changed a few months ago, in the summer of 2025, when I started using AI for coding much more than I had done before then.

Today, the cost of not experimenting, of not refining one’s workflow has gone up. If it’s possible to increase one’s productivity by 5-10x, the cost of not doing so is very high. The new standard becomes that new, high level of productivity. At the same time, it’s still important to be skeptical. Do those numbers represent progress towards the real goal? If I get to 50-100 PRs a week, but I’m not delivering more value than before, that’s a failure. Likely the failure is not in my day to day workflow, but in my planning or review processes. It’s worth spending some time improving my coding workflow, but it’s also worth spending more time on the question of what to build.