Inside Ro’s AI Hackathon: What 150 Builders Did in Three Days

I’ve been Chief of Staff to Ro’s Tech Org for six years and part of Ro since Day 0. From the beginning, I helped shape the organizational blueprint for the tech team, establishing its operations, processes, and culture as we scaled from 15 to 150+ people. As our business evolves to meet the changing needs of our patients, we have to be just as intentional about evolving how we work.

One of the most deliberate ways we do that is through our twice-yearly onsites, where we bring together our engineers, product managers, data analysts, designers, and cyber folks for three days away from their roadmaps to chase ideas that don't fit into the day-to-day. This is an opportunity to build something creative and reinforce the camaraderie that carries us into the next half. Each onsite is uniquely designed around what the org needs at that moment. No two have ever looked the same because no six months at Ro have ever looked the same. What follows is the story of our most recent onsite and the work that emerged from it.

We focused on how we build and the software development lifecycle itself. It’s one of the hardest areas to plan for because it supports the roadmap rather than being an explicit part of it. Our team is responsible for both building for patients and architecting the development pipelines that allow us to move quickly at scale.

Anyone who has shipped software knows the overhead involved, whether it’s an afternoon lost to spinning up a test environment, a release stalled by manual coordination, or a review delayed because a service expert isn’t online. This all takes time away from building and creates opportunities for mistakes. By automating manual steps and capturing knowledge that otherwise lives in people’s heads, we can make quality and safety more consistent.

We approached AI implementation with a focus on improving quality, range, and accuracy by 10x before prioritizing speed. We had conviction that when work is accurate by default, speed follows naturally.

When we grouped what people built during the onsite, three areas of investment emerged—spanning architectural foundations, development tooling, and safety guardrails. Here are the standouts:

Development risk detection and standards

How to catch a risky change before it ever ships, and turn the tribal knowledge of what tends to break into something a machine can read? PR Blast Radius.

How it works: The team built a skill called “ripple check.” You hand it a GitHub PR URL, and the first thing it does is determine what kind of change it is actually looking at. From there, it launches only the specialized agents that change warrants instead of running every check on every PR. Instead of judging a schema change in theory, the migration agent cross-references it against real-world system usage to understand how the affected infrastructure is being used in production. Then, a front-end agent scans for known risk patterns. Everything the agents find lands in a single, digestible report with a risk verdict, confidence level, and a ranked list of the acceptance tests needed. This tool continues to sharpen as we feed our incident history into it. We describe it internally as a “linter” for our tech, catching the kind of high-level risk that syntax checks never could.

Why this matters: The real value turned out to be less about the tool itself and more about what it revealed. Over the past year, the number of PRs opened has jumped more than 70%, while median time-to-merge has grown roughly 2.5x. This reflects how much more the team is shipping now that agentic tooling is embedded in daily work. Keeping review in step with that pace means meeting agentic code with agentic review. Ripple check was our first real move in that direction. Building it also forced us to define what a good review looks for and codify the system-specific knowledge that had previously lived in a handful of people’s heads. What we learned was clarifying: generating feedback is the easy part. The harder, more contextual judgment is deciding what’s actually worth saying. That’s where a reviewer either earns or loses trust.

Where it stands: Pieces of ripple check are already running in production, and the thinking it forced has since grown into a dedicated AI PR reviews initiative. It’s now a more robust, composable review agent that routes each pull request to the checks its diff actually warrants and goes after the high-level issues linters and type checks miss. Every review it runs creates trajectory data we can use to improve the system around our own review needs over time, rather than keeping it static.

Shout out to Dheeraj Sayala, Alexandra Hoefinger, Irene Hui, Max McKinley, Kimberly Ha, and Dan Shultz.

AI infrastructure: foundational capabilities

How to build with AI without duplicating efforts, namely where an agent runs, how it proves who it is acting for, and what it is allowed to touch? Zero.

Zero moves coding work into the background. You hand a task off and review the result, instead of babysitting a session on your laptop. There is far more to say about Zero than one section can hold (stay tuned for a dedicated blog). For now, what stood out was how far the team got in three days. 

How it works: Getting an agent to safely do real work against our systems is genuinely hard. It needs enough access to actually change things without having access to everything. It needs a clear record of who authorized it to act and a human still needs to be accountable for whatever ships. By the last day, our team had the entire loop running end-to-end. An engineer kicks off a task, Zero works in a temporary, tightly controlled environment with limited permissions, and the engineer can follow its progress as it goes. When Zero finishes, it pushes its work to a branch for a human engineer to review and ultimately decide what ships. 

Why this matters: Building that in three days provided a working proof of concept for something most teams would scope as a multi-quarter bet. This is what turned Zero from a promising idea into a funded build.

Where it stands: The team is already onto the harder problem of session handoff: carrying context cleanly between a local session and Zero and back. Solving it could let someone kick off work on their laptop and hand it to Zero to finish overnight. It could also allow Zero to keep iterating on a pull request as review comments land, picking up right where it left off.

Shout out to Tiffany Major, Alexander Selz, Michael Folino, Remi Dymecki, Ryan Klingaman, and Clem Huyghebaert.

Eliminating end-to-end lifecycle friction

How to take the most time-devouring chores out of the development cycle? The most painful one is the on-call investigation, where a single tricky ticket can eat an engineer's afternoon. Enter Velma—named after the one Mystery Inc. team member who actually solved the mysteries while everyone else chased ghosts.

How it works: We get a steady stream of tickets when a patient hits a wall in one of our apps. The root cause can hide across several systems at once. Velma takes the first pass at investigating. Its secret sauce is the methodology baked into it: the same triangulation a senior engineer runs on instinct. It brings together signals from across our systems and codebase to reconstruct what happened, trace the issue back to its likely source, and hand the engineer a root-cause report with a confidence score and the evidence behind it.

Why this matters: Plenty of external products can help investigate an issue. What they don't have is context on how our systems connect. That context is the whole game when it comes to triage. It's also exactly the kind of knowledge that usually lives in a handful of senior engineers' heads. Codifying that methodology into Velma gives broader access to it and helps engineers across the org get to the actual problem faster.

Where it stands: Velma has been in production for a few months now. It's been running first-pass investigations across different domains and taking investigations that used to eat an afternoon down to twenty or thirty minutes. It lives directly in the tools our engineers already use, so there is no new workflow to learn. A select group of us lean on it day to day, and it has earned enough trust for us to keep investing in its capabilities and the safeguards around it as we expand its use.

Shout out to Sahil Gupta, Andrzej Dybionka, Kwok Leung, and Maciej Pasternacki.

None of this is an accident. The roadmap is the visible part of the work. The technical craft underneath is what actually carries us toward it. It's where our people spend their days. We put real intention into making that experience genuinely delightful, wiring it into our environment, tools, culture, and processes. When building here feels fast, safe, and low-friction, people do their best work. That energy flows straight into the care we are here to deliver for our patients.

The onsite is the most concentrated form of that investment. Some of these projects had been in the works for a while. The onsite finally gave the team room to build them out fully rather than squeezing them into the margins of a busy week. We invest in this time because building this way is how we keep learning what our patients need and staying a step ahead of it. None of it ends when the onsite does. Those investments carry on in parallel with the roadmap, so every product we ship leaves behind sharper tools for building the next one. We rarely tackle the same problem the same way twice. The platform underneath keeps compounding and driving our scale as much as any product strategy does.

If you want the freedom to look beyond the roadmap and tackle the hard problems that make everything else possible, come build with us!