I Hate Quality Assurance. I Also Run Water Through the Pipes.

I hate quality assurance. I always have. And I say that as a man who has spent two decades unable to escape it.

The cruel joke of my career is that I came up as a Lead Analyst and Project Manager, and on a great many of those projects the budget did not stretch to a proper QA team. It barely stretched to coffee. So the testing did not always get handed to some dedicated department down the hall. It often got handed to me. I wrote the test scripts. Then I ran them. I was the analyst who designed the thing, and then I was the poor soul who had to sit there at the end and prove it actually worked, which is a bit like being asked to mark your own homework and doffing the dunce hat, every time you find a mistake.

So this is not the airy contempt of someone who has never done the job. This is the specific, bone-deep weariness of someone who has done it for twenty years and resented every minute. I have earned my hatred. I have kept the receipts.

Nevertheless, after twenty years, I cannot overstate the importance of it...but it is dreadfully boring.

Building something, designing something, solving something, that's a high. You start with nothing, a blank page and a half-formed idea, and you make a thing that works, and for a few glorious hours you feel like a demi god. And then the QA phase arrives, except sometimes the QA phase is also you, tapping yourself on the shoulder, asking "shall we just check that it actually does the thing?"

And I die a little. Every time. Because I know it works. I designed it. I was there. I have the warm, unearned confidence of a man who has just finished cooking and is certain, absolutely certain, that he doesn't need to taste it before serving. The plating is gorgeous. Look at it. Why would I poke holes in my own beautiful soufflé?

The answer, of course, is that my soufflé is a lie and I have salted it with what I genuinely believed was sugar.

The plumber's rule

We have something we call "The plumber's rule" and we learned it the hard way. And it's the reason we put extra emphasis on the work I so hate.

When a plumber finishes a job, he does not pack up his tools, shake your hand, and drive off into the sunset trusting that water will simply know what to do. He turns the taps on. He runs water through the pipes. He stands there, arms folded, watching the joints he just sweated, because the entire point of a pipe is to carry water and he has not actually proven that this one does until he sees it happen.

Nobody applauds the plumber for this. There is no standing ovation for "the water came out of the tap, as water has done since the dawn of indoor plumbing." It's the least glamorous part of his entire day. It's also the only part that matters, because the alternative is a phone call at eleven on a Sunday night from a man standing ankle-deep in his own kitchen, and that man is not going to recommend you to his friends.

I hate running water through the pipes. I have done it for twenty years anyway. Because I have, more than once, been the eleven-o'clock phone call, or rather the person who got dragged out of bed to answer it. And being the phone call is worse than being bored. It turns out boredom has a competitor, and its name is humiliation.

QA was always the afterthought, and we mostly got away with it

For most of the history of software, we treated quality assurance as the thing you did if you had time and budget left over, which you never did, because the budget was set by someone who believed testing was where ambition went to die.

QA got the leftover schedule. It got squeezed from both ends, the build ran long because builds always run long, and the deadline did not move because deadlines never move, so the testing window compressed from three weeks into a frantic long weekend of someone clicking around hoping nothing falls over before Monday. We called this a process. It was closer to a prayer.

And the dirty secret is that we got away with it. Mostly. A human wrote the code, so a human's mistakes were in it, and human mistakes have a certain familiar shape. We knew where to look. The off-by-one error. The unhandled null. The form that breaks if you put an apostrophe in your surname (apologies to every O'Brien who has ever tried to sign up for anything). The bugs were ours, they were finite, and a tired tester on a Sunday could usually find enough of them to keep the worst from shipping.

That world is vanishing as we speak.

Then the machines started cooking

Generative AI changed the shape of the problem, and it did it quietly enough that a lot of teams haven't noticed they're now playing a different game with the old rulebook.

When a human builds something, the work is slow and the mistakes are legible. When a model builds something, the work is fast and the mistakes are fluent. That's the word that should keep you up at night. Fluent. The model does not produce obvious garbage that announces itself. It produces beautiful, confident, well-structured output that is wrong in ways you have to actually look for, because nothing on the surface is waving a flag.

A human junior developer who doesn't know the answer will usually, mercifully, look nervous. They'll hedge. They'll say "I think this is right but can you check it." The model has no such decency. It delivers the hallucinated function with the exact same serene confidence as the correct one. It does not know when it is wrong, and worse, it does not know that it does not know, and it will hand you a steaming plate of nonsense garnished so beautifully that you'll want to photograph it before you eat it.

So now the volume has gone up and the tells have gone down. We're producing more, faster, than any QA process designed for the human era was ever built to catch, and the errors are camouflaged as competence. The soufflé doesn't just look good anymore. It looks good and it was made in four seconds and there are forty more behind it, all equally photogenic, and somewhere in that batch is the one that's been salted instead of sugared and you cannot tell which by looking.

This is the part where the afterthought becomes a liability you can no longer afford.

You can't bolt the brakes on after the crash

Here is what I want every founder, every PM, every person setting a budget to sit with for a second.

The reason QA worked as an afterthought in the old world is that the volume was throttled by the speed of human hands. You could only make mistakes so fast. The testing window, however cramped, was roughly proportional to the size of the thing being tested, because both were gated by the same slow human process.

AI broke that proportion. Building got faster by a factor that genuinely shocks people when they first feel it. Checking did not. A model can generate a hundred variations of something in the time it takes you to read this sentence, and not one of those hundred has been looked at by anything that can feel embarrassed. The generation scaled. The judgement didn't. And the gap between those two is exactly where your reputation goes to quietly bleed out.

If you've read anything I've written about managing AI projects, you've heard me bang this drum. The cost of building has collapsed. An afternoon now does what a quarter used to. And the single dumbest thing you can do with that windfall is spend all of it building more, faster, and none of it checking whether any of it is true. That's not efficiency. That's just running faster at the same wall, with a nicer shirt on.

The discipline now, the actual craft, is to take a serious slice of the time the machines just handed back to you and pour it into the unglamorous work. Validation. Real validation, the kind that tries to break the thing rather than confirm it works. Planning the checking before you plan the building. And, the part almost everyone skips, baking in metrics from day one that tell you whether the thing is actually succeeding, not just whether it's novel.

Because novel is easy now. Novel is free. A solution can be dazzling and new and demoed to applause and still have absolutely no mechanism for knowing whether it's any good. If you can't measure whether your clever output actually produces the outcome it promised, you don't have a solution. You have a magic trick, and magic tricks have a way of stopping working the moment a paying customer is watching.

I'm not asking you to learn to love QA. I've been doing it for twenty years and I'm not about to start lying to you now. You're allowed to find it boring. Boredom is a perfectly honest response to watching water come out of a tap.

I'm asking you to stop treating it as the optional dessert and start treating it as the kitchen's health inspection. Build the checking layer before you build the thing. Put a human, by name, with real time in the plan, standing between the model and the client. Decide what success actually looks like in numbers before you start, so that "is this working" has an answer that isn't a shrug and a vibe. And track it, because a metric you set and never look at is just a decoration with delusions of usefulness.

The machines got fast. Spectacularly, genuinely, change-the-business fast. That speed is a gift, and like most gifts it comes with a card that nobody reads, and the card says: the faster you can make things, the more it matters that someone, somewhere, is still willing to do the dull, vital, deeply unsexy job of turning the taps on and watching the water flow.

That's the part I have personally hated for fifteen years. It's also the part I have never once skipped, because I know exactly what it costs to skip it. And it's the reason DCX does it by the book, every time, whether the budget loves us for it or not. We build the checking layer first. We put a name against the validation. We agree what success looks like in numbers before anyone touches a keyboard, and then we actually measure it. Not because it's glamorous. It isn't. Because it's the difference between a thing that works and a thing that merely looks like it does.

DCX will be the company turning the taps on. Grudgingly, in my case, with a face like a slapped backside the entire time.

But we'll be that company, because I have received the eleven-o'clock phone call, and I would genuinely rather be bored than get another one of those.