Why “Move Fast and Break Things” Was Never Actually Good Advice (And AI Just Makes That More Obvious)

I was in a meeting a few days ago when a colleague brought up something she’d been reading about. The gist of it: companies using AI to speed up development are shipping product faster than ever, but the bug counts are climbing right along with it. Faster code, more breakage. That seemed to be the going narrative.

I pushed back a little, because that hasn’t been our experience, and I think I know why.

Yes, we use AI heavily. Yes, we move fast. A lot of our code gets written, reviewed, and shipped at a pace that would have been unthinkable a few years ago. But there’s one part of the process we refuse to speed up, almost to a fault: QA.

Nothing touches a sandbox with real data in it before it’s been through code review. A lot of those reviews involve AI now, which is honestly a good thing. But AI doesn’t get the final word. If a review comes back and something feels off, we push back on it. “I don’t agree with this, go check that again.” “You missed this edge case, and here’s why it matters.” The AI speeds up the first pass. It doesn’t replace the judgment call.

After that, it goes through actual QA. Real test data, real interactions with the UI, watching to see if it behaves the way it’s supposed to under conditions that look like how people will actually use it. Only after all of that does anything get anywhere near production.

The result of keeping that step slow and deliberate while everything else speeds up is that rollbacks are rare for us. Not nonexistent, nothing’s perfect, but rare enough that when one does happen, it’s a notable event, not a Tuesday.

That doesn’t mean the process is pleasant. Anyone who’s been on the developer side of a QA fail knows the feeling. You get the report back and your first reaction is something like “come on, that’s it? That’s the thing that failed it?” It feels small in the moment. It feels like nitpicking. Nobody enjoys being on either side of that conversation, honestly. The QA tester doesn’t love being the person who has to send something back for the third time either. But that friction is the whole point. The stuff that gets caught because someone was annoyed enough to push back on a small inconsistency is exactly the stuff that would have quietly become a real problem six months later, in front of an actual client, at the worst possible time.

And this is bigger than clients, honestly. I’m talking about your own people. The employees who sit in front of this platform every single day, the ones pulling up records, making decisions off of what’s on their screen, trusting that the data in front of them is accurate. That trust is incredibly hard to earn. You build it slowly, one reliable day at a time, one system that does what it’s supposed to do without drama. And it is unbelievably easy to lose. One bad rollback, one time someone finds out the numbers they relied on last week were wrong, and that trust takes a hit that doesn’t just bounce back. Sometimes it never fully does. People start double checking everything, working around the system instead of with it, and once that habit forms it’s brutal to undo. The same thing applies to customers too, obviously, but I think people talk about that side of it a lot and forget the internal side is just as real, and in some ways harder to rebuild because these are the people who have no choice but to keep using the thing you broke their trust in.

I think that’s the real split between companies that are getting AI right and the ones that are getting it wrong. It’s not about how much AI you use or how fast you move. It’s whether you let the pace of development outrun the pace of verification. Those are two different things, and AI has made it very easy to confuse them, because it makes the first one so much easier.

Moving fast for the sake of moving fast is a fine strategy right up until you’re handling something that actually matters. Client data. Customer trust. Production systems that people depend on. At that point, speed without reliability isn’t an advantage, it’s a liability you haven’t been billed for yet.

Nobody enjoys QA. I’ve done it for years and I still don’t love it. It’s repetitive, it’s often tedious, and there’s a lot of back and forth that can feel like it’s slowing you down right when you want to be done. But it’s the part of the job that actually earns the speed everywhere else. You don’t get to skip it just because the code got written faster than it used to.

Testing has always been the thing that separates software that works from software that just compiles. AI hasn’t changed that. If anything, it’s made it more obvious who already understood that and who was just getting lucky.