Inside Zalando's software factory
Agentic engineering across 250+ teams since January 2024, with no mandated tool and a risk classifier that auto-approves a third of pull requests.
Zalando at a glance
The company
| Sector | "The leading European technology platform for fashion and lifestyle" 5 |
|---|---|
| Employees | More than 15,000, from 140 countries 5 |
| Customers | 62m active, across 29 markets 5 |
| Revenue | ~€12.3bn revenue, ~€17.6bn GMV (2025) 5 |
Customer and financial figures are reported for Zalando and About You combined 5.
The engineering organisation
| Engineering size | More than 250 engineering teams 1 |
|---|---|
| AI tooling since | January 2024, when the internal model proxy was deployed 1 |
| Tool policy | No centrally mandated tool; teams choose IDE, CLI, and model 1 |
| Agents in the SDLC | Risk-tiered PR auto-approval; cross-repo transformation via agent CLI 1 |
| Reported adoption | ~2,000 monthly actives on the internal model proxy 1 |
| Published metrics | PR-size distributions, cyclomatic complexity per commit, cache-hit ratios 1 |
The ~2,000 figure counts users of the internal model proxy. The source does not state that all of them are engineers 1.
People
What they set out to solve
Bartosz Ocytko, an Executive Principal Engineer, frames the central problem as one of scale rather than capability. "With >200 teams innovating and broadly exploring the ecosystem, the question arises whether and when to converge," he writes, pointing to "the cambrian explosion of AI tools and the rapid expansion of the ecosystem" as the source of a need for clearer guidance. That sprawl carried a governance cost: legal assessments had to run on a per-use-case basis to keep compliance intact.
Underneath the governance question sat a set of more mundane operational ones, all traceable to the same root: hundreds of teams choosing their own tools with nothing standardising the plumbing between them 1. Third-party tools lacked support for custom auth commands, so tokens depended on environment variables that expired and had to be refreshed by hand. Those same tools presented a generic User-Agent header, which made it hard to tell which tools clients were actually running. Configuration itself drifted, because, as the source puts it, "there is always a long-tail group of users who do not adjust their local configurations and who do not follow new model releases." And token spend leaked quietly into overhead nobody was watching for: plan names, terminal window titles, and recaps generated for idle sessions.
The pull-request gate had a single, clearly stated motivation.
In the pursuit of protecting lead time to merge for PRs, we built a risk-based PR approval tool.
Knowledge sharing posed a problem of tempo rather than content: "when state of the art changes daily, early adopters have different needs for exchange." Ocytko also points to a cost that isn't financial: "the temptation of participants to use coding agents as a shortcut to achieve results is high. Yet, using coding agents usually inhibits learning" 1.
A separate project had an older, more concrete problem. Naval Singh, a Principal Engineer, describes two parallel UI component libraries producing "inconsistent user experience across different partner facing applications," on top of duplicated design and development effort, two design languages to maintain, increased maintenance complexity, and higher onboarding time for new developers. Automating the fix carried its own risk, since "any inaccuracies in the process could have a direct impact on our partners' experience" 2.
Two things the source leaves open temper the picture. Managing tooling and configuration on users' devices, or moving local environments to the cloud entirely, along with local sandboxing and auto-routing across models, are all described as still unsolved. And the LLM proxy itself gets no stated motivation: the post presents it as complementing existing model access rather than solving an identified pain point 1.
Maturity level
Assigned by testing published facts against fixed criteria, and capped by what the sources state.
How Zalando's software factory works
A single LiteLLM-based API proxy gives unified access to OpenAI, AWS Bedrock, and Google Vertex. It runs on six modest pods of two CPU cores and 4GB each and serves roughly 2,000 monthly actives. Pre-call and post-call hooks handle cost tracking and version enforcement, and adoption more broadly is tracked through proxy telemetry on model and User-Agent rather than surveyed.
Alongside the proxy sits an internal CLI, built on pydantic-ai, which grew into the layer that makes agents usable against internal systems 1. Its agent mode carries MCP support and automatic Bearer-token injection for internal MCP servers, the direct answer to the token-expiry friction described above, while a separate http-to-stdio MCP proxy bridges transports so agents can reach servers that only speak one protocol. A configuration command installs vetted setups for Claude Code, opencode, and pi. And a centralised skill collection, spanning data, engineering, frontend, and SRE, is distributed by managed config or CLI-installed symlinks with contributions syntax-validated in CI; migration skills are its most popular category.
Every pull request is scored by an approval bot whose rule set was built from analysis of Zalando's own production incidents 1. Configuration typos sit at the high-risk end, the class the post ties directly to a specific past outage; backwards-incompatible changes count as medium risk; documentation-only changes count as low risk. Only the low-risk tier skips human review: roughly a third of all pull requests fall into it and are auto-approved with no human reviewer, a policy the post credits with cutting PR lead time by 20–40% measured against all PRs.
For work that spans the microservice estate rather than a single repository, a separate cross-repo transformation tool performs AI-based adjustments by running a coding-agent CLI against the codebases 1.
A separate pipeline runs over incident postmortems in five stages: summarisation, classification, analyser, patterns, opportunity. Dmitry Kolesnikov, a Senior Principal Engineer, records that it moved from NotebookLM through open-source models in LM Studio to Claude Sonnet 4 on AWS Bedrock: the evolution was "primarily driven by compliance topics rather than technical necessity," because postmortems contain on-call responders' PII and business metrics, so legal alignment was a precondition for using cloud-hosted models 3.
Governance reuses machinery that already existed: an AI section on the internal Tech Radar, an entry point in Sunrise (their Backstage-based portal), and Docker image scanning that auto-detects model usage, auto-registers the service, and triggers documentation and legal-review requirements 1.
Operating the software factory: teams, roles, and skills
No tool is centrally mandated: across more than 250 engineering teams, engineers choose their own IDE, CLI, and model based on availability and preference, and Ocytko frames the whole account as observational rather than a mandated rollout. There is no dedicated AI enablement function; the work sits with the existing ML platform and engineering-office teams 1.
Learning runs in tiers rather than as a training push 1:
- A weekly one-hour guild, running since 2024, with 20-minute presentation slots, recorded.
- Themed hackathons of two to three days in teams of four to six, which seeded the organisation's first community-maintained MCP servers.
- On-site "GenAI Labs" for around twenty people, one to four hours, run through their Tech Academy.
- Recurring monthly trainings, converted from the lab sessions they intend to repeat, currently covering MCP servers and building agents with pydantic-ai.
One rule in those sessions runs against the grain of everything else on this page: coding agents are discouraged during skills training, because using them inhibits learning. Ocytko frames the skill collection itself as discovered rather than planned: "by encouraging broad contribution of skills that teams found useful, we got an opportunity to discover and disseminate best practices across the organization" 1.
When state of the art changes daily, early adopters have different needs for exchange.
Implementation journey
- January 2024LiteLLM-based proxy deployed by the ML platform team 1.
- 2024Weekly knowledge-sharing guild begins 1.
- August 2024Internal CLI built at a hackathon, before coding agents existed as a category 1.
- February 2025Fifteen B2B frontend applications migrated between component libraries using GPT-4o at temperature 0 2.
- Q2 2025Internal PR-size distributions shift upward, following the Sonnet 4 release 1.
- September 2025Two years of AI-assisted postmortem analysis published 3.
- August 2026Zalando publishes its 2.5-year retrospective: the approval bot handles a third of PRs, and the agent platform remains on the roadmap 1.
Measuring the software factory
The most striking thing about Zalando's measurement is an absence: no percentage of AI-authored code appears anywhere in their material. What they track instead is the shape and quality of what comes out 1. PR-size distributions show growth in the 100–500, 500–1k, and 1k–2k character buckets following the Sonnet 4 release in Q2 2025. A four-codebase study, two Go and two Java, ranging from newly built to more than twelve years old and each paired against a reference codebase, tracks cyclomatic complexity per commit. Commit messages carry their own footprint: agent commits typically run around 5,000 characters, and one contained a full log of unit test execution. And cache-hit ratios and token waste are inspected with two tools, AgentsView and codeburn, across multiple agents and projects, a check that surfaced one engineer running below a 30% cache-hit ratio on opencode against an expected 80% or better.
Where a project had a defined scope, they published its economics. The component-library migration reached roughly 90% accuracy at under $40 per repository, using deterministic settings and LLM-generated examples that doubled as regression tests 2. The postmortem pipeline reports smaller models showing up to 40% hallucination probability, later described as negligible with approximately 10% attribution errors remaining, a category Kolesnikov distinguishes from hallucination, alongside human curation falling from 100% of output batches to a 10–20% random sample, and processing time per postmortem dropping from 90–120 seconds to around 30 3.
Lessons learned
The complexity finding is the one that complicates the story, and the source does not resolve it. Having shown complexity building up as agents were adopted then tapering, Ocytko declines to claim the taper proves recovery: if complexity plateaus for a well-scoped microservice, one would hope build time has been drastically reduced. He also notes the study's attribution is incomplete, because not all open-source commits disclose agent involvement 1.
Time will show whether this is the case.
Smaller failures are recorded without ceremony. The proxy itself leaks memory, forcing restarts every 20,000 requests. The rest share a pattern: waste that went undetected until someone specifically instrumented for it, whether in token spend on idle-session artifacts, one engineer's cache-hit ratio, or the length of agent-generated commit messages, each described above 1.
A behavioural effect sits apart from the technical ones: the approval bot changed how engineers work, not just what got merged. The post states it "affects behavior of engineers to increase the probability of a low-risk PR," with pull requests now broken down so the low-risk parts can ship quickly. Whether that is the intended effect or a side effect, the source does not say 1.
Human oversight was retained deliberately where the stakes were legible. Singh's account of the migration states that human oversight and verification is crucial at every stage, with code reviews and thorough visual testing needed 2. Kolesnikov's pipeline reduced human curation to a sample rather than to zero 3.
What's next for Zalando's software factory
Everything below is described as planned rather than running 1:
- An internal agent platform composed of open-source components, with kagent as the Kubernetes runtime. The stated aim is to "solve the hard authentication and authorization problems in agentic systems in one place," so teams can define and deploy agents "without the need to take care of sandboxing themselves."
- An Identity Broker capturing delegation chains and brokering between different OAuth2 infrastructures. It's the component that would put scoped agent credentials in production, a precondition for letting any agent here run a task unsupervised rather than interactively.
- A per-repository "AI readiness" scanner.
- Further monthly trainings on coding agents and agentic loops.
- A presentation at AGNTCon and MCPCon Europe, Amsterdam, 18 September 2026.
