Learn how we leverage Ona Automations to be in the 99th percentile of engineering productivity.
Our engineers average 10.8 pull requests per week, roughly 2.5× the 90th percentile. That performance is the result of a system.
It took us two and a half years to ship our first 10,000 pull requests. At our current pace, we'll ship the next 10,000 in under a year, while keeping change failure rates low and mean time to recovery fast.
We didn't hire a larger team to get there. We rethought where human attention belongs in the SDLC and used Ona Automations to handle everything else.
If you aren't sure where to start, or what is even possible to automate, we collected our team's favorite automations and put them in the Ona Template Library for you to use.
I spend close to 40 hours a week in meetings, my calendar is pretty disgraceful. But I still ship features end-to-end while context-switching between calls. This is not unique to me. The whole team operates this way now.
The principle we drove across the org is simple: if a task doesn't require human judgment, automate it. Not one automation. A fleet of them, each handling a different stage of the lifecycle, running 24/7 in the background.
Planning the structure of a feature requires judgment. Deciding what to build requires judgment. Breaking a plan into tickets, formatting a pull request, checking if docs are up to date, closing stale PRs, cleaning up dead code? None of that does. It just requires attention, and attention is the scarcest resource in any engineering org.
The compound effect of automating all of it is what drove the step change.
I use Ona's spec mode to plan features through conversation. I describe what I want to build, Ona asks hard questions until the approach is solid, and the output is a structured Markdown plan. From there, Ona creates a Linear project with tickets and dependencies mapped out automatically. Each ticket has explicit scope, tests, and stopping conditions, so the agent can't wander or expand the blast radius. Then the agent works through the tickets one by one.
The whole team uses this as the default way to plan and deliver work.
We have an engineer named Anton who writes exceptional PRs and gives thorough reviews. Instead of hoping everyone adopts his habits, we encoded them into slash commands that the whole team runs on every PR. We also run automated code review before a human ever looks at the code. If an AI can catch it, a human doesn't need to.
Every PR that reaches a reviewer across our team is already clean, well-described, and linked to its ticket. Human review time goes to architecture and logic, not formatting.
This is where automations deliver the most unglamorous but compounding value. We run a fleet of background automations that keep the codebase healthy without anyone thinking about it.
Stale PR cleanup. Closes any PR older than two weeks with no activity.
Feature flag removal. Checks whether flags are still in use, confirms it's safe, and opens a PR to clean them up.
Documentation maintenance. Scans the codebase daily, detects when code changes have made docs out of date, and opens PRs that match our tone of voice. Customers have told us unprompted that our docs have gotten noticeably better. This is why.
CVE remediation. Runs Snyk scans, feeds the output to an agent, and iterates until all vulnerabilities are resolved. Not just the first pass. All of them.
None of these are exciting on their own. Together, they're why our codebase stays healthy at scale. Removing noise is a boring thing that humans hate doing. AI is incredibly good at it.
I built an automation I call "the 10x engineer." Not because it replaces humans, but because it compounds work we'd otherwise never get to. The automation runs every morning at 7am. It scans our backlog, picks a ticket it's confident it can handle (backend-focused, no visual evidence needed, mid-level complexity), writes the code, and opens a PR.
By the time I've had my morning coffee, there's a pull request ready for review. I didn't select the ticket. I didn't know what it was. I just review and merge.
Right now, a human still writes the initial spec and reviews the final output. Everything in between is increasingly handled by automations.
This year, we expect to get to a position where an engineer writes a plan, goes to bed, and wakes up to a completed feature ready for review.
It took us two and a half years to drive 10,000 pull requests. If we keep this velocity up and add a couple more people, we'll do the next 10,000 in six months.
We didn't get here by making individual engineers marginally faster. We got here by deploying a fleet of AI software engineers across every stage of the SDLC, running 24/7, handling the work that doesn't need human judgment so our humans can focus on work that does.
Everything described here, we built with Ona. The same automations, the same infrastructure, the same approach. It's available to your team today.
Check out our Ona Template Library to browse our favorite automations.
Tell us what you want to automate, and we will help you build it.
This website uses cookies to enhance the user experience. Read our cookie policy for more info.