Building Your Software Got Twice as Fast. Testing It Got Optional.
"With the new AI tools, we can build that in half the time" sounds like unambiguous good news. A report out this month put a number on the other half of that trade: 60% of organizations are now shipping code that was never properly tested.
Somewhere in the last year, you probably heard a version of this pitch: "With the new AI tools, we can build that in half the time." Maybe from a firm bidding on your project. Maybe from your own team. It sounds like unambiguous good news — same software, half the wait, probably less money. Who says no to that?
Hold that thought, because a report out this month put a number on the other half of the trade, and it's not small.
The number
A software-testing company called Tricentis surveyed about 2,500 senior technology decision makers this spring — CIOs, CTOs, the people who actually sign off on this stuff — across six countries. Sixty percent of their organizations admitted they're shipping code that was never properly tested. Not "we cut a corner once." Shipping untested software as a matter of course.
The reason it's worth your attention is why. A third of them said they're doing it on purpose — because someone above them wants it faster, and testing is the thing that gets sacrificed when speed becomes the whole point. Another big chunk said the AI is simply writing more code than their people can keep up with checking. The machine got faster. The part where a human makes sure it actually works did not.
And it's already costing real money. About one in five of these companies reported losing more than a million dollars a year to it — mostly to security holes, compliance failures, and the slow tax of fixing things that shipped broken.
Why "faster" quietly became the risk
Here's the part nobody mentions in the sales meeting. For most of the history of software, writing the code was the slow, expensive part. So when a tool comes along that writes it two or three times faster, it feels like the whole job just got two or three times faster.
It didn't. Because the typing was never the hard part. The hard part — the part you were actually paying for — was the judgment. Knowing what could go wrong. Checking the thing under load, with weird inputs, with a real customer doing something nobody planned for. AI made the cheap part cheaper and left the expensive part exactly where it was. Worse: there's now more code to check, much of it written by a machine — and surveys this year keep turning up the same uncomfortable admission: most developers using these tools say they ship AI-written code they don't fully understand, at least some of the time.
So "we can build it twice as fast" is true. The unspoken question is what happened to the time that used to go into making sure it works. Sometimes it went back into testing. Increasingly, per that report, it just got handed to you as an earlier delivery date.
The kitchen that plates twice as fast
Think of it like a restaurant that figured out how to plate every dish in half the time. Genuinely impressive — until you learn the time came out of the step where someone tastes the food before it leaves the kitchen. The plates are flying out. Nobody's checking the seasoning. Most go out fine. The ones that don't go straight to the customer, and you find out only when they do.
Fast and untested isn't a quicker version of good work. It's a different thing wearing the same clothes.
Where we sit
We use these tools every day, and they genuinely make us faster. The difference is where the saved time goes. When AI writes a chunk of something for us, that doesn't shorten the part where we read it, test it, and try to break it before a customer ever sees it — that part stays. Mostly the speed buys us room to test more, not to ship sooner. The invoice doesn't shrink because a machine typed faster; what you were paying for was never the typing.
Which means sometimes we'll tell you something you might not want to hear: that we could ship the exciting version next week, but we're going to take the extra few days to make sure it doesn't fall over the first time real people use it. That's not us padding the timeline. That is the job.
And here's the honest tell to take with you. If a firm's whole pitch is how fast they are — if speed is the headline and quality is a word they use once near the end — that tells you where their attention will go the day the deadline gets tight. The firms worth hiring will happily tell you how fast they can move, and then, without being asked, tell you what they refuse to rush. If you only ever hear the first half, you've learned something anyway.
The question worth asking this week
You don't need to know a line of code to use this one. Next time someone's quoting you a timeline — your vendor, your team, anyone — ask the question the speed pitch skips over: "When the AI writes the code, who reads it, and what actually gets tested before it reaches my customers?"
A good answer will be specific and a little boring. A bad one will be some version of "the AI's really good now." One of those is worth your money. The other one is the 60%.