Agentic Engineering Maturity: From Writing Code to Running Systems

The conversation about AI and software development often starts with how quickly an agent can write code. That is an understandable measure because code is visible and demonstrations are easy to compare. Yet a working application also needs a sensible design, reliable tests, somewhere to run and someone responsible when it fails. Faster coding changes one part of that work. Delegating the surrounding responsibilities changes the shape of the team.

Consider an internal application that reconciles warehouse stock with deliveries. An agent might help build it, generate tests, configure its infrastructure or investigate a failed release. These are different kinds of responsibility, with different consequences when something goes wrong. Calling all of them “AI-assisted development” hides distinctions that matter when deciding what people should do next.

Nine levels of delegated engineering

View model at full size

This model describes how delegation expands from building agents into the wider engineering lifecycle:

0. Human-built agents: developers write the agent code.
1. Agents build agents: agents generate code under human direction.
2. Engineering support: agents create tests, documentation and tooling.
3. Complete implementation: agents produce application code and infrastructure as code.
4. Agent-augmented design: people lead; agents explore and assess options.
5. Agent-led design: agents develop designs; people assess and approve them.
6. Deploy and monitor: agents release software and check system health.
7. Manage operations: agents investigate incidents and execute approved recovery.
8. Bounded self-healing: agents generate, test, deploy and verify fixes within defined limits.

A team can operate at several levels at once, delegating documentation while retaining direct control of production changes. Higher numbers describe broader delegated scope, not automatically better engineering. Human accountability remains at every level.

More autonomy needs stronger evidence

In the stock-reconciliation application, an agent could generate a change and tests that confirm it works. If both assume that a delivery is always complete, they may miss the same problem with a partial shipment. Someone needs to establish the expected behaviour independently, using real examples and requirements that the agent cannot quietly rewrite to make its answer pass.

The same distinction applies to self-healing. Restarting a failed service follows a known recovery procedure. Changing its code introduces a new behaviour. An agent that stops an error by removing a security check has made the dashboard quieter while making the system less safe. Permission to recover a service should not automatically become permission to change its rules.

Each increase in authority therefore needs clear boundaries, evidence of success and a way to stop or reverse the action. Some changes should still require human approval. The useful measure is whether the team can demonstrate that delegated work remains within its intended limits.

Developers move closer to the business

For a developer whose role centres on turning tickets into code, this is a substantial change. More effort can move towards clarifying requirements, examining proposed designs and investigating behaviour across the whole system. Technical depth remains important because the person accepting a generated solution needs to recognise what it leaves out.

The movement also comes from the other direction. A business analyst can use an agent to turn an unclear requirement into a prototype that colleagues can examine. A product manager can explore alternative interactions. An operations specialist can express the conditions under which a recovery action is acceptable. People who previously relied on a development queue can participate more directly in shaping software.

These roles begin to overlap around a shared problem. In the stock application, a developer and a warehouse planner might investigate why a partially received shipment appears complete. The planner understands how goods actually arrive; the developer understands how the records and integrations behave. Easier implementation brings their work closer together without making their expertise interchangeable.

Junior roles need a different starting point

Hiring only experienced engineers would overlook something important. Many new entrants are developing AI-native working habits during their education, rather than adding AI to an established approach. In HEPI’s 2026 survey of 1,054 full-time UK undergraduates, 95% reported using AI in at least one way. Familiarity is not the same as expertise, but it should not be underrated.

Someone who has learned to explore a problem with AI may approach an assignment differently from someone trained to complete every step manually. That can bring useful experimentation and challenge established habits. Learning should flow both ways: experienced staff contribute judgement and knowledge of consequences, while juniors can introduce different ways of investigating and building.

Junior roles can therefore begin with product exploration, developing acceptance examples, evaluating agent output or tracing integration failures. They still need programming, debugging and security foundations, supported by real mentoring. Continuity depends on people gaining responsibility over time. An organisation that stops developing juniors may make today's team smaller while leaving tomorrow's team without the experience it needs.

Smaller teams need broader ownership

As more implementation work is delegated, some products may need fewer people to reach the same result. A smaller team can remain focused on one customer problem and carry it from discovery into operation, with fewer handoffs between specialist queues. Its members will need a broader understanding of the product and enough technical judgement to assess what agents produce.

That does not produce a universal headcount formula. Some organisations will use the capacity to build more, while others will reduce staffing. Review, incident cover and shared knowledge still require people. A team that depends on one person understanding every generated change has created a fragile operation, even if its delivery figures look impressive.

When building becomes cheaper than validating

Development cost often forced an idea through questions about budget, demand and expected return. When a simple application can be produced quickly at low initial cost, that pressure weakens. Building first and looking for a reason to use it afterwards becomes an affordable habit. The ability to create software starts to outrun the discipline of choosing what deserves to exist.

The increase in supply is already visible. Sensor Tower estimates, reported by 9to5Mac from a New York Times report, put new App Store releases at about 560,000 in the first half of 2026, double the comparable period. Downloads grew by only 2%. Separately, Appfigures data in RevenueCat’s 2026 report shows monthly subscription-app launches rising from around 2,000 in January 2022 to more than 14,700 in January 2026.

The contrast between release growth and download growth illustrates the competitive setting: producing another application is becoming easier while customer attention remains limited. For a hobbyist, making something personally useful may be sufficient. A commercial product still needs a reason for people to adopt it and keep using it.

Cheaper development also makes experiments possible that previously could not justify their cost. The distinction is whether the team uses a small release to learn or treats publication itself as success. Running a product brings continuing obligations around support, maintenance and customer trust, even when its first version was cheap.

Adapting when the work you enjoy changes

We should recognise that this can provoke resistance, for understandable reasons. If you enjoy writing software, being pushed towards directing agents or managing a product can feel like losing the part of the job you chose. Years of practice form part of a professional identity. Describing every change as an exciting opportunity ignores that loss, but resisting the change does not stop it from affecting the work available.

Some developers will deepen their technical expertise; others will move closer to product decisions, experimentation or direct work with people. The change will not reach every role at the same speed, but relying on today's division of work to remain unchanged carries a growing risk of falling behind. Employers share responsibility for the transition. They need to provide learning time, mentoring and opportunities to practise new responsibilities while retaining experienced people.

For people whose role centres on implementation, upskilling is becoming a matter of professional survival rather than simply a career preference. Product management, innovative exploration and human-facing work offer ways to build on judgement, context and trust, even as AI changes parts of those roles too. There is still time to adapt, but the acceleration around us is shortening the period in which we can comfortably postpone it. Learning the next part of the job needs to begin while we still have room to grow into it.

This article was developed from the author’s ideas, with artificial intelligence (AI) used to help structure the argument, refine the text and create the illustrations. The final article has been reviewed and approved for publication.

© Centipod B.V., 2026