Software Development Was Recursive Before AI

Part two of Building the Recursive Enterprise: Software development has spent decades building faster feedback loops. AI can now participate in—and improve—more of that process.

In Part 1 of this series, I argued that recursive self-improvement needs a budget, an evaluator and a stopping condition. But I also argued that businesses should start early, because the experience accumulated through adoption is itself part of the return.

This idea is not entirely new.

Software development has been moving toward increasingly recursive ways of working for decades. Agile, the Spiral Model, Git-based collaboration, automated testing, continuous integration, DevOps, cloud infrastructure and production telemetry all help us do the same basic thing:

Build something
→ observe what happens
→ learn from the result
→ improve the next version

AI did not invent this loop. It can, however, participate in far more of it—and run it much faster.

From completing projects to improving products

When I first started building software, projects were often managed as finite journeys.

A business defined what it wanted. Analysts produced requirements. Architects and developers designed the system. The team implemented it, tested it against the specification, delivered it and eventually closed the project.

Requirements
→ specification
→ design
→ implementation
→ testing
→ delivery

This is the familiar Waterfall model as many organizations practised it.

The historical picture is more nuanced. Winston Royce’s original 1970 paper recognized the risks of a purely sequential process and proposed feedback, prototyping and effectively building the system twice. Nevertheless, many organizations came to treat Waterfall as a predominantly one-directional process.

The weakness was not that planning, documentation or architecture were unnecessary. They remain important.

The weakness was treating delivery as the end of the learning process.

A product can satisfy its original specification and still fail to satisfy its users. The market may have changed. The original assumptions may have been wrong. Users may behave differently from what the requirements predicted.

A project-completion mindset asks:

Did we deliver what we specified?

A product-improvement mindset asks:

What did we learn after people started using it?

Building shorter feedback loops

Agile made feedback more central to the development process. Instead of waiting until the end of a large project to discover whether the assumptions were correct, teams could deliver smaller increments and adjust earlier.

The Spiral Model approached the problem through risk:

Set objectives
→ identify risks
→ prototype or experiment
→ evaluate
→ plan the next cycle

Agile added frequent delivery, changing requirements, customer collaboration and regular reflection. The Agile principles explicitly call for teams to reflect on how to become more effective and then adjust their behaviour.

Modern development tools made these cycles faster and more measurable.

Git and platforms such as GitHub made changes easier to isolate, review, compare and reverse. Jenkins and other continuous-integration systems automated builds and tests. Cloud platforms reduced the time required to create infrastructure. DevOps connected software delivery with operational performance. Feature flags and production telemetry allowed teams to observe how users responded after a release.

These tools are not recursively improving systems by themselves. They are infrastructure for creating better feedback loops.

They helped software development move from:

Plan → build → deliver → finish

toward:

Hypothesize
→ build
→ test
→ release
→ observe
→ learn
→ repeat

They also created a second loop that improves how the team develops software:

Deliver software
→ measure the delivery process
→ identify friction and failures
→ improve tools and practices
→ deliver more effectively

The first loop improves the product. The second improves the software factory.

That second loop is where the comparison with recursive self-improvement becomes more interesting.

AI makes experimentation cheaper

Technology problems rarely have only one possible solution.

Several architectures may all satisfy the basic requirements. The best choice may depend on factors outside the technical problem itself:

• cost;
• delivery time;
• maintainability;
• available skills;
• expected scale;
• security;
• compatibility;
• and how easily the decision can be reversed.

Humans naturally favour approaches that have worked before. Experience is valuable, but it also creates bias. We tend to select familiar languages, frameworks, architectures and vendors because we understand their risks.

An AI agent can help expand the set of possibilities. It can propose several approaches, research unfamiliar options, build prototypes and compare the results.

That does not mean its recommendation is automatically correct. It means more of the solution space can be explored before making a commitment.

Agentic AI changes the economics of experimentation:

Lower cost of implementation
→ more alternatives can be tested
→ evidence arrives earlier
→ decisions can improve

This should make businesses more Agile, not less.

The documentation pendulum

My own experience with agentic development has demonstrated both sides of this.

Initially, we used relatively light documentation and allowed the agents considerable freedom to propose and build solutions. The early results were impressive. AI could move from a general idea to working code much faster than expected.

But when we examined the implementations more closely, the weaknesses became apparent. The agent had made assumptions that had never been discussed. It had selected architectures without understanding the wider business context. It sometimes solved a different problem from the one we intended.

So we moved in the opposite direction.

We produced more detailed requirements, architecture documents and technical specifications before allowing the agents to implement anything. This reduced some ambiguity, but eventually we went too far. The specifications became expensive to produce, slowed down experimentation and sometimes encouraged the agents to build deeper, more elaborate solutions than we actually needed.

We had moved from under-specification to over-engineering.

The better balance was somewhere in the middle:

Define the objective
→ specify important constraints
→ establish acceptance criteria
→ leave room for alternatives
→ build a small version
→ evaluate it
→ refine the specification

This is not an argument against documentation. AI makes good documentation more important because an agent can implement a poorly understood idea with extraordinary speed.

But the first specification should not pretend that everything is already known. Some questions are answered more cheaply by building and testing than by extending the document.

Faster coding increases the importance of evaluation

AI reduces the cost of producing software, but it does not reduce the need to determine whether the software is useful, correct or maintainable.

In some cases, it increases that need.

An agent can generate a large implementation before a human team has fully understood the assumptions behind it. It can create tests that confirm its own interpretation of the requirements. It can produce technically sophisticated code for a problem that did not need a sophisticated solution.

The bottleneck moves.

When implementation was expensive, much of the effort went into producing the code. As implementation becomes cheaper, more attention must go into:

• selecting the right problem;
• defining constraints;
• evaluating alternatives;
• testing behaviour;
• reviewing architecture;
• measuring business outcomes;
• and deciding what not to build.

The value of AI is not simply that it lets us produce more software. It lets us test more ideas before committing to one.

Probabilistic tools need repeated evaluation

There is another complication: AI systems are probabilistic.

The same model can produce different results across repeated runs. Small changes in context, prompts, tools or repository state can materially affect the answer. A model that performs well on one project may struggle on another.

This does not make scientific comparison impossible, but it makes single demonstrations unreliable.

A useful evaluation process needs:

• repeated tasks;
• consistent acceptance criteria;
• recorded model and tool versions;
• retained corrections;
• cost and time measurements;
• and enough examples to identify patterns rather than isolated successes.

No SME can test every combination of model, agent harness, prompt and workflow. The objective is not to find one universally best system.

It is to build a flexible process in which new systems can be tested against your own evaluated experience.

From software factory to recursive enterprise

This is where modern software development begins to resemble practical RSI.

An AI-assisted development system might perform a task, receive test results and human feedback, and then use that evidence to improve its future workflow:

Agent performs a task
→ tests and humans evaluate it
→ corrections and outcomes are retained
→ prompts, tools or processes are improved
→ the revised system performs the next task

The foundation model may remain unchanged. But the wider system—models, agents, tools, data and people—becomes better at producing the next result.

This is not full autonomous RSI. It is bounded organizational recursive improvement.

For most businesses, that is the more immediate opportunity.

The lessons from Agile and DevOps remain relevant:

• make changes small enough to evaluate;
• keep them reversible;
• shorten the distance between action and evidence;
• retain what each cycle teaches;
• and improve the process as well as the product.

AI does not make these principles obsolete. It makes them more important, because the loop can now run much faster.

In Part 3, I will look at who should control that loop—and why practical AI sovereignty does not require running every model locally.

Further reading

• Manifesto for Agile Software Development
• Principles Behind the Agile Manifesto
• CMMI maturity levels and continuous improvement
• Why I Returned to Coding in the Agentic AI Era

Building the Recursive Enterprise

How businesses can enter the RSI curve early without surrendering cost control, judgment or sensitive data.

1. Recursive AI Needs a Budget—but Waiting Has a Cost
2. Software Development Was Recursive Before AI
3. Sovereign AI Does Not Mean Running Everything Locally — coming soon