Can We Use Old Ways to Build New Systems?

Is the engineering discipline that produced four decades of reliable enterprise software still fit for purpose when the component at the centre of the system no longer behaves the same way twice?

Or are organisations quietly discarding a body of hard-won assurance practice on the untested assumption that AI demands an entirely new one?

The prevailing conversation offers two answers to that question, and both are unsatisfactory. The first holds that AI is simply the next technology wave, governable through the project methodologies, acceptance criteria, and pre-launch sign-offs that have served the enterprise since the arrival of client-server computing. The second, more fashionable position holds the opposite: that probabilistic systems are so unlike conventional software that established practice has nothing useful to offer, and that assurance must be reinvented from first principles by whichever vendor happens to be selling the platform.

Neither position survives contact with an actual deployment. The truth is less dramatic and considerably more useful. The methods are not the problem. Three disciplines developed long before generative AI existed—the Pre-Mortem from decision science, Red Teaming from military and security practice, and Chaos Engineering from distributed-systems operations—remain the most serviceable instruments available for making an AI programme defensible. What must change is not the method but the failure model each method is pointed at. The old ways work; they simply have to be aimed at a different kind of failure.

It is worth being precise about the discontinuity, because imprecision here is what produces both of the unsatisfactory positions above. Conventional enterprise software fails deterministically. Given the same inputs and the same state, it produces the same defect, which can be reproduced, isolated, corrected, and regression-tested. Assurance in that world is fundamentally an exercise in enumeration: identify the paths, test them, and close them out.

A LLM offers no such courtesy. The same prompt may produce a different output on successive calls; the input space is natural language and therefore effectively unbounded; the artifact under test is non-stationary, since a provider may update the underlying model without notice and invalidate a test suite that passed the previous week. Worse, the characteristic failures are not crashes. They are confident, fluent, plausible outputs that happen to be wrong, or correct outputs produced through a decision path nobody can reconstruct, or an agent that completes its task successfully by taking an action nobody authorised. A system that fails loudly is an engineering problem. A system that fails quietly, at scale, while reporting success is a governance problem.

What has not changed is the structure of the discipline. Enterprises still need to anticipate failure before committing capital, to attack their own systems before an adversary does, and to establish how the whole arrangement behaves when a dependency degrades in production. Those three obligations are precisely what the Pre-Mortem, Red Teaming, and Chaos Engineering were built to discharge. The question is not whether to use them. It is what each one must be re-aimed at.

Gary Klein introduced the Pre-Mortem in the Harvard Business Review in 2007 as a technique of prospective hindsight. The team assumes the project has already failed, comprehensively and publicly, and then works backwards to explain why. The mechanism is psychological rather than technical: people who are asked to explain a failure that has notionally already occurred surface concerns they would suppress if asked merely to assess risk, because the social cost of appearing obstructive has been removed. Klein, Koller, and Lovallo later positioned the same exercise as a bias-buster in complex capital decisions, and structured facilitation guides from bodies such as the Agency for Healthcare Research and Quality turned it into a repeatable workshop pattern.

The method transfers to AI almost without modification. What must be supplied is the failure vocabulary, because a room of business owners and engineers left to imagine AI failure unaided will imagine outages and cost overruns, which are the least likely things to go wrong. The NIST AI Risk Management Framework and its Generative AI Profile provide the missing taxonomy: reliability, safety, privacy, security, bias, transparency, misuse, and dependency on infrastructure or suppliers. Used as a prompt sheet, that taxonomy converts a vague anxiety into a specific and answerable question. Not "what if the agent underperforms", but "assume that in eighteen months we discovered the agent had been applying a legacy pattern embedded in unaudited historical data, uniformly and at speed, across every applicant segment; what would have allowed that to happen, and what would have caught it".

The output of an AI Pre-Mortem should never be a risk register that is filed and forgotten. Each plausible failure identified in the room should leave the workshop as a design requirement: a minimum quality threshold, an access-control boundary, a defined human-approval point, a monitoring signal, or an explicit stop condition. A Pre-Mortem that does not change the architecture, the budget, or the approval gates has not been conducted; it has been performed.

Red Teaming is older still, and its transfer is where most enterprises go wrong. In its conventional security form, a red team exercise is bounded, periodic, and conducted against a system whose attack surface is composed of interfaces, credentials, and code. The generative equivalent inherits the mindset but almost none of the boundaries, because a model cannot reliably separate informational context from actionable instruction; anything it reads is a potential instruction, which means the attack surface includes every document, email, ticket, calendar entry, and web page the system is permitted to ingest.

The practical starting point is a catalogue rather than a creative exercise. The OWASP Top 10 for LLM Applications converts directly into test scenarios: for each risk, define the attempted action, the asset at risk, the control expected to intervene, and the evidence that will constitute success or failure. Microsoft’s planning guidance for AI red teaming adds the operational scaffolding, namely which attacker personas to simulate, which assets are sensitive, and what the organisation will accept as a failed test. Where systems are agentic and connected to enterprise SaaS, the relevant literature has moved on to subtle authorisation failures rather than jailbreaks, which is the correct emphasis: the realistic enterprise breach is not a model persuaded to say something embarrassing, it is an agent persuaded to use a legitimate permission on an illegitimate instruction.

Two adaptations are non-negotiable. The first is that Red Teaming must become continuous rather than periodic, because the target is non-stationary; a model or system-prompt update can silently reopen a finding that was closed and verified, which makes regression testing after every change an operational requirement rather than a maturity aspiration. The second is scale. Manual adversarial testing cannot cover an unbounded input space, and the research direction established by work on using one language model to generate adversarial cases against another exists precisely because human red teams cannot generate enough volume. The mature posture is a hybrid: human ingenuity to define what an attacker actually wants, automation to explore the space, and a documented, prioritised remediation path connecting the two.

Chaos Engineering arrived from a world of distributed infrastructure, where the governing insight was that a system’s resilience is unknown until failure is injected deliberately, under controlled conditions, in a bounded blast radius, with a defined steady state and an abort condition. Its transfer to AI is the least discussed of the three methods and, for autonomous agents, arguably the most important, because it is the only one of the three that examines the system as it actually runs rather than as it was designed or attacked.

The infrastructure experiments carry over unchanged: a slow or failing model endpoint, a provider rate limit, an unavailable retrieval source, a degraded database, a partial network. What must be redefined is the steady state. For a conventional service, healthy means available and within latency bounds. For an AI system, availability is close to irrelevant as a safety measure, because the dangerous condition is not the agent that stops; it is the agent that continues. The meaningful hypotheses are behavioural. When the knowledge source is unavailable, does the agent decline to answer, or does it answer from parametric memory with undiminished confidence? When a downstream write fails midway through a multi-step task, does the system reconcile, roll back, and report, or does it retry against a partially mutated state? When the human-approval mechanism is unreachable, does the workflow halt, or does it proceed on a default?

The reliability engineering tradition supplies the instruments for making those questions measurable: safety-oriented service-level indicators, error budgets, circuit breakers, checkpointing, and staged deployment, applied to agents that call models, tools, and services. The specific measures that matter for agent systems are also reasonably well established in practitioner literature, including task completion rate, recovery time, shared-state corruption, retry amplification, and failure propagation between agents. An organisation that can state, with evidence drawn from controlled experiments, exactly how its agent behaves when a dependency degrades has something that no vendor assurance document can provide.

Treated separately, each of these methods is a useful exercise. Treated as a sequence, they become an assurance architecture, because each one produces the input the next one requires, and each occupies a distinct position in the lifecycle where the others cannot operate.

The Pre-Mortem belongs before commitment, when the cost of changing a decision is a conversation rather than a rebuild; it produces the failure hypotheses. Red Teaming belongs before and throughout deployment; it converts those hypotheses into adversarial test cases and establishes which of the anticipated failures can actually be provoked. Chaos Engineering belongs in staging and then in production; it establishes whether the controls that passed adversarial testing still hold when the environment underneath them misbehaves. Imagined failure, provoked failure, operational failure: design, adversary, and reality, in that order.

The connective tissue is documentation, and this is the point at which the sequence becomes a governance asset rather than an engineering habit. A cross-functional committee asked to approve an AI use case is entitled to see the failure scenarios the team identified, the tests derived from them, the results of those tests, and the residual risks that were consciously accepted. That evidence chain, rather than a vendor’s assurance or a successful demonstration, is what makes a deployment defensible to a regulator, an auditor, a board, or a court.

Intellectual honesty requires acknowledging the limits, because a method applied beyond its competence produces false confidence, which is worse than no method at all.

Three limitations are structural. The first is coverage: conventional testing derives its authority from enumeration, and no test suite can enumerate natural language, which means AI assurance produces statistical confidence rather than proof, and must be reported in those terms. The second is shelf life: every finding is valid only against the model version, system prompt, tool configuration, and data state that were in place when it was produced, so results carry an expiry date that traditional test evidence does not. The third is the acceptance criterion itself: pass and fail are ill-defined for a probabilistic output, and organisations must therefore agree in advance on thresholds and tolerances, which is a business decision about acceptable error, not a technical one.

There is also a boundary these methods do not reach at all. None of them addresses unsanctioned use. A rigorously pre-mortemed, red-teamed, chaos-tested enterprise system provides no protection whatever against an employee pasting proprietary material into a personal account on an unmanaged consumer platform. That is a governance and literacy problem, and it must be solved separately, through access controls, gateways, policy, and training. The three methods make sanctioned systems trustworthy; they do nothing about the systems nobody sanctioned.

So the answer to the question is a qualified yes, and the qualification is the entire substance of the matter. The old ways are not merely usable; they are the only mature assurance practice available, and an organisation that discards them in the belief that AI requires something wholly novel will find itself reinventing, badly and at expense, disciplines that already exist in refined form. But they cannot be applied as inherited. The Pre-Mortem must be armed with an AI-specific risk taxonomy or it will imagine the wrong failures. Red Teaming must become continuous and partly automated or it will certify a system that has since changed underneath it. Chaos Engineering must measure behavioural safety rather than availability or it will confirm resilience in precisely the dimension that does not matter.

"The heart of being trustworthy is that you take the other person’s interests into account… A good answer will never be, ‘AI made me do it.’""

As with every genuine transformation, the most stubborn obstacle here is not technical but human; a deep-seated preference for the familiar over the uncertain, and an understandable reluctance to entrust consequential decisions to an unfamiliar analytical infrastructure. There is a certain irony in the resolution, because the remedy for that hesitation turns out to be familiar as well. It is not blind faith in the technology, and it is not the invention of a new discipline. It is the disciplined application of methods the enterprise already understands, pointed at failures it has not yet learned to imagine.

Ultimately, competitive advantage in the AI era will not belong to the organisations that deploy algorithms fastest. It will belong to those that establish the highest standard of institutional trust, operational integrity, and continuous assurance; the enterprises that earn the right to rely on their machines, rather than simply hoping they can.