Delivery Hero’s Herogen: when autonomous software delivery becomes a production system

The platform had to standardize control without erasing local autonomy.

Delivery Hero operates a decentralized technology landscape across subsidiaries serving roughly 65 countries. Local autonomy supports market speed, but it also makes a single prescribed coding environment or model difficult to scale across the organization.

The company established a shared AI access layer instead. LiteLLM operates as a model proxy through Google Cloud, allowing engineers to reach Claude and Gemini from their preferred development environments. The central platform governs access and availability while engineering teams retain model and workflow flexibility.

Implementation and verification are deliberately separated.

Herogen uses Claude as the primary coding model. Gemini participates in a council of agents that reviews the resulting code and performs security checks. This assigns different models distinct responsibilities instead of asking one model to generate, justify, and approve its own work.

The architectural lesson is broader than vendor choice. Independent review reduces correlated failure risk only when the reviewer has a separate instruction set, access to relevant evidence, and authority to block promotion. Model diversity is useful; control separation is the actual design principle.

• A shared proxy provides a governed model-access plane.
• The implementation model owns bounded code-generation work.
• Independent models review quality and security evidence.
• Existing CI and repository controls remain the promotion boundary.

Herogen is designed around complete work units—not autocomplete.

The agent can take a Jira ticket, write code, run tests, and review its own output. Delivery Hero reports using it for work that spans more than 50 files, changes across fleets of repositories, and design-system updates touching roughly 100 components.

That scope changes the unit of engineering automation. The relevant object is no longer a code suggestion; it is a traceable delivery packet with an originating ticket, repository changes, test evidence, review findings, and a production decision.

Throughput matters only when paired with production evidence.

Google Cloud reports that Herogen creates and merges more than 170 pull requests each day and accounts for over 10 percent of Delivery Hero’s pull-request volume. Adoption in the first quarter of 2026 reportedly exceeded assumptions by 18 times.

The more important control metric is the reported 85 percent success rate for tickets merged to production. That figure still requires careful interpretation: enterprises should define what qualifies as success, the observation window, defect severity, rollback frequency, and the share of changes requiring human intervention.

The transferable operating model is a controlled autonomy ladder.

Enterprise teams should not begin by targeting a percentage of company-wide pull requests. They should start with low-blast-radius work that already has strong automated tests, explicit ownership, and reversible deployment paths, then expand authority as evidence accumulates.

Delivery Hero’s stated goal is for Herogen to handle 20 percent of merged pull requests by the end of 2026. That is a forward target, not a realized outcome. A credible path toward that level requires workload classification, policy gates, exception routing, model and infrastructure cost controls, and continuous measurement of escaped defects.

• Tier work by blast radius, reversibility, and data sensitivity.
• Require deterministic tests and policy checks before AI review begins.
• Use independent reviewers for security and architecture-sensitive changes.
• Track cost per accepted change—not tokens or generated lines of code.
• Expand autonomous merge authority only after cohort-level production evidence.