Most engineering leaders assume that a platform's success lives in the code. Max Körbächer's presentation argues otherwise: success can't be coded, and the sooner teams internalize that, the sooner they stop building expensive internal tools that nobody adopts. His point isn't subtle, but it bears repeating because most of us still default to infrastructure-first thinking. We see a developer experience problem and assume the fix is another service, another abstraction, another API. Körbächer's message is that this is a product problem wearing an engineer's uniform.
That framing connects directly to a concern we've been circling in our own coverage: the gap between what automation promises and what it delivers. When AI Made Me 5x Faster. It Also Made Me 5x Worse at My Job. describes a near miss with an AI agent, it's the same root cause Körbächer identifies: we get so excited about the machinery that we ignore the human workflow it disrupts. Similarly, Multi-Agent Coding Isn’t Enough — Agents Need a Commitment Layer shows that even when agents communicate perfectly, the missing piece is alignment on intent, not capability. Körbächer's take is that platforms fail for the same reason: they're built as technical artifacts, not as products serving a user base.
His emphasis on product mindset is the practical shift here. That means asking who the internal customer is, what their pain points actually are, and what "good" looks like from their seat, not from the platform team's dashboard. He's also right to push back on vanity metrics. Measuring adoption by logins or request counts misses the point when you haven't defined what successful adoption changes about someone's day. That's where DevEx and SPACE metrics come in, but only if you're honest about what they measure. SPACE isn't a scorecard; it's a diagnostic tool. If you use it to justify your platform's existence rather than to find friction, you're back to infrastructure-first thinking with a nicer label.
The related piece on verifying AI code lands on the same principle. In Verify Your AI Code: Ensuring Intent Without Reading a Single Line, the lesson is that intent must be made explicit and testable, because the code alone won't tell you if you're solving the right problem. Körbächer's argument is the platform equivalent: the internal developer portal won't tell you if you're solving the right problem, either. Only a clear understanding of your users' actual workflow can do that.
What we'd tell a reader asking about this presentation is simple: stop treating platform engineering as a technical initiative. Treat it as a product line with a customer, a roadmap, and a definition of success that isn't "we shipped it." If you can't name the person whose life gets better because your platform exists, you're building for your own resume, not for your team.
The concrete takeaway worth quoting: **"A platform that nobody uses isn't a platform; it's a cost center with good intentions."** Körbächer doesn't say that verbatim, but it's the logical conclusion of his argument. The open question we're left with is whether organizations will treat this as a one-time adjustment or as an ongoing discipline. That distinction will separate teams that build lasting internal tools from those that keep rebuilding the same failed ones, just with newer tech.