The quota has increased. Developers are shipping more, and they’re shipping faster. PRs are landing at a pace that seemed unrealistic just a couple of years ago. Boilerplate is gone, and documentation is actually getting written instead of being backlogged for months. All of this results in more tickets closed. On paper, everything is A-OK.The numbers look great… But is the whole situation really that great?It all sounds neat on a pitch deck, but what those numbers don’t mention is that 45% of the code an AI agent has shipped has at least one OWASP top 10 vulnerability, or that teams leaning heavily on AI are seeing monthly production incidents up by 50% or more.That’s not so great.And though the increase in speed is real, the costs are starting to creep up in places that matter, like your customers' screens.TL;DR AI-based coding assistants are making developers measurably faster. Those same assistants are also making products less reliable and more incident-prone. Of course, the "10x" in the title is not literal, but the trend is hard to ignore. The fix isn’t to put a band-aid on it or move slower. It’s to rebuild the quality layer that the old, pre-2024 workflow used to have.Just to be clear, this is no "AI is a fad" article. You’ve felt the shift firsthand. Spinning up a boilerplate took an afternoon, and now it takes less than 10 minutes. The "I’ve never used this library before" tax has dropped to almost zero. You get the point.Upstream, the PR queue is longer than before. CI runs more often, sprints look greener, and by any traditional measure of engineering throughput, the team really is shipping more. And to be honest, when an EM says AI has made the team faster, you cannot say they are lying. They’re just reading directly off the dashboard. 😄The problem is that this dashboard just ends there, with numbers. It doesn’t show what the heck happened to the product.Hidden TaxThe situation is uglier than it looks.Luckily, most failures can be grouped into a few recurring patterns. If you are running production code in 2026 (hi, time travelers), you’ve probably seen at least one of these:Code that looks fine but is missing a single check. It passes review because it resembles hundreds of things you’ve already seen.Hallucinated APIs that compile successfully, ship, and only break on a real edge case in prod.Hardcoded secrets pasted in by autocomplete and then committed by a developer who trusted the suggestion a little too much. Yikes.Gradual drift from the architecture everyone knew due to thousands of small commits across a codebase that hasn’t been properly reviewed.This is the hidden tax, and nobody gives it any standup time until it becomes obvious.What "10x Worse" Feels Like to a CustomerEngineers feel the speed. They are driven by it. You see it when you’re running parallel agents and stuff seems to appear from thin air. But, customers don’t really care about any of this. They only feel the symptoms that come with it instead.| Where Engineers Felt Faster | Where the Customer Felt It Instead ||----|----|| They shipped a feature in half the time. | The button works, but only on the second click. || They pushed a fix without a full diff review. | A subtle regression elsewhere was found two weeks later by a support ticket. || AI suggested an auth helper that looked clean. | A group of users gets logged out at random for two days. || They refactored a payment flow in an afternoon. | The cart total is right, but the receipt total is off by one currency conversion. || They generated a thousand-line config because AI made it easy. | An obscure setting flips a feature flag for 3% of users, and nobody knows which one it is. || They wrote tests with the same tool that wrote the code. | Both pass, but the product still breaks. |This isn’t just about "a small regression we’ll catch in the next sprint.” This is about actual customers seeing a broken checkout, users finding their data has been leaked, SLAs being missed, and brand trust eroding. None of it shows up on your engineering throughput dashboard.However, there is something that all these have in common. Code still runs, the old tests still pass, but what breaks is the goal. Users can no longer do what they intended.Selector-based suites and unit tests check mechanics, not meaning, so they wave it through, but QA.tech takes a different approach. Its agents start from the user's intent and navigate the app with computer vision, so a receipt that silently disagrees with the cart gets caught before it ships.What Broke and What to BuildBaseline output per engineer has increased by a significant margin. The reason is clear: more tooling means more output. However, more output per engineer is also exactly why things start to break 10x more in practice.For starters, code review simply can’t keep up with the volume, and test suites only catch what someone thought to explicitly script. The edge cases nobody had time to write (such as the long tail where AI code actually fails) often go unchecked.On top of that, “let the model fix it" loops add new bugs faster than they can remove the existing ones, and observability assumes humans understand what was shipped. Most of the time, they don’t anymore.Sure, you’ve sped up the part of the pipeline that produces code, but everything downstream has stayed where it used to be in 2022. And to be clear, banning AI coding isn’t the answer, but there are a few things that actually work as of now:Treat AI code as its own risk class, with its own quality gates.Automate quality gates at every stage of the pipeline.Measure outcomes, not output.Make testing continuous and autonomous, and have it learn your product.Run it on every PR in CI so that the quality gate sits at merge time, not after deploy.If you get this right, you won’t slow code down. This way, you’ll make the quality layer move at the same pace as your agents writing code, so it will stop being the bottleneck.You’ll get to keep the fast rollout, but you’ll stop shipping the breakage with it.This is exactly what QA.tech was built for: autonomous testing agents that learn your product, test it based on user goals with computer vision instead of brittle selectors, and run continuously in CI.When the UI changes, the agent adapts and keeps testing the same goal. If something breaks only on an edge case nobody thought to script, this agent is the one that has already started exploring it, not a regression suite someone wrote two product versions ago.Wrap-up"AI made your engineers 10x faster" is true. "AI made your product 10x worse" can’t be taken literally, but the trend is clear if you are paying attention. The gap is widening, and it doesn’t look like it’s going to slow down any time soon.Speed without a quality layer is just a faster way to break the product.Build that layer. Demo QA.tech now.\Frequently Asked Questions (FAQs)Is AI code really that worse than human code?Yes, mostly on the security and business logic end.Is AI to blame for the recent rise in production outages?Nobody can prove there is a 1:1 link, but the correlation is hard to ignore.Should I stop using AI then?Productivity gains are real, and the economics aren’t reversing. Instead of avoiding AI, you can rebuild the quality layer underneath with the help of QA.tech.What is the single biggest red flag?Production incidents climbing alongside shipping speed.How can I start fixing all this?At the quality stage, since this is the layer that has stopped keeping pace with your code. Point QA.tech's agents to your highest-risk flows first (checkout, auth, anything that touches money). They will learn the product, test by user goal with computer vision, and run on every PR in CI. That way, the failures unit tests miss get caught before your customers ever see them.\\See the verification gap in action \n On June 24, we're hosting a free session on the verification gap – why faster coding keeps breaking traditional QA, and how goal-based testing changes what can be verified. Expect real customer outcomes, honest limits, and open Q&A. \n Join the webinar →