The 10x engineer: autonomous backlog execution with Ona Automations
Ona's Automation that ships code, cleans tech debt, and fixes vulnerabilities — all before the team has had their morning coffee.
What if your backlog started solving itself overnight? Here's how we at Ona are clearing our backlog using an Automation that picks up tickets, writes code, and has a PR ready to review before the team starts work. If you want to use it yourself, copy it from the Ona Template Library.
The problem
Every engineering org has the same dirty secret: a backlog full of tickets that will never get touched.
Not because the work is hard, most of it is pretty straightforward. Backend refactors, small bug fixes, incremental improvements, minor feature requests. The kind of work a mid-level engineer could knock out in a few hours. But it never gets prioritized because there's always something more urgent. It sits there, accumulating, while the team fights fires and ships roadmap features.
The backlog comes from a lack of time, not planning failure. There's more work than there are humans to pay attention to it.
The solution
Ona Automations can run on a schedule or trigger events, execute autonomously in secure isolated environments, and work through multi-step tasks from ticket to pull request. That's all you need to point an AI software engineer at your backlog and let it work.
Here's how it works.
How the automation is configured
The automation runs on a daily schedule (at Ona, it's set to 7am). Each run follows a simple loop:
1. Scan the backlog. The automation reads open tickets from your project management tool (Linear, Jira, or others via integrations) and evaluates which ones an AI software engineer would be capable of handling.
2. Self-assess capability. Not every ticket is a good fit. The automation filters based on criteria that predict success: Is this primarily a backend change? Does it require visual evidence or manual QA? Does the ticket have enough context to execute without asking questions? Tickets that don't meet the criteria are skipped.
3. Pick a ticket and execute. The automation selects the highest-priority ticket that passes the filter, spins up a secure ephemeral environment with full access to the codebase, and starts working. It reads the ticket description, pulls context from linked docs and code, makes the changes, and runs tests.
4. Open a PR. When the work is complete, the automation opens a pull request with a structured description linked to the original ticket. It's ready for human review.
The entire cycle happens without human involvement. No one has to select the ticket, prompt the agent, or monitor the run. The automation handles the full loop from backlog to PR.
What makes this work
Three things make autonomous backlog execution reliable rather than reckless:
Scoped autonomy. The automation doesn't try to do everything. The self-assessment filter is critical. By constraining the automation to tickets it's confident it can handle, you avoid the failure modes that make people nervous about autonomous agents. It's not picking up architecture redesigns or complex frontend work. It's picking up the straightforward backend work that's been sitting in your backlog for months.
Isolated environments. Each run happens in a fresh, ephemeral environment that's destroyed after use. If the agent makes a mistake, the blast radius is zero. Nothing touches production or persists. The only output is a PR that a human reviews.
Human review as the gate. The automation produces work and humans approve it. This is the same review process your team already uses for human-written code. The automation doesn't merge or deploy anything on its own. It opens a PR and waits.
Tuning the automation
Like any automation, this gets better with iteration. A few things we learned at Ona:
Start conservative with the filter criteria. Begin with only the most straightforward tickets: small scope, clear descriptions, backend-only, well-tested areas of the codebase. Expand the criteria as you build confidence in the output quality.
One ticket per run. It's tempting to have the automation pick up multiple tickets per cycle. Resist this initially. One ticket per run keeps PRs reviewable and makes it easy to trace issues back to their source.
Review quality, not just correctness. The automation might produce code that works but doesn't match your team's conventions. Use custom slash commands and AGENTS.md to teach the agent your codebase standards so output quality improves over time.
The result
At Ona, the team wakes up to a pull request ready for review every morning with their coffee.
This is what Ona Automations are built for: background execution, multi-step task completion, and autonomous decision-making from ticket to pull request. The backlog stops being a graveyard of good intentions and starts being a queue that an AI software engineer works through every day.
The question isn't whether your backlog has tickets an AI could handle. It does. The question is how long you want them sitting there.