How Ona's engineering team ships features end-to-end. From spec to merged PR.
Most engineering time isn't spent writing code. It's spent on everything around the code: planning, ticket creation, dependency mapping, PR formatting, review cycles. Here's how to collapse that workflow using Ona, and where Automations can take you next.
Feature delivery is slow, and the bottleneck usually isn't the coding.
A typical feature goes through a predictable cycle: someone writes a spec, someone breaks it into tickets, tickets get assigned and sequenced, engineers pick them up, write code, open PRs, format descriptions, link tickets, request reviews, address feedback, and merge. Each handoff introduces latency. Each manual step is a place where context gets lost.
For engineering leaders, this is especially painful. The people with the most product context are often the ones with the least time to act on it. They know exactly what should be built and how, but their calendars are full. The work sits in a backlog waiting for a block of focused time that never comes.
Features that should take days stretch into weeks. Not because the work is hard, but because the process around the work is slow and manual.
Ona collapses the spec-to-shipped workflow into a continuous loop where AI handles the process and humans provide the judgment. The interactive agent handles planning and execution. Ona Automations handle everything that doesn't require a human in the loop.
Ona's agent works in spec mode, where you describe a feature in natural language and the agent asks clarifying questions until the approach is solid. It pushes on edge cases, permissions, dependencies, and implementation details.
The output is a structured Markdown plan. Using the Changes tab in Ona, you can review the rendered plan side-by-side with the raw text, making it easy to scan and approve.
This replaces the typical cycle of writing a spec doc, circulating it for feedback, revising, and then manually translating it into tickets. The plan is the spec, and it's already structured for execution.
Once the plan is approved, a single prompt tells Ona to create a project in Linear (Jira is also supported) with all tickets and dependencies mapped automatically.
The tickets aren't half-baked. They include detailed descriptions, acceptance criteria, and dependency relationships so the agent (or a human) knows what to pick up next and in what order.
This eliminates the manual work of creating, describing, and sequencing tickets, work that typically falls on a tech lead or PM and can take hours for a mid-sized feature.
With the project created, Ona picks up the first ticket and starts working. It writes the code, runs it in a secure ephemeral environment with full access to the codebase, and moves through tickets sequentially, respecting the dependency chain.
Engineers can review output between other work. They don't need to context-switch into the codebase or set up a local environment. They review what the agent produced, provide feedback if needed, and the agent continues.
Up to this point, a human is still driving the workflow. This is where Ona Automations start removing humans from the loop.
Standardized PRs via custom commands. When work is ready to push, custom slash commands handle the PR formatting. At Ona, the team uses a command that removes obvious comments, runs formatting, applies PR templates, links the ticket, and generates a detailed description. Every PR follows the same structure, regardless of who or what wrote the code. Reviewers always know where to look and what to expect.
Automated first-pass review. Before a human reviewer ever sees the PR, an Ona Automation runs an automated code review. It checks for common issues, adherence to standards, and potential problems. If something isn't ready for human review, the automation catches it first. Human attention goes only to the decisions that require judgment: architecture, logic, and edge cases.
Event-triggered quality gates. These automations are triggered automatically on PR creation. No one has to remember to run them. No one has to configure them per-PR. They run on every PR, every time, as part of the Automations pipeline.
This is the key shift: the interactive workflow gets you from spec to code. Automations handle everything between code and merge.
The full cycle from "I want to build this feature" to "there's a PR ready for review" can now happen without a single dedicated block of focused engineering time. Planning happens in conversation, tickets create themselves, and the agent executes. Automations then format, review, and gate the output before a human ever looks at it.
At Ona, this workflow has become the team's default. It's a core part of how the engineering org reached 10.8 PRs per engineer per week while maintaining a low change failure rate.
And this is just the starting point. Once teams are comfortable with automations handling PR formatting and review, the natural next step is autonomous backlog execution: automations that select tickets, write the code, and open PRs without any human involvement at all. The interactive workflow described here is how you get started. Automations are how you scale it.
This website uses cookies to enhance the user experience. Read our cookie policy for more info.