Delegating Responsibility to Agents

The technology community is engaged in an intense debate about which language model is better at generating code — a narrative that entirely misses the real issue. In practice, as models grow more intelligent, the role of the human architect does not diminish; paradoxically, the value of their key decisions increases dramatically.

The golden rule of agentic engineering: AI does not create new software architecture on its own — it merely accelerates the trajectory that a human defines for it.

We tested a number of projects — prototypes that were extremely easy and quick to build. Yet every subsequent iteration of functional requirements led to growing opacity and inconsistency within the system itself, to the point where it could no longer be reliably extended without risking unexpected failures.

The greatest contribution of AI agents is not that they can write code faster than a human. The real revolution lies in the fact that, for the first time in the history of software engineering, we have the ability to actively and radically influence the trajectory of a system's internal complexity. Give an agent a sound architecture and it will accelerate the development of a robust application. Hand it chaos, and it will construct an unmaintainable digital jungle with frightening speed and efficiency. Implementation can be delegated to machines almost entirely; architectural responsibility cannot.

1. The Autonomy Lifecycle and the Break Point

The conventional view of task delegation assumes that the more complex the system we are building, the more human effort and direct supervision it requires. In agentic development, the opposite is true — as illustrated perfectly by the S-curve (sigmoid) in Graph 1, which charts the degree of AI autonomy over the lifecycle of a project. [1]

Graph 1: The agent autonomy lifecycle

At the very start of a project, the curve is flat or only gently rising. At this stage, the agent occupies the position of an exceptionally qualified programmer who possesses encyclopaedic knowledge of the entire internet, yet has no local intuition or context whatsoever. If the architect does not take responsibility at this point and invest time in rigorously defining rules, structures, and constraints, the project will not develop in the right direction. At this zero point, the architect must do the greatest share of contextual work — designing data models, interfaces, and system boundaries.

This investment pays off at the moment represented on the graph by the steeply rising curve: the Break Point. Once a codebase contains firm rules, clear architectural patterns, and a consistent application skeleton, the dynamic of collaboration changes radically. The agent no longer needs to be guided step by step. It begins to understand the system not from general principles, but from the context of the application itself.

Anyone who has worked with agents at a deeper level will recognise this moment: last week you were writing half the code yourself and prompting every endpoint in detail; today the agent autonomously handles 80% of the implementation from a single brief intent, because it simply reads the correct pattern from the existing structure. The autonomy curve subsequently approaches its maximum asymptotically. The better and more cleanly you lay the foundations, the less micro-management will be required in the later stages of a project.

2. Three Trajectories of Complexity Growth

When we delegate code writing to agents, the key business and technical question is not how quickly we have a first version ready. What matters most is what happens to the structural complexity of the system after hundreds or thousands of further changes and iterations. This brings us to Graph 2, which illustrates the long-term consequences of three different approaches to managing an agent.

Graph 2: Three trajectories of complexity growth

A strict distinction must be drawn between two concepts: code size and code complexity. Many managers labour under the illusion that more lines of code automatically means a more complex system. This is a mistake. You can have a perfectly modular system of 20,000 lines with low complexity, where dependencies are clean and readable. And you can have a 2,000-line script exhibiting catastrophic complexity, riddled with hidden dependencies and implicit behaviour. Complexity is defined by the number of dependencies, the degree of branching, and the volume of knowledge required to understand the system. [2] Because agents generate enormous volumes of code at virtually no cost, code size ceases to be a meaningful metric. The real battlefield is structural complexity — which the graph divides into three trajectories:

1) Uncontrolled complexity escalation

This scenario arises when an agent is given absolute autonomy without architectural oversight. Every new requirement is resolved as a local optimisation — the agent writes code that fulfils the specification and passes a basic functional test (the "happy path"), but without regard for the wider whole. Code begins to accumulate haphazardly on top of older layers.

System complexity grows significantly faster than the volume of new functionality being added. After a certain point, the system degrades to a state where neither the human nor the agent itself — constrained by a limited context window — can reliably predict what a further change might break. Every new line requires enormous effort, and the project becomes unmanageable.

2) Controlled superlinear growth

This state corresponds to standard, commonly experienced software development today. System complexity grows in proportion to the product itself and the addition of new business features. The human acts as a constant filter, corrector, and validator.

The stakeholder or developer continuously monitors inputs, iterates requirements against the existing codebase, and does not allow the agent to make radical structural excesses. The overhead of maintenance and ongoing context refinement is high, and development naturally slows over time — but the system is kept operational and does not collapse under its own weight.

3) Active complexity reduction and scalability

The ultimate goal of successful agentic development. From the outset, the architect constrains the agent's autonomy with strict rules and forces it to write code as efficiently, modularly, and linearly as possible. The agent initially pushes against the constraints, but once the system stabilises, the architect no longer uses AI merely as a mindless code generator — instead employing it as a powerful tool for ongoing refactoring.

The agent is systematically tasked with cleaning up older modules, eliminating duplication, and simplifying dependencies. After an initial rise, the overall structural complexity of the system stabilises and grows significantly more slowly than the volume of functionality.

3. The Psychology of Models: Why Does AI Tend Towards Over-Engineering?

To keep complexity on the lower curve, the architect must understand why language models have a natural tendency to overcomplicate and inflate code. It is often claimed that models generate unnecessary boilerplate simply because they were trained on mediocre, low-quality data from the internet. That is only half the truth.

Models without explicit architectural context tend towards over-engineering — not because it is an irremediable flaw, but because a robust pattern is statistically the safer answer than elegant simplicity. The less context a model receives, the more readily it reaches for a textbook solution. Architectural rules correct this tendency — but it will not disappear on its own until the architect establishes strict constraints.

Models are trained to maximise the likelihood of correctness and to favour so-called "safe completions" and academic industry best practices. [3] When given a business specification, a model will rarely choose a primitive, elegant three-line solution. The statistically safer approach is to apply a robust, widely accepted textbook pattern.

Diagram: How a specification without architectural context leads to over-engineering

In practice, we see situations where an agent introduces deep inheritance hierarchies, dependency injection, interfaces, and generic factories into a trivial script. Technically, everything is correct — the model has successfully delivered a "bulletproof" solution. In practice, however, it has created a system with massive internal overhead that is unnecessarily expensive to maintain. A model has no intrinsic sense of when engineering simplicity is preferable to academic correctness. It has no long-term intuition for technical debt. A senior developer looks at the code and says: "This works for now, but it could be a problem in six months. "The LLM sees only: "This satisfies the statistical patterns of correctness — task complete."

4. The Economic Paradox of Agentic Development

This difference in approach to managing complexity has profound economic consequences that are almost entirely absent from current managerial debates about AI. Viewed through the lens of Total Cost of Ownership (TCO), poorly managed AI radically reduces the cost of the first phase — whilst burdening the project economically over the long term.

In unmanaged agentic development, you obtain a prototype at a fraction of the cost and time of a human team. But due to the exponential growth of hidden complexity and over-engineering, the maintenance phase becomes increasingly unmanageable. Every further modification requires massive analysis of an excessive volume of complex code, and the cost of developing the system begins to climb steeply. Conversely, well-managed agentic development — where the architect maintains firm control over the constraints — demands greater initial engineering effort, but delivers lasting economic sustainability: cheap implementation accompanied by cheap maintenance. [4]

Graph 3: TCO — unmanaged versus managed agentic development

5. Machine versus Human: The Anatomy of Legacy Code

Whilst building a new project from scratch with AI is relatively straightforward, the greatest technical challenges arise when we attempt to deploy agents on an already existing, live solution — a legacy codebase. Here we encounter a fundamental paradox in the human and machine perception of software.

The fundamental conflict of perception: Code that humans consider elegant may be entirely unreadable and confusing to an AI agent.

Historically, software was written to be comprehensible primarily to the human mind. To manage complexity, people rely on logical abstractions and mental models. When reading code, a developer visualises the business logic, domain relationships, and the intent of the original author. They infer a great deal from context and experience — which allows us to employ the advanced magic of frameworks, deep inheritance, or implicit behaviour where much happens invisibly.

Diagram: Humans read intent, models read statistics

A language model, however, has no mental model of the world or of your business. It perceives code as a pure network of tokens, structures, and statistical relationships, bounded by the size of its context window. If a codebase is extremely fragmented — full of hidden states and implicit magic, in the name of human "cleanliness" — the model immediately loses its bearings and cannot statically determine what connects to what. Paradoxically, a machine is better served by code that is explicit, highly modular, and linear.

A significant advantage of deploying an agent on an existing project is that the model can absorb enormous volumes of existing code within seconds and immediately grasp the established patterns of the project. This is more valuable than a thousand lines of instructions in a prompt. Yet the quality of that existing codebase will inexorably determine the entire future of the project.

If the existing architecture is clean and well-structured, the agent immediately absorbs those qualities and begins to multiply them. If the codebase is opaque, laden with technical debt and structural flaws, the agent begins to improvise on top of those poor patterns. The result is the generation of very weak or unusable code, which condemns the human developer to an endless cycle of corrections, clarifications, and hallucination-wrangling.

Conclusion: AI as a Mirror of Architecture

The rise of agentic development does not change the fundamental rules of software engineering — it merely makes them extraordinarily unforgiving. An AI agent is not an architect. It is an incredibly powerful, encyclopaedically educated implementor.

The central question facing software development is therefore not how advanced and autonomous the models available to us will be. The central question is how high-quality, clean, and robust an architecture we can prepare and entrust to those models. AI will never cure a poorly designed system — it will merely scale it at a speed no human developer can effectively moderate.

Reference:

1. Wikipedia — Technology adoption life cycle
2. Wikipedia — Cyclomatic complexity (McCabe, 1976)
3. Raj et al. — The Buy-or-Build Decision, Revisited: How Agentic AI Changes the Economics… (arXiv, 2026)
4. Lientz & Swanson — Software Maintenance Management (1980); referenced in [3]