Claude Code and 11 agents: how a QA team automated up to 80% of routine testing

A QA team has shown that AI agents can already take over most of the routine testing work: from reading requirements and designing scenarios to loading test cases into a TMS and opening a Merge Request with ready-made autotests. Instead of expanding headcount by two more testers, the team built an "exoskeleton" of 11 specialized agents on top of Claude Code, and says it covers up to 80% of a QA engineer's operational work.

The starting point was a familiar problem for product teams: development ships new features faster than testing can turn requirements into scenarios, data and automation. By the team's internal estimate, about 20% of QA time goes to requirements analysis and test design, another 15% to creating cases in the TMS, 10% to preparing data and 25% to automation, with the checks themselves, regression and reporting coming after that. In total, up to 80% of the workload can be described by rules and broken into repeatable stages.

Hence the idea: not to replace the engineer, but to turn them into a pipeline operator who sets the task, controls the artifacts and steps in only where the system lacks context or an ambiguous decision has to be made.

The architecture is a modular chain of 11 skills plus a separate orchestrator. One agent pulls the task from Jira and related materials from Confluence, another decomposes requirements into User Stories and tasks, and a third generates test scenarios following ISTQB rules. The next ones handle missing data, discrepancies, DOM selectors, API and UI autotests, comparing scenarios with code, loading cases into Zephyr Scale and creating a Merge Request in GitLab.

JSON scenarios with full traceability to requirements and acceptance criteria serve as the single source of truth, while an RTM coverage matrix is built in parallel. For the frontend, the system also reaches into Figma via MCP and extracts not just screenshots but the interface structure, states and element constraints.

The team put particular emphasis on quality and on guarding against typical LLM weak spots. After scenario generation, the orchestrator runs quality checkpoints: it verifies the JSON schema, completeness of steps, priorities, absence of duplicates and requirements coverage. After autotest generation the control gets even stricter: the Python code, fixtures and the test run itself are validated.

Debugging uses a two-stage scheme. First, the system runs each test separately and distinguishes problems in the test code from real product defects. Then mutation testing kicks in: for a test that has already passed, the assert is inverted, and if the test still stays green, it is considered empty and needs rework.

Another important layer is a protocol for discrepancies between Jira, Figma, the requirements text and the actual behavior of the interface. Obvious conflicts are resolved automatically according to a hierarchy of source priorities, while disputed cases are escalated to the engineer.

In practice, the pilot delivered, within a month and a half, the kind of numbers these experiments are usually launched for. The number of regression test cases grew from roughly 50 to 400, scenario detail became complete, and automation coverage of regression approached 100%. The regression run itself shrank from about one day to tens of minutes, the path from development completion to QA approval went from several days to several hours, and onboarding testing for a new project now takes about four hours of setup instead of months for hiring and adaptation.

In addition, the system began finding more hidden contradictions in requirements and more bugs than the manual process. The pilot version runs on a Claude Pro subscription at $100 per month and, as claimed, can serve 2–3 projects with more than 100 tests per month each.

The main takeaway from this case is that the QA role is indeed starting to shift from manual execution to managing context, rules and the quality of decisions made by AI. But the story works only under several conditions: requirements must be reasonably complete, the project must have a proper source of context such as API contracts and test data, and the pipeline itself must not be a "black box". The value here lies not in magical test generation but in a transparent chain of steps that can be rerun, checked and gradually strengthened.

If this approach takes off beyond pilots, the testing market may get not a replacement for engineers but a far more productive and scalable way for them to work.