I've watched the same class of bug get fixed twice. Once quietly, before anyone outside the team knew it was there. Once loudly, after someone outside the team found it first. Same root cause both times. Same code fix, usually something you could finish in under an hour. The bill was nothing alike.
The fix was never the hard part
Most of the security gaps I come across in AI-built apps aren't exotic. They're default settings nobody went back and checked. A database rule that got skipped when the app was first scaffolded. An endpoint that assumes only logged-in users will ever call it, with nothing actually enforcing that assumption. None of that takes long to fix once you know it's there. Which is exactly why the before-and-after comparison is so lopsided. The engineering cost barely moves. Everything wrapped around it does.
Before launch, it's a five-minute checklist item
Early last year, a researcher looking into one of the popular AI app-building platforms found that the backends it generated could ship with a core data-access rule either missing or set backwards, meaning one user's records could be read by a different user who simply asked. By the time that became public knowledge that May, more than 170 live production apps built on the platform already had the flaw running, spread across a scan of roughly 1,645 projects. Any one of those builders could have caught it before launch with one setting and one test. Nobody but them would ever have known it needed fixing.
After launch, it's a headline
A few months later, a different platform had a worse version of the same story. Someone found that a stranger could register themselves into another person's private app using nothing but a public identifier that was already sitting in the app's own URL. No password needed. The team fixed it fast, within about a day of being told, which is a genuinely good response. But the fix landed a few weeks after that same platform had been acquired by a much larger company for eighty million dollars. The story that traveled wasn't 'fixed within a day.' It was 'newly acquired AI platform let strangers log into other people's private apps.' Same shape of bug as the one above. Completely different weight, because by then it wasn't a private finding anyone could quietly close. It was public record.
Trust doesn't come back at the price it left at
This is the part that's easy to miss if you're only counting engineering hours. Before a breach, trust is the default setting. Nobody asks you to prove the app is safe, they just assume it, and that assumption doesn't cost you anything until you spend it. After a breach, trust turns into something you have to earn back one interaction at a time, and it gets priced worse every time. People who would have shrugged at 'we found and fixed something' now want to know if their own data specifically was touched. The technical debt gets paid off in an afternoon. The reputational debt gets paid off in installments, on someone else's timeline, sometimes for years.
Neither team in those two stories was unusually careless. They did what most people building fast with AI tools do: ship first, plan to look under the hood later. The only real difference between the quiet fix and the loud one was whether 'later' happened on their own schedule or on a stranger's. That's the actual decision sitting in front of you before launch. Not whether the gap gets found. Who finds it first.