{"slug": "a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day", "title": "A software engineer's playbook to go from single-digit to 100 PRs a day", "summary": "A software engineer's playbook argues teams can scale from single-digit to over 100 merged pull requests per day by treating coding agents as parallelizable for loops, running multiple agents simultaneously via git worktrees, and codifying a standardized software development lifecycle. The article outlines three principles — internalize how coding agents work, understand your development process baseline, and accelerate each step — and cites a claim of teams shipping well over 100 PRs a day. It notes the approach requires standardized process to produce standardized agent outputs and is aimed at developers without frontier-lab resources or unlimited tokens.", "body_md": "These days, you might see some incredible claims of teams shipping [well over 100 PRs a day](https://x.com/poteto/status/2102050467505430555?s=20). But it isn't immediately clear how *your* team can bridge that gap.\n\nMost days, your team might only muster single-digit PRs. Barely clearing ten PRs merged into master, let alone over a hundred.\n\nOn top of that, you don't work at a frontier lab, and you don't have infinite tokens. So immediately, you have reason to be skeptical. You might think:\n\n*\"PR count is a useless metric anyway. What matters is getting the* right *things done, not as many things as possible.\"*\n\n*\"We don't even have 100 tickets in our backlog to feed those 100 PRs.\"*\n\n*\"AI is smart, but way over-complicates code when a 1-line change would do. All those PRs are probably garbage.\"*\n\n### The dream for us all\n\nAnd yet, many of us have projects that are **yearning** to see the light of day.\n\nProjects that – if only we could get through the hump of finishing them – could actually see and delight their first user. You out there with an ambitious side project and only 1 hour a day to work on it: I'm talking to you.\n\nAI promises 100x productivity benefits. And by tapping into this un-imaginable power, we can get to the finish line far sooner rather than later.\n\nBut how?\n\nHow do you use AI to do your job that quickly, without sacrificing quality?\n\nHow much of this AI stuff is BS, and how much isn't?\n\n### How you can do the same\n\nThis phenomenon is real.\n\nPeople really are shipping 100x faster – without sacrificing quality.\n\nAnd the rest of this article walks through 3 principles:\n\n1. **Internalize** . Develop an intuition for how coding agents work.\n2. **Understand** . Establish your development process's baseline.\n3. **Accelerate** . Systematically improve each step of your process.\n\nThat together help you accelerate your team's output.\n\nBy the end of this article, you'll be mentally equipped to transform your own coding setup into a PR-generating machine.\n\n## You wield an army of for loops at your fingertips.\n\nTo start churning out PRs with AI, it helps to understand what we’re working with.\n\nIf you've never seen it, a coding agent is essentially a for loop:\n\nYou give a coding agent a prompt. It reads the codebase, then thinks and uses tools until it comes up with a final response. All the meanwhile, it gives you chat feedback while it's working.\n\nThe two key things to internalize are:\n\n1. **You set the for loop's condition** . Implicitly, you are asking the agent to keep running while your request hasn't been satisfied.\n2. **You aren't limited to one** . You can run multiple agents in parallel.\n\nA lot of people start using AI by prompting one agent at a time, then waiting for that single agent to respond before continuing. But to maximize your productivity gains from AI, you should exercise your ability to multiple agents in parallel (within sane limits, of course 🙂).\n\nThe easiest way to start running multiple agents in parallel is to use git worktrees:\n\nOpen a new chat session, and in each one, choose \"New Worktree\" (or an existing, unused worktree) as the option. Each chat session then runs in its own directory that has been cloned from the original repo, yet still remains part of the same git repository:\n\nI find that it helps to name each of your chat sessions to help you remember what each session is doing:\n\n## Codify your process.\n\nEvery team I've ever worked on uses JIRA (or some other Kanban board), and for good reason:\n\n*JIRA provides a shared mental model of how work is completed and verified.*\n\nThus, it's critical to clarify your software development lifecycle (or SDLC) if you want to multiply your productivity with AI, because standardized process leads to standardized outputs for your agents.\n\nTo take an example, here's the process that I've been using for the past few years:\n\n1. **Todo** . Your backlog. This column might contain Epics (big features of work that require product and system design before further breakdown). It might contain bug reports. Or it might capture internal work, such as refactoring, or updating docs or configuration.\n2. **In Progress** . Actually implementing the ask in the ticket.\n3. **Tech Review** . Tickets must pass your project's code review policies.\n4. **Needs Verification** . Tickets must be verified end-to-end in the deployed build by QA or production staff.\n5. **Verified** . Tickets have been verified in the current build by a teammate.\n\nWith 2 explicit stages of review (Tech Review and Needs Verification), this pipeline **builds quality in** by definition, so we know we aren't churning out slop. You should ensure that your process has something similar:\n\n## **Measure your baseline.**\n\n**Measure your baseline.**\n\nIt then helps to uncover your team's current throughput. In other words, how many PRs is your team getting done?\n\nRun the following prompt:\n\n[*Gist link*](https://gist.github.com/nucleartide/6df6f714d884d4c02e2f8c25691d47e3)\n\nAnd you'll get a chart similar to this one:\n\nThis chart gives you a baseline of output to work with. Given your process, and given your current level of output, the goal becomes to systematically improve each stage of your process.\n\nAnd you do so by carefully considering how agents can automate each step:\n\n## Use agents to curate your backlog.\n\nAt work, I made an `atlassian-api` skill that gives an agent read-write access to my team's JIRA board (as well as Confluence docs).\n\nWhether you use JIRA or Linear or some other project management system, **give your agents API/CLI access via an agent skill**. Make it effortless for them to curate, prioritize, and update tickets on your behalf.\n\nThis enables a bunch of tiny, automated enhancements to your workflow:\n\n1. **Bug reports** . You might set up some Slack automation, such that messages that arrive in a \"product-qa\" Slack channel are triaged, and valid issues are automatically converted into bug report tickets.\n2. **Task breakdown** . Have AI analyze a product or system design spec, and break down the tasks into concrete, prioritized tickets on your board.\n3. **Filling in ticket descriptions** . Have AI revise ticket descriptions to be optimally formatted for a coding agent, pausing for human input if there are insufficient details.\n4. **Task capture** . When doing chores such as refactoring, configuring CI, updating dependencies, or revising documentation, craft a \"/make-ticket\" skill that allows your agent to author tickets on your behalf.\n\nThis is the input to your PR machine, so it's important that the quality of these inputs is high.\n\n## Curate architecture docs for every section of your codebase.\n\nPrompt your agent to create an AGENTS.md that acts an index to further documentation in your `docs/` directory.\n\nThen, make sure that a section exists for each and every sub-system in your codebase. Here's an example for a Unity project:\n\nHave AI interrogate each subsystem's owner:\n\n*\"Please interview me on how the architecture of this system is set up.**Ask me about the interfaces, dataflow, and conventions. Then please update the corresponding documentation in our docs/ directory.\"*\n\nFor example, you might clarify such things as:\n\n1. The Model-View-Presenter pattern for game UI.\n2. Your project's UI design system and design language.\n3. Instructions on how to author and manage database migrations.\n4. Three-tier architecture for APIs, business logic, and your data layer.\n5. Conventions for authoring animations by hand or with code.\n\nFinally, instate a `.github/CODEOWNERS` file so that subsystem owners can hold the team accountable, and to keep architecture docs up-to-date.\n\n(It may help to copy the entire previous section into an agent prompt to help set up your repo's documentation harness.)\n\nArchitecture docs are critical for quality results. In absence of these clear conventions, AI is all too willing to imitate adjacent code, which may not always be what you want.\n\n## **Play prompt golf by crafting AI skills.**\n\n**Play prompt golf by crafting AI skills.**\n\nOnce you've established architecture and conventions, the key to multiplying your team's output is to **ensure that a ticket's work can be done in a single prompt**.\n\nIdeally, it should take one prompt to go from JIRA backlog to an implemented, tested, and ready-to-merge PR:\n\n**If you're still clicking around in Unity (or generally, your coding environment), there is potentially still more to automate.**\n\nAny time you catch yourself doing this, think of how you can revise your AI skills so that your manual action can be delegated to an agent.\n\n### **Third party skills**\n\n**Third party skills**\n\nAlthough there are plenty of third party skillsets out there, I'm not sure they always help since every project is unique. It's best to refine your project's skills around your unique architecture rules and repeated actions.\n\nHere are some example skills extracted from the prompts that I've been writing over and over. These skills have enabled me to prompt an agent to address a ticket in my backlog in one go, and have that work run autonomously to opened PR without any of my input:\n\nRather than write code directly, software development becomes a different, but still interesting exercise:\n\n*How might I standardize my development process so that agents can work on my behalf?*\n\nIn business, they call these SOPs (or Standard Operating Procedures). Think of a food service establishment like a McDonald's: they are able to staff their kitchens with relatively little training because their process has been so standardized and refined.\n\nFocus on standardizing *your* process so that agents can carry your work out.\n\n## Develop an eye for loops in your work.\n\nInstructing agents effectively is an exercise in answering 2 questions:\n\n1. **Definition of done** . What is it? Be precise.\n2. **Self-verification** . How can an agent self-verify that a task is done?\n\nThis is the key behind all those people saying that their agent ran for hours and hours. It's really that simple.\n\nBut here are some examples to illustrate the idea:\n\nThink of Cursor's Debug Mode, which basically boils down to:\n\n*\"Instrument this code path with logs, then invoke that code path to investigate what happened. Keep on going until you uncover the issue. When you do, fix the issue, invoke the code path, and confirm that the issue has been remediated.\"*\n\nThen, think of the performance equivalent:\n\n*\"Profile this code path to set a frame time baseline, then make changes and re-profile. Keep on going until we've fulfilled our frame time requirements.\"*\n\nWhen you recall that agents are just loops under the hood:\n\nAssigning loops to agents lets you take advantage of their built-in behavior.\n\n## Feed code review comments back into your harness.\n\nFor many teams, I'd guess that human code review remains the biggest bottleneck. It certainly is for our team.\n\nI'd argue that decisions that change architecture must always be reviewed by their respective CODEOWNERS to ensure the system (as a whole) doesn't go off the rails.\n\nBut even so, we can speed up what we can. For run-of-the-mill PRs, there's nothing particularly special about a human's feedback. If the PR:\n\n- Doesn't introduce new architecture or design new systems (that’s your job to design and oversee).\n- Follows the existing architecture.\n- Keeps changes modular and isolated.\n- And passes all static analysis that you throw at it (linters, compilers, Roslyn analyzers, code formatters).\n\nThen PRs should be quick to skim and check off. ✅\n\nTo reach this minimal review state, it helps to feed your *manual* code review comments back into your code review agent's instructions. Prompt your agent to read your PR comments (via the `gh` CLI), and revise your in-repo agent documentation and code review instructions in response:\n\nYour code review agent (such as GitHub's Copilot or Cursor's Bugbot) will then catch more and more issues in automated review.\n\nOver time, you'll find yourself having fewer issues to point out in AI-generated PRs, and greater trust in your agent review system.\n\n## Automate end-to-end testing with feature maps.\n\nYou might think that end-to-end testing a feature is the only step that still requires human input. But these days, even end-to-end QA can sometimes be automated.\n\nHere's an example.\n\nI use [Unity CLI](https://docs.unity.com/en-us/unity-cli/use-unity-cli) at work. (If you're not working in Unity and instead building a web or mobile app, the tooling is different but the ideas remain.)\n\nAnd these days, Unity CLI enables your agent to send button tap commands to the Unity Editor, to enter/exit Play Mode, and to tick game time forward in desired increments.\n\nIf you complement those capabilities with:\n\n1. **Test selectors** . Tag specific click or input targets with identifiers so that they can be looked up programmatically, and\n2. **Feature maps (credit to** [Lauren](https://x.com/poteto)**)** . Write `<X>FeatureMap.md` instructions for interacting with UI in a standalone scene. These files live alongside their UI scripts, and serve as living documentation.\n\nYou have all the tools needed to start automating your QA process.\n\nThat leaves true, exploratory testing for human QA, which remains valuable even after you've automated the known paths of your product's UX.\n\n## Implications\n\nIn spite of all these techniques, AI won't be perfect.\n\nYou'll still need to (at times) micromanage your agents, scrutinize their traces, and continuously refine your documentation to achieve your desired outputs.\n\nBut this is liberating. We don't need to write code by hand anymore. We don't need to master the minutiae of syntax, or sink hours into debugging a segfault.\n\nIn many ways, **we're not in the coding business anymore, but in the managing business**. [Lauren](https://x.com/poteto) (of Grok Bot fame) likens agent management to overseeing a Michelin kitchen; I liken it to being a nice Gordon Ramsay, gently nudging your agents along the right path.\n\nWe don't do the cooking, but we write the menu and decide the end-user experience. I think that's what we wanted all along.\n\n## Takeaways\n\nTo recap, by developing an intuition for a coding agent's pseudocode and your process:\n\n1. **You wield an army of for loops in your fingertips.**\n2. **Codify your process, and establish your baseline.**\n\nAnd by systematically improving each step of your process with AI:\n\n1. **Use agents to curate your backlog.**\n2. **Curate architecture docs for every section of your codebase.**\n3. **Play prompt golf by crafting AI skills.**\n4. **Develop an eye for loops in your work.**\n5. **Feed code review comments back into your harness.**\n6. **Automate end-to-end testing with feature maps.**\n\nYou can make a serious dent, empower your team to become a PR shipping machine, and build that much faster for your product's users:\n\nIf you try any of these techniques, I'd love to know how it goes. Just drop a reply in the article's comments.\n\n*Hi, I'm Jason. I'm a senior engineer at MLB building an unannounced, multiplayer, PvP mobile game. On the side, I build Navi: an app that helps people with type 1 diabetes manage their blood sugar.**This article was originally presented to my coworkers to teach my AI workflow. All work-specific details have been scrubbed, and opinions are my own and do not reflect my employer.**If you liked this article, follow me for more articles about my 0-to-1 startup journey.*", "url": "https://wpnews.pro/news/a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day", "canonical_source": "https://twitter.com/nucleartide/status/2104508871641350612", "published_at": "2026-09-28 09:57:50+00:00", "updated_at": "2026-09-28 10:17:34.344903+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["JIRA", "git worktrees"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day", "markdown": "https://wpnews.pro/news/a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day.md", "text": "https://wpnews.pro/news/a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day.txt", "jsonld": "https://wpnews.pro/news/a-software-engineer-s-playbook-to-go-from-single-digit-to-100-prs-a-day.jsonld"}}