Is moving fast more important than shipping quality code?

Last night in London, we put two experienced engineering leaders in a room and asked them to settle on a very important question "Is moving fast more important than shipping quality code?"

Spoiler, they didn't settle it, but what they said was far more useful than a clean answer.

The false trade-off

Meri Williams, former Monzo & Pleo CTO and Chair of LeadDev, came out strong, "I find it very frustrating that we treat it like a trade-off between the two."

Their point "move fast and break things" only works if you can actually fix the things you break, companies that skip the fixing part don't survive. The goal isn't to choose between speed and quality, it's to build the kind of infrastructure and culture that lets you do both.

Alicia Collymore, Engineering Manager at incident.io leading 30+ engineers, came with a slightly different angle, "do what needs to be done and clean up afterwards." Here's the key bit, you need a real process in place to make sure "clean up afterwards" actually happens, shipping fast with known failure modes beats shipping fast with unknown risks every time.

What does "quality" actually mean?

Before you can debate it, you have to define it and the panel broke it into two camps:

User experience quality: if the product feels good to your users, some internal messiness is acceptable, but only temporarily. Alicia put it plainly "if the user experience is good, internal errors are something we can fix, but if the user is suffering, that's on us."

Maintainability quality: this one's sneaky, Meri's framing was memorable, imagine the person who has to maintain your code in six months is a murderous psychopath. The further you get from when you wrote something, the harder and more expensive it is to get back into it, spending an extra hour now might save three times that later.

Neither is more important in the abstract, it depends entirely on what you're building and where you are.

The AI elephant in the room

Both panellists had opinions on the AI productivity question, and they were honest ones.

Meri estimated real productivity gains at 10–20%, not the transformative step-change most headlines promise. They also noted something they've changed their mind on. A year ago they thought they'd spend the next decade cleaning up after AI, but the models that came out late last year and early this year feel like a genuine step change.

The more interesting point was that AI intensifies whatever you've already got going on. Strong guardrails, solid infrastructure, good testing means AI makes you go faster and produce better output. Missing any of that and you fail quickly, and repeatedly.

The Spotify example stood out, they've used AI to handle dependency updates and keep their codebase current, but it only works because they'd already invested in strong test coverage and clear contracts between services. They've also implemented a dual-agent setup where a second AI judges the first one's output, not as a gimmick, but as a genuine quality gate.

The takeaway was that AI is an amplifier and not a shortcut. If your house isn't in order, it'll just help you make a mess faster.

Startup vs Scale-up

One of the more grounding moments of the evening was Meri talking through the Monzo years.

Early Monzo got a lot of leeway to experiment because it was a scrappy startup. Then it became a top-10 UK bank, and the regulatory environment shifted overnight. The team that used to be supervised by an innovation unit found itself under the scrutiny of the team that supervises major financial institutions, with different expectations entirely.

This resulted in a period of overcorrection, having to slow down more than felt right, being overly cautious about shipping and occasionally building things that could have been validated faster with real users. Sometimes they built things they probably should have thrown away sooner.

"If you know 100% that something will live for a long time, it's worth doing it right the first time. But if you might end up throwing the thing away, ship it, see, just don't wait six months to fix it."

The practical lesson for smaller companies is you have more existential risk from not shipping than from shipping imperfect code. That tolerance however erodes as you grow, so it's important to know where you are.

Alicia had a parallel experience at incident.io, when the team built their Status Page product, it was the first time they deliberately slowed down. "There has to be a sense of reliability, if the customer status page goes down when your customer goes down, what are they going to think?" It wasn't just a technical decision, it was a trust decision. Once it shipped, they sped back up and iterated, the lesson being that some features earn the right to be built slowly.

B2B vs B2C

The panel pushed back on a common assumption that B2C companies can afford to be sloppier.

Meri's take, "the standard required for B2C is actually higher than for B2B." B2C users will put up with a lot from products they love, but they'll also leave in seconds for something better, meaning the polish bar is high.

The real difference is tolerance for failure, in B2C, a few users hitting a bug occasionally isn't catastrophic. In B2B, your contract probably has clauses that start costing you money the moment something breaks for too long. The bigger the procurement department, the harder the consequences.

Alicia added an interesting observation from hiring, when interviewing engineers coming from B2C they tend to be more experimentation-focused, using A/B testing, staged rollouts, lots of validation. Whereas B2B engineers tend toward thoroughness before release. Neither of these approaches are wrong, they are just responses to their environment.

The ownership problem

A question from the audience landed well "As AI lets smaller teams own bigger codebases, what happens to understanding?"

Meri's answer, the AI drift is real and the gap between "the agent wrote it" and "I understand it" is growing. When something goes wrong at 2am, someone has to be able to reason about the system, not just run it.

Their prediction for where this leads is for more standardisation, relying less on elegance and more on consistency. Over at Spotify they're deliberately making their microservices look more alike so that any engineer (or agent) can dive in and make sense of it quickly, making large estates manageable.

Teams won't necessarily get bigger just because you can build more with AI, but they'll certainly own more. That means the ability to get up to speed fast on an unfamiliar system, under pressure at 2am, becomes one of the most valuable things you can invest in.

Summary

Speed and quality aren't the opposites we think they are. The real question is: what kind of quality matters right now, for this thing, for these users, and do you have the processes in place to clean up what you ship fast?

If you don't, you're not moving fast, you're just accumulating debt.