The Agentic Software Development Lifecycle: Ten Decisions

Agentic AI does not change individual development steps; it changes the operating model of software development. Our whitepaper "The Agentic Software Development Lifecycle" describes ten decisions that guide large organizations from manual development to agentic delivery: well-founded, regulated, and measurable. This article summarizes them and their three levels.

Why now: the learning curve cannot be bought

Banks, insurers, utilities, industrial groups, and public administrations run application landscapes that have grown over decades. Most of the IT budget is tied up in maintenance, operations, and regulation, system knowledge lives in people's heads and outdated documents, and the labor market offers no replacement for retiring developers. The current operating model cannot solve this equation.

Meanwhile, the technology has moved within three years from autocompletion via copilots to agents that plan and complete multi-step tasks on their own. The length of tasks that agents complete autonomously with a 50 percent success rate doubles roughly every seven months (Kwa et al. 2025, arXiv:2503.14499). The decisive point is the asymmetry: tools can be bought at any time, the transformation cannot. Verified specifications, a robust knowledge graph, and a practiced organization emerge only through operation. Whoever starts in 2026 has accumulated two years of learning curve by 2028 that latecomers cannot skip.

The difference between a copilot and an agent is structural, not gradual. A copilot assists one person with one step of work. An agent takes on entire assignments against defined quality criteria, checks itself against the specification, and hands a verified result to human gates. In our maturity model from L0 to L5, the tipping point lies between L3 and L4: up to L3, licenses and training suffice; from L4 on, organization, quality assurance, and governance carry the change. This is why copilot programs that leave the operating model untouched get stuck in pilot islands.

Ten decisions on three levels

The decisions build on one another: I to III lay the foundation (assets that last), IV to VII describe the operating model (division of labor between humans and agents with non-negotiable quality), VIII to X govern scaling (from proven pilot to operating standard).

The foundation: assets that last

Own the spec, not the code. When agents generate code in hours, code becomes a renewable artifact. The lasting asset is the precise, machine-readable description of what a system must do for the business: rules, data, interfaces, acceptance criteria. Whoever owns it can have code regenerated in a different technology, with a different model, by a different provider. For existing systems this means reconstructing as-is specifications systematically, for example with App2Spec from observed usage. For new developments it means formulating requirements in verifiable quality according to ISO/IEC/IEEE 29148 before agents build.

The knowledge graph as context foundation. Without structured knowledge about systems, terms, and rules, models guess and create rework. The knowledge graph models the organization in machine-readable form and links systems, requirements, test cases, releases, and regulations through typed, evidenced relationships. Impact analyses take minutes instead of weeks, and the chain of evidence from regulation to release emerges as a by-product. Above all, the context remains when you switch models over the coming years: the most effective insurance against vendor lock-in.

Platform and orchestration. The target picture is an end-to-end delivery platform as the single source of truth for code, specification, tests, and pipelines, plus an orchestration layer that coordinates agents and enforces permissions and audit trails. Tool decisions follow capabilities, not preferences, based on a two-dimensional scoring against weighted criteria such as TCO, security, and lock-in risk. Models remain interchangeable, sensitive workloads stay in European hosting, with no training on your own data.

The operating model: division of labor with non-negotiable quality

The smallest value-creating unit of the agentic Software Development Lifecycle is the cell: five people and a growing number of agents, responsible for one business domain end to end, from idea to operation. The cell lead owns the outcome, the domain expert holds the business truth, two full-stack engineers steer architecture, review, and the agents themselves, and the ops expert secures the last mile into production. Eight specialist roles become five responsibilities, not five leftovers; the transition happens through natural attrition and requalification.

When generation becomes cheap, verification becomes the bottleneck and the quality promise. Two principles carry the answer: the separation of generators and verifiers, because no agent checks its own work, and binding quality gates along the lifecycle, from Definition of Ready to Definition of Deploy. Test cases are derived from the specification before code is generated. Every release at a gate remains a human decision; every agent step behind it is logged. In ReqPOOL projects, quality rises by around 30 percent (project experience 2023 to 2026, verifiable per project).

Governance belongs in the process, not in hindsight: a human is accountable for every change an agent makes, policies are enforced as compliance as code in pipelines, and a complete audit trail makes every agent action reconstructible. The EU AI Act (Regulation (EU) 2024/1689) demands exactly these building blocks, DORA (Regulation (EU) 2022/2554) robust ICT risk management. Built correctly, the agentic lifecycle is not the compliance risk it is often taken for, but the first form of delivery in which evidence emerges as a by-product of the work. The role shift, finally, leads from execution to judgment: developers become architects of agentic systems, domain experts the precise source of the specification.

Scaling: from pilot to operating standard

At board level, one metric is enough: delivery efficiency, measured as completed units of work per full-time equivalent, quarterly per division, straight from the delivery systems. Efficiency gains count only with constant guardrails: change failure rate, production incidents, defect rate, and test coverage must not deteriorate; the four DORA metrics of delivery research (Forsgren, Humble, Kim 2018) provide the standard. Scaling happens in waves along a maturity path, not in a big bang. The whole becomes binding through a north star with board sponsorship, budget, and one metric in corporate steering.

The next step

In large organizations, the transformation is a program of 18 to 36 months; robust efficiency evidence emerges after 90 days of pilot operation. The first step is small and concrete: determine your position, set up two to three lighthouse cells, measure against the baseline after 90 days.

The full whitepaper, including the maturity model, the quality gate architecture, and the anonymized case of a major European bank, is available under Publications. How we anchor it in your organization is described on the Agentic Software Development Lifecycle service page. Or talk to us directly: in an expert conversation we clarify where your organization stands on the maturity path.