Designing Automations: a new operating model for engineering at scale

Ona Automations turn cross-repository lack of standards and tech debt into a system that teams can understand and trust. It introduces a new operating model for orchestrating engineering work at scale, built on the reality that: engineers can fix individual problems quickly with AI. However, scaling those fixes across the entire organizations takes months of effort.

My name is Carl, and I'm a designer and engineer at Ona and this is the story of why and how we built Automations and the design principles that went into it.

Migration work slows teams down

Engineers using AI can now solve problems faster, but scaling those fixes across hundreds or thousands of repositories is complex. Solving this challenge has significant opportunity in saved time and reduced risk for organizations by automating away significant engineering toil.

This large-scale migration work is rarely glamorous, and includes chores like: version bumping, dependency updates, CI migrations, doc changes. These tasks might be relatively simple in one repository, but are a grind and a huge cost as they stretch across an entire organization.

These are problems that are individually simple, but collectively expensive.

This is the problem Automations was designed to solve.

The orchestration challenge

While AI has made writing and reviewing code easier, it has not yet solved large-scale coordination. In our early conversations with enterprise engineering organizations about the impact of AI, the same patterns kept appearing.

Technical friction showed up first:

• Brittle, one-off scripts
• Spreadsheets standing in for orchestration
• PR queues turning into black boxes
• CI migrations running long without clarity
• No single view of what was actually done

Human friction wasn’t far behind:

• Teams chasing updates across Slack
• Work that didn’t align cleanly with roadmap priorities
• Repeated nudges to keep everyone on track

The friction wasn’t being able to make changes, but orchestrating and rolling out those changes at scale. So our design question became clear: How do we collapse scattered engineering work into one mental model that feels trustworthy and predictable at any scale?

Building the interaction model

The breakthrough was reducing everything to a simple, predictable structure:

Trigger → Context → Steps → Report

This interaction model gives teams a consistent way to think about automation whether it touches one repository or thousands.

Triggers: define intent

Triggers set the intent. They describe the moment the automation starts:

• Manual triggers for fast iteration
• Scheduled triggers for hygiene and compliance
• Pull request triggers for automated review flows

We wrote the phrasing so it matches how engineers naturally think about work rather than how configuration files express it.

Context: defines what the Automation operates on

Context describes the surface area of the work, and it can be a single repository, a group of repositories, or an entire project. First you decide when an Automation runs, and then you also decide what context it runs on.

Steps: are 'the actual work'

Steps perform the changes of the Automation. Each repository in the scope gets its own execution path and isolated environment, which is what makes them predictable at scale.

Steps can include:

• commands
• prompts
• metadata lookups
• CI checks
• pull request creation

Some steps are fully customizable, while others are handled by Ona when the platform can make a faster or safer decision.

Reports: show status and progress

Operating parallel work at-scale needs an easy overview and summary. The Report view gives teams a single place to understand what happened, what succeeded, what failed, and what needs human review.

It focuses on:

• throughput across the scope
• failures
• linked pull requests
• execution metadata
• a clean, audit-friendly record

A good report should feel like the system walking you through the work.

Designing for scale

One of the hardest design problems we faced was psychological. How do you make an automation that touches thousands of repositories feel safe?

Listing every repository creates noise, but hiding them creates anxiety.

The design we chose focused on clarity and confidence:

• Show samples instead of overwhelming lists
• Surface summaries instead of clutter
• Use funnel patterns to show progression
• Highlight only what requires human attention

This shifts the mindset from “is this safe” to “I understand exactly what is happening" and is where design proves its value.

Pull request triggers needed a new UX language

Traditional pull request tools assume a one-to-one relationship. One pull request, one review, however Automations needs to support many-to-many. So, we designed a new interaction model to make that possible.

“Runs when…”

Instead of asking teams to write filters or configuration strings, Automations lets them describe intent in plain language: “Runs when a pull request targets the main branch and modifies package.json.”

Ona then generates the correct GitHub or GitLab filter and shows both sides of the definition. Natural input, precise output.

Webhooks without anxiety

Webhook setup is often the moment where things start to feel complex for the user. We built the webhook integration as a short guided sequence with clear explanations, safe defaults, and simple copy actions.

This keeps setup fast, predictable, and safe.

Safety as a design constraint

When an automation can open or modify pull requests across thousands of repositories, safety has to be designed in from the beginning.

We treated safety as a core part of the interaction model:

• Execution limits
• Environment selection
• Rollback paths
• Reviewer assignment
• Automation toggles
• Clear ownership and metadata

AI handles the labor, whereas Humans stay accountable.

Design is what makes that balance feel trustworthy.

What are our customers doing with Automations today?

Our customer teams are already using Automations to:

• Migrate CI systems
• Update languages and frameworks
• Patch CVEs at scale
• Standardize development environments
• Generate and review hundreds of pull requests across large codebases

Work that once required quarters of planning can now happen in days. Teams are reducing coordination overhead, eliminating repetitive cross-repo work, and freeing engineers to focus on problems that actually move the business forward.

The strongest indicator has been the shift in how teams talk about their engineering time. Instead of burning weeks coordinating mechanical work across repositories, they can point Automations at the problem, stay in control, and move on. This is the type of outcome design should push for. Not just a cleaner UI, but a real change in how organizations operate.

From the 'first hill' to the 'second hill'

We have a value at Ona which is to 'climb the next hill'. With Automations we've given our customers a new capability to create change at scale. Automations today is our 'first hill'. It is the design approach, the language, and the guardrails.

The 'second hill' may cover large-scale code review, deeper refactoring patterns, agents collaborating with humans inside real environments, and clarity as the interface between engineering teams and AI-driven operations

Design is the foundation for all of it. It keeps complex systems usable, understandable, and safe at a scale engineering teams have never had before.

If this resonates with you, we'd love to show you how it works.
You an also find me on LinkedIn.