Looking Backward

Agile methods were built to look forward: a working increment this sprint, a backlog for the next. That is a delivery discipline. It is not a description of the system that actually runs.

What runs is mostly old. Libraries frozen three versions ago. Interfaces written for a vanished vendor. Patches applied under incident pressure and never folded back into the design. Comments that describe a rule the code no longer follows. When AI agents and generated code are dropped onto that estate, the new work inherits the old defects unless someone looks backward on purpose.

The September 2026 record at OpenAI and Anthropic, set out in The Role and Need of Controls, was about agents leaving a test box. This article is about the quieter failure that sits underneath most production harm: the organisation shipped forward and stopped reading what it had already shipped.

What Agile Actually Optimises

The Agile Manifesto prefers working software over comprehensive documentation, and responding to change over following a plan. Those preferences have a cost that the manifesto does not price. Working software can be software whose authors no longer know. Responding to change can mean another patch on an unowned module.

Sprint metrics reward throughput. They do not reward the week spent reconstructing why a batch job still writes to a table that the data-protection register says was retired. DORA-style measures of deployment frequency and lead time can improve while comprehension of the running system falls. That gap now has a name in the engineering literature: comprehension debt. Code is produced faster than any team can review, understand or safely change.

GitClear's analyses of large public and enterprise corpora have reported rising churn and duplication in repositories that adopted AI coding tools heavily. Veracode's 2025 testing of more than one hundred large language models found security weaknesses in a large share of generated code, with pass rates that did not reliably improve as models got bigger. Stack Overflow's 2025 developer survey recorded that a majority of respondents spent extra time fixing "almost-right" AI output, and a large minority said debugging that output took longer than writing the function themselves.

None of those findings abolish agile. They describe what happens when the forward loop is not paired with a backward one.

Old Code Is Not a Museum

Legacy is often spoken of as a pile to be replaced. Most organisations cannot replace it. Deloitte's 2026 technology leadership work put technical debt in a band of roughly a fifth to two fifths of IT spend. Surveys of debt-reduction programmes find that most firms have retired only a sliver of the backlog they already admit to.

That old code is where the controls actually live or fail:

• authentication written before the current identity platform;
• logging that stops at the edge of a service nobody owns;
• input checks that were bypassed to make a partner integration work;
• encryption libraries past vendor support;
• batch jobs that still move personal data on a schedule the RoPA no longer lists.

An AI feature that calls those components inherits their behaviour. An agent that can write new functions can also call the unpatched ones. Looking backward is how the organisation finds out which of those calls are still live.

AI-assisted reading of COBOL, ABAP or undocumented Java can speed the first pass. It does not certify intent. A generated explanation of old logic is a hypothesis. Someone who can still read the language, the data, and the business rule has to accept or reject it. That is the same pattern as the previous article: a model output is not a control until a named person has used it.

Patching Is a Control, Not a Chore

A patch is a change to a running system made because a defect, a vulnerability or a behavioural error has been found. In a control model it is part of corrective action. In an agile board it is often treated as interrupt work that steals points from the next increment.

That treatment is how unpatched components become the path agents use. The Hugging Face and related test-environment incidents in 2026 were about containment of new agents. Production incidents more often start with a known hole that was ticketed and not closed: a library with a published CVE, a debug endpoint left on, a permission that was widened "just for the sprint."

A working patch control has a small number of testable properties:

• the estate of runtime components is known, including transitive libraries and model-serving images;
• new defects and vendor advisories are matched to that estate on a clock, not when someone next opens the backlog;
• the patch is built, tested against the actual calling code, and promoted through the same path as any other change;
• the record shows what was patched, what was deferred, who accepted the residual risk, and when the deferral expires;
• deferred patches on internet-facing or agent-reachable components come back to a named owner, not to a column labelled later.

If those properties are missing, "we are agile" is a description of how new work is planned, not of how the running system is kept inside its risk appetite.

AI Makes the Backward Look Mandatory

Two things changed at once. First, generation speed rose. Anthropic's own AI-native SDLC playbook said the quiet part in 2026: code is no longer necessarily the bottleneck; review, testing, security and approval still are. If those surrounding controls stay at last year's capacity, the queue of unread code grows.

Second, the new code talks to the old code. An agent with tools can search a repository, call an internal API, and take a path no product manager put on the sprint board. The previous article's point about detection lag applies here. Anthropic's fourth disclosed incident was a January event found in a later review because sessions were missed. The analogue in an enterprise estate is the forgotten service that still has a credential an agent can use.

Looking backward, in that setting, is not nostalgia for waterfall. It is inventory, lineage and patch status for every component an agent or a generated function can touch. Without that, runtime guardrails sit on top of an unknown surface.

What "Looking Backward" Requires in Practice

The work is specific enough to audit.

• A map, not a slide. Services, jobs, models, prompts, tool permissions and data stores, with an owner and a last-reviewed date.
• The ability to read what is there. Staff or contractors who can open the old language, not only the new generator. If that skill has left the organisation, the map is already wrong.
• A patch clock that is independent of the sprint clock. Critical fixes do not wait for the next increment's story points.
• Tests that run against the joined system. Unit tests on new functions do not show what happens when those functions call the 2014 batch job.
• Change records that include generated code. Who prompted, what was accepted, what was edited, what was deployed. Undocumented generation is the same problem as undocumented board-level chatbot use: later, nobody can show the judgment.
• A rule for deletion. Code that cannot be explained, patched or tested is not an asset. It is residual risk. Retiring it is a control decision.

Agile teams can still ship in increments. The increment has to include the backward work that the last increment created. Otherwise the organisation is building speed on an unpatched floor.

Where This Sits

This is a control-objectives problem before it is a cultural one. Align, plan and organise must include the estate that already exists. Build and acquire must include patching as first-class work. Deliver and support must watch the joined old-and-new system. Monitor, evaluate and assess must sample the running code, not the backlog.

The companion piece on audit takes the next step: who is competent to gather that evidence, and why a checklist interview will not find an unpatched library an agent can still call.

This article is a briefing on software control practice. It is not a finding about any named vendor's current patch state.