How to Scale AI Developer Productivity Across a Team

Nate B. Jones (0:00)

In July, Lauren Tan shipped about 1,000 pull requests. That's a lot of code. She said August would be double that. August came in at 2,462. She called her own number, and she beat it. Now, your team probably isn't going to do that this month. That's not because they're worse engineers, necessarily. It's because 1,000 pull requests isn't a skill issue. It's a setup issue, and nobody sells you the setup. Nobody helps you understand what that setup is. Your agents are shipping work with your name on it, and you're being told to ship faster and faster and faster. But what control do you have? If you had to name the controls you have to manage agent velocity and quality, how long is that list? For most of us, I find it's quite short. And that's not a character flaw. It's that no one has handed you the controls to drive these agents effectively. I'm Nate B. Jones, and I want to help you build a better life with AI. And in this video, I'm going to teach you six principles that I've extracted from developers like Lauren and a bunch of others who will help you build faster using the AI tools you already have. Cursor's Developer Habits Report says its top developers merge about 15 times as many pull requests as a typical developer who's actively submitting those proposed code changes. And that's what they are. Pull requests are proposed code changes that actually get accepted. And yet, for most of us, what I hear is that we still have a pile of work waiting for someone to finish, even with the AI tools. So what happened? Why does it feel like with all the AI tools, you end up buying a nice big queue instead of a faster factory? Lauren Tan, who goes by Poteto Online, recorded a talk for Cursor Compile London about how she actually gets 2,000 pull requests a month done. And she put it out for free on X. And I love that because some of the most useful things happening in AI right now are so hard to find. They end up buried in how somebody has set up their work, or companies have plenty of reasons to keep these details to themselves. They don't go viral. And so when people share them, the rest of us get a chance to learn something that we can all actually use to change the story of how AI tooling turns into real value. Lauren's setup is a great example. It's not the only one, but it's a great example. I'll tell you some others as well. Shopify is another one. Shopify has built a shared system for agent work across the company. Another one is from Adios Monte. He's been writing about what humans are still responsible for as we commit code. Fiona Fung is another one. She's described how the team building cloud code changed the way it works. The question I keep coming back to is pretty simple.

How do systems that we build stay resilient as AI continues to scale, especially around productivity? We can build an elaborate setup that takes weeks to maintain. In fact, we've seen them. Steve Yuggie's Gastown is a good example. He talked about the fact that he has never built anything really productive with Gastown. He built Gastown, but then Gastown itself did not end up producing for him, and it was a very elaborate system. And so we can build super elaborate setups that take a long time to craft and maintain, and we can feel productive doing that. But if we end up having to rebuild our setups every time a model changes or another person joins, we've just given ourselves more work. If you want something that you can keep using and improving, you have to think about simplicity. So the principles I've crafted have that in mind. Now, a lot of you already understand what accountability means when it comes to agent's shipping code, but you may have very little control over how that work gets done, and that can lead to a lot of frustration. I've heard that from developers. So what can you actually change beyond yelling at your agent? The six principles I'm going to give you here give you different ways to improve the setup and actually push accountability that you hold in yourself onto the agent in a way that's productive. And they're crafted with simplicity in mind so you can keep scaling them. So let's get into what you can actually change and drive in all of the six principles. Number one, make agents multiplayer. And by that, I mean put the work somewhere the team and the agents can see it and reuse it. It sounds simple, but think about the last time you and an agent figured out a really annoying problem. You tried a few things, you found out what didn't work, and you finally got it right. Certainly, that's my story. I yell at my agents a lot, and I'm like, no, this is not it. It's not it. And then you get there. Well, where did that knowledge go? If it's sitting in a private chat on your laptop, the next person next to you may have to go through the whole thing again. And that's especially expensive when it comes to code, when we're all working on larger projects together.