Artificial intelligence is changing software development most visibly in one area: implementation is getting faster. Code can be written in less time, tests generated automatically, requirements structured, documentation expanded, and entire work steps delegated to specialized agents. Work that once took hours or days can now sometimes be completed much faster.
That sounds entirely positive at first. But greater speed does not automatically mean better product development. An organization benefits from additional delivery capacity only when the rest of the system can handle it.
That is a central challenge. If requirements remain unclear, priorities keep changing, decisions take too long, or teams rarely check whether a release actually improved anything, AI does not automatically speed up progress. At first, it only increases the rate at which outputs are produced.
At worst, this only amplifies existing weaknesses.
The bottleneck shifts
For many years, software development focused heavily on how to build faster. Processes were optimized, deployments automated, development environments improved, and teams supported in delivering more work in less time.
AI changes this starting point.
As implementation becomes significantly cheaper and faster, the bottleneck moves elsewhere. What matters less is how quickly a solution can be built and more how quickly teams can determine which change is worthwhile, describe it clearly, and see whether it achieved the intended impact.
Software development is therefore better understood as a series of short feedback loops than as a linear production line.
This is exactly where LoopsWork comes in.
At its centre are three interconnected loops: Build, Value and Learning. Together they form a cycle of implementation, impact assessment and adaptation.
Build Loop: small changes instead of large assignments
In the Build Loop, an idea becomes a change that is as small and testable as possible.
This boundary is particularly important when working with AI. Large, vague briefs need extensive context, leave more room for interpretation and make the outcome harder to assess. Small Specs reduce the context needed and make the expected outcome clearer.
Rather than simply requesting a new login feature, for example, a Small Spec describes the affected endpoints, expected parameters, failure cases and tests used to verify the implementation as concretely as possible.
This reduces technical complexity. The context for AI agents also becomes smaller, outcomes become easier to trace, and changes are easier to review or roll back.
More implementation capacity should therefore not automatically lead to larger work packages. The opposite may be useful: the cheaper changes become, the smaller they can be shaped.
Value Loop: a change is not finished when it is released
One of the biggest weaknesses of traditional development processes is that work often ends with technical completion.
A ticket is closed, a feature released, and the team starts the next topic. Whether the change actually produces the expected impact often remains much less visible.
As development speeds up, this problem grows.
When many more changes can be released in a short time, the risk also grows that plenty of output is produced while little is understood about which changes actually create value.
The Value Loop therefore follows implementation directly. For relevant changes, the expected impact and how to observe it should be defined beforehand.
A simple scorecard can record the expected change, the metrics or observations that indicate it, potential unwanted side effects, and when to assess it.
This also changes the meaning of “done”. A change is not complete simply because it works technically and has been deployed. The loop is complete only when its impact can be understood.
Learning Loop: learning must change the system
Assessing a change does not always produce the expected result.
Perhaps the original assumption was wrong. Perhaps a spec was unclear, an important edge case was missed, or an agent lacked the necessary context. Perhaps the technical solution works perfectly but fails to solve the underlying problem.
These findings are valuable.
They should not remain only in retrospectives, notes or personal experience. A Learning Loop is complete only when learning feeds back into the working system.
This may mean adapting specs, adding tests, changing AI Agent Roles, improving prompts, adding monitoring requirements or developing working rules.
A completed change then produces an improved system for future tasks, as well as the next task.
Clear accountability matters more
AI can take on many tasks, but it does not remove unclear accountabilities.
If it is unclear who sets priorities, makes a business decision or judges whether an outcome is good enough, a capable agent will not reliably fill that gap.
As technical implementation capacity grows, clear decisions become even more important.
LoopsWork therefore deliberately separates support from accountability.
Agents can analyse, code, test, document, monitor and prepare proposals. Humans remain accountable for goals, priorities, quality, collaboration and decisions.
This distinction prevents technical automation from being confused with organisational accountability.
More speed must not create more work in progress
An obvious response to extra capacity is to start more work at the same time.
If AI theoretically enables a team to address many more topics, fully using that extra capacity may initially seem sensible. Yet this can create a new problem.
More parallel work creates dependencies, increases coordination needs and cognitive load, and makes individual changes harder to assess. At the same time, more changes need to be observed, operated and understood.
Limiting Work in Progress therefore becomes even more important.
The scarcest resources are attention, decision-making capacity, product understanding and an organisation's ability to learn from change, rather than implementation capacity alone.
A fast Build Loop achieves little if Value and Learning are then overloaded.
From push to pull
This also changes how new work emerges.
Many organisations still distribute work largely through a push principle. Initiatives, requirements and projects are started and handed to teams. When extra capacity becomes available, the amount of planned work often grows too.
AI can reinforce this pattern considerably.
A more useful consequence would be a stronger pull mechanism. New work starts only when sufficient focus is available, the problem can be clearly described, and its impact can realistically be observed afterwards.
The central question then becomes which next change offers the greatest learning or value, rather than how much additional work could be started.
The focus shifts from maximum utilisation towards learning cycles that are as short and complete as possible.
AI makes small changes more attractive
Cheaper development also changes the economics of small experiments.
Previously, a change might have needed to be large enough to justify planning, implementation and deployment effort. If a small trial can now be delivered much more cheaply, another option emerges: implement a bounded change and observe its impact instead of spending a long time debating whether an assumption is correct.
This reduces the need to establish extensive certainty in advance.
What matters is reducing uncertainty quickly and cheaply.
Small Specs, Small Context and tight feedback loops thus become an organisational advantage as well as technical improvements.
Speed requires observability
The faster software changes, the more important it becomes to understand what actually happens afterwards.
This includes business impact, technical stability, error rates, performance and the availability of important components.
Monitoring and alerting are therefore part of the feedback loop, rather than a later operational concern.
Without observability, a substantial part of the Value Loop remains invisible. A change may have been successfully deployed yet still cause new failures, strain central components or negatively affect user behaviour.
A fast development process therefore needs equally fast feedback from the running system.
Less process, more feedback
Many discussions of agile software development still focus heavily on processes, meetings and frameworks.
In future, a more useful question may be how quickly an organisation can complete a full cycle.
A small change is implemented, its impact observed, and a finding emerges that changes the next spec, test or decision.
This is the core of LoopsWork.
The goal is to shape the way of working so that faster delivery leads to faster learning—not simply to add as much AI as possible to existing processes.
Good organisations become capable of learning faster
The pointed thesis therefore remains:
AI makes poor organisations worse faster.
Unclear goals, slow decisions, excessive parallel work and weak feedback mechanisms do not disappear with AI. If more tasks are merely automated, these problems can become visible faster or intensify.
Well-organised organisations experience the other side of the same development.
Clear accountabilities, small work packages, limited Work in Progress, good observability and tight feedback loops enable them to use extra speed productively.
The decisive advantage is not simply producing as much code or releasing as many features as possible.
It lies in completing a full loop faster:
Build → Value → Learn.
The ability to implement changes quickly, understand their impact and immediately feed learning into the next decision matters more than production speed alone.