AI-generated code arrives faster and gets stuck in the testing queue

AI-produced code speeds up raw delivery and pushes the bottleneck to validation. That's the conclusion of a DeviQA survey of 4,000 quality specialists. However, the survey was released on September 25.

The numbers make the paradox clear. However, 65% reported that new features reach validation faster.

At the same time, 64% confirmed that work arrives in parallel batches. Consequently, these batches overload the delivery flow.

Another 55% noticed increased delays in verification areas.

The fix cycle got longer, not shorter

Writing speed solves little when the next stage loses visibility. The data confirms this point.

According to the survey, 52% of teams recorded an increase in test, fix, and retest cycles. Of that total, 39% saw slight increases and 13% faced significant delays.

Only 21% observed shorter rework phases.

A manual quality engineer with 5 to 7 years of experience summed up the routine. According to him, AI writes fast, while a person remains responsible for the outcome. The main scenario works, while business logic, edge cases, and related functionality fail.

New code breaks what was already working

Here's the study's most uncomfortable finding. About 47% of professionals found code that ran the main scenario and broke other parts of the product.

In addition, 44% of defects involved disruption of existing functionality.

Three causes tied at 33% each. They are flawed business rules, unhandled edge cases, and data validation errors.

The damage also escapes the changed file. In 42% of cases, failures spread to adjacent modules.

Another 23% hit legacy components. Connections with external interfaces broke in 18% of incidents.

Context is missing when the task changes hands

The problem grows in the handoff between teams. At this point, 44% of testers worked without documented component dependencies.

Even worse, 42% received no structural impact analysis.

The result shows up in satisfaction with documentation. Only 18% described the material they received as sufficient.

Teams responded by expanding the scope of inspection

The reaction was practical. About 58% started examining adjacent functionality more rigorously.

Exploratory testing grew in 56% of teams. The same percentage implemented end-to-end suites.

Regression sweeps expanded in 52% of organizations.

Planning, in turn, split opinions. While 36% reported shorter planning phases, 29% saw greater demand at this stage.

The controls that work before the pull request

Leaders pointed out what actually catches defects. For 77%, clear acceptance criteria form the most effective control.

Next, 55% prioritized direct conversations about risk between developers and testers.

The pressure reached the author of the change. About 80% encourage the developer to personally verify compliance with the criteria before opening the pull request.

In addition, 58% require proof of local execution of the main paths. Along with that, they ask for documented review of interactions between components.

A QA automation engineer with two to four years of experience gave the recipe. According to him, it's worth focusing on architecture, breaking work into smaller tasks, giving the agent enough context, and requiring review by the responsible specialist.

The seven-point list that's becoming standard

Some organizations formalized a release checklist. It tracks the exact file modifications.

The document also maps component dependencies. Then, it defines unverified risks before functional evaluation begins.

Finally, designated human reviewers maintain responsibility for each approved commit.

Notice what this list solves. It returns to the testing team the context that automatic generation usually leaves behind.

Follow our profile on Instagram!