Where QC creates value
when delivery becomes continuous

Recommendation — Codex inference: keep QC embedded in the three teams during the transition. Move their primary contribution toward defining acceptable behavior, finding risks the checks miss, and improving the system that produces release evidence. Fund that transition with developer time and reduced feature commitments. Do not derive a headcount reduction from AI code-generation speed.

The desired change is sound, with one qualification: an engineering system can continuously produce evidence that a change satisfies specified conditions. It cannot generally prove that the product is correct in every situation. Someone must still challenge the conditions, the checks, and the remaining risk.

1. Background and scope

User-provided context: three Scrum teams working as a Nexus, with a ratio of five developers to three Manual Quality Control Engineers, moving toward continuous delivery in an agentic software engineering environment.

Planning assumption: the ratio describes each team. That gives 15 software developers and nine QC engineers, or 24 people across these two specialties. QC is 37.5% of that group; this is arithmetic, not an industry benchmark. Product Owner and Scrum Master capacity are outside this calculation. If 5:3 describes the entire Nexus instead, use the same work design but share specialty coverage across teams; the nine-person allocation below would not apply.

Background: Quality work spans product intent, domain rules, implementation, and operational behavior. This study connects independent verification to an organizational question: where people create value, how capacity moves, and what makes a transition credible.

Evidence boundary: researched on 14 September 2026, using sources published by that date. Recent evidence includes a 31 August 2026 engineering account. organization case studies below are first-party reports, not independent audits. No verified case in this research establishes an optimal 5:3 ratio or documents this exact nine-person QC transition.

Continuous delivery means being able to release on demand safely and sustainably. Continuous deployment adds automatic production deployment of changes that pass the relevant controls. A team can achieve delivery while keeping an explicit release decision. DORA: continuous delivery

“Agentic” here means agents help plan, edit, execute tools, test, and repair software. It does not mean the product itself contains AI. Testing an ordinary application built by agents and evaluating an AI feature are related but different jobs.

2. What the evidence supports

Sources: Continuous Testing, DORA, March 2026, Meta paper, 2024, METR update, February 2026, Nexus Guide, January 2021. The limits of testing and the staffing implications are analysis, not measured results from these sources.

3. Where QC creates value

Proposed work design — Codex inference. QC's enduring skill is investigating the gap between intended behavior and observed behavior. Put that skill at several points in delivery, with concrete outputs.

Do not make all six areas separate jobs. Each team needs coverage of the first five; agent evaluation needs dedicated capacity only when its use and risks warrant it. A QC engineer can be strong in domain analysis and exploration while gradually learning technical investigation. An automation specialist needs deeper programming skills. These are valid complementary paths.

The minimum technical progression should include reading a change, calling an API, understanding data state, reading test results and logs, and explaining why a check should fail. An agent can help draft a script; it cannot substitute for the person's ability to explain its assertion.

The value statement becomes: “I improve the evidence and decisions that let this team release safely.” Counting executed test cases will reward the old work even after job titles change.

4. A realistic arrangement for nine QC engineers

Proposed starting arrangement, not a staffing benchmark: retain three QC engineers in each team. Let them develop complementary focus areas while remaining responsible for their team's product work.

These are learning emphases, not three isolated queues or mandatory job titles. Rotate pairing and share knowledge. Assign focus based on demonstrated skills and interest; there is no evidence here about any individual's suitability. Initially A may help B specify cases while B helps A inspect API responses.

Across the Nexus, the three people emphasizing integration maintain a shared map of critical journeys and dependencies with developers. Their work remains visible in the product backlog and team capacity. They do not become a final testing department that receives completed work from all three teams.

The Nexus Integration Team remains the accountability that ensures a Done Integrated Increment. Its members help resolve integration constraints; it is not prescribed as a separate group that performs every integration task. Nexus Guide

Within Scrum terminology, QC specialists who help create the Increment fall under the Developers accountability. “Software developer” in the 5:3 ratio is an occupational distinction. Quality belongs to the team. Sprint boundaries also do not require releases to wait for the Sprint Review. Scrum Guide, November 2020

Suggested division of work: the PO clarifies product intent and priorities; domain experts validate domain rules; QC leads risk discovery and challenges evidence; software developers build testable code and maintain its checks; technical leadership supports architecture and delivery infrastructure. Operations or the team operating the service supplies production expertise. Map release and risk decisions to the existing organization’s authority. This study does not appoint new owners or change its RACI.

5. Replace the handoff with an evidence loop

Proposed delivery pattern — Codex inference. Start with one customer journey and make the evidence visible beside the change.

1. Frame: identify the user outcome, unacceptable failures, examples, affected teams, and unknowns. QC helps make the acceptance criteria testable.
2. Build: a developer or agent implements a small change with suitable checks. Developers make seams for testing and deterministic data setup.
3. Challenge: run checks that could reject the implementation. QC investigates important gaps, and another qualified person reviews changed expectations.
4. Integrate: check the actual combination of changed components, including contracts, permissions, and schema compatibility.
5. Release: apply the risk policy to the built artifact. Use staged exposure where appropriate, explicit stop conditions, and a tested recovery method.
6. Learn: connect incidents, exploration findings, and customer signals to missing examples, checks, or monitoring. Feed improvements into the backlog.

An evidence record can be a compact, automatically assembled section in the pull request or delivery system. It contains the intent and acceptance version, change and artifact identifiers, affected components, test results and environments, unresolved risks, required review, and rollout/recovery evidence. Do not ask QC to manually copy pipeline output into a second document.

Evidence belongs to the specific candidate. A material change after checks ran needs relevant checks again. Missing, stale, skipped, or inconclusive required checks are not passing evidence. An exception records its reason, scope, authorized decision-maker, and expiry; routine overrides are a signal that the control needs repair.

This makes QC's review more focused: “Which conclusion is unsupported?” becomes more useful than repeating every familiar screen flow.

6. What changes because agents write software

Proposed controls — Codex inference. Cheap test generation can increase the volume of weak checks. Separate the authority to define expected behavior from the convenience of generating implementation details.

Using a different model to review is an additional perspective, not demonstrated statistical independence. Stronger independence comes from externally grounded rules, controlled data, different check mechanisms, and people who can reject the premise. A deliberate fault can test whether a critical assertion catches the intended error; it still cannot establish complete correctness.

For a product that contains an agent, evaluate final state as well as responses: did the action occur correctly, did it obey the allowed boundaries, and did it leave unwanted side effects? For subjective quality, use a rubric with human calibration. Repeat representative scenarios when variability matters. Anthropic describes this combination of outcome checks and calibrated evaluation practices in its January 2026 engineering guidance. Demystifying evals for AI agents

For an ordinary product built with coding agents, keep normal application checks central. A separate agent evaluation program should earn its cost by answering a concrete question, such as whether a harness update increases incomplete fixes or weakens tests.

7. Risk determines the release path

Illustrative policy, not an approved standard. Classification considers customer impact, reversibility, uncertainty, and ability to detect failure. Change size alone is insufficient.

A feature flag can reduce exposure; it cannot undo corrupted data or already disclosed information. A canary helps only if the relevant failure is observable and the sample is meaningful. Rare critical failures need strong pre-release controls even when the traffic dashboard looks healthy. These are reasons to strengthen particular evidence, not reasons to require a full manual regression for every change.

8. One worked example across three teams

Hypothetical equipment-management example; not a claim about an existing product, incident, or decision. Team A owns inspection capture, Team B owns status calculation, and Team C owns exports and reporting. A change allows an inspection correction after submission.

The obvious test edits a result and sees the new status. QC adds the harder questions: who may correct it; which version a report shows; what happens to the audit history; whether another tenant can see the correction; and what an old client does while the new API rolls out.

Before implementation, QC helps settle the rules. During implementation, an agent can draft fixtures and tests; people inspect expected results. Before exposure, QC explores unusual sequences while the system reruns known checks. After exposure, QC helps investigate mismatches and improve the dataset.

The reusable asset is the agreed behavior and its evidence. The manual session still creates value because it searches for missing behavior, not because it repeats everything already checked reliably.

9. Transition over six to twelve months, with readiness gates

Planning hypothesis — not an observed duration or a promise. A narrow pilot may show useful changes in 90 days. Broad capability across all three teams could need six to twelve months or longer. Legacy coupling, unstable environments, sparse telemetry, and limited mentoring can dominate the schedule. Advance on evidence, not elapsed time.

During the pilot, try protecting 20% of QC capacity and 10% of software developer capacity for learning and improving verification. These are illustrative budget choices. Across nine QC and 15 developers that is 1.8 QC and 1.5 developer full-time equivalents, spread across people—not additional staff or immediate savings. In a five-day week, it is roughly one day per QC and half a day per developer. Pairing time counts inside both allocations.

Management must reduce feature commitments accordingly. “Learn automation while keeping every old test and every old deadline” is not a funded transition. Avoid promising equal output during the investment period. Choose one pilot team; the other two contribute only where the selected journey crosses their boundaries.

A possible later QC work mix: 15% repetitive verification, 25% acceptance and risk work, 25% automation and evidence maintenance, 20% exploration, and 15% integration and operational learning. This totals 100% and is a discussion model, not a measured baseline, productivity forecast, or quota. Actual allocation should follow risk and capability.

10. Career paths and learning without pretending everyone is already an engineer

Proposed development paths. Keep domain expertise valuable while increasing technical self-sufficiency. Do not require everyone to become an automation framework maintainer.

Use real product work as the curriculum. Begin with API requests, data inspection, logs, and basic Git; add small test changes and CI diagnosis; then progress toward independent maintenance. Pairing, examples, and review are part of delivery capacity. Judge skill by an explanation and a working artifact, not by certificates or generated test volume.

The uncomfortable part: a role consisting only of repetitive scripted manual execution becomes narrower as those checks become reliable automation. Retraining does not guarantee that every person will prefer or master the same new work. Offer several paths and assess progress fairly. These sources support investing in capability; they do not guarantee unchanged staffing indefinitely or justify an immediate reduction.

11. Success stories, with their limits

Dropbox: turn domain interpretation into continuous checks — August 2026

Dropbox reports an auditor for cookie behavior across more than 200 web surfaces. Privacy and Engineering first agreed what correct behavior meant. Playwright then exercised consent choices in isolated sessions and checked behavior after reload. Classifications stayed outside the auditor's code so policy knowledge could be maintained separately. Dropbox, 31 August 2026

Transferable lesson — inference: QC can help make domain rules executable and identify what the inventory misses. Limit: this is a scoped first-party practice account, with no quantified QC redeployment or defect-reduction outcome. It does not establish an agentic staffing model.

Meta: generated tests earn admission — February 2024

In a Reels and Stories evaluation, Meta reports that 75% of TestGen-LLM cases built, 57% passed reliably, and 25% increased coverage. In separate Instagram and Facebook test-a-thons, 73% of recommendations were accepted by engineers and 11.5% of targeted classes improved. These are different populations and denominators. Meta research paper, 14 February 2024

Transferable lesson — inference: the filtering and review process creates value alongside generation. Limit: coverage and accepted recommendations are not demonstrated reductions in customer incidents or staffing needs. Do not read “73% accepted” as “73% of all generated tests were useful.”

Dropbox: faster releases required infrastructure and ownership — 2016, reported 2017

Dropbox reports moving major desktop releases from every eight weeks to every two, with daily internal alpha builds. Investments included automated builds, integration testing, quality metrics, and explicit failure routing. Engineers worked to stabilize tests before expanding them. Dropbox, 21 April 2017

Transferable lesson — inference: automate repeated work while investing in diagnostics and ownership. Limit: this predates coding agents, retained stabilization controls, and describes a desktop release context. It supports a gradual investment pattern, not a claim of continuous production deployment or a target team ratio.

Counterweight: productivity evidence is still context dependent

DORA's 2026 discussion connects AI adoption with both throughput and instability and describes effort moving into verification. These are associations and qualitative findings, not a causal staffing forecast. METR's February 2026 update explicitly warns that selection and timing problems make its newer productivity estimate unreliable. Neither source supports assuming that faster code creation releases an equivalent amount of QC capacity. DORA, METR

12. Measure the transition as a system change

Proposed pilot scorecard. Combine delivery outcomes with evidence quality and actual time use. Keep raw counts and context beside percentages. DORA's current measurement guidance covers throughput and instability; the QC-specific measures here are local proposals. DORA metrics

Collect a two-week time-use baseline, but use a longer historical incident window if available. Evaluate over enough changes and representative releases; two quiet weeks cannot establish safety for rare failures. Compare the same journey and record changes in scope, staffing, and release volume. A before/after pilot is useful operational evidence but cannot isolate AI's causal effect by itself.

An illustrative exit discussion after 90 days is: did manual regression effort fall for the pilot, did total lead time improve, did customer harm stay within the agreed tolerance, and can the team maintain and recover the system? Choose numeric thresholds from the baseline before the pilot. Pause expansion if severe escapes occur, required evidence is bypassed, or maintenance consumes the apparent savings. Investigate the cause; retain manual checks where evidence remains weak.

The economics are simple: net capacity released = retired repetitive effort − added maintenance − ongoing review and investigation overhead. Track the one-time build and training investment separately. Time moved into previously neglected risk work is valuable even when it is not a staffing saving.

13. A practical first month

Suggested experiment — not an organizational decision. Select one frequent, reversible journey with meaningful manual regression and a developer willing to pair. Avoid beginning with the most dangerous migration or an entire regression suite.

In week one, observe the current flow and collect failure examples. In week two, agree a handful of acceptance and negative cases with the relevant domain authority. In week three, build reliable data and checks that fail on representative defects. In week four, run them alongside the existing process, compare results, and inspect maintenance effort.

The review should show a real change, its evidence, a deliberately detected fault, a remaining uncertainty, and the human time spent. Decide from that evidence whether to extend the pilot. The first success is a credible reduction in repeated inspection for one bounded scope, with stronger understanding of its risks.

14. Open questions before adopting the proposal

The study can recommend a direction without inventing the team's starting state. A concrete rollout needs answers to these questions: does 5:3 apply per team; how much QC time is repetitive execution today; which people want each learning path; how reliable are current CI and environments; which journeys cross teams; who operates the product; which changes require domain or external acceptance; and what can be rolled back or repaired safely?

The main decision is whether to fund QC and developers to improve the acceptance and verification system together. Without that capacity, the likely outcome is a faster implementation queue waiting for the same manual inspection stage.

Sources and further reading

All sources below were accessed on 14 September 2026. Publication dates are stated where verified; undated capability pages are living guidance. No quoted industry ratio, vendor productivity estimate, or staffing forecast has been used as a target.