A coding agent finishes a change. It has planned the work, written the code, run the tests, and opened a pull request, all within minutes. Under the usual model, this is where the change sits, waiting for a person with enough time and enough confidence to merge it. That wait can stretch for days.
Hud‘s newly launched agentic rollouts are designed to keep that change moving. The capability lets coding agents take a change from pull request to production while Hud checks every step against how the code actually runs. Following a single change through the process shows how it works.
The Pull Request Opens
Before anything merges, Hud examines the pull request. It compares the change against a production impact map built from real parameters and real code flows drawn from production itself, then classifies the change’s production risk level.
If the change is safe, it can proceed at the pace the agent wrote it. If it is risky, Hud attaches clear context about the concern, so whoever reviews it can work through the change faster. This is the point where the change would normally stall. With Hud’s analysis in hand, it does not have to.
All of this depends on data Hud has already gathered. Its runtime code sensor, installed with a one-line SDK, has been automatically learning the baseline behavior of the team’s backend code at the function level.
The Merge and the First Traffic
The change merges, and the new version starts receiving production traffic. Hud watches closely, comparing how each function behaves in the new version against the learned baseline, continuously.
If a regression appears, Hud catches it immediately. Because it is watching at the function level, it can name the root cause and identify the exact pull request responsible. That precision points directly to what needs fixing.
When Something Goes Wrong
Suppose the change does introduce a regression. Hud’s context makes it possible to roll back the release, revert the change, and fix the underlying issue.
The coding agent is part of this step too. It receives deep context about what happened, so it can avoid repeating the same mistake. The agent that wrote the code learns from how that code behaved in the real world. Recovery and the lesson arrive together. That deep context is what lets the software factory fix the underlying issue and learn from the regression.
At the end of the journey, the team knows the production-level impact of the change before, during, and after its rollout. Hud calls the whole process an agentic rollout: a rollout built for agents.
Agentic Rollouts at Riverside
Riverside, the platform for recording and editing studio-quality audio and video, runs every deploy through Hud’s agentic rollout. The company ships fast with AI, and much of its backend is real-time media code that only shows its true behavior under production load.
Each deploy goes through a canary, with Hud’s agentic rollout and automatic rollback. Flawed deploys are detected quickly and reverted in about eight minutes, usually before a customer notices.
“Our engineers use AI agents every day, and writing code is no longer the bottleneck. The real challenge is shipping that code to production with confidence.”
That is how Shilo Magen, VP of R&D at Riverside, describes the starting point. He went on: “For a real-time media platform like Riverside, even a small regression can have a major impact on the user experience. With Hud, we can automatically detect regressions and roll back problematic releases in minutes. Our engineers now spend less time worrying about deployments and more time building.”
Why the Journey Used to Stall
Every engineering team is working toward an AI software factory, and the early stages of that factory now run quickly. The later stages have not kept pace. Coding agents have depended on human-driven validation to reach production, which increases time to delivery and reduces productivity. Agents cannot see production, so their pull requests wait for a reviewer willing to merge, approvals come from people short on time, and someone has to keep an eye on dashboards after each deploy. The fastest part of engineering ended up feeding directly into the slowest, and every team adopting AI ran into it.
The data reflects this. Faros AI’s 2025 vendor survey found that teams with high AI adoption merge 98% more pull requests, with pull request review time up 91%. Engineers who use AI heavily produce about twice as many pull requests, each taking about twice as long to review. Harness’s 2025 vendor survey found that only 6% of organizations describe their continuous delivery as fully automated.
Roee Adler, Co-Founder and CEO of Hud, explained what the journey has been missing:
“AI already changed how code gets written. The bigger problem now is getting that code into production safely, at the speed agents write it. Every engineering leader I talk to is trying to solve this problem. Coding and triage have agents, but the merge and rollout still run on people, because it’s scary to give coding agents accountability over the stability and reliability of the production environment. That’s the missing link in the AI software factory, and it’s the problem we built Hud to solve. With agentic rollouts, agents and engineers work from the same runtime context, at the function level, so a change is merged to production based on evidence. When something does regress, it’s immediately detected and fixed, but more importantly the agent that wrote it gets a feedback loop to learn and improve.”
The Next Change
The story continues past a single rollout. Each one teaches the coding agent how its changes behave in production, so the next change it writes ships with less risk than the last. The agent learns from how its earlier changes behaved once they shipped.
