AI-Assisted Bug Escape Prevention System

Summary

This project was broader than a test-plan critique assistant. The idea was to prevent software bugs from reaching customers by analyzing new code changes before release, identifying uncovered or weakly verified behavior, generating structured test intents, and eventually producing human-reviewed test-code changes.

The work is intentionally framed as conceptual design and prototype-level planning, not a shipped production system. Its value was in defining a rigorous upstream workflow for bug escape prevention.

Context

Failure investigation looks backward after a regression has failed. Bug escape prevention asks a harder upstream question: before a change reaches customers, do we understand which behavioral paths changed, which paths are tested, which paths are actually verified by meaningful assertions, and which risks still need SME attention?

The design explicitly moved beyond simple code coverage. Executing a path is not the same as verifying correctness, so the workflow treated path coverage, oracle strength, mutation effectiveness, runtime cost, and flake risk as separate signals.

Problem

The primary problem was customer-visible bug escapes caused by incomplete impact understanding, missing regression coverage, weak assertions, untested edge cases, and late discovery of code-change risk.

Test planning often depends on expert judgment, historical memory, and awareness of subtle product interactions. The proposed system was meant to make that reasoning more systematic without pretending the AI could replace SME judgment.

Design goal

The design goal was to create a human-in-the-loop system that could analyze every relevant code change before release, map the changed symbols to behavioral paths, identify execution and verification gaps, propose test intents, and produce evidence that risks were either closed or explicitly accepted by reviewers.

The system was prevention-oriented, not postmortem-oriented. It was intended for code review, test planning, pre-merge, and pre-release workflows.

Proposed workflow

• Phase 1: build a touched-components report, impact graph, exhaustive behavioral path catalog, and path risk recommendations.
• Phase 2: run selected feature or regression tests, then produce execution gap, oracle gap, and mutation-survivor reports.
• Phase 3: generate a test plan pack with oracle suggestions, data generation plans, edge cases, negative tests, metamorphic relations, and fuzz or property-based testing candidates.
• Phase 4: generate test-code changes and an evidence pack showing paths covered, gaps closed, mutants killed or surviving with reasons, runtime impact, and flake risk.
• SMEs review risk recommendations, decide which gaps matter, approve or edit test intents, review generated diffs, and approve or reject merges.

Inputs and context

The proposed inputs were code-change and test-context artifacts rather than only a written test plan. Public-safe examples include changed files, changed symbols, entry points, public APIs, constants, error codes, configuration checks, existing test suites, impact graphs, path catalogs, dynamic traces, coverage evidence, exception paths, runtime events, existing assertions, mutation-survivor results, SME annotations, formal test-strategy documents, feature descriptions, product documentation, and optional test patterns or style guides.

The design did not specify a RAG architecture as the central mechanism. Context quality would primarily come from code structure, test execution data, existing tests, mutation results, SME notes, product context, and formal strategy inputs.

Structured outputs

The system would produce several artifact types across the phases: touched-components reports, impact graphs, behavioral path catalogs, path risk recommendations, execution gap reports, oracle or assertion gap reports, mutation survivor reports, unified gap prioritization, test plan packs, oracle-library suggestions, data generation plans, generated test-code changes, evidence packs, and regression-selection metadata updates.

The test intent specs were designed to be explicit: purpose, setup, stimulus, oracle, failure modes, determinism notes, runtime cost, invariants, negative tests, metamorphic relations, and fuzz or property-based testing candidates.

Human ownership

SMEs remained the control point throughout the proposed workflow. They would annotate risk, attach domain notes, confirm which gaps matter, mark acceptable will-not-test cases, identify proper oracles, approve or edit test intents, verify runtime classification, review test-code diffs and evidence packs, and approve or reject merges.

The AI would recommend, generate, and provide evidence, but it would not autonomously approve coverage, block releases, decide product correctness, replace SME judgment, or own acceptable-risk exceptions.

Evaluation approach

The evaluation framing combined engineering signals and expert review. Success would be measured through path-schema coverage closure, oracle-strength distribution, assertion metrics, mutation sampling deltas, mutants killed, surviving mutants with reasons, test runtime, flake rate, and gaps closed.

A strong end-to-end evaluation set would include historical escaped-bug cases and SME review of whether the proposed gaps, tests, or generated changes would have exposed the issue earlier.

Why the project was paused/reprioritized

At the time of proposal, the higher priority in the department was broader AI adoption enablement. I was asked to contribute to department-wide AI education and adoption efforts first, saving this larger human-in-the-loop codebase automation undertaking for later.

That matters for maturity framing: this project clarified a serious upstream AI opportunity and practical architecture, but it should not be described as a productionized escaped-defect reduction system.

Value of the design

• Defined a phased architecture for bug escape prevention.
• Clarified why simple coverage is insufficient without path coverage, oracle strength, and mutation effectiveness.
• Connected code-change impact analysis to test-gap analysis, test-plan generation, automated test implementation, and evidence review.
• Identified the need for stable path identifiers to connect analysis, coverage, test generation, and evidence.
• Kept SMEs as final owners of coverage decisions, oracle correctness, runtime placement, merge approval, and acceptable-risk exceptions.
• Framed quality improvement around measurable evidence such as gaps closed, oracle strength, mutation deltas, runtime, and flake rate.

What I learned

Upstream AI workflows need especially careful framing because their output influences what teams choose to test before customers see the result. The goal is not to make a model sound like a confident reviewer; it is to make risk, coverage, verification strength, and uncertainty visible enough for experts to make better decisions.

The design also reinforced that AI-generated tests are only useful when connected to evidence: what path they cover, what oracle they assert, what mutants they kill, how expensive they are to run, and how likely they are to be flaky.

Limitations

This was a high-level conceptual framework and prototype plan. The real implementation complexity would depend on the quality of code-change analysis, path extraction, dynamic traces, test harness integration, mutation sampling, and SME feedback loops.

Path completeness is hard in real systems. Loops, recursion, polymorphism, dynamic dispatch, configuration-sensitive behavior, and concurrency interleavings require careful abstraction rather than naive enumeration.

Coverage is not enough, oracle quality is difficult, false positives can waste reviewer time, and generated tests can be brittle or flaky. The design therefore kept SMEs as final owners of coverage and release decisions.