Agentic Engineering Without a Platform Team
What's left of Zalando's two and a half years when you have fifteen developers
Almost everything Zalando built solves a coordination problem. A team of fifteen people doesn't have a coordination problem. It has a verification problem.
Everything else in this piece follows from that sentence.
A corporation measured it
Bartosz Ocytko, Executive Principal Engineer at Zalando, published what two and a half years of agentic engineering across 250 engineering teams produced. The piece is on the Zalando Engineering Blog.
What makes it unusual isn't that a corporation writes about AI. It's what the piece contains: a central LLM proxy, a tech radar for tooling, a marketplace for shared instructions, an internal guild, training formats, plus entry points into legal review and a scanner that checks deployed container images for model usage.
And then comes the part nobody else publishes. They show what's going wrong, too. Pull requests are getting larger. Complexity per commit is rising. Ocytko's phrase for it is that AI amplifies good and bad practices alike.
That's an honest balance sheet, and it's the work you would otherwise have to do yourself.
Except: almost none of it transfers.
Why almost none of it transfers
The obvious reason would be money. It isn't.
Look at what those measures actually do. A proxy means 250 teams don't manage 250 separate accesses. A tech radar means team A knows what team B already tried. A marketplace for instructions means a solution from the checkout team reaches the logistics team. A guild means knowledge crosses a department boundary.
Every one of those measures organises work between teams.
With fifteen developers there is no between. There's one room, one channel, one codebase. Building a marketplace for shared instructions there solves a problem you don't have, and costs time you need elsewhere.
This isn't an argument against Zalando. It's an observation about structural form. Platforms emerge when coordination becomes more expensive than technology. In a small team, coordination is almost free.
The other problem
What does get more expensive in a small team is verification.
In a corporation, a defect is spread across several stages. There's a review, an architecture board, a staging environment, a release gate. None of those stages is perfect, but they're independent of each other, and independence is the entire trick. A defect has to pass all of them.
In a team of fifteen, the same two people often review each other's work, and they wrote the code as well. When a machine now produces three times as much code, you don't get more work. You get more unverified work.
That's exactly the shift Zalando's data shows indirectly: larger pull requests are not a throughput problem. They're a verification problem that looks like a throughput win.
There's a second property of machine-generated code that a review catches poorly. It's rarely obviously wrong. It's plausible. Variables are named correctly, the structure matches what's already in the repository, and the tests are green. A human who writes their own misunderstanding into code usually leaves traces of it in the code. A machine that misreads a specification leaves clean code with a wrong assumption inside it.
A code review isn't built for that. It checks whether the code is any good, not whether it does the right thing.
What's left
Five things that work without a platform. Each with an honest estimate of effort.
No mandated tooling
Across 250 teams, Zalando never mandated a tool centrally. They keep a radar showing what's in use where and leave the choice to the teams.
A team of fifteen that standardises on one tool has imposed more governance on itself than a corporation with 250 teams. That's usually not deliberate. It happens because somebody set something up and it has been that way since.
Effort: none. This is about not doing something.
Measure instead of assume
The strongest move in Zalando's account isn't a platform. It's an analysis. They looked at how complexity per commit and pull request size changed over time, and they published the result, including where it's uncomfortable.
That doesn't take a team. It takes a script over your own repository history and half an hour to look at the output.
Without measuring, you notice the inflection point when reviews start backing up. By then it's six months old.
Effort: one afternoon, once.
What are you building against
This is the core, and it's the one measure on this list that is cheaper in a small team than in a corporation.
An unbounded instruction to a system that doesn't know what's correct produces a lot, quickly. A specification turns that into a bounded instruction. It isn't documentation for humans. It's the input for the machine, and at the same time the only thing you can verify the result against.
In a corporation, something like that has to be agreed, rolled out and enforced. In a team of fifteen it takes one decision and the discipline to hold it.
The uncomfortable side: if business changes may only originate in the specification, there's no quick fix in code with documentation to follow. There is no later.
How much that matters only becomes visible during verification. In a modernisation programme I'm currently involved in, the business tests found defects no code review would have caught. In one case the generated code was technically sound and the business process would still have gone wrong. One step would have been triggered, the corresponding second one never. It would have surfaced weeks later during a reconciliation.
It wasn't found because somebody looked at the code particularly carefully. It was found because there was a specification to hold the behaviour against.
Effort: one project decision, then ongoing discipline.
Who verifies
Zalando doesn't verify everything to the same depth. Low-risk changes pass through automatically, without anyone looking.
In a small team, verification layers aren't roles and aren't systems. They're people. But they have to be different perspectives, at least three: is the code technically sound, does the business behaviour hold, and is what a user ends up seeing correct.
If one person covers all three perspectives, only one exists.
Effort: days per verification round. This is the most expensive item on the list, and the first one people cut.
Shared instructions instead of a shared platform
Zalando's marketplace for shared instructions has a trivial equivalent at small scale: a directory in the repository holding the five procedures that keep coming up.
The benefit doesn't come from distribution. It comes from writing them down. Anyone who formulates a recurring procedure precisely enough for a machine to execute has understood it fully for the first time.
Effort: hours, spread over weeks.
What's more dangerous without a platform
So far you might conclude that everything is easier at small scale. In one respect the opposite is true, and it concerns exactly the environments I work in.
For early-stage work, Zalando has entry points into a legal assessment per use case. They detect model usage automatically by scanning deployed container images, register the system in their developer portal, and prompt the owners to document it.
A mid-sized company has no portal, no scanner and no legal department. Which models end up in use is decided in practice by whoever just tried out a tool. Nobody knows centrally which model has seen which data.
In a product with regulatory approval, CE marking or legal consequence, that is the actual risk, not code quality. Code quality shows up in testing. Undocumented model usage shows up in an audit, and by then the product is already in the market.
What I'm not claiming
This piece builds on someone else's work. So it's worth stating what it doesn't support.
I haven't worked with 250 teams. What's here comes from one ongoing engagement and from reading someone else's analysis.
The numbers in this piece are Zalando's, not mine. Where I write about complexity, pull request size or automated approval rates, I'm reporting their measurement.
The five points haven't been tested against each other. There's no control group and no comparison. It's what held up in one small organisation.
I'm saying nothing here about cost or speed, because I have no reliable figures. Anyone who quotes you some usually doesn't either.
What are you building against
What's called a platform in a corporation is called discipline in a small team.
In the end, two questions remain, and both can be answered without budget: what are you building against, and who verifies the result.
If your team has no answer to that, it isn't a tooling problem. It means AI now delivers faster, and nobody can say whether it's right.
If AI writes code at your company and nobody can say where the business decisions are recorded: let's talk.
Transparency: this text was revised with AI assistance for grammar and structure. The content, the figures and the decisions are mine.