Something has quietly broken in software delivery over the last three years, and most engineering leaders haven’t named it yet.
AI made writing code fast. Absurdly fast. Features that used to take a sprint now take an afternoon. Pull requests pile up. Velocity charts point up and to the right. Everyone in the org is thrilled — until the bugs start showing up in production, and nobody can quite explain why, because “the team is shipping faster than ever.”
Here’s why: you didn’t remove a bottleneck, you moved it. Development sped up. QA didn’t. And QA was never built to absorb a 10x increase in throughput.
The pressure nobody budgeted for
QA teams are now expected to validate a volume of change they were never staffed, tooled, or timed for. The result isn’t a gradual increase in workload — it’s a wall. Release cycles that once gave testers days now give them hours. Something has to give, and it’s usually one of two things: the release date, or the thoroughness of the testing. In most orgs under growth pressure, it’s the latter.
This is how QA quietly gets held hostage by its own development team’s speed. Not through malice or mismanagement — just physics. You cannot manually verify at AI speed what AI wrote at AI speed.
The “just automate it” trap
Most teams see this coming and reach for the obvious answer: more automated tests. And it works — for a while. Then a second, quieter problem shows up.
Automated tests are not fire-and-forget. Every UI change, every refactor, every new flow breaks a percentage of the existing suite — not because the product is broken, but because the tests were written against yesterday’s app. Someone now has to triage: is this a real regression, or did the test just fall out of sync with reality?
That someone is QA. And this is the part leadership often misses: AI can write you a pile of tests in minutes, but it cannot make a maintenance burden disappear. Someone still has to review those generated tests, confirm they test the right thing, and keep fixing them as the product evolves. The team meant to be freed up by automation ends up spending its time patching test scripts instead of hunting down actual bugs. QA stops being a quality function and becomes a test-maintenance function.
That’s not a hypothetical trade-off. It’s a full-time job shift, and it happens silently, one flaky test at a time.
Why this hits front-end the hardest
Backend logic is comparatively forgiving to test. Inputs and outputs can be specified, rules are explicit, and a well-written contract test tends to stay valid even as implementation details change underneath it.
Front-end applications don’t get that luxury. Layouts shift. Component trees get refactored. Elements move, get renamed, or get wrapped in new containers — all without changing what the user actually experiences. A test suite built around specific selectors or flows becomes brittle almost immediately, and every one of those small UI changes has a chance of quietly breaking a test that had nothing to do with a real bug.
This is precisely where AI-accelerated development creates the most damage: front-end code changes constantly and cosmetically, and the testing approaches available today were never designed to absorb that rate of superficial change without constant human upkeep.
The real cost: bugs that make it through anyway
Put these together and you get the pattern showing up across engineering orgs right now: QA under time pressure, buried in test maintenance instead of test design, working against a front-end that changes faster than any suite can stay accurate. Something has to be sacrificed, and too often it’s thoroughness.
Teams end up pushing releases QA would have blocked if they’d had another day. Not because anyone signed off on lower quality — because nobody had the time to prove otherwise. The bugs that get through aren’t exotic edge cases. They’re the ordinary ones that a rushed, under-resourced QA process simply didn’t have the bandwidth to catch.
This is the problem we’re building for
We think this is the actual, unglamorous bottleneck in modern software delivery — not writing code, but knowing whether the code you just shipped actually works. And we think the answer isn’t “more tests” or “more QA headcount.” It’s rethinking how testing itself gets done, so it can move at the speed development already moves at, without dumping a maintenance burden on the people meant to be doing quality work.
That’s what we’re building. Over the coming weeks, we’ll be writing about the decisions behind it, in the open — the architecture, the trade-offs, what’s worked, what hasn’t. If this problem sounds familiar, you’re exactly who we’re building for, and we’d like you along for the ride.