1. Introduction
Test-Driven Development (TDD) has long been recognized as a discipline that improves software reliability and design quality (Beck, 2003; Martin, 2008). By requiring tests to precede implementation, TDD encourages modular design, reduces defects, and improves maintainability. For two decades, this discipline has served as a foundation for professional software engineering practice.
However, the systems we now build have changed in ways that strain TDD's underlying assumptions in operationally significant ways. Modern AI-driven systems incorporate large language models whose outputs are probabilistic by construction, dynamic execution environments that introduce runtime state variability, recursive agent orchestration where a single user request may trigger dozens of model calls across tool boundaries, and external model APIs subject to latency variability, cost sensitivity, and behavioral drift between provider releases.
These are not theoretical concerns. I have encountered each of these failure modes directly in production: silent quality regressions introduced by provider model updates that no existing test caught; runaway agent loops that consumed API budget before any monitoring threshold was breached; execution environment failures that corrupted shared state across concurrent sessions. Classical TDD was doing its job. The job had outgrown classical TDD.
As Fowler (2018) notes, architectural evolution is driven by new operational realities. AI systems represent such a shift, requiring not an abandonment of TDD, but a disciplined extension of it. The properties that make TDD valuable, writing expectations before implementation, making behavior testable, treating tests as first-class artifacts, are precisely the properties needed to address AI system reliability. They need to be applied more broadly.
I want to introduce you to a new concept, a different approach to software engineering, which I call "Recursive Engine-Driven Development (REDD)", an extension of TDD designed to address the reliability challenges specific to AI-driven systems. REDD preserves the RED-GREEN-REFACTOR cycle and the write-test-first discipline, while extending the definition of testable behavior to include execution safety, probabilistic evaluation, and interface contract compliance.
Section 2 examines where and why TDD assumptions fail in AI systems. Section 3 defines reliability requirements for AI-driven software. Sections 4 through 8 present the REDD framework in detail. Section 9 presents a production case study. Section 10 articulates what REDD contributes beyond existing practice. Section 11 addresses limitations, risks of adoption, and future directions.
REDD is intended for practitioners operating AI systems in production environments where reliability, governance, and provider independence are operational requirements.
2. Limitations of Traditional TDD in AI-Driven Systems
TDD's power derives from a set of assumptions that, when valid, make tests both precise and trustworthy: outputs are deterministic given the same inputs; execution is synchronous and bounded; dependencies are controllable via mocks and stubs; runtime behavior is predictable from the code under test. AI-driven systems violate each of these assumptions, with distinct operational consequences.
2.1 Nondeterministic Outputs
Unlike traditional software functions, LLM outputs are probabilistic (Bommasani et al., 2021), influenced by sampling parameters, prompt structure, context window composition, and model version. A prompt that reliably produces a well-structured JSON response may produce malformed output after a provider updates underlying model weights, with no change to the API interface specification. Asserting equality of LLM outputs either over-constrains the system, failing on acceptable variation, or under-constrains it, passing on semantically degraded outputs. Both failure modes lead teams to abandon LLM-facing tests entirely, leaving behavior unvalidated.
2.2 Dynamic Execution Environments
Runtime code execution, REPL environments, and stateful agent contexts introduce failure modes not addressed in classical TDD. When an agent executes code in a shared or persistent runtime, prior executions may leave state that affects subsequent behavior. Startup failures under load, timeout conditions, and resource exhaustion are runtime failure modes that cannot be caught by unit tests operating on isolated functions, they require lifecycle testing of the execution environment itself.
2.3 External Model Dependencies and Behavioral Drift
Modern AI applications rely on external APIs subject to latency variability, version changes, and behavioral drift between model releases. A provider may update an underlying model without changing the API endpoint or version identifier. The interface contract remains satisfied, requests and responses conform to the schema, while the behavioral contract silently regresses. This class of failure is invisible to traditional integration tests that validate schema compliance but not semantic quality. It is detectable only through probabilistic evaluation against calibrated thresholds on a representative evaluation dataset.
2.4 Recursive and Agent-Based Workflows
Recent research in agent-based LLM systems demonstrates recursive task decomposition and tool orchestration (Yao et al., 2023; Wu et al., 2023), creating execution flows beyond traditional testing assumptions. A single user request may trigger a tree of model invocations, tool calls, and state updates. Without explicit recursion bounds and execution budget controls, these workflows can produce runaway processes that are operationally and financially costly. Classical TDD has no mechanism for testing the termination properties of recursive execution graphs. This is not a gap that can be addressed by writing more unit tests; it requires a new category of testing artifact.
3. Reliability Requirements for AI-Driven Systems
Before defining REDD, it is worth stating precisely what reliability means for AI-driven systems, because the term is used loosely in AI engineering discourse and the requirements exist in real tension with one another.
A reliable AI-driven system must satisfy five properties:
Deterministic behavior where possible: logic surrounding model interaction, routing, prompt assembly, output parsing, state management, must behave deterministically and be fully unit-testable.
Controlled probabilistic evaluation where necessary: model behavior cannot be asserted to be deterministic, but its quality can be measured statistically against defined thresholds.
Interface stability across model providers: the system must be able to substitute model providers without downstream behavioral changes, enabled by contracts that specify both schema and semantic expectations.
Lifecycle safety for execution environments: dynamic execution environments must be tested for startup, steady-state, degraded, and teardown conditions. In practice, this is the requirement teams most commonly skip, and the one that produces the most operationally surprising failures.
Graceful degradation under failure: the system must have defined and tested fallback behaviors for each failure category.
It is worth acknowledging that these requirements can conflict. Graceful degradation sometimes requires accepting probabilistically lower-quality outputs: a fallback response that terminates a runaway execution cleanly may be less complete than a full extraction result. Teams encountering this tension for the first time often treat it as a design flaw to eliminate; it is not. The REDD discipline does not resolve the tradeoff, it makes it explicit and testable rather than implicit and undiscoverable. A behavioral contract that specifies both the primary quality threshold and the degraded-mode quality floor acknowledges the tension and ensures both states are validated.
This framework aligns with principles of resilient system design (Nygard, 2018) and continuous delivery reliability practices (Humble & Farley, 2010), extending them to cover the probabilistic and recursive characteristics specific to AI systems.
4. REDD: Recursive Engine-Driven Development
4.1 Conceptual Overview
REDD extends TDD by embedding four reliability mechanisms into the development cycle: contract testing, deterministic/probabilistic validation separation, execution lifecycle testing, and recursion safety controls. The discipline does not replace TDD. It extends it by expanding the definition of testable behavior and the set of artifacts that must exist before a feature is considered complete.
TDD's core discipline, writing a failing test before implementation (Beck, 2003), remains intact. What changes is the scope of what must be specified before implementation begins. In REDD, a feature is not considered ready to implement unless its interface contract is defined, its execution budget is bounded, its quality thresholds are specified probabilistically (with metric limitations acknowledged), and its failure modes have defined fallback behaviors. These constraints are not post-hoc governance, they are part of the RED phase, and their absence is treated as a failing condition in the same way that a missing test is a failing condition in classical TDD.
Martin (2008) emphasizes that tests enable fearless refactoring. REDD preserves this property while addressing nondeterministic execution contexts. By separating deterministic logic tests from probabilistic quality evaluations, REDD provides a test suite that is both stable, the deterministic layer does not produce false positives from model variation, and sensitive, the probabilistic layer detects semantic regressions that deterministic tests cannot. These two properties are often in tension in naive testing approaches; REDD resolves the tension by design through layer separation.
4.2 The REDD Development Cycle
The RED-GREEN-REFACTOR cycle (Beck, 2003) remains central in REDD, extended with a VALIDATE phase that operationalizes probabilistic and lifecycle testing. The four phases are defined as follows:
Table 1. The REDD development cycle extending classical TDD with AI-specific reliability constraints. The VALIDATE phase is first-class, not deferred to CI or post-deployment monitoring..
The VALIDATE phase is not optional or deferred to continuous integration. It is a first-class part of the development cycle, executed against live model endpoints before a feature is considered complete. This distinguishes REDD from ad-hoc testing approaches that bolt evaluation onto existing TDD workflows as an afterthought, a pattern that preserves the appearance of rigor without its substance.
4.3 REDD Artifacts
Each feature developed under REDD produces four artifacts in addition to the implementation and its classical unit tests. These artifacts are version-controlled alongside the implementation and are treated as required deliverables, not optional documentation:
Interface Contract: specifies the input schema, output schema, behavioral quality thresholds (with the evaluation metric and its known limitations), latency SLA, and fallback behavior for each model interaction point.
Evaluation Harness: a deterministic test suite covering all logic surrounding model interaction (using mocked responses that include edge cases), plus a probabilistic evaluation suite covering semantic quality against a defined evaluation dataset.
Execution Budget: explicit token budget, recursion depth limit, wall-clock timeout, and cost ceiling for all agent and recursive execution paths. Budget values should be derived from empirical baseline measurements with a defined safety margin, not estimated from intuition, which teams consistently underestimate by a factor of two or more.
Lifecycle Test Suite: tests covering startup, steady-state, degraded mode, and teardown for all dynamic execution environments, with failure mode classifications driving remediation priority.
When a model provider updates, the interface contract and evaluation harness define the acceptance criteria for determining whether the update is safe to deploy, making provider governance a computable process rather than an organizational judgment call made under uncertainty.
5. Deterministic vs. Probabilistic Validation
The most operationally important distinction in REDD is the separation of deterministic testing from probabilistic evaluation. Conflating these two types of validation is the primary source of unreliable test suites in AI-driven systems: suites that are either brittle from over-constraining model outputs, or insensitive from under-constraining them.
5.1 Deterministic Testing Layer
The deterministic layer validates all logic that does not involve the model itself: prompt assembly from structured inputs, output parsing and schema validation, routing logic that directs requests to different model configurations, retry and fallback invocation, state management across execution steps, and tool call sequencing. These components can and must be fully unit-tested with mocked model responses.
A critical implementation requirement: mocked responses in deterministic tests must be representative of the full range of real model outputs, including failure cases, truncated responses, malformed JSON, unexpected refusals, empty responses, and responses that are schema-compliant but semantically empty. The deterministic layer should test the system's ability to handle the full variability of model output, not only the happy path. Teams that mock only well-formed responses will discover the gap when their parsing logic encounters a real malformed response in production.
5.2 Probabilistic Evaluation Layer
The probabilistic layer measures semantic correctness and task success using evaluation metrics applied to real model outputs. This layer cannot use equality assertions. Instead, it defines pass thresholds: a semantic similarity score above a defined threshold, a task completion rate above a defined percentage across an evaluation dataset, a structured output compliance rate above a defined ceiling.
Evaluation metric selection requires domain-specific judgment, and the metrics currently available have meaningful limitations that practitioners must account for when specifying behavioral contracts. The table below summarizes the metrics used in the case study described in Section 9, with their known limitations for factual extraction tasks:
Table 2. Evaluation metrics used in the REDD probabilistic layer, with limitations relevant to factual extraction tasks. Metric selection should be calibrated against human judgments on a domain-representative sample before use in behavioral contracts.
The limitation most consequential for the case study system, an extraction platform where factual accuracy is the primary quality dimension, is BERTScore's insensitivity to numerical substitution. Two extractions that differ only in a reported figure may receive high semantic similarity scores because the surrounding language is identical. For this reason, the case study system supplemented BERTScore with a task-specific rubric evaluator that explicitly scored numerical and entity extraction accuracy, calibrated against 300 human-evaluated documents.
Evaluation dataset requirements are a first-class specification concern in REDD. A behavioral contract that does not specify the evaluation dataset against which its thresholds are measured is not a complete contract. Minimum viable specification includes: dataset size (empirically, 150–300 examples per task type provides adequate statistical power for detecting regressions of 5 percentage points or greater at 90% confidence), representativeness criteria (coverage of distribution tails, edge cases, and known failure modes), and update protocol (dataset must be reviewed when task definition changes materially).
Run on a scheduled cadence, daily in high-change production environments, weekly where change rates are lower, against a fixed, versioned evaluation dataset, the probabilistic layer establishes a statistical baseline against which model provider updates and prompt changes can be evaluated before deployment (Sculley et al., 2015). Daily is the right default; weekly is an acceptable tradeoff when API costs are constrained, but teams that switch to weekly cadence typically discover they dislike the longer detection lag the first time it matters.
5.3 Layer Separation in Practice
In practice, layer separation is enforced by test suite organization and CI configuration: deterministic tests run on every commit with mocked model calls, providing fast feedback in approximately 2-4 minutes; probabilistic evaluation runs separately against live model endpoints on a defined schedule, providing regression detection within one evaluation cadence period. This separation ensures that CI pipelines remain fast and stable, preserving the rapid feedback loop that makes TDD effective, while probabilistic evaluation provides the sensitivity required to detect semantic regressions that deterministic tests cannot see.
6. Contract Testing and Interface Stability
Contract testing in REDD serves a purpose that differs from classical consumer-driven contract testing (Fowler, 2018) in one critical dimension: it must detect behavioral drift between provider model releases, not just schema violations. Traditional contract testing ensures that a provider's responses conform to the structure expected by the consumer. In AI systems, the structure can remain compliant while the content degrades. A provider can satisfy the output schema contract while failing the behavioral contract. Both must be tested.
6.1 Contract Structure
A REDD interface contract for a model interaction point specifies five properties:
The behavioral contract connects to the probabilistic evaluation layer through a defined reference: the contract specifies which evaluation metric is used, what threshold constitutes a pass, what evaluation dataset it is measured against, and, critically, which known limitations of the chosen metric are acknowledged and compensated for by supplementary metrics or human spot-checking. A behavioral contract without this specification is incomplete.
6.2 Enabling Provider Substitutability
The contract structure enables provider substitutability by making the acceptance criteria for a new provider explicit and computable. When evaluating a new model provider or a major version update, the process is defined: run the full contract test suite against the candidate; if all contracts pass, the substitution is safe; if behavioral contracts fail, determine whether the failure reflects a genuine regression requiring prompt adaptation, or a threshold that was miscalibrated against the previous provider and should be updated upward. The second case is more common than teams expect, migrating to a better model often reveals that thresholds were set lower than they needed to be.
Operationally, contract-driven provider evaluation eliminates the pattern common in teams without REDD: discovering provider-introduced regressions in production hours or days after deployment, after user-facing quality degradation has already occurred.
6.3 Contract Versioning and Evolution
Contracts are versioned alongside the implementation. When a prompt changes, the behavioral contract thresholds must be re-evaluated against the updated prompt, and not always downward. Prompt improvements should raise thresholds, committing the system to the improved quality level and preventing future regressions to the previous baseline.
Each prompt change paired with a contract re-evaluation produces an audit trail: every change is associated with a quality delta, and that delta is recorded. The trail is operationally valuable when diagnosing regressions, it enables the team to identify whether a current quality failure stems from a specific prompt change, a provider update, or a distribution shift in production inputs. Without version-controlled contracts, this kind of root-cause analysis typically devolves into guesswork.
One failure mode to guard against is threshold inflation: teams under delivery pressure may lower behavioral contract thresholds to make a failing evaluation pass rather than fixing the underlying quality issue. The contract audit trail makes this visible; code review processes should treat threshold lowering with the same skepticism as disabling a failing unit test.
7. Lifecycle Testing for Execution Environments
Dynamic execution environments, REPL sessions, code execution sandboxes, and stateful agent contexts require a category of testing absent from classical TDD: lifecycle testing. The failure modes of these environments are not logic errors detectable by unit tests; they are operational failures that manifest under conditions of load, resource exhaustion, concurrent access, or unexpected state, conditions that only occur at runtime.
7.1 Lifecycle Test Phases
A lifecycle test suite in REDD covers four operational phases. Each phase validates a distinct failure mode category:
Startup: validates that the execution environment initializes correctly under nominal conditions, under concurrent initialization load, and following a prior failure. Startup tests must verify that failures are detected and reported, and that failed initializations do not leave a partial state that corrupts subsequent executions. Cold-start time under load should be measured and thresholded.
Steady-State: validates behavior under sustained load, memory usage growth over time, latency percentile stability, and resource utilization. These are time-bounded load tests, not unit tests, and the distinction matters: a steady-state test running for thirty seconds exercises failure modes that a millisecond unit test cannot reach by construction.
Degraded Mode: validates behavior when the execution environment is resource-constrained or partially failed. This includes timeout handling under heavy load, memory pressure responses, and behavior when dependent services are unavailable. Degraded mode tests should verify that the system fails in the defined manner, returning the specified fallback, not in undefined manners that produce confusing outputs downstream.
Teardown: validates that execution environments release resources cleanly and leave no state affecting subsequent sessions. In multi-tenant agent environments, session isolation is a correctness requirement. A teardown test failure is a correctness bug, not a performance regression, and should be treated accordingly.
Resilient systems must handle timeouts, resource exhaustion, and failure isolation (Nygard, 2018). REDD formalizes these requirements as testable artifacts rather than operational runbooks, making them discoverable before production deployment rather than after production incidents.
7.2 Failure Mode Classification
Lifecycle tests in REDD produce failure mode classifications that determine remediation priority. Hard failures, such as the execution environment cannot start or terminate unexpectedly, or block deployment. Soft failures, execution environment starts but produces degraded behavior, require documented mitigation before deployment. Resource failures, execution environment exceeds defined resource budgets, trigger a capacity review. This classification prevents the pattern of shipping lifecycle test failures with the implicit assumption that they will be addressed post-deployment.
8. Recursive Execution and Agent Orchestration
Agent-based systems rely on recursive task decomposition and tool invocation (Yao et al., 2023; Wu et al., 2023). Without explicit safeguards, recursive execution can produce runaway processes, unbounded cost escalation, and cascading failures. What makes these failures particularly insidious is that they emerge from the interaction of individually correct components; no individual component is broken, but the system as a whole misbehaves in ways that unit tests cannot see. System-level testing of execution paths under adversarial conditions is the only reliable detection mechanism.
8.1 Execution Budgets
REDD requires that every recursive or agent execution path have an explicit execution budget specified as a versioned artifact. An execution budget defines four dimensions:
Maximum recursion depth: the maximum number of recursive agent invocation levels before the execution is terminated with the defined fallback behavior.
Maximum token budget: total token consumption limit across all model calls in an execution path, including both input and output tokens. In practice, this is the dimension that triggers most frequently; token budgets need to be set from measured baselines, not intuition.
Wall-clock timeout and cost ceiling: maximum elapsed time before termination (regardless of recursion depth), and maximum API cost in USD per execution path. These two dimensions are often correlated, but the cost ceiling provides a financial guardrail that survives changes in model pricing that would otherwise invalidate token-based budgets.
Execution budgets are enforced at runtime by the agent orchestration layer, not by convention or documentation. The orchestration layer must be instrumented to track all four dimensions of budget consumption and trigger graceful termination when any dimension is exhausted. A budget that is defined but not enforced provides false assurance.
Budget values are derived empirically: baseline measurements of normal execution paths provide the reference, with a defined multiplier (typically 2-3x for the safety margin) applied to account for legitimate variation. Budget values must be re-validated when prompts or tool configurations change materially. A prompt change that increases average token consumption may push normal executions above an unchanged budget ceiling, producing false-positive terminations.
8.2 Bounded Recursion Patterns
REDD defines two implementation patterns for bounded recursion in agent systems, which may be used independently or in combination:
Depth-limited recursion: the orchestration layer maintains a recursion depth counter in the execution context, decremented on each recursive invocation. When the counter reaches zero, the execution returns the best available partial result and terminates. The fallback behavior at depth limit must be specified in the interface contract and tested in the lifecycle test suite.
Budget-aware recursion: rather than counting levels, the orchestration layer maintains a shared budget object across all recursive calls and checks remaining budget before each model invocation. If any dimension would be exceeded, the invocation is replaced with the specified fallback. More flexible than depth-limiting, it accommodates variable-depth executions that stay within budget, but the instrumentation is more complex and the failure modes less predictable. Teams new to REDD are generally better served starting with depth-limited recursion.
A recursion that terminates cleanly at its depth limit but produces a confusing or misleading partial result has not satisfied its contract. The fallback behavior specification in the interface contract must define what the terminated execution returns, a partial result with an explicit incompleteness marker, a cached result from a prior execution, a defined error response, and this behavior must be tested.
8.3 Testing Recursive Execution Paths
Testing recursive execution paths requires a combination of unit tests on the bounded recursion machinery itself and integration tests that inject controlled failures at specific recursion depths. The unit tests validate that the depth counter decrements correctly, that budget tracking is accurate, and that the fallback behavior is invoked correctly when limits are reached. The integration tests validate that the complete execution path, including the orchestration infrastructure, correctly terminates and returns the specified fallback under adversarial depth and budget conditions.
These integration tests belong in the lifecycle test suite, not the deterministic unit test layer, because they require the orchestration infrastructure to be exercised. A unit test that mocks the orchestration layer cannot validate that the budget enforcement instrumentation actually works.
9. Case Study: AI-Driven Document Processing Platform
The following case study describes a production AI-driven document processing platform. The system and organization details have been anonymized. Metrics are reported as measured; confounding factors that may affect interpretation are discussed explicitly in Section 9.5.
9.1 System Description
The platform extracts, classifies, and summarizes content from unstructured professional documents, contracts, financial reports, and regulatory correspondence, to support downstream review workflows at a mid-sized professional services firm. The system processes approximately 4,000 documents per day across three document categories: financial statements, contracts, and regulatory filings, each with distinct extraction schemas and quality requirements.
The core architecture consists of a document ingestion pipeline; a classification agent that routes documents to category-specific extraction configurations; an extraction layer that invokes an LLM provider (initially GPT-4, subsequently migrated to Claude 3 Opus, then Claude 3.5 Sonnet) to populate structured extraction schemas; a validation layer that checks extraction outputs against JSON schemas; a Python REPL environment used by the extraction agent for document parsing operations including table extraction and date normalization; and a downstream API exposing extraction results to review workflow tooling.
Prior to REDD adoption, the team practiced classical TDD on deterministic components, ingestion, routing, schema validation, API layer, with approximately 85% line coverage. There was no systematic approach to testing LLM-facing behavior. The high coverage figure gave the team false confidence: the test suite was testing the parts of the system that were least likely to fail, while leaving the parts most likely to fail untested.
9.2 Failure Modes Before REDD
Over a six-month pre-REDD period, the platform experienced four categories of reliability failure that collectively established the baseline against which post-REDD improvements are measured:
Silent extraction quality regressions: the LLM provider updated an underlying model, changing extraction behavior on financial statement documents. The regression was not detected by the test suite, all 847 tests passed, and was discovered by a downstream reviewer 72 hours after deployment, after approximately 600 documents had been processed with degraded extraction quality. The regression manifested as a change in date formatting behavior that caused date fields to be extracted in a non-standard format accepted by the JSON schema but misread by the downstream review tool.
Runaway agent executions: a prompt configuration error caused the classification agent to recursively re-classify documents when it encountered a specific document subtype at the boundary between two categories. Over eleven distinct incidents across the six-month period, this produced unbounded API calls that exhausted the daily token budget. Detection occurred through cost monitoring, not functional monitoring, with a mean detection lag of 4.2 hours after onset.
REPL environment state corruption: the Python REPL used for document parsing retained imported module state across sessions in a multi-tenant deployment. Extraction operations in one session occasionally modified shared globals in a widely-used parsing library, corrupting subsequent sessions with intermittent extraction errors that had no reproducible cause and were initially attributed to document quality rather than infrastructure state.
Provider migration incident: when migrating from GPT-4 to Claude 3 Opus for cost reasons, semantic extraction quality changed materially for regulatory filing documents despite full schema compliance. The change was discovered through user complaints three days post-migration. Partial rollback required two weeks of prompt remediation and parallel validation before the migration could be completed.
These failure modes share a structural characteristic: none were detectable by the existing test suite. They were not failures of engineering quality in the traditional sense, the code was correct, the tests passed, they were failures of the discipline's scope relative to the system's actual failure surface.
9.3 REDD Implementation
The team adopted REDD over a twelve-week period, implementing the four mechanisms in sequence. The sequencing was deliberate: contract definition and evaluation harness construction were prioritized because they provided the most immediate regression detection value; lifecycle testing and execution budget enforcement addressed the infrastructure failure modes that were less frequent but higher-impact.
Contract definition (weeks 1–3): interface contracts were defined for each model interaction point, the classification prompt, three category-specific extraction prompts, and the REPL invocation interface. Behavioral contract thresholds were derived from a human-evaluated baseline of 200 documents per category, evaluated by domain reviewers against a rubric covering field completeness, value accuracy, and format compliance. Execution budgets were derived from baseline measurements of 500 normal execution traces, with a 3x safety margin applied.
Evaluation harness construction (weeks 4–6): the deterministic test suite was extended to cover edge cases in LLM output handling, truncated responses, schema violations with partial content, unexpected refusals, using mocked responses drawn from the production failure log. The probabilistic evaluation suite was built using BERTScore for semantic similarity, a task-specific rubric evaluator for field-level accuracy (including numerical extraction accuracy to address BERTScore's known limitation in this domain), and an output compliance rate metric. All three metrics were included in the behavioral contract specification with their respective thresholds and known limitations documented.
Lifecycle test suite implementation (weeks 7–9): lifecycle tests were implemented for the REPL environment across all four phases. The steady-state tests immediately identified that memory usage grew linearly with session count due to the shared-globals issue, providing a reproducible failure signal for a bug that had manifested previously only as intermittent corruption. The fix, session isolation via subprocess spawning, was targeted and validated by re-running the lifecycle suite.
Execution budget enforcement (weeks 10–12): the classification agent was refactored to implement budget-aware recursion with all four budget dimensions instrumented. Budget consumption was surfaced in the observability layer, providing real-time visibility into how much budget each document category consumed relative to its ceiling. This visibility revealed that regulatory filings consumed 2.7x the token budget of financial statements, a distribution-level insight that informed a subsequent prompt optimization effort.
9.4 Results
The following metrics were measured over the six months following full REDD adoption and compared against the six months prior. A discussion of confounds and limitations follows in Section 9.5.
The provider migration result is the most structurally significant. Eight months after REDD adoption, the team migrated from Claude 3 Opus to Claude 3.5 Sonnet. Using the contract test suite, the migration process took three days: one day to run all behavioral contracts against Claude 3.5 Sonnet, one day to update two extraction prompts where behavioral contracts failed (one genuine regression in regulatory filing extraction; one threshold that had been set against Claude 3 Opus characteristics and was appropriately updated upward for the improved model), and one day to re-validate. The migration deployed with zero downtime and zero post-deployment regressions detected within the first 30 days. The contrast with the pre-REDD migration, two weeks, partial rollback, user escalations, reflects the same fundamental difference: contract testing made the acceptance criteria for migration explicit and computable before deployment.
9.5 Confounds and Interpretation Caveats
The magnitude of improvement in the metrics warrants explicit discussion of factors that may amplify the apparent effect size:
Baseline quality: the pre-REDD baseline was exceptionally poor by any standard, no AI-specific testing discipline, no evaluation metrics, no execution budgets. This is not unusual for teams at early stages of AI system maturity, but it means the effect size of applying any disciplined approach would be large. The improvements reported here should be understood as the delta from 'no discipline' to 'REDD discipline,' not as the marginal value of REDD over alternative approaches.
Shared-globals bug fix: the 94% reduction in REPL startup failures was driven primarily by a single targeted bug fix surfaced by lifecycle tests in week 7. REDD provided the instrumentation to find and confirm the fix, but the improvement is attributable to the bug fix itself. If the bug had been found through other means, the lifecycle test contribution would have been smaller.
Confounding improvements: over the same twelve-month measurement window, the team also improved their observability tooling and on-call processes. Some reduction in MTTR may reflect these improvements rather than REDD's probabilistic evaluation layer exclusively.
Despite these caveats, three of the five metrics, runaway execution elimination, provider migration improvement, and regression detection rate, reflect structural changes in the system's architecture and testing discipline that are directly attributable to REDD mechanisms and are not plausibly explained by confounding factors.
9.6 Implementation Costs
The twelve-week implementation required approximately 240 person-hours of engineering time, with the majority concentrated in contract definition and evaluation harness construction (weeks 1–6). Ongoing operational cost is approximately 4 person-hours per week for evaluation dataset maintenance and contract review when prompts change.
The daily probabilistic evaluation suite incurs API costs of approximately $12–18 per day at current provider pricing for 600 evaluation documents across three model interaction points. For context, the system's production API costs run approximately $400/day at its 4,000-document processing volume, the evaluation overhead represents roughly 3–4% of production API spend. Teams with tighter budget constraints may run evaluation weekly at proportionally lower cost, accepting a corresponding increase in MTTR from 1.2 to approximately 8 hours.
While implementation details are anonymized, the contract structures, evaluation methodology, and lifecycle testing approach are reproducible across comparable AI-driven systems.
10. What REDD Contributes Beyond Existing Practice
A legitimate question is whether REDD is a novel contribution or a repackaging of existing practices. Contract testing (Fowler, 2018), probabilistic evaluation (Bommasani et al., 2021), bounded recursion, and lifecycle testing all exist as independent concepts. The answer requires specificity about what is new and what is integration.
10.1 The Integration Is the Primary Contribution
No existing framework, as of the time of writing, integrates contract testing with semantic behavioral thresholds, probabilistic quality evaluation with explicit metric limitation acknowledgment, execution lifecycle testing, and recursion safety controls into a unified development discipline anchored to TDD's RED-GREEN-REFACTOR cycle. This claim is based on a review of available frameworks in three adjacent areas: LLM evaluation frameworks (HELM, LMSYS Chatbot Arena, OpenAI Evals), MLOps observability tooling (LangSmith, Arize, Weights & Biases, Braintrust), and AI safety frameworks (Constitutional AI, RLHF pipelines). None of these frameworks addresses the full set of failure modes described in Section 2, and none is structured as a development discipline that integrates into a write-test-first workflow. If prior work integrating these mechanisms exists and was not identified in this review, the authors welcome correction.
The practical significance of integration over individual adoption is that the failure modes described in Section 2 interact in ways that individual practices, adopted independently, leave unaddressed at their boundaries. A provider migration that introduces a behavioral regression may also change latency characteristics that trigger timeout failures in the lifecycle test suite. An execution budget without a defined fallback behavior, recursion safety control without interface contract, produces clean termination and confusing output. The mechanisms reinforce each other; and in the author's experience, the boundary failures between independently adopted practices are where the most expensive production incidents originate.
10.2 Distinction from Related Work
REDD vs. LLM evaluation frameworks (HELM, LMSYS): those frameworks evaluate model quality in isolation, assessing what a model can do on benchmark tasks. REDD evaluates system behavior in the context of a specific application's contracts and requirements, assessing whether the system does what it is specified to do in its production context. A model that scores highly on HELM benchmarks may fail its behavioral contract in a specific extraction task; a model that scores lower on benchmarks may pass because the task plays to its strengths.
REDD vs. MLOps observability tooling (LangSmith, Arize, Weights & Biases): those tools provide visibility into what is happening in production. REDD specifies what should happen before implementation and validates it before deployment. Observability tools are valuable complements to REDD, they provide the production signal that informs evaluation dataset updates and threshold re-calibration, but they address a different point in the development lifecycle and cannot substitute for pre-deployment contract validation.
REDD vs. AI safety frameworks (Constitutional AI, RLHF, red-teaming): those frameworks address model alignment, misuse prevention, and value specification. REDD addresses operational reliability in deployed systems, whether the system behaves correctly and predictably within its defined operational envelope. These concerns are orthogonal and complementary. A system can be reliably unreliable (consistent failures that REDD would detect) or reliably misaligned (consistent harmful behavior that safety frameworks would address). Both frameworks are necessary.
10.3 The Write-Contract-First Discipline
The most practically significant behavioral change REDD introduces is the requirement to define interface contracts and execution budgets in the RED phase, before any implementation begins, the direct extension of TDD's write-test-first discipline into AI system engineering. The effect is familiar: forcing explicit reasoning about behavior, boundaries, and failure modes before the implementation creates the inertia of sunk cost.
In practice, this requirement is more disruptive than it sounds. 'What is the acceptable quality threshold for regulatory filing extraction?' is a question that must be answered before writing a line of implementation code. Without REDD, it is answered implicitly, by whatever the model produces, and the team encounters the answer only when a user reports that the quality is insufficient. The write-contract-first discipline makes uncomfortable requirements conversations happen early, when they are cheap, rather than late, when they are not. Teams new to REDD should expect mild organizational friction in the RED phase for the first several iterations; in the author's observation, this friction dissipates as the question-asking becomes habitual. The discipline, not any individual mechanism, is the core contribution.
11. Limitations, Risks of Adoption, and Future Work
Intellectual honesty about REDD's costs and risks is as important as documenting its benefits. The following subsections address both the conditions under which REDD is not justified and the failure modes that REDD itself can introduce.
11.1 When REDD Is Not Worth the Cost
REDD's overhead, contract definition, evaluation harness construction, lifecycle test suite implementation, evaluation dataset maintenance, is justified when the cost of failure is high, the rate of change is meaningful, and the system will operate in production for long enough to recoup the investment. The applicability assessment below summarizes the key considerations:
The threshold question teams most commonly face is whether to adopt REDD at prototype stage or at the production boundary. The recommendation is clear: defer to the production boundary. Applying REDD to exploratory systems imposes iteration overhead with no reliability benefit, because behavior specification is deliberately underspecified during exploration. REDD's value scales with the stability of requirements, which coincides with the production boundary in most workflows.
11.2 The Risk of False Security from Miscalibrated Contracts
REDD introduces a failure mode that its predecessor discipline does not: the false security of miscalibrated contracts, the AI-system analog of coverage theater in classical TDD, where high coverage metrics are achieved by tests that exercise code paths without asserting meaningful outcomes. The risk manifests in three forms: threshold permissiveness (thresholds set too low to detect meaningful regressions); dataset unrepresentativeness (evaluation set missing distribution tails where regressions manifest); and threshold degradation (thresholds lowered under delivery pressure, converting a quality guarantee into a quality record of what the system does rather than what it should do).
Guarding against these failure modes requires treating contract calibration as a first-class engineering activity, not a one-time setup task. Contracts should be reviewed against production failure distributions at least quarterly. Threshold changes should require the same code review scrutiny as disabling a failing unit test, the question 'why are we lowering this threshold?' must be answerable with a justification that does not reduce to 'to make the failing evaluation pass.' Without this governance posture, REDD becomes a sophisticated mechanism for documenting quality degradation rather than preventing it.
11.3 Evaluation Metric Limitations in Production
Section 5.2 discusses the limitations of automated evaluation metrics. An additional production concern not addressed there: evaluation metrics can be gamed by the system itself, not through intentional manipulation but through ordinary optimization pressure. A system whose prompts are iteratively refined against an evaluation dataset may overfit to that distribution, producing high metric scores that do not generalize to production inputs outside the evaluation set. The phenomenon is familiar from model training; it applies equally to prompt optimization, and it is underappreciated in AI systems engineering practice.
Mitigation requires periodic evaluation dataset refresh with examples drawn from production failures, maintaining a held-out evaluation set used only for quarterly baseline audits, and treating large metric score improvements with the same scrutiny as large metric score regressions, both may indicate evaluation distribution shift rather than genuine quality change.
11.4 Multi-Agent Coordination
The current REDD framework addresses single-agent recursion and individual model interaction points. Multi-agent systems with peer-to-peer coordination introduce contract compliance challenges not fully addressed here: whose contract governs inter-agent interaction, how execution budgets are allocated across peers, and how lifecycle failures propagate. These questions have tractable extensions from the REDD framework, Wu et al. (2023) provides a starting point for the architectural patterns involved, but the extensions have not been validated in production and represent a clear direction for future work.
11.5 Formal Verification of Termination Properties
REDD's recursion safety constraints are enforced programmatically and tested empirically. For high-stakes deployments where termination guarantees must be provable rather than empirically validated, medical decision support, financial transaction processing, safety-critical infrastructure,empirical testing provides insufficient assurance. Future work should explore formal verification of agent workflow termination properties using bounded model checking with probabilistic branching models, acknowledging that the nondeterministic branching of LLM-based workflows makes full state space exhaustion intractable for most current verification approaches.
11.6 Contract Threshold Evolution Over Time
As model capabilities improve, appropriate quality thresholds for a given task will increase. A behavioral contract threshold calibrated against GPT-4 in 2023 may represent a floor that substantially better models clear trivially in 2025, providing no meaningful regression detection. REDD does not specify a threshold evolution protocol; future work should address this through defined review intervals, annually, or following major provider model generations at which thresholds are re-calibrated against current capabilities. Threshold recalibration should be treated as a quality investment, not a quality concession.
12. Conclusion
The failure modes that motivated REDD are not edge cases or signs of engineering negligence, they are the predictable consequences of applying a testing discipline whose scope ends at the deterministic logic boundary to systems whose most consequential failure surface lies beyond it. REDD addresses this by extending TDD's scope, not replacing its principles.
REDD extends TDD principles to recursive, probabilistic, and dynamically executed systems by integrating four mechanisms, contract testing, deterministic/probabilistic validation separation, lifecycle testing, and recursion safety controls, into a unified development discipline anchored to the write-test-first workflow that TDD practitioners already know. The discipline is not a replacement for TDD. It is TDD applied to the full failure surface of AI-driven systems.
The case study demonstrates that REDD adoption produces measurable operational improvements: 90% reduction in silent regressions, elimination of runaway executions, 93% reduction in regression detection time, and structural improvement in provider migration resilience. The effect sizes are large in part because the baseline was poor, as is typical for teams at early AI system maturity. Teams adopting REDD from a stronger baseline should expect smaller relative improvements but equivalent structural benefits: explicit, computable acceptance criteria for provider migrations; regression detection before production deployment; and execution paths with tested termination properties.
The risks of REDD require active management: miscalibrated contracts provide false security; threshold degradation under delivery pressure converts quality guarantees into quality records. Teams that adopt REDD without the governance posture described in Section 11 produce a more sophisticated mechanism for accumulating reliability debt, not a mechanism for preventing it.
The core insight of REDD is simple: the same discipline that makes TDD effective, define expectations before implementation, make behavior testable, treat tests as first-class artifacts, can and must be applied to the probabilistic, recursive, and environmentally complex systems that modern AI engineering produces. The extension requires new mechanisms for new failure modes. It does not require new principles. The principles of TDD are sound. The job has outgrown them. REDD extends the job description.
As AI systems become operational infrastructure rather than experimental tooling, engineering discipline must expand accordingly. REDD represents one step toward that expansion.
References
Beck, K. (2003). Test-Driven Development: By Example. Addison-Wesley Professional.
Bommasani, R., Hudson, D. A., Aditi, E., et al. (2021). On the Opportunities and Risks of Foundation Models. arXiv:2108.07258.
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley Professional.
Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional.
Liu, Y., Iter, D., Xu, Y., Wang, S., Xu, R., & Zhu, C. (2023). G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment. arXiv:2303.16634.
Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
Nygard, M. (2018). Release It!: Design and Deploy Production-Ready Software (2nd ed.). Pragmatic Bookshelf.
Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems, 28.
Wu, Q., Bansal, G., Zhang, J., Wu, Y., Zhang, S., Zhu, E., Li, B., Jiang, L., Zhang, X., & Wang, C. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework. arXiv:2308.08155.
Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.
Zhang, T., Kishore, V., Wu, F., Weinberger, K. Q., & Artzi, Y. (2020). BERTScore: Evaluating Text Generation with BERT. International Conference on Learning Representations (ICLR).
