I make quality the competitive advantage.

Senior Manager, Accenture, AI in Quality Engineering. Based in Burlington, Ontario.
20+ years turning testing from bottleneck into accelerator, by building the tools myself, then proving what they save.

Explore my work Connect on LinkedIn

Tool

The AI in QE Savings Analysis

What can AI actually save a testing program? It depends on how far you take it: one use case at a time, or the whole lifecycle run from the spec. A short guided setup, all figures in CAD, shows both layers side by side: Layer 1, cherry-picked use cases, at −26% of QE effort, and Layer 2, Spec-Driven QE, at −42%, with coverage rising from 58% to 76% across the two layers. Stated plainly: the Layer 2 figure is my implementation experience, not a published study, and the tool shows ranges, not just point figures.

Open the Savings Analysis →

Insights

Insights

The AI × QE newsletter, new every Wednesday, plus the week’s AI news with my read on it.

Upcoming · Oct 28, 2026

Spec-Driven Development: stop vibe-coding, start blueprinting

Takeaway: a spec written as a contract is the cheapest quality gate AI makes practical.

Upcoming · Nov 4, 2026

The ROI of AI in enterprise QE: in two layers

Takeaway: count savings in hours and coverage before dollars, and separate research from vendor claims.

AI × QE: the newsletter

A weekly LinkedIn newsletter on AI in quality engineering, new edition every Wednesday.

Subscribe on LinkedIn ↗

Recent AI news

The last two weeks →

About

About

I’m DJ Chanda. I build AI tools for quality engineering (FAST, Press-n-Go, the spec-driven framework) and I lead QE transformation for enterprise clients at Accenture. Two decades across banking, payments, insurance, retail, and public-sector systems taught me the one lesson I keep coming back to: quality holds when it’s engineered in, not inspected in.

I still think like a tester. Baseline first. Measure honestly. Specs as contracts, evidence over demos, a human on every irreversible step, and never let a tool grade its own homework. What I care about is work a planning meeting can rely on: numbers with their baselines and limits attached. If a number can’t show where it came from, I don’t trust it, and I don’t expect you to either.

Home is Burlington, Ontario, where I live with my wife and our two boys. The work matters to me. It just isn’t the whole story.

Role
Senior Manager, Accenture, Custom Application Engineering
Focus
AI in Quality Engineering: QE transformation, test automation, and performance engineering
Based in
Burlington, Ontario: home is my wife, our two boys, and the crew in the photos below
← Back to the site

The AI in QE Savings Analysis

Tell me how your testing runs today. I'll show you what AI can save, in two layers.
Layer 1: cherry-picked AI use cases, one at a time. Layer 2: Spec-Driven QE, spec as contract, tests generated from it, eval gates in CI. You answer plain questions; the model does the rest. Every number names its evidence.

How your testing runs today

Start with the guided setup: five answers and both layers recompute instantly, beside the inputs. Tools, pyramid, testing types, and lifecycle phases sit under Advanced settings, pre-set to sensible defaults.

Your program

Guided setup: starting answers describe a mid-size enterprise team: 15 QE engineers, 10 releases a year, mixed manual/automated. Change any number to your own; results update as you type.

Your real cadence: cadence turns per-release savings into annual ones.

Your real headcount: the effort pool savings come from, at 1,880 hours per engineer-year.

Traditional automation plateaued at 23–25% (Forrester, 2025). Your position sets the headroom and the baseline coverage.

AI-ready frameworks get more from the same use cases than legacy stacks.

Regression selection learns from run history. No history, smaller gain.

Inverted pyramids make AI gains slower and pricier. Healthy pyramids compound them.

Used only to price the hours. The hours are the real answer. All money on this page is CAD.

Your estimate: tooling, rollout, training. Kept separate from the savings so net value stays honest; leave at 0 if you only want capacity.

Types of testing you run Tap to toggle. Each type switches on the AI use cases that apply.

Phases of the lifecycle you run in-house AI only saves effort in work your program actually does.

Two layers, two different answers

-

Layer 1: Cherry-picked AI use cases

-

of total QE effort saved per year, use case by use case

Effort saved / year
-
Value of that effort / year
-
Released capacity
-
Implementation cost (your est.)
-
Net value, year one
-
Execution speed
-
Coverage
-
Regression cycle
-

-

AI adopted activity by activity. Gains come from the published ranges below, adjusted for your tooling and pyramid, and capped where the evidence caps. Cherry-picking plateaus: each use case only touches its own activity.

Layer 2: Spec-Driven QE

-

of total QE effort saved per year, end to end from the spec

Effort saved / year
-
Value of that effort / year
-
Released capacity
-
Implementation cost (your est.)
-
Net value, year one
-
Execution speed
-
Coverage
-
Regression cycle
-

-

Everything in Layer 1, plus the connective layer: tests generated from the spec and checked by gates, so phases stop handing effort to each other. This figure is my implementation experience, 38–48% across enterprise programs, not a study result.

Write cases faster → testing starts sooner

-

Automate faster → execution finishes sooner

-

Find defects sooner → remediation costs less

-

What the client should do: the Spec-Driven QE path

Layer 2 is an operating model, not a bigger licence. It pays only if the client changes how work flows. Five moves, in order:

  1. Write specs as contracts. Versioned spec (intent, scope, acceptance criteria) approved before any code or test is generated. The spec, not the prompt, is the source of truth.
  2. Make acceptance criteria executable. Tests are generated from the criteria; every test traces to a requirement. A criterion that can't be made executable gets flagged while it's cheap to fix.
  3. Gate every AI-generated asset. Build, flakiness, and coverage checks in CI. Nothing generated merges unchecked. The verification loop, not the model, turns AI output into quality.
  4. Keep humans on irreversible steps. Approval boundaries on merges, releases, and production. People stop typing tests and start judging them.
  5. Baseline first, then track outcomes. Coverage, escape rate, and flake rate measured before adoption, reviewed after. Half the industry doesn't measure escaped-defect cost at all (PractiTest, 2024).

The honest limit: no peer-reviewed outcome study of spec-driven adoption exists yet, and blog-scale SDD speed claims have no identifiable study behind them. Layer 2 numbers are my experience, labelled as such. The evidence does support the mechanism: with a verification loop, generated tests stopped rejecting correct behaviour (canonical pass 30% → 100%, ReqTestAgent ablation); without one, they rejected it up to 68% of the time.

Tools that fit your answers

Independent platforms, matched to your answers. None of them are mine. I sell judgement, not tools, and take nothing from any vendor listed.

The data behind these numbers

Layer 1: measured, with the hedges on

  • Regression selection: the strongest evidence in testing. Meta's predictive test selection cut test-infrastructure cost ~2× while surfacing >95% of test failures and >99.9% of faulty changes (ICSE-SEIP 2019). An independent 2025 study ran ~15% of tests, cut execution 5.9×, detected >95% of failures. The saving is a decision to miss a small share of failures, backstopped by full-suite runs.
  • Test generation: only behind a filter. Meta's TestGen-LLM (FSE 2024), behind build, flakiness, and coverage filters: 57% of generated tests passed reliably; engineers accepted 73% of recommendations. Unfiltered, the best model reached 35.2% coverage and an 18.8% mutation score (TestGenEval, ICLR 2025). The filter is the product. Generation gains count only where a checking step exists.
  • Script generation: the honest range is wide. Trials span 55.8% faster on a small greenfield task (Copilot RCT, 2023), ~26% more tasks across 4,867 developers (Cui et al.), and 19% slower for expert maintainers on their own codebases (METR, 2025). This model uses the middle, adjusted for your stack.
  • Self-healing: vendor numbers, counted small. Every quantified claim (70–90% of UI-change failures auto-resolved) is vendor marketing, no published method. The mechanism is real for locator drift only, and a heal can mask a real defect, credited here as one small maintenance category.
  • Performance and exploratory AI: assistive only. No quantified enterprise effect size exists for AI in performance testing; exploratory agents have no controlled study. Both counted at token weight, drafting help, not savings engines.

Layer 2: experience, and the two warnings

  • The figure is experience, not a study. 42% (range 38–48%) is what I've seen implementing spec-driven QE in enterprise programs. No peer-reviewed outcome study of spec-driven adoption exists. This page won't dress it up as one.
  • Why it works when it works: the verification loop. ReqTestAgent ablation: adding execution-and-verification to generation took canonical pass rates from 30% to 100% and mutation scores from 0.216 to 0.678. MutGen (2025) shows the same lever. Specs as contracts plus eval gates is that loop, run as an operating model.
  • Warning one: the base rate. 46% of enterprise AI PoCs were scrapped before production in 2025; 42% of companies abandoned most AI initiatives (S&P Global). Layer 2 assumes the operating model is actually adopted, gates, baselines, and all. Half-adopted, it performs like an expensive Layer 1.
  • Warning two: perception lies. In METR's 2025 trial, developers using AI were measured 19% slower while believing they were ~20% faster. Baseline first; judge on coverage, escapes, and flake, never on how fast the team feels.

Method

How the estimate works

Your answers set the size of the program: QE effort per year = team size × 1,880 hours. Layer 1 then adds up the use cases your answers switch on (test design, script generation, regression selection, self-healing, triage, test data, reporting, and the rest), each contributing the share of effort its published evidence supports, adjusted by your automation tool's aptitude, your test-management history (selection needs it), and your pyramid shape. The Layer 1 total is capped at 30% of effort, because that is where cherry-picking plateaus in practice.

Coverage starts from a baseline derived from your automation share and pyramid (an automation-first, healthy-pyramid program starts high; a manual, inverted one starts low), and each layer adds the points its use cases can defend, capped, because coverage bought by generation alone is coverage without verification. Execution speed is the reduction in regression-cycle time: per release, execution is modelled at 35% of QE effort and test design at 25%. Stated assumptions, the same for every visitor, so two programs answering alike get alike answers.

Layer 2 replaces the sum with the operating-model figure: 42% of effort (range 38–48%), execution speed carried a further step beyond Layer 1, and coverage lifted end to end, because in a spec-driven program the gains are not confined to the activities you remembered to cherry-pick.

How to read the result

  • Hours first, dollars second. The dollar figure is your hours at your rate. It moves when your rate moves. The hours, the speed, and the coverage are the substance.
  • Capacity, not headcount. Saved effort is hours your team gets back: for the coverage you never had time for, the exploratory testing that keeps getting cut, the backlog. What leadership does with released capacity is a leadership decision; this analysis will not dress it up as a reduction plan.
  • Ranges, not promises. Every figure here is an estimate from evidence and experience, to be replaced by your own pilot readout. If a vendor shows you a bigger number with no evaluation step and no source attached, you now know which questions to ask.
  • The gap between the layers is the argument. If Layer 1 already looks good, Layer 2 is what the same investment returns when it stops being a collection of tools and becomes how the program runs.

Want this run on your program? The analysis gives you the shape. Baselining, eval gates, sequencing on your stack, knowing which vendor numbers to ignore. That's the work I do with enterprise QE teams.

Talk to DJ on LinkedIn ↗
← Back to the site

AI news, week by week

The AI stories that matter for quality engineering, one line each, source linked.
The last two weeks, newest first. A new week lands every Friday; the oldest rolls off.

Last updated October 19, 2026. The interpretations under each item (why it matters for QE, and what I would test next) are mine.

Week of Oct 12–19, 2026

Latest