An expert Q&A with Daniil Mazepin, Senior Engineering Leader
Across the software industry, the story of the past 2 years has been speed. Agentic coding tools now draft, review, and merge code at a pace that would have been unthinkable in 2023, and the dashboards leaders watch — pull requests merged, deployment frequency — point sharply up. A quieter problem is building underneath the productivity gains. We put it to Daniil Mazepin – known for a contrarian view on how the industry measures engineering work, who has run reliability for payments, social, and gaming platforms at Playtech, Meta, and Teya and now works on AI infrastructure at CoreWeave, and who has keynoted on system availability across Europe – for his read on where AI adoption is going wrong and how to get it right.
First of all, could you tell our readers about yourself and how you came to specialise in reliability?
I’ll be glad to. I’m a senior engineering manager with 14+ years building high-load, real-time systems across payments, large-scale consumer technology, mobile, and now AI. I grew up in Donetsk on chess and mathematics, which taught me to break a problem apart before building. I started in iOS, then spent 7 years at Playtech leading a mobile department of around thirty engineers, where I scaled the platform to roughly 10 times the customers with almost flat headcount and shipped the first native-games SDK in the iGaming industry. That work opened Playtech’s entry into the US market and put me on the international tech stage. Meta then recruited me to lead backend teams on Shops, its e-commerce platform serving billions of users. Later, at Teya, a UK payments unicorn, I built the Dynamic Currency Conversion platform and significantly improved the reliability of a payments domain. The through-line is systems where failure costs real money and, having lived through two wars, I don’t take reliability for granted. There’s a quiet satisfaction I’ve never lost — when a system just holds and no one has to think about it. My guiding line is simple: build systems people can rely on, because I know what it means when everything reliable disappears overnight. And I’ll be honest — in every one of those places, across gaming, social, and payments, I watched the same mistake repeat itself: teams optimising the number that’s easy to count instead of the one that actually matters. That’s the lens I bring to what’s happening with AI now, and it’s why I joined CoreWeave to work on AI infrastructure.
AI coding tools are everywhere now, and most of the coverage is about how much faster teams ship. What is that framing missing?
That speed is never free – you’re trading it against quality, and that trade doesn’t show up on the dashboards. And let me be clear up front: I use these tools every day and I’m an advocate for them; they’re genuinely good at generating code. But what agentic coding really changes isn’t cost, it’s what ends up in your codebase. ‘Vibe-architecting’ — letting the model drive the design and structure, not just the syntax — isn’t good enough yet, so you get more code, shipped faster, with worse maintainability and design quality. And a lot of it has no owner: someone says ‘let’s just try a prototype,’ it works, and it quietly becomes production code that nobody actually understands — a widening gap between how fast we ship and how well we can maintain and stand behind it. I call that gap reliability debt. And I don’t mean it as a metaphor, I mean it as an assessment, made through reliability engineering, which is what I’ve been doing for fourteen years and arguing on main stages across Europe.
You mentioned “reliability debt.” What does that debt actually look like inside a team?
Honestly, this is the idea I find myself explaining most often these days – so I’m glad you’re asking. A human bug usually looks wrong, so review catches it. An AI bug looks right — clean, plausible — and arrives at a volume no reviewer can absorb, so it passes review by construction, hiding missing edge cases, hallucinated interfaces, and supply-chain risk. To give you an example of the shape these failures take: a generated function that rounds currency can look flawless, pass every review, and then quietly lose a fraction of a cent on millions of transactions before anyone notices. Invisible until it’s expensive — that’s the whole problem in one line. What frustrates me isn’t the technology, it’s the industry’s response to it: teams let AI generate and merge code faster than anyone can own, design, or truly understand it — and treat the output as finished because it looks finished. You don’t get to multiply your change volume by ten, keep the same review process, and call it progress. That’s not speed – it’s shipping faster than anyone can stay accountable for what ships.
The standard defense is that productivity metrics are up and to the right. Is the industry measuring the right things?
No. And it’s the same mistake I’ve spent years arguing against with availability. In my keynotes at Highload fwdays, KCD Porto, and London’s National DevOps Conference, I make the case for user satisfaction: uptime is a vanity metric, because you can be 100% available and still failing your users. Velocity is now the new uptime. Counting merged pull requests is like grading a factory on how fast it stamps parts without checking whether any of them fit. The honest signals already exist — change-failure rate and recovery time on AI-authored changes specifically. They’re well established in the industry’s own DevOps research, but rarely the ones leaders celebrate. For anyone who wants more information about it I always recommend Accelerate by Nicole Forsgren, Jez Humble and Gene Kim — the research behind those metrics is very convincing.
From your point of view, where is AI adoption going wrong at the organisational level?
Most companies adopted AI as a productivity mandate, not as a system with a failure mode. In payments you don’t get to say “the model wrote it” – someone is accountable at three in the morning, and the org chart and the tooling don’t agree on who. And I disagree with the fashionable idea that AI means you need fewer junior engineers; I think it’s one of the most short-sighted calls the industry is making. This one is personal for me. As an IEEE senior-grade assessor and a mentor to engineers in more than 120 countries — many of them just starting out — I review other engineers’ work constantly, and the most rewarding part of it is watching judgment actually form in someone, slowly, through friction. That’s exactly what we’re automating away. Cut the juniors today, and in five years no one can judge the machine’s output.
Looking ahead, what advice would you give the leaders adopting AI right now?
Of course there’s no clean recipe here — anyone who offers you one is selling something. But the approach I’ve found effective is almost boring: stop pretending this is new. We already built the discipline for trusting systems we can’t fully predict, and we called it reliability engineering — SLOs, error budgets, blast-radius limits. AI is just the newest unpredictable component; govern it like one. None of this is a reason to slow down – I want teams using AI aggressively; I just want a seatbelt in the car. Measure the outcome, not the output. Gate the verification. Keep a human who understands the system accountable. An amplifier without a governor doesn’t make you faster – it makes you louder. The winners of this cycle won’t be whoever generates the most code. They’ll be whoever can still tell when the machine is confidently wrong, and has built both the systems and the people to catch it. And if I have one hope for this moment, it’s that we don’t relearn these lessons the hard way. I’ve seen what happens when reliable things vanish overnight – I’d rather we build the governor before we need it than after.
The views expressed here are Daniil’s own and do not represent any current or former employer.
