Your QE Program Has a Structural Problem, and AI Just Made It Visible

A structural problem in quality engineering (QE) programs has been exposed by AI-driven development, according to an analysis by an engineering leader. The classic QE model, which runs development and quality on separate branches, is now a bottleneck as AI tools like Cursor, Claude Code, Copilot, and Codex multiply pull request velocity, while testing tooling fragments by protocol and stage, and tests rot faster than they are maintained. The analysis cites a fintech technical director of quality who said the testing waterfall squeezes all testing into a final push, and a senior director of quality at a financial services firm who reported 160 major customer-impacting incidents after launch despite testing.

Your QE Program Has a Structural Problem, and AI Just Made It Visible The problem, in one line. Your QE program works by the standards it was built for, and those standards no longer match the speed your developers ship at. AI multiplied how fast code and API calls arrive, while the gates, tests, and audit process underneath were sized for a slower world. The gap between what QE is asked to deliver and what it can deliver widens every month. I spend most of my time with engineering leaders who already run real QE programs. They have people, tools, and process. Tests run, releases ship, audits pass. By the standard the program was built for, it works. Here is what I keep watching happen. The forces reshaping software development are exposing problems those programs were never designed to handle. Coding agents multiply PR velocity per developer. Runtime AI agents consume production APIs in ways no integration test anticipated. Continuous compliance is trading the quarterly audit window for a live evidence requirement. Headcount is not growing to match any of it. So the function gets asked to do more, faster, with the same people, against a surface growing in every direction at once. That is a structural problem, and no single tool fixes it. The shape of the problem The classic QE model runs development on one branch and quality on another. Tests run after code is written, integration tests after services are assembled, performance and security in pre-release windows, audits at quarter-end. The pipeline can only move as fast as its slowest branch. That held when development moved at human pace: one developer, one PR, one review cycle. The gate infrastructure was sized for exactly that throughput. Build-time AI changed the math. Cursor, Claude Code, Copilot, and Codex are lifting PR velocity per developer by multiples in every organization I work with. Gates sized for human-paced review are now the bottleneck. Hour-long test suites, suites that flake at 5 percent, manual review queues: none of them scale to the new pace. The velocity did not create the weakness, it made the missing guardrails impossible to ignore. An engineering technical director of quality at a 1,000-plus-employee fintech put it the way I hear most often. The testing waterfall squeezes every testing activity into one final, all-or-nothing push. Teams declare dev complete, testing begins, and that is where it falls apart. Over a cycle, confidence never accumulates. Risk does. Six problems that compound The difficulty is not any single problem. It is that they stack, and each one inherits the weight of the one before it. Quality is structurally serial. Development and quality run on separate branches and meet at release. As development accelerates through smaller services, faster commits, and AI-assisted code, the gap between the branches widens, and QE becomes the brake the rest of engineering tries to route around. Testing tooling fragments by protocol and stage. A modern enterprise runs REST, GraphQL, gRPC, WebSocket, and event-driven services in production. Each gets its own tool: Pact for contracts, k6 or JMeter for performance, Karate or ReadyAPI for end-to-end, custom harnesses for eventing. Each produces its own report, its own coverage view, its own evidence format. There is no single picture of what is tested and what is not, and the seams between tools are where coverage leaks. Tests rot faster than they are maintained. Flaky tests get muted to keep the build green. Spec and behavior drift apart. Brittle scripts break on cosmetic changes while silent regressions slip through. Every team hits a ceiling on how many tests it can sustain, usually well below what real coverage needs. A senior director of quality at a large financial services firm told me her team launched a product and took 160 major customer-impacting incidents in production. They had tested. What they did not have was an automation suite or a regression suite. When a team is feature-driven and delivery-driven, she said, testing is the first thing that stops. The long tail goes undefended. The services that earned QE attention are well covered: the high-revenue APIs, the regulated workloads, the customer-facing checkout flows. Everything else underperforms. Defects cluster in the underinvested surface, where tests, mocks, monitors, and evidence are thinnest, and those services are often the least visible to leadership until an incident lands. Flagship coverage masks the broader exposure until something breaks. Audit evidence is a scramble, not a system. When the audit window opens, engineering capacity gets pulled off product to assemble proof: test runs, change tickets, deployment logs, and approval trails, hand-collated across tools and sometimes across quarters. A quality engineer at a top-five pharmaceutical company walked me through it: generate the environment file, generate a test plan, generate a test execution, trigger it by hand, attach artifacts by hand, mark it done by hand, route it for approval by hand. Then repeat for every protocol, every release, across multiple test levels. SEC cyber materiality disclosure, DORA, FedRAMP continuous monitoring, and PCI 4.0 are turning that model from painful into unsustainable. Evidence has to be a continuous output of the pipeline, produced as the work happens. AI amplifies every gap. This is the force that changed the urgency. Build-time AI raises the rate at which code reaches the pipeline. Runtime AI raises the rate at which APIs get exercised in unexpected ways: agents pick endpoints by name, infer parameters, and fail creatively rather than consistently. Without rich context, meaning specs, examples, mocks, known-good workflows, and traceable failure modes, AI test generation produces plausible-looking tests that miss real failures. Give AI a strong pipeline and it compounds your coverage. Give it a thin one and it produces more bugs, faster. Why it becomes visible now None of these problems is new, and most leaders I talk to can name them. What changed is that the forces converging right now make them impossible to defer. Every slow release is unrealized revenue. Every escaped defect is a customer-facing incident with reputational risk. Every quarter-end audit scramble is capacity not spent building product. And the curve is exponential, because AI amplifies whatever pipeline you already have, good or bad. So the QE function becomes one of two things: the team that limits throughput, or the team that solves it. This is the decision in front of you now. What to do now. Take the six problems above and rate each one red, yellow, or green for a single domain you own, three to ten services where the pain is visible. The reds are your structural exposure, and they compound whether or not you act on them. That map is your starting point, and the input to everything in Part 2. In the next post I break down the five metrics I use to find exactly where a pipeline leaks, one per stage. If you want to pressure-test your program first, talk to a Postman expert https://www.postman.com/postman-enterprise/ talk-to-a-postman-expert and we will walk your pipeline stage by stage.