# How AI fits into software quality AI changes the economics of verification, but not uniformly. What sorts the effect by method is **AI's relationship to the oracle**: whether AI *is* the oracle, *consumes* one, or *writes* one. That is the split this section is organized on — the oracle being whatever decides an output is correct ([oracle axis](https://quality.stereobooster.com/oracle.md)). The same shift also makes AI a prolific source of the code being checked, with a characteristic failure mode — plausible but subtly wrong — surveyed in [bugs in AI-generated code](https://quality.stereobooster.com/ai-generated-code-bugs.md). A companion page on [agent experience](https://quality.stereobooster.com/ai-agent-experience.md) takes the supply side: how a codebase's readability and feedback loops set what an agent can do in it, and why that can be measured, unlike human developer experience. An agent that holds tools is also a system to be verified rather than a tool to verify with, and that turns it back into an ordinary security target. [Agent security testing](https://quality.stereobooster.com/agent-security-testing.md) is the method, classified in the domain family alongside penetration testing. That relationship comes in three kinds. Where no fast, sound oracle exists, AI's verdict has to stand in for one — AI *is* the oracle. Where one exists, AI either produces the thing being checked (it *consumes* the oracle) or authors the check itself (it *writes* the oracle). The division is an organizing convenience, not a theory; it earns its place because each kind predicts how far to trust AI. A method can sit in more than one — example tests are written by AI (an authored oracle) *and* run under a test runner (a consumed one). A dated tool catalog runs one page per method family, mirroring the [methods catalog](https://quality.stereobooster.com/methods.md). A snapshot, not a directory. ## AI is the oracle No sound oracle exists, so a model's verdict stands in for one: LLM as judge, a reward model, an AI code review. The only ground truth is human consensus, which the verdict approximates. The one correctness lever is the *scaffold* (a checklist, STRIDE, a rubric) — completeness, since soundness is unavailable. ### Current state The densest tooling and the thinnest evidence. Code review, requirements and threat-modeling copilots, and the observability / AIOps summary layer cluster here; the tooling is advisory and vendor claims dominate. AI fails predictably at intent-vs-implementation drift, production semantics, and social context. #### Judging intent and design | Method | What AI does | Trap | | --- | --- | --- | | [Threat modeling](https://quality.stereobooster.com/threat-modeling.md) | STRIDE enumeration from an architecture description ([STRIDE-GPT](https://github.com/mrwadams/stride-gpt), Auspex (Crossman et al. 2025)[^crossman2025]) | False comprehensiveness — a plausible list that misses the domain-specific threat | | [Code review](https://quality.stereobooster.com/code-review.md) | PR review ([Open Code Review](https://github.com/alibaba/open-code-review), [PR-Agent](https://github.com/The-PR-Agent/pr-agent)); catches low-level defects (null derefs, missing error handling, leaked secrets); design-level review is attempted (Rasheed et al. 2024)[^rasheed2024] but unproven, echoing human review's known skew to low-level issues (Bacchelli and Bird 2013)[^bacchelli2013] | Treating AI review as a *replacement* rather than a triage pass | | [ADRs](https://quality.stereobooster.com/adrs.md) | Drafts *Context* / *Consequences* prose; flags PRs touching a decision | An ADR with no human decision behind it is decoration | | [Requirements quality checking](https://quality.stereobooster.com/requirements-quality-checking.md) | Per-requirement ISO 29148 scoring (Lubos et al. 2024)[^lubos2024]; ambiguity detection | Cross-requirement contradiction detection is research-grade only | | [Refactoring practice](https://quality.stereobooster.com/refactoring-practice.md) | Mechanical refactors at scale; the change runs under the test suite (a Tests oracle) | *What* to refactor, *whether* it's worth it, and the social context have no sound oracle | | [Checklists](https://quality.stereobooster.com/checklists.md) | Generates a launch / on-call checklist from a service description | A generic list misses the routinely-skipped items that are the whole point | #### Judging runtime signals | Method | What AI does | Trap | | --- | --- | --- | | [Monitoring and observability](https://quality.stereobooster.com/monitoring-and-observability.md) | Triage: cluster correlated alerts, summarize log spikes (Notaro et al. 2021)[^notaro2021] | SLO/alert catalogs from code alone are production-naive | | [Chaos engineering](https://quality.stereobooster.com/chaos-engineering.md) | Experiment hypotheses from manifest inspection ([ChaosEater](https://github.com/ntt-dkiku/chaos-eater) (Kikuta et al. 2025)[^kikuta2025a], research) | Designing a *useful* experiment needs production semantics (blast radius, tiering) | | [Change-point detection](https://quality.stereobooster.com/change-point-detection.md) | Reads the metric series and attributes the regression to a diff | Pinning environmental drift (hardware, input changes) on a commit | | [Supply-chain hygiene](https://quality.stereobooster.com/supply-chain-hygiene.md) | CVE-noise triage, SBOM diffs; [Socket.dev](https://socket.dev) behavioral risk | Reachability triage is static analysis with an LLM front-end, not an AI verdict | | [Load and stress testing](https://quality.stereobooster.com/load-and-stress-testing.md) | Script generation from an API spec ([k6](https://k6.io/) / [Locust](https://locust.io/) / [Gatling](https://gatling.io/)) | A *realistic* load profile is production-semantics work AI doesn't do | | [Profiling](https://quality.stereobooster.com/profiling.md) | Flame-graph triage; correlates profiles with deploy timestamps | Root-causing is contextual (cache topology, allocator, GC) — hint-generator, not analyst | | [Microbenchmarking](https://quality.stereobooster.com/microbenchmarking.md) | Interprets benchmark results | — | | Canary / shadow launches | Synthesizes canary-metric deltas into a verdict, drafts the rollback | Promotion decisions stay statistical (Kayenta since 2018) | | A/B experimentation | Drafts hypotheses, summarizes results, flags imbalances | Doesn't change the statistics (variance reduction, sequential testing, sample-ratio mismatch) | | Exploratory testing | Vision-LLM browser agents notice broken UI; convert a found bug into a [Playwright](https://quality.stereobooster.com/playwright.md) repro | Lacks the charter sense and domain curiosity a human brings | ### Trap Plausible output nobody can cheaply check, so the verdict stays advisory. Shared evaluation is what separates a real signal from vendor claims: [Code Review Bench](https://github.com/withmartian/code-review-benchmark) scores review tools on precision and recall against human-verified pull requests, with a refreshed online set so a tool can't memorize the cases. ## AI consumes an oracle A compiler, test runner, sanitizer, or solver already says yes-or-no; AI proposes code or inputs and the oracle decides — an *external oracle in the loop*. ### Current state The only consistently strong relationship. The oracle gives feedback on the code AI writes, so it can iterate toward something correct rather than merely plausible, and every empirically successful AI tool in the survey works this way. Sound by construction: the oracle rejects wrong output however plausible the proposal looked. | Method | Oracle in the loop | Trap / note | | --- | --- | --- | | [Linear types](https://quality.stereobooster.com/linear-types.md) | `rustc` ([DARPA TRACTOR](https://www.darpa.mil/research/programs/translating-all-c-to-rust)) | The clearest consume relationship — AI *cannot* ship an unsafe program through rustc; C→Rust of non-trivial modules at scale is still unreliable | | [Type systems](https://quality.stereobooster.com/static-types.md) | the compiler (on shape) | Types that compile but are *wrong about intent* — an `any` slipped past the checker, an over-narrow union | | [Effect systems](https://quality.stereobooster.com/effect-systems.md) | the effect checker | Thin training data (Koka/Eff/Unison); realistic use is annotating mainstream code with *what it does* | | [Refinement and dependent types](https://quality.stereobooster.com/refinement-and-dependent-types.md) | an SMT solver | AI proposes predicates and **repairs failed verifications** — genuine new capability ([Dafny](https://dafny.org/) + LLM) | | [Static analysis](https://quality.stereobooster.com/static-analysis.md) | [CodeQL](https://codeql.github.com) / [Semgrep](https://semgrep.dev/); autofix ([Copilot Autofix](https://docs.github.com/en/code-security/concepts/code-scanning/copilot-autofix-for-code-scanning), [Project Naptime](https://projectzero.google/2024/06/project-naptime.html)) | Finds a different distribution (semantic / intent bugs) at higher false-positive rates | | [Clone detection](https://quality.stereobooster.com/clone-detection.md) | a clone detector ([jscpd](https://github.com/kucherenko/jscpd), [PMD CPD](https://pmd.github.io/), [Simian](https://harukizaemon.com/simian)) | No AI-specific tool needed — a general agent consumes the report and proposes the de-duplication | | [Dead-code detection](https://quality.stereobooster.com/dead-code-detection.md) | a detector ([knip](https://knip.dev), [Vulture](https://github.com/jendrikseipp/vulture)) + tests | Confirming a removal is *safe* needs a second oracle — the test suite plus whole-program reachability | | [Example tests](https://quality.stereobooster.com/example-tests.md) | the test runner, via compile-run-repair | AI tests written from AI-written code share the blind spot — write them from an *independent* spec (Siddiq et al. 2024)[^siddiq2024] | | [Property-based testing](https://quality.stereobooster.com/property-based-testing.md) | the property | Authoring the property is the weak link (see *AI writes an oracle*) | | [Fuzzing](https://quality.stereobooster.com/fuzzing.md) | sanitizer + harness ([OSS-Fuzz-Gen](https://github.com/google/oss-fuzz-gen), Fuzz4All (Xia et al. 2024)[^xia2024]) | AI solves the harness / seed / grammar first-mile; it doesn't run the engine | | [Differential testing](https://quality.stereobooster.com/differential-testing.md) | an independent reference implementation | AI can't supply the oracle — inventing one shares the blind spot; its role stays proposer-side | | [Symbolic execution](https://quality.stereobooster.com/symbolic-execution.md) | a [KLEE](https://klee-se.org/) / [angr](https://angr.io/) harness | AI drives the harness and prioritizes path-explosion output; it does not replace the engine | | [Theorem proving](https://quality.stereobooster.com/theorem-proving.md) | the proof kernel (Lean Copilot (Song et al. 2024)[^song2024]) | Genuinely new: automates most proof steps for short lemmas (human-in-the-loop, not yet autonomous; see *AI writes an oracle*) | | [Decision tables](https://quality.stereobooster.com/decision-tables.md), [state machines](https://quality.stereobooster.com/state-machines.md), [executable specifications](https://quality.stereobooster.com/executable-specifications.md), [model checking](https://quality.stereobooster.com/model-checking.md), [statistical model checking](https://quality.stereobooster.com/probabilistic-model-checking.md) | a model checker / rule engine | AI drafts the artifact; fidelity to intent is the failure mode (see *AI writes an oracle*) | | [Statistical testing](https://quality.stereobooster.com/statistical-testing.md), [deterministic simulation testing](https://quality.stereobooster.com/deterministic-simulation-testing.md) | the test / the simulator | AI authors the workloads and assertions; the test or simulator adjudicates | ### Trap Gaming the oracle, or the oracle being weaker than assumed — a proposal that satisfies the check without satisfying intent: a test suite passed by overfitting to its cases, a program that type-checks only because the hard parts were widened away. ## AI writes an oracle AI authors the check itself: a property, a contract, a schema, a spec, a snapshot. The historical blocker was the cost of writing the check, and that is what AI absorbs. ### Current state Weak, consistently, across independent studies. The recurring shape is *syntactically valid far more often than meaningful*: weak property quality (Vikram et al. 2023)[^vikram2023], type-correct-but-semantically-wrong annotations (Yee and Guha 2023)[^yee2023], mediocre single-shot tests (Siddiq et al. 2024)[^siddiq2024], and weak conformance of generated TLA+ models to the systems they claim to model (Cheng et al. 2025)[^cheng2025]. AI does lower the authoring cost, which is why methods once rejected as too expensive to write are worth recalculating; but the recalculation has to price in the validation cost the authoring cost shed. The one genuinely new *capability* is narrow: proving short lemmas and repairing failed verifications in theorem proving and refinement types (DeepMind 2024)[^deepmind2024], where the solver still adjudicates. #### Authoring a check from intent | Method | Check AI authors | Trap | | --- | --- | --- | | [Type systems](https://quality.stereobooster.com/static-types.md) | TypeT5 (Wei et al. 2023)[^wei2023] | Inferred types compile yet miss intent (Yee and Guha 2023)[^yee2023] — encode existing assumptions, not intended types | | [Refinement and dependent types](https://quality.stereobooster.com/refinement-and-dependent-types.md) | Laurel (Mugnier et al. 2025)[^mugnier2025], Clover (Sun et al. 2023)[^sun2023] | An authored predicate may encode existing behavior, not the intent | | [Property-based testing](https://quality.stereobooster.com/property-based-testing.md) | AI proposes properties and generators (Vikram et al. 2023)[^vikram2023] | Skew too weak (tautologies) or too strong | | [Contracts and runtime assertions](https://quality.stereobooster.com/contracts-and-runtime-assertions.md) | LLM ranks Daikon-mined invariants (Ernst et al. 2007)[^ernst2007]; intent→postcondition (Endres et al. 2024)[^endres2024] | Inferring invariants for a non-trivial module encodes existing assumptions, not intended contracts | | [Metamorphic testing](https://quality.stereobooster.com/metamorphic-testing.md) | Matches the relation catalog (identity, idempotence, round-trip, algebraic laws) to a function | No dedicated tool; a general agent writes the relations | | [State machines](https://quality.stereobooster.com/state-machines.md) | Stately Studio AI | Fidelity to intent — admits transitions the designer didn't mean | | [Executable specifications](https://quality.stereobooster.com/executable-specifications.md) | [Specula](https://github.com/specula-org/Specula) (spec synthesis) | Same; the artifact is small enough to audit (the method's cost floor anyway) | | [Decision tables](https://quality.stereobooster.com/decision-tables.md) | the table and its test cases | Compiles but admits cells the designer didn't mean | | [Model checking](https://quality.stereobooster.com/model-checking.md) | Drafts TLA+ models (Cheng et al. 2025)[^cheng2025] | Syntactically valid, poor conformance (SysMoBench) | | [Theorem proving](https://quality.stereobooster.com/theorem-proving.md) | AlphaProof (DeepMind 2024)[^deepmind2024] — short lemmas | Long proofs and novel definitions stay human | | [Deterministic simulation testing](https://quality.stereobooster.com/deterministic-simulation-testing.md) | Workload generators, assertions over simulated state | The simulator is the work; AI triages failed seeds and summarizes counterexamples | A second pattern — the artifact constraining the model — appears at the lightweight tier (decision tables, state machines, executable specifications); see the [formal-methods AI page](https://quality.stereobooster.com/ai-formal.md). No tool or study yet covers AI authoring [effect-system](https://quality.stereobooster.com/effect-systems.md) annotations (niche languages, untested) or [statistical testing](https://quality.stereobooster.com/statistical-testing.md) / [statistical model checking](https://quality.stereobooster.com/probabilistic-model-checking.md) designs — a general agent drafts the check and a human validates it against intent. #### Authoring a check from observation | Method | Check AI authors | Trap | | --- | --- | --- | | [Snapshot / approval tests](https://quality.stereobooster.com/snapshot-testing.md) | the scaffold | **Cannot approve** — and approval is the whole operation; an LLM rubber-stamping the first run is the sharpest authored-oracle trap | | [Characterization tests](https://quality.stereobooster.com/snapshot-testing.md#value-snapshot) (legacy code) | Turns observed behavior into a guard before a refactor (the Feathers move) | Freezes current behavior, bugs included | | [Mutation testing](https://quality.stereobooster.com/mutation-testing.md) | Codebase-specific mutation operators; killing tests for survivors | A signal, not an oracle (see *Signals*); triage survivors into equivalent / write-an-assertion / real-gap | ### Trap A solver or proof kernel keeps the *code* honest against the authored check, but nothing keeps the *check* honest against intent: the authored oracle passes something other than what was meant. Sharpest in a characterization test that bakes current (maybe buggy) behavior in as "expected." ## Signals The signal methods — [coverage](https://quality.stereobooster.com/coverage.md), [git-history hotspots](https://quality.stereobooster.com/git-hotspots.md), [mutation testing](https://quality.stereobooster.com/mutation-testing.md) — are things AI *reads*, not oracles; AI uses them to target where to write the next test or mutant. An AI reads a high-churn file and proposes what's structurally wrong — the *causes, not rankings* finding (Lewis et al. 2013)[^lewis2013]; it generates the test for an uncovered line (the CoverUp / [Qodo Cover](https://github.com/qodo-ai/qodo-cover) loop); it pipes [Code Maat](https://github.com/adamtornhill/code-maat) hotspot output through an assistant. ## Referenced by - [Oracle](https://quality.stereobooster.com/oracle.md) · The axes - [Testing machine-learning systems](https://quality.stereobooster.com/testing-ml-systems.md) · Methods - [AI tooling for requirements engineering](https://quality.stereobooster.com/ai-requirements-tools.md) · AI - [Agent experience](https://quality.stereobooster.com/ai-agent-experience.md) · AI - [Bugs in AI-generated code](https://quality.stereobooster.com/ai-generated-code-bugs.md) · AI - [Software Quality](https://quality.stereobooster.com/index.md) · Overview ## References [^crossman2025]: Crossman, Andrew, Andrew R. Plummer, Chandra Sekharudu, Deepak Warrier, and Mohammad Yekrangian. 2025. "[Auspex: Building Threat Modeling Tradecraft into an Artificial Intelligence-based Copilot](https://arxiv.org/pdf/2503.09586)." *2025 IEEE Conference on Artificial Intelligence (CAI)*, 1160–67. . [^rasheed2024]: Rasheed, Zeeshan, Malik Abdul Sami, Muhammad Waseem, et al. 2024. *[AI-powered Code Review with LLMs: Early Results](https://arxiv.org/pdf/2404.18496)*. . [^bacchelli2013]: Bacchelli, Alberto, and Christian Bird. 2013. "[Expectations, Outcomes, and Challenges of Modern Code Review](https://sback.it/publications/icse2013.pdf)." *Proceedings of the 35th International Conference on Software Engineering (ICSE '13)*, 712–21. . [^lubos2024]: Lubos, Sebastian, Alexander Felfernig, Thi Ngoc Trang Tran, et al. 2024. "[Leveraging LLMs for the Quality Assurance of Software Requirements](https://arxiv.org/pdf/2408.10886)." *Proceedings of the 32nd IEEE International Requirements Engineering Conference (RE '24)*, 389–97. . [^notaro2021]: Notaro, Paolo, Jorge Cardoso, and Michael Gerndt. 2021. "[A Survey of AIOps Methods for Failure Management](https://jorge-cardoso.github.io/rd/Papers/JA-2021-025-Survey_AIOps_Methods_for_Failure_Management.pdf)." *ACM Transactions on Intelligent Systems and Technology*, 1–45. . [^kikuta2025a]: Kikuta, Daisuke, Hiroki Ikeuchi, and Kengo Tajiri. 2025. "[LLM-Powered Fully Automated Chaos Engineering: Towards Enabling Anyone to Build Resilient Software Systems at Low Cost](https://arxiv.org/pdf/2511.07865)." *2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE)*, 3861–65. . [^siddiq2024]: Siddiq, Mohammed Latif, Joanna C. S. Santos, Ridwanul Hasan Tanvir, Noshin Ulfat, Fahmid Al Rifat, and Vinicius Carvalho Lopes. 2024. "[Using Large Language Models to Generate JUnit Tests: An Empirical Study](https://arxiv.org/pdf/2305.00418)." *Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering (EASE 2024)*, 313–22. . [^xia2024]: Xia, Chunqiu Steven, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. "[Fuzz4All: Universal Fuzzing with Large Language Models](https://arxiv.org/pdf/2308.04748)." *Proceedings of the IEEE/ACM 46th International Conference on Software Engineering*, 1–13. . [^song2024]: Song, Peiyang, Kaiyu Yang, and Anima Anandkumar. 2024. *[Lean Copilot: Large Language Models as Copilots for Theorem Proving in Lean](https://arxiv.org/pdf/2404.12534)*. . [^vikram2023]: Vikram, Vasudev, Caroline Lemieux, Joshua Sunshine, and Rohan Padhye. 2023. *[Can Large Language Models Write Good Property-Based Tests?](https://arxiv.org/pdf/2307.04346)* . [^yee2023]: Yee, Ming-Ho, and Arjun Guha. 2023. "[Do Machine Learning Models Produce TypeScript Types That Type Check?](https://arxiv.org/pdf/2302.12163)" *Proceedings of the 37th European Conference on Object-Oriented Programming (ECOOP 2023)*. . [^cheng2025]: Cheng, Qian, Ruize Tang, Emilie Ma, et al. 2025. *[SysMoBench: Evaluating AI on Formally Modeling Complex Real-World Systems](https://arxiv.org/pdf/2509.23130)*. . [^deepmind2024]: DeepMind. 2024. *[AI Achieves Silver-Medal Standard Solving International Mathematical Olympiad Problems](https://deepmind.google/discover/blog/ai-solves-imo-problems-at-silver-medal-level/)*. . [^wei2023]: Wei, Jiayi, Greg Durrett, and Isil Dillig. 2023. *[TypeT5: Seq2seq Type Inference using Static Analysis](https://arxiv.org/pdf/2303.09564)*. . [^mugnier2025]: Mugnier, Eric, Emmanuel Anaya Gonzalez, Ranjit Jhala, Nadia Polikarpova, and Yuanyuan Zhou. 2025. "[Laurel: Unblocking Automated Verification with Large Language Models](https://arxiv.org/pdf/2405.16792)." *Proceedings of the ACM on Programming Languages*, 1519–45. . [^sun2023]: Sun, Chuyue, Ying Sheng, Oded Padon, and Clark Barrett. 2023. *[Clover: Closed-Loop Verifiable Code Generation](https://arxiv.org/pdf/2310.17807)*. . [^ernst2007]: Ernst, Michael D., Jeff H. Perkins, Philip J. Guo, et al. 2007. "[The Daikon system for dynamic detection of likely invariants](https://people.csail.mit.edu/cpacheco/publications/daikon-tool-scp2006.pdf)." *Science of Computer Programming* 69 (1–3): 35–45. . [^endres2024]: Endres, Madeline, Sarah Fakhoury, Saikat Chakraborty, and Shuvendu K. Lahiri. 2024. "[Can Large Language Models Transform Natural Language Intent into Formal Method Postconditions?](https://arxiv.org/pdf/2310.01831)" *Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE 2024)*, 1889–912. . [^lewis2013]: Lewis, Chris, Zhongpeng Lin, Caitlin Sadowski, Xiaoyan Zhu, Rong Ou, and E. James Whitehead. 2013. "[Does Bug Prediction Support Human Developers? Findings from a Google Case Study](https://users.soe.ucsc.edu/~ejw/papers/lewis-icse-2013.pdf)." *Proceedings of the 35th International Conference on Software Engineering (ICSE)*. . ## Acronyms - ADR — architecture decision record - OSS — open-source software - RE — requirements engineering - SBOM — software bill of materials - SLO — service level objective - SMT — satisfiability modulo theories - STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege