Software testing has accumulated a large vocabulary over several decades. Unit testing, integration testing, system testing, regression testing, TDD, BDD, shift-left, shift-right, continuous testing, service virtualisation, model-based testing, exploratory testing and, more recently, AI-augmented testing all describe techniques, practices or organisational approaches that emerged in response to real engineering problems. The terminology can be useful, but it also creates a risk that the adoption of a named approach becomes confused with the quality of the outcome it is supposed to produce.

Beneath that vocabulary, the purpose of testing is relatively straightforward. Testing is the disciplined production of evidence that software behaves correctly against its requirements under relevant operating conditions, and that a change has not introduced unintended behaviour elsewhere in the system. Establishing this requires considerably more than demonstrating that a new function produces the expected result on a handful of normal inputs. It requires evidence across representative data, boundaries, exceptional conditions, failure paths, dependencies and the existing behaviour that may be affected by the change.

This distinction is important because a piece of software can satisfy the immediate requirement and still create a defect elsewhere. A new calculation may be correct while altering downstream reconciliation. An API may return the right result while handling retries incorrectly. A user interface may implement the requested workflow while producing unexpected state in another system. Testing therefore has two related responsibilities: to establish that the intended behaviour has been implemented correctly and to provide confidence that existing behaviour has not been damaged in the process.

The relevant question is consequently not whether a test suite is green or whether an organisation has reached a particular automation percentage. It is whether the evidence produced by the testing process is sufficient to support confidence in the software that will actually be operated.

Testing as a discipline

Formal software-testing disciplines developed because answering that question consistently is difficult. ISO/IEC/IEEE 29119 provides an internationally recognised family of standards covering software-testing concepts, processes, documentation and test-design techniques [1][2][3]. The standards are deliberately independent of a particular software-development lifecycle and therefore do not require an organisation to use Waterfall, Agile, DevOps or any other named delivery model.

That is useful because testing itself should not depend on the methodology currently in fashion. The standards describe a disciplined process in which testing is governed, planned, analysed, designed, implemented, executed, monitored and completed against defined criteria. They also formalise techniques for deriving tests rather than leaving test selection entirely to intuition or precedent.

The standards should not be treated as an answer in themselves. They provide a useful external reference against which testing practices can be examined. Many large organisations have developed substantial internal testing procedures over years or decades. These may include dedicated test teams, automated regression suites, integration environments, defect-management processes, performance testing, user acceptance activities and formal release gates. Such organisations may perform a great deal of testing without explicitly governing their processes against ISO/IEC/IEEE 29119.

That distinction is more significant than it first appears. A process can be highly structured while still containing weaknesses that have evolved unnoticed because the organisation measures itself against its own procedures rather than against an independent model. Automation may be excellent while environment fidelity is poor. Testers may work carefully against stories and expected outcomes while the available data does not represent production behaviour. Failure scenarios may be simulated while the wider architecture on which those failures depend is materially different from the live environment.

The problem is therefore not necessarily a lack of testing or even a lack of formality. It is that internally evolved procedures can create confidence in the process without necessarily establishing whether the process is producing sufficiently strong evidence.

AI provides a useful reason to revisit this. Before asking how existing testing activities can be automated, an organisation can first ask whether those activities are the right ones.

From methodology to evidence

Software engineering has a tendency to turn successful practices into organisational doctrine. A technique is found to work well in a particular context, training and tooling develop around it, and eventually the language of the technique can become a substitute for examining whether it continues to serve the intended purpose.

Testing has experienced this repeatedly.

Test-driven development is one example. TDD remains useful where a developer can describe the expected behaviour of a sufficiently bounded element before implementing it. It can improve local reasoning, encourage explicit contracts and provide rapid feedback during development. The difficulty begins when the technique is treated as a universal design principle rather than one available engineering practice.

Complex systems do not always present themselves as a series of small, fully understood behaviours waiting to be encoded. Requirements may be incomplete. The technical decomposition may not yet exist. Dependencies may shape behaviour in ways that cannot be known until implementation progresses. The most useful boundary for testing may emerge through design rather than precede it.

A strict response that every ambiguous behaviour should simply be decomposed further also has limits. Beyond a certain point, additional decomposition can increase indirection, multiply interfaces and spread a coherent business rule across so many small abstractions that the implementation becomes harder to understand. Testability is an important characteristic of good software, but it is not the only characteristic. Readability, cohesion, operational simplicity, performance and the ability of another engineer to reason about the system remain equally important.

The same caution applies to newer testing terminology. Shift-left, shift-right, continuous testing, testing pyramids and similar models all contain useful ideas, but none removes the need to understand the system being built. A mature testing function is not one that can demonstrate adherence to a particular vocabulary. It is one that can explain what evidence is required, how that evidence will be produced and why it is sufficient for the risks associated with the change.

AI makes that distinction increasingly important because it can apply a methodology with extraordinary consistency while still applying it poorly. If instructed to maximise coverage, it can generate enormous numbers of tests. If instructed to pursue isolated testability, it can continue decomposing code. If instructed to make a suite green, it can modify tests and implementation until they agree. None of those outcomes necessarily demonstrates that the software is correct.

The objective has to remain external to the method.

Testing begins with understanding

At the developer level, testing is closely connected to software construction. Unit tests rarely constitute independent evidence that a business requirement has been delivered. Their primary value is as engineering instruments that help a developer examine whether an implementation behaves according to the technical understanding used to create it, expose gaps in logic, exercise boundaries and protect behaviour as the code evolves.

This becomes particularly relevant when AI is introduced into development.

A well-written story can provide the initial statement of intent, but it will not normally define every internal class, method, parameter, state transition or technical contract that will emerge during implementation. Those are products of engineering design. Attempting to generate a complete set of low-level tests directly from the story therefore confuses business intent with implementation structure.

A more useful starting point is a structured interaction between the developer and AI in which the story is examined before implementation begins. The purpose of that discussion is not to force every test into existence before code is written, but to establish what is known, what remains ambiguous and what evidence will eventually be needed.

The discussion might explore the intended behaviour, dependencies, data types, valid ranges, failure conditions, state transitions and assumptions that have not yet been resolved. It can also help determine which behaviours are suitable for isolated testing and which depend on a larger component or interaction.

As the design becomes clearer, AI can then provide substantial practical value. Once a component contract and its data constraints are understood, AI can generate candidate cases across boundaries, invalid values, empty states, malformed inputs, unusual combinations and error paths far more quickly than a developer could construct them manually. This does not remove the need for engineering judgement; it shifts that judgement away from repetitive test construction and towards deciding whether the underlying contract and expected behaviour are correct.

Recent research into AI-generated testing demonstrates both the opportunity and the limitation. Large language models can generate significant numbers of candidate tests and can derive cases from natural-language requirements, code and other artefacts, but their effectiveness remains dependent on the quality and completeness of the available context [4]. AI can automate an incomplete assumption just as effectively as it can automate a correct one.

The useful role for AI at this level is therefore not simply to write more tests. It is to participate in the reasoning process through which meaningful tests become possible.

The test ecosystem is part of the architecture

Testing becomes progressively more demanding as software moves beyond an isolated component. Modern systems depend on databases, APIs, message brokers, identity platforms, external services, asynchronous processing, batch workloads and other components whose behaviour may vary according to state, timing, transaction volume and failure conditions.

For that reason, the test environment cannot be treated merely as infrastructure supplied after development has started. The architecture of the production system should always be considered alongside the architecture of the test ecosystem required to validate it.

In practice this is frequently neglected. A component is designed and built, and only later does someone ask for a UAT environment, staging environment or performance environment. What is then produced may simply be another instance of the component surrounded by simplified stubs. That may answer some questions, but it may be inadequate for establishing how the component will behave when connected to the systems, data and operating conditions it will encounter in production.

A large banking platform illustrates the difficulty. It would be impractical to reproduce every branch, ATM, payment participant and external interface physically. A credible test ecosystem does not need to duplicate production in every detail. It needs to reproduce the production behaviours, conditions and dependencies that are relevant to the change.

That may include a core banking platform with materially equivalent behaviour, realistic account and transaction states, representative volumes, controllable API and message responses, delays, retries, duplicate transactions, batch cycles and failure conditions. Simulators may represent branch systems, ATMs or third-party services, but the simulated interfaces must behave closely enough to production that the evidence produced remains meaningful.

The critical requirement is therefore not physical similarity but behavioural fidelity.

This should be determined during architecture and design. Every significant architectural decision creates corresponding test requirements. A new event stream creates requirements for message ordering, replay, duplication and failure handling. A stateful service creates requirements for representative state transitions. An external API creates requirements for both normal and abnormal responses. A high-volume component creates requirements for realistic workloads and meaningful performance observation.

If those requirements are considered only after development is complete, the organisation may discover that the software cannot be tested credibly using the infrastructure that exists. The architecture of the test ecosystem must therefore evolve with the architecture of the software itself.

AI can make this relationship easier to maintain. Given a sufficiently documented production architecture and test architecture, it can help identify the dependencies introduced by a proposed change, determine which are represented adequately in the available environments, distinguish between real and simulated behaviour, and highlight production characteristics that cannot currently be reproduced. This moves AI beyond test generation and into testability analysis.

Data fidelity and the limits of conventional environments

Environment fidelity is only one part of the problem. Test data can be equally important.

Organisations operating in sensitive environments have legitimate obligations to protect personal, financial and other confidential information. Production data may therefore be masked, tokenised, obfuscated or replaced with synthetic data before it enters a conventional test environment. These controls are necessary, but they can also alter the relationships and distributions that drive real system behaviour.

If a transformation changes the characteristics that determine how software responds, the resulting test may satisfy a privacy requirement while weakening the evidence that the test was intended to produce.

This becomes particularly significant when validating replacement processing engines or other high-risk changes. In such cases, one of the strongest approaches may be to run the candidate implementation in parallel with the incumbent system for an extended period. The same production events are processed by both implementations, but only the existing system remains authoritative. The candidate path produces a non-authoritative result that can be compared with the production result.

Over several weeks or months, this exposes the new implementation to the actual distribution of production activity, including unusual combinations of data and state that may never have been anticipated when conventional test cases were designed.

Event-streaming platforms such as Kafka make this practical in some architectures because production events can be consumed by an additional processing path without changing the authoritative transaction. Similar patterns can be implemented through mirrored traffic, temporary production code or other forms of shadow processing.

Organisations often describe this as a parallel run rather than testing. From an engineering perspective, however, its role is clearly part of the testing discipline because its purpose is to produce evidence about whether the candidate implementation behaves correctly.

This example exposes an important limitation in conventional testing terminology. Testing should not be defined by whether an activity occurs inside an environment called TEST, UAT or STAGING. In some situations, the strongest available evidence can only be obtained alongside production, provided that the candidate implementation is prevented from creating production consequences.

Testing therefore has to be defined by its purpose rather than by the label attached to the environment in which it is performed.

What AI changes

The examples above point to a broader change. AI should not be treated merely as another source of test automation. Its more significant effect is that activities which were previously too expensive to perform comprehensively — systematic test derivation, large-scale data variation, comparison of environments, maintenance of traceability and continuous examination of gaps in evidence — can increasingly become part of ordinary delivery.

This creates an opportunity to review the testing discipline itself rather than simply accelerate existing procedures. The starting question for an organisation is therefore not which testing tasks can be handed to AI, but whether its current testing process produces sufficient evidence that software behaves correctly against its requirements, under representative operating and failure conditions, without introducing unintended behaviour elsewhere.

AI can then be applied where it strengthens that evidence or materially reduces the effort required to obtain it. Existing processes that remain useful do not need to be discarded, but neither should they be preserved simply because they have become institutionalised. Recognised standards provide an external reference, established organisational practices provide experience, and AI provides new capability. The opportunity lies in combining those elements around the required outcome rather than creating another prescribed methodology.

There is already substantial research activity in AI-augmented software testing, while ISTQB now provides a specialist certification specifically concerned with applying generative AI across software-testing activities [5][6]. The significance of these developments is not that another testing doctrine has appeared, but that rigorous analysis, test derivation and evidence management can increasingly be performed at a scale that was previously too labour-intensive.

The objective remains unchanged. Software must behave correctly against its requirements, including under realistic abnormal and failure conditions, and changes must not create unforeseen behaviour elsewhere in the system. What has changed is the amount and breadth of evidence that can now be produced, analysed and maintained economically.

Testing is not Quality Assurance

One final distinction is important because the terms are frequently confused.

Testing and Quality Assurance are not interchangeable. Testing produces evidence about software behaviour. Quality Assurance is the broader oversight function that determines whether the evidence produced across the delivery is sufficient to justify confidence in the intended outcome.

That evidence may come from analysis, architecture, development, testing, risk assessment, security, compliance, operational readiness and other activities. Testing is therefore one contributor to assurance rather than another name for it.

The widespread organisational practice of referring to test teams as “QA” obscures that distinction. A team can execute tests extremely well and still not perform the broader assurance role.

AI may eventually make continuous, evidence-based assurance considerably easier because it can maintain visibility across the full delivery process. That is a larger subject in its own right. For the purposes of testing, however, the distinction is enough: testing establishes evidence about behaviour; assurance determines whether the total evidence is sufficient.

A reason to review testing now

The introduction of AI into software delivery creates an unusual opportunity. Organisations do not need to preserve every existing testing ritual merely because it has become institutionalised, nor should they abandon the discipline developed through decades of software engineering.

The useful task is to separate the purpose from the procedure. Recognised standards provide a reference point, existing organisational practice provides experience, modern techniques provide additional options, and AI reduces the cost of analysis, test derivation, execution and evidence management.

The resulting question for any organisation is therefore not whether it follows the latest testing methodology. It is whether its current testing approach can produce credible evidence that software behaves correctly against its requirements, across representative operating conditions and failures, without introducing unexpected behaviour elsewhere.

If the answer cannot be demonstrated convincingly, increasing the amount of automation will not solve the underlying problem. AI gives organisations the opportunity to improve the testing discipline itself before accelerating it.

References

[1] ISO (2022), ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General concepts, International Organization for Standardization.

https://www.iso.org/standard/81291.html

[2] ISO (2021), ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processes, International Organization for Standardization.

https://www.iso.org/standard/79428.html

[3] ISO (2021), ISO/IEC/IEEE 29119-4:2021 — Software and systems engineering — Software testing — Part 4: Test techniques, International Organization for Standardization.

https://www.iso.org/standard/79430.html

[4] Folorunsho, O. and Reza, H. (2026), AI-Driven Test Case Generation from Natural Language Requirements: A Survey of Techniques and Research Gaps, arXiv.

https://arxiv.org/abs/2606.06563

[5] A Taxonomy for AI-Augmented Software Testing (2025), arXiv.

https://arxiv.org/abs/2506.14640

[6] ISTQB (2026), Certified Tester — Testing with Generative AI (CT-GenAI), International Software Testing Qualifications Board

https://istqb.org/certifications/gen-ai/

Most discussions of AI and organisational structure begin from the assumption that the existing organisation is broadly effective. AI is then introduced as an external force that will flatten hierarchies, alter spans of control, redistribute decisions and create new combinations of human and machine labour.

That assumption deserves closer examination in software delivery.

Many contemporary IT organisations were already fragmented before generative AI arrived. Over several decades they accumulated specialist functions, outsourced capability, delivery frameworks, coordination roles, workflow platforms and recurring ceremonies. Much of this structure arose in response to genuine problems, including technical complexity, organisational scale, supplier dependence, weak visibility and slow delivery. The difficulty is that the accumulated model has rarely been examined as a whole. Organisations have added layers more readily than they have tested whether those layers improved end-to-end delivery.

AI changes the conditions under which this structure operates. Analysis, coding, testing, documentation and investigation can now be accelerated, particularly when experienced people work with capable agents. As execution becomes faster, delays caused by ambiguous requirements, repeated hand-offs, duplicated documentation and procedural supervision become more visible. AI is revealing weaknesses that were already present rather than creating the need for organisational change from nothing.

The same technology also places greater demands on the organisation. Reliable AI-assisted delivery depends on clear scope, authoritative context, explicit boundaries, defined permissions, strong assurance and named accountability. The future human operating model cannot be designed by taking the current organisation chart and removing whichever jobs appear automatable. It requires a more fundamental examination of how IT departments evolved, why their present structures exist and which parts continue to contribute useful work.

From the computer department to corporate IT

Corporate IT did not begin with product owners, delivery leads, Scrum Masters, Agile coaches, squads, tribes or release trains.

Early computer departments were shaped by the technology and by the work required to use it. Mainframe computing was centralised, expensive and comparatively scarce. Organisations therefore concentrated technical knowledge within internal departments containing systems analysts, analyst programmers, programmers, chief programmers, systems programmers, database specialists, computer operators and project managers.

The names varied, but the responsibilities were usually recognisable. Analysts worked with users to understand administrative and business processes. Analyst programmers carried much of that understanding into system design and implementation. Programmers developed and maintained applications. Chief programmers and other senior technical staff provided design direction, reviewed work and carried responsibility for the integrity of the system. Operations staff controlled production environments, scheduled workloads and dealt with failures. Project managers coordinated substantial programmes of change and were expected to understand the deliverables, dependencies, resources, costs and risks involved.

Architectural work certainly existed, although it was often embedded within experienced technical roles rather than separated into a distinct profession. Analysis, design and programming remained relatively close because the organisation contained fewer boundaries through which the work had to pass.

These departments were not idealised communities of technical excellence. They could be hierarchical, insular and slow to respond. Users sometimes waited months or years for changes. Documentation could be excessive, and technical specialists could exercise substantial power over business departments that had few alternatives. Projects still failed, exceeded budgets or delivered systems that did not meet their intended purpose.

Even so, the organisation was largely shaped around the actual work of computing. Its roles had developed around analysis, programming, operations and project delivery rather than around a methodology imposed across the department.

Professionalisation and formal methods

As computing spread through government and industry, organisations sought to make systems development and IT management more systematic.

Britain played an influential role in that professionalisation. The National Computing Centre was established by the UK government in the 1960s to encourage the effective use of computers, develop skills and promote professional practice. During the following decades, it provided training, publications and consultancy to public and private organisations, including local authorities. Its role was not to invent the software development lifecycle, but to help turn emerging systems-development knowledge into repeatable organisational practice.[1]

UK public institutions also helped codify methods that later travelled internationally. Structured systems analysis and design approaches influenced how requirements and systems were examined. PRINCE emerged from UK government practice as a method for controlled IT project delivery before PRINCE2 broadened its application.[2] ITIL was developed during the 1980s by the UK government’s Central Computer and Telecommunications Agency, which documented and distributed a body of recommended practices for IT service management.[3]

These methods addressed related but distinct concerns. Systems-development lifecycles described the progression through analysis, design, construction, testing, implementation and maintenance. Project-management methods dealt with scope, deliverables, phases, resources, milestones, risks, budgets, governance and accountability. Service-management practices dealt with the operation, support and continuing improvement of live IT services.

The distinction mattered because developing a system, delivering a project and operating a service were not the same activity.

A credible project plan was also more substantial than the Gantt chart with which it is now often associated. It was a written body of analysis and agreement covering purpose, scope, deliverables, assumptions, phases, activities, milestones, dependencies, resources, costs, risks, responsibilities, governance and completion criteria. Schedules, resource charts and critical-path diagrams represented aspects of that plan, usually as supporting material. They did not constitute the plan by themselves.

Formal methods could become rigid and bureaucratic, particularly when organisations treated documentation as an end in itself or attempted to fix every technical decision too early. Their underlying purpose was nevertheless rational. They made the intended undertaking explicit, established who was responsible and exposed whether the proposed sequence, resources and commitments were credible.

Technology decentralises

The move from mainframes to minicomputers began to change the shape of IT departments. Computing no longer had to remain entirely within one central facility. Business units and regional offices could operate departmental systems, gaining greater control over their own applications and priorities.

Personal computers accelerated that decentralisation. Users could perform work without sending every request through a central computing function. Departments acquired applications independently, and local spreadsheets and databases proliferated. Some of this was empowering because it placed useful capability directly in the hands of users. It also created duplication, inconsistent information and systems that central IT neither understood nor controlled.

Client-server computing introduced another structural shift. Applications were distributed across desktop clients, application servers, databases and networks. New technical specialties and teams developed around each layer. Database administrators, network engineers, server teams, desktop support, middleware specialists and application developers increasingly operated across separate organisational boundaries.

This specialisation created genuine expertise, but it also increased dependency. A change to one business service could require agreement among application, database, infrastructure, network, security and operations groups. More people became involved in delivery, while fewer retained an end-to-end understanding of the system.

The modern coordination problem therefore did not begin with Agile. It grew partly from the increasing distribution of technology and ownership. As systems crossed more technical and organisational boundaries, organisations added coordination to manage the resulting fragmentation.

Packaged software, suppliers and outsourced capability

Packaged business software altered the balance again.

Organisations increasingly purchased enterprise resource planning systems, customer platforms, banking products, insurance applications and other large commercial packages rather than developing every capability internally. IT work moved towards configuration, integration, data conversion, vendor management and local customisation.

Consultancies and suppliers gained influence because they understood the products and controlled much of the implementation expertise. Outsourcing and offshoring extended this development. External delivery could provide scale, specialist capability and access to labour markets unavailable internally, but it could also transfer system knowledge, technical authority and institutional memory outside the organisation.

Permanent employees increasingly managed contracts, suppliers, governance, reporting and escalation while consultants performed much of the analysis, design and implementation. When suppliers changed, practical knowledge often left with them. New providers then had to rediscover the systems, creating further demand for documentation, transition programmes and management oversight.

Organisations responded by adding coordination. They introduced more supplier governance, more delivery oversight, more status reporting and more intermediaries between the business and the people performing the technical work. This did not necessarily restore ownership. It often institutionalised its absence.

By the time Agile entered many large organisations, their delivery environments were already fragmented across technical disciplines, suppliers, commercial products and governance boundaries.

Agile as an engineering correction

Agile emerged against a genuine background of frustration.

Software practitioners had experienced projects burdened by excessive documentation, delayed feedback, rigid technical prescription and plans treated as immutable even after their assumptions had failed. The Manifesto for Agile Software Development, written in 2001 by seventeen software practitioners, described a search for better ways of developing software. Its values emphasised individuals and interactions, working software, customer collaboration and responsiveness to change, while explicitly recognising value in processes, documentation, contracts and plans.[4]

The manifesto was not an argument against planning, nor was it a general theory of corporate management. It did not propose a universal organisational structure.

Its important contribution was to restore the role of evidence and professional judgement in software development. Capable technical teams should work closely with customers, deliver working results earlier and adjust their approach when reality contradicted the assumptions on which a plan had been based.

This was compatible with serious project management. A project could retain a defined purpose, scope, deliverables, milestones, dependencies, resources, costs and risks while allowing the engineering team to decide how best to achieve them. Project leadership remained responsible for the wider undertaking and its commitments. Engineers remained responsible for the technical method.

That division of responsibility required trust. It assumed that experienced people closest to the work were best placed to organise their execution within the agreed outcome and constraints.

From engineering principle to enterprise identity

The word Agile gradually escaped this original scope.

Executives began describing entire businesses as Agile in much the same way that they described them as innovative, transformative or disruptive. These words became desirable corporate identities. They implied speed, modernity and responsiveness, although they often said little about how authority, incentives, architecture or delivery actually worked.

A company could adopt the language of agility while remaining hierarchical and slow. It could reorganise teams, rename departments and introduce ceremonies without altering the dependencies, funding structures or decision rights that constrained delivery.

The difference between agility as a capability and Agile as an enterprise framework became blurred. The first concerns the ability to respond intelligently to evidence and changing conditions. The second became an installable operating model containing prescribed roles, terminology, ceremonies, reporting structures, planning intervals, maturity assessments and transformation programmes.

This expansion created a professional Agile industry. Consultancies could sell transformations, training organisations could certify practitioners, software vendors could encode the framework into tools, and human-resources departments could establish new career structures around it.

There was no need for every participant to act cynically. The incentives were embedded in the model. A principle such as employing experienced people, giving them a clear outcome and allowing them to organise the work is difficult to package. A framework containing roles, courses, assessments, workshops, implementation roadmaps and supporting products is easier to sell and easier for executives to mandate.

As the framework became more elaborate, organisations needed more specialists to install, administer and interpret it. Each addition could be defended individually, while the cumulative structure received far less scrutiny.

From accountabilities to organisational machinery

Scrum originally described a small team with a limited set of accountabilities. The current Scrum Guide refers to Developers, the Product Owner and the Scrum Master as accountabilities within the Scrum Team rather than as an enterprise hierarchy.[5]

Corporate implementations eventually contained a much broader collection of titles, including iteration managers, delivery leads, Agile delivery managers, product managers, Agile coaches, chapter leads, tribe leads, release train engineers, value-stream managers, portfolio leads and transformation specialists.

Some people holding these titles perform essential work. A delivery manager who controls budgets, negotiates resources, manages suppliers, resolves external dependencies and remains answerable for milestones is performing substantive project management regardless of the title attached to the role.

The concern arises when positions exist mainly to administer teams that are described as self-managing. Frameworks introduced roles to control ceremonies, backlogs, estimates, planning intervals, workflow states, dependencies and reporting. The engineering team retained responsibility for the technical result while procedural authority increasingly sat with people surrounding it.

This created a contradiction. Teams were expected to be autonomous, yet their work was structured, estimated, scheduled and monitored through an external procedural apparatus. The organisation could describe this as self-management while supervising many of the decisions through which self-management would normally be exercised.

The proliferation of responsibility also weakened accountability. Product vision might belong to one person, delivery to another, process to another, architecture to another, testing to another, release to another and operations to yet another. Each role appeared accountable for part of the process, but responsibility for the complete outcome became increasingly difficult to locate.

More accountable titles did not necessarily produce greater accountability. In some organisations, they divided ownership so widely that nobody remained answerable for the undertaking as a whole.

Teams designed around the methodology

Enterprise frameworks also began influencing organisational design.

Instead of beginning with the business outcome, system boundaries, operational responsibility, technical risk and expertise required, many organisations started with a methodology template. They established squads, tribes and chapters, assigned product and delivery roles, introduced fixed sprint intervals, required recurring ceremonies and represented work through epics, stories, tasks, points and workflow states.

The structure often implied autonomy even where the technical and organisational conditions made autonomy impossible. A squad might still depend on central architecture, shared databases, infrastructure teams, security gates, funding committees, external suppliers and executive approvals for routine delivery.

Changing the name of the team did not remove those dependencies. It changed the language used to describe them.

The framework had therefore reversed the natural relationship between work and method. Teams should be organised around the outcome, systems and expertise involved, with methods selected according to the needs of the work. Instead, the work was increasingly adapted to fit a standard organisational and procedural template.

The bureaucratic pipeline

The resulting delivery model can appear highly efficient when viewed through dashboards and workflow reports.

A request enters through business representatives or product functions. Analysts translate it into epics and stories. Product owners prioritise the backlog. Delivery roles prepare and monitor the work. Engineering teams estimate and implement it. Testing functions validate it. Release teams promote it, and operations receives the result.

Every activity has an owner, every ticket has a status and every team has a board. The movement is visible, but visibility does not establish delivery effectiveness.

The requirement may be scattered across a workshop board, several Confluence pages, an epic, multiple stories, acceptance criteria, ticket comments and informal conversations. No single document may explain the complete deliverable, assumptions, dependencies, milestones, resources, costs and risks. The organisation can observe work moving through its process while remaining unable to describe the undertaking coherently.

Epics, stories, backlogs, sprints, Miro boards and Confluence pages can all be useful within their proper scope. The problem begins when they are expected to perform the work of requirements analysis, project planning, dependency management and governance.

A backlog can organise prospective work, but it does not by itself establish a delivery strategy. A sprint can help a team organise near-term execution, but it does not provide an end-to-end project schedule. A workshop can help people explore a problem, but it is not an agreed plan. A page is not authoritative simply because it has been published.

The pipeline can therefore maintain an impressive volume of activity while leaving the underlying intent fragmented.

When the sprint became the planning horizon

Sprints were intended as short periods within which a team could pursue a goal, produce an increment and learn from the result. In many organisations they gradually became the dominant planning horizon.

The next fortnight was described in considerable detail. The following year was represented by broad roadmaps, loosely defined epics and aspirational dates. This did not necessarily reflect adaptability. It often indicated that project-level planning had weakened.

A sequential list of requirements, a set of milestones, resource estimates, dependencies and a critical path do not make a project waterfall. They are basic disciplines needed for any substantial undertaking.

The sprint should sit beneath the project plan. The engineering team should examine the agreed requirements and milestones, assess what can reasonably be achieved during the next cycle and decide how to organise the technical work.

In many organisations, this relationship was reversed. The wider plan was expected to emerge from the accumulated content of successive sprints. That approach could provide regular activity without offering a credible account of how the complete outcome would be delivered.

Large-scale planning and coordination by crowd

Large planning events demonstrate the consequences of this inversion.

Hundreds of people may be assembled to align teams, identify dependencies and negotiate short-term commitments. These events can reveal conflicts and provide temporary synchronisation, particularly in complex organisations. Their existence does not, however, mean that they provide a substitute for project planning.

A credible project plan does not require every person who may eventually touch the work to be present in the same room. It requires people who understand the intended deliverable to establish phases, milestones, dependencies, sequencing, resources, assumptions, costs and risks through informed negotiation with the experienced professionals capable of assessing them.

Teams can then organise their own work against those targets.

Large planning ceremonies often attempt to construct the macro plan by aggregating team-level intentions. Dependencies become items on boards, and capacity is negotiated before technical analysis has fully established the work. Many participants spend substantial time listening to discussions unrelated to their contribution. The event may expose complexity, but exposure does not resolve the architecture, ownership or organisational boundaries that created it.

Independent studies of large-scale Agile development repeatedly identify cross-team coordination, technical dependencies, requirements, integration, testing and knowledge sharing as persistent challenges.[6][7][8] The available research does not demonstrate that adopting a scaling framework causes these problems to disappear. Instead, it documents the additional coordination practices introduced to manage them.

The UK National Audit Office reaches a related conclusion from a governance perspective. Its guidance on Agile in large-scale digital change warns that iterative methods do not remove the need for boards and senior leaders to understand intended outcomes, dependencies, funding, skills, assurance, risk and accountability. Agile can change how delivery work is organised, but it does not remove the obligations involved in governing a substantial undertaking.[9]

That evidence supports a more demanding question. Organisations should examine whether a framework solves the structural problem or mainly provides a disciplined way of administering it. If supposedly autonomous teams require repeated mass coordination, the architecture, ownership boundaries and distribution of decision rights deserve as much attention as the ceremony used to align them.

The human cost of procedural management

The accumulated operating model places a particular burden on experienced engineers.

Senior engineers often carry much of the practical technical risk because they understand the systems, data, architecture, dependencies, operational history and likely failure modes. They are the people most likely to recognise that a requirement is incomplete or that an apparently isolated change has broader consequences.

At the same time, they may spend substantial amounts of time servicing people who manage the representation of the work rather than its technical substance. They attend recurring ceremonies, translate technical activity into framework-compliant stories, defend estimates expressed through points, repeat the same explanations across several layers and respond to people who possess procedural authority without carrying responsibility for the technical result.

This can produce a form of professional infantilisation. Engineers are described as members of self-managing teams while other roles supervise their backlog, estimates, workflow, planning intervals and commitments. Their expertise becomes decisive when a system fails, but their autonomy is constrained during the work that leads to the outcome.

The resulting frustration is often characterised as resistance to process. That interpretation is too convenient. Experienced engineers are generally familiar with the need for requirements, planning, security, testing, review, operational controls and accountability. Their objection is more often directed at process that consumes expert attention without improving intent, reducing risk or strengthening evidence.

The relevant measure is therefore not whether a ceremony was performed or a status updated. It is whether the activity improved the outcome enough to justify the professional time it consumed.

Why the model persists

The modern framework satisfies several organisational interests.

Executives receive visible evidence that transformation is taking place. Managers receive dashboards and reporting structures. Consultancies receive substantial programmes of work. Training organisations receive certification markets. Tool vendors gain workflows that embed their products deeply within delivery. Newly established professional roles gain career paths and institutional legitimacy.

These interests do not prove that the framework lacks value. They do make objective examination more difficult.

Failure does not necessarily discredit the method. It can be attributed to incomplete adoption, insufficient organisational maturity, resistant culture, weak leadership or a lack of further coaching. Critics may be described as outdated or as people who do not understand Agile properly.

A methodology becomes difficult to evaluate when success confirms the framework while failure is attributed to the people or organisation implementing it.

A mature professional discipline should impose the same test on every role, ceremony, artefact and governance layer, whether traditional or Agile. What delivery problem does it solve? Is the problem reduced or merely reported more consistently? Could the same outcome be achieved through a simpler arrangement with clearer ownership?

The time and money consumed by the process should be justified by evidence of value. Engineers should not carry the burden of proving that every imposed practice is unnecessary.

AI reveals the original Agile proposition

AI changes this debate in an unexpected way.

The original Agile proposition placed considerable faith in small, capable, self-managing teams. Such teams were expected to organise themselves around the work, collaborate directly, respond to evidence and deliver without unnecessary procedural interference.

AI makes that model more achievable.

A small group of experienced people supported by capable agents can investigate repositories, analyse systems, propose implementation approaches, write code, generate tests, examine failures and prepare documentation with a level of capacity that previously required a much larger human team.

AI is not independently accountable and should not own consequential organisational decisions. It can, however, provide much of the analytical and execution capacity needed for a small human group to operate as a genuinely capable delivery unit.

This places enterprise Agile in an uncomfortable position. The technology may allow organisations to move closer to Agile’s original logic while making the administrative structure accumulated in Agile’s name increasingly difficult to justify.

A small expert team using agents may need less allocation, less translation and less procedural supervision. It will still need clear outcomes, appropriate project planning, strong analysis, technical authority, assurance, security and accountability. Those disciplines support the work directly rather than supervising the team’s internal organisation.

AI exposes rather than creates the dysfunction

Commentary about AI and organisational structure often presents the technology as the reason companies must reconsider hierarchy, management and team design. In software delivery, many of the relevant deficiencies were already present.

AI makes them more visible because it changes execution speed and concentration of capability.

A two-week cycle appears less natural when a bounded change can be analysed, implemented and tested within hours. Repeated refinement becomes harder to defend when its real purpose is compensating for an unresolved requirement. Chains of intermediaries look less necessary when experienced people and agents can work directly from agreed intent. Large status meetings provide less value when reliable evidence can be obtained from the delivery environment.

The bureaucracy existed before AI. Faster execution makes it easier to see where elapsed time is really being consumed.

This is why simply inserting AI into the existing pipeline is unlikely to produce the full benefit. Organisations may generate stories faster, summarise more meetings, populate more fields and create new roles to supervise agent activity. That would automate the administrative model without correcting its underlying weaknesses.

The more significant opportunity is to use AI as a reason to reassess the model itself.

AI forces organisational clarity

Reliable AI-assisted delivery places greater pressure on the quality of work before execution begins.

Human engineers can sometimes compensate for incomplete requirements through conversation, experience and institutional knowledge. An agent may instead produce a coherent implementation of one plausible interpretation. The result can be technically polished while remaining fundamentally wrong.

As execution accelerates, ambiguity becomes more consequential.

Analysts must therefore produce clearer requirements and identify contradictions rather than simply converting conversations into stories. Committees and decision-making bodies must resolve disagreements over scope instead of allowing competing interpretations to travel into delivery. Architects and engineers must define system boundaries, dependencies and constraints. Reviewers must assess whether the result satisfies the intended outcome and risk rather than merely confirming that the prescribed workflow was followed.

Reliable delivery requires an agreed objective, current and authoritative context, explicit constraints, known dependencies, defined permissions and measurable evidence of completion. These are demanding organisational disciplines, but they are substantially different from ceremonial compliance.

AI does not diminish the need for governance. It exposes where governance has been reduced to process observation rather than decision quality.

Control after ceremony

Criticism of the current model should not be confused with an argument for uncontrolled automation.

AI introduces significant new risks. Agents can modify large areas quickly, act on faulty assumptions, expose sensitive information, generate misleading assurance and produce changes whose consequences are not immediately visible. The future operating model therefore needs stronger controls around quality assurance, independent verification, identity, permissions, security, privacy, provenance, auditability, supplier risk and release authority.

These controls should be connected to the work and proportionate to its consequences.

A story point does not provide assurance. Attendance at a stand-up does not establish governance. A ticket moving to a completed state does not demonstrate that the intended outcome was achieved.

More meaningful control comes from agreed scope, trusted requirements, bounded authority, independent evidence and named human responsibility. The purpose is not to remove discipline, but to direct it towards the aspects of delivery that influence quality, safety and accountability.

A new human operating model

A replacement for the current structure cannot consist only of removing roles and ceremonies. It must describe how software delivery should be organised when experienced people and agents can perform more work with fewer hand-offs.

Organise around outcomes and systems

Teams should be aligned with coherent business outcomes, products, services or system boundaries. Their design should reflect the expertise required, the operational responsibilities involved, the dependencies that cannot be removed and the risks associated with the work.

A team should not be described as autonomous if it lacks authority over its system or remains dependent on several unrelated functions for routine delivery. Where dependencies are unavoidable, they should be acknowledged explicitly rather than concealed behind team labels.

Restore project-level planning

Substantial undertakings still require an authoritative project plan. It should describe the purpose, scope, deliverables, phases, milestones, assumptions, dependencies, resources, budget, risks, governance arrangements and evidence of completion. Current UK government project-delivery guidance similarly retains the need for defined outcomes, planning, assurance, resources, governance and control across projects and programmes.[10]

The plan should evolve when evidence changes the project’s assumptions. Its existence does not impose a rigid technical method on the engineering team. It provides the wider context and commitments against which the team organises its work.

A backlog can support execution, but it should not replace this level of planning.

Separate requirements from technical work definition

Business and project analysis should establish what the organisation intends to achieve, including the relevant rules, constraints, dependencies and evidence of success.

The engineering team should determine how those requirements are decomposed into technical work. It may use stories, tasks, specifications or another internal method according to the nature of the system and the work involved.

AI can assist engineers by analysing systems, identifying possible dependencies and proposing implementation plans. The engineering team remains responsible for deciding whether those proposals are technically and operationally sound.

Use small expert delivery units

AI increases the capability of small teams, but it does not remove the need for expertise.

An effective delivery unit requires access to business knowledge, analysis, engineering, operational understanding, assurance and security. These are responsibilities rather than a mandatory set of permanent titles. A small team may combine several of them, while a large regulated programme may require dedicated specialists.

The structure should follow the work rather than reproduce every role created by a framework.

Give agents bounded authority

Agents should operate through controlled identities, permissions, tools and environments. The organisation must define what each agent may inspect, propose, modify, test, deploy or approve.

Authority should reflect the sensitivity and consequences of the work. An agent may be allowed to prepare a low-risk code change and run automated tests while remaining unable to access production data or execute a production deployment.

These boundaries should be built into the delivery environment rather than relying on informal instructions.

Maintain continuous evidence

Requirements, design decisions, implementation changes, tests, reviews, security checks, approvals, deployments and production outcomes should remain connected.

Evidence should accumulate throughout delivery, allowing reviewers to trace the relationship between the original intent and the result. This becomes particularly important when several agents and tools contribute to the same change.

Apply human attention according to risk

Human intervention should be concentrated where ambiguity, novelty, consequence or irreversibility requires judgement.

Routine and reversible changes may proceed with limited intervention where automated evidence is strong. Changes affecting payments, safety, privacy, regulatory reporting or critical infrastructure require deeper and more independent review.

The purpose of human involvement is to protect the outcome, not to preserve an inherited approval ceremony.

Restore clear accountability

Each significant outcome needs named human ownership.

Different people may be responsible for the requirement, technical decision, assurance decision and release authority, particularly in large or regulated environments. Those responsibilities should be explicit and connected. The participation of several specialists and agents should not allow accountability to dissolve across the process.

Human work that becomes more valuable

AI increases the value of people who can understand business outcomes, resolve ambiguity, negotiate scope, reason about systems, identify dependencies, make technical judgements, assess risk, evaluate evidence and accept responsibility.

Analysts should spend more time performing analysis and less time populating backlogs. Project leaders should manage deliverables, milestones, dependencies, resources, budgets and risks rather than supervise the engineering team’s internal task sequence. Engineers should retain control of technical decomposition. Security, assurance and governance specialists should help define controls throughout delivery rather than operate only as final gates. Operational expertise should ensure that production evidence influences future requirements, tests and decisions.

The common feature of these responsibilities is judgement. AI can assist with the work, expose relevant information and accelerate execution, but the organisation still needs people capable of determining what the evidence means and which consequences are acceptable.

Work that deserves reassessment

Activities designed mainly to allocate, supervise and report slow human execution should no longer carry a presumption of necessity.

Mandatory story templates, arbitrary points, velocity targets, repeated status ceremonies, mass planning events, duplicated documentation, externally imposed sprint boundaries and technical decomposition by non-technical intermediaries should be retained only where they solve a demonstrated problem.

The same applies to roles whose principal function is moving information between other roles or maintaining the workflow through which work is represented. Some organisations may find genuine value in particular practices, especially where teams are inexperienced, dependencies are substantial or coordination is unavoidable. The appropriate test is contribution to the outcome rather than conformity to a methodology.

This is not a demand for universal abolition. It is a demand for objective assessment.

The leadership challenge

Executives should resist treating AI as the next corporate identity.

Declaring an organisation AI-first will not create the clarity, expertise or accountability required for reliable delivery. Buying agent platforms and appointing new coordinators may simply add another layer to the existing structure.

Leadership must be prepared to examine why current roles and ceremonies exist, which responsibilities have become fragmented and whether the organisation retains enough internal technical knowledge to judge the work it commissions.

The relevant questions are practical. What is being delivered? Who understands the system? Where is the authoritative requirement? Which dependencies constrain the outcome? What resources are needed? Who can make the technical decision? What evidence demonstrates that the result is correct? Who remains accountable when it is not?

An organisation able to answer those questions is better prepared for AI than one with an elaborate transformation programme but weak ownership of its systems and outcomes.

Conclusion

The human operating model for software delivery has evolved through several technological and organisational eras.

Centralised computer departments concentrated technical knowledge and authority. Formal methods professionalised systems development, project delivery and service management. Minicomputers, personal computers and client-server systems distributed computing and created new specialisations. Packaged software, outsourcing and consultancy dependence fragmented ownership and moved practical knowledge beyond organisational boundaries.

Agile emerged as a legitimate engineering correction to rigid processes, delayed feedback and excessive distance between technical decisions and the people doing the work. Its original logic placed trust in small, capable teams that could organise themselves around a clear outcome.

Enterprise Agile expanded far beyond that purpose. Frameworks began shaping organisational structures, roles multiplied around supposedly self-managing teams, and procedural authority became separated from technical responsibility. Epics, stories, sprints, boards and ceremonies were increasingly used to provide the appearance of planning and control, even where end-to-end ownership remained weak.

AI now makes the consequences of that evolution harder to ignore. It increases the capacity of small groups of experienced people, reduces the need for some of the machinery created to allocate and monitor human execution, and exposes where delay is caused by ambiguity, hand-offs and procedural supervision.

At the same time, AI demands greater precision. Scope must be agreed, requirements must be clearer, context must be authoritative, boundaries must be explicit and evidence must be stronger. Quality assurance, security, governance and accountability become more important because incorrect work can be produced and propagated much faster.

The emerging human operating model should therefore be organised around outcomes and coherent systems, supported by credible project planning, strong analysis, engineering-led decomposition, bounded agent authority, continuous evidence and risk-based human intervention. It should retain roles and practices that contribute materially to delivery while removing the presumption that every element of the existing framework is necessary.

AI is not requiring a previously effective IT organisation to abandon a successful model. It is revealing that much of the current model was already poorly aligned with the work and sustained partly by the conditions of slow, distributed human execution.

The opportunity is to move closer to the original Agile proposition: small groups of capable people trusted to organise around a clear outcome, now supported by machines that multiply their analytical and execution capacity. Realising that opportunity will require organisations to simplify the structures surrounding engineering while strengthening the disciplines that protect the outcome.

Whether they do so will depend less on the capability of the agents than on the willingness of leaders to distinguish useful control from inherited ceremony.

References

[1] UK Parliament (1965), ‘National Computing Centre’, House of Commons debate, 7 December.

https://hansard.parliament.uk/commons/1965-12-07/debates/f3efe022-11bd-4f42-814a-2c8ad8312b32/NationalComputingCentre

[2] PRINCE2 (n.d.), ‘Management Overview: PRINCE2’.

https://www.prince2.org.uk/management-overview/

[3] IBM (n.d.), ‘What Is IT Infrastructure Library (ITIL)?’

https://www.ibm.com/think/topics/it-infrastructure-library

[4] Beck, K. et al. (2001), ‘Manifesto for Agile Software Development’.

https://agilemanifesto.org/

[5] Schwaber, K. and Sutherland, J. (2020), ‘The Scrum Guide’.

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

[6] Uludağ, Ö. et al. (2022), ‘Revealing the State of the Art of Large-Scale Agile Development Research: A Systematic Mapping Study’, Information and Software Technology.

https://arxiv.org/abs/2007.05578

[7] Biesialska, K. et al. (2021), ‘Mining Dependencies in Large-Scale Agile Software Development’.

https://www.essi.upc.edu/~biesialska/Biesialska_2021-Mining_Dependencies_in_Large-Scale_ASD.pdf

[8] Dingsøyr, T., Moe, N.B. and Seim, E.A. (2018), ‘Coordinating Knowledge Work in Multi-Team Programs: Findings from a Large-Scale Agile Development Program’.

https://arxiv.org/abs/1801.08764

[9] National Audit Office (2022), ‘Use of Agile in Large-Scale Digital Change Programmes’.

https://www.nao.org.uk/insights/use-of-agile-in-large-scale-digital-change-programmes/

[10] UK Government (2025), ‘Government Functional Standard GovS 002: Project Delivery’.

https://www.gov.uk/government/publications/project-delivery-functional-standard

Part 2 of this series examined the state of AI software development in July 2026. It considered interactive assistants, repository-scale agents, asynchronous execution, multi-agent systems, orchestration and the point at which an emerging capability becomes reliable enough to influence an enterprise operating model.

This article begins from that foundation and asks how the parts fit together.

Software delivery begins before code is written and continues after it enters production. A business need has to be understood, its feasibility assessed, requirements established, dependencies identified, architecture considered, resources committed, work organised, changes implemented, evidence produced, releases controlled and operational results fed back into later decisions.

These activities are not inventions of modern software development. Any substantial human undertaking has required some version of scope, feasibility, resources, sequencing, deliverables, milestones, control and verification, whether raising a pyramid in ancient Egypt or replacing a core banking system today. The terminology changes, and the methods used within each activity may change considerably, but the underlying disciplines remain.

Something became muddled in software delivery over the past twenty years. Flexibility in how engineers perform technical work was increasingly confused with an absence of end-to-end planning. Requirements were reduced to stories, project progress was reduced to sprint movement, and the team’s internal method of organising its work became entangled with management control of the project.

AI exposes that confusion.

An agent may complete a well-defined technical task much faster than a human team could have completed it previously. It gains no benefit from story points, ceremonies or the administrative weight attached to a sprint. It requires accurate intent, relevant context, explicit constraints, suitable tools and clear evidence of completion. When those are missing, greater execution speed does not improve delivery. It increases the speed at which a plausible misunderstanding can become implemented software.

The AI delivery platform landscape should therefore not be judged only by the number of agents a vendor provides or the number of lifecycle activities into which it has inserted AI. It should be judged by the delivery model underneath the product. Which parts remain fit for purpose? Which parts are inherited assumptions? What does AI change? Where can the lifecycle be improved rather than merely automated?

The platform is larger than the agent

An AI delivery platform is not simply a coding agent, an editor, a work-management product or a pipeline with AI features added to it.

It includes the environment through which work is defined, the information humans and agents can access, the authority under which they act, the tools they may invoke, the evidence they produce, and the controls used to decide whether a result can proceed. It must also connect production behaviour back to the requirements, decisions, implementation and release evidence that produced it.

A coding agent may inspect a repository, propose a plan, edit several files, run commands, generate tests and prepare a pull request. None of those capabilities establishes that the change should have been made, that the requirement was accurate, that the available context was complete or that the tests prove the intended outcome.

The platform is the wider delivery system surrounding that execution.

This becomes more important when several agents participate. One may analyse a requirement, another may modify the code, another may produce tests, another may review the result, and another may control deployment or respond to a production incident. The organisation needs to know more than what each agent did in isolation. It needs to understand how their combined work remained connected to the original purpose of the change.

That requires continuity of intent, context, authority and evidence across the full lifecycle.

A reference model for software delivery

A useful assessment should begin with the functions required to deliver software rather than with the products currently available.

The lifecycle can be represented as:

Business purpose and project planning → feasibility and analysis → requirements and architecture → engineering work definition → human and agent execution → testing and assurance → release and deployment → production operations → feedback and learning

Several concerns extend across the entire sequence:

Context, identity, authority, permissions, policy, security, evidence, audit, cost, human judgement and accountability.

This is not an argument for a rigid sequence in which every decision is fixed before work begins. It is a statement of the activities that must be addressed.

Some may occur concurrently. Some may be revisited repeatedly. A prototype may deliberately use execution to test feasibility or discover what the requirement should become. A well-understood migration may allow large volumes of similar work to proceed through a repeatable method. An operational incident may require rapid analysis and remediation before the wider project plan is updated.

The method should reflect the nature of the work.

What should not happen is for an organisation to abandon necessary analysis and then claim that discovering the requirement during implementation is inherently Agile. Iteration is valuable when uncertainty is genuine and learning is the objective. It is not a substitute for understanding a deliverable that could have been analysed before execution began.

The reference model also separates two kinds of continuity.

Workflow continuity exists when one activity can trigger another. A work item can be assigned to an agent, the agent can create a branch, a pipeline can test it, and a deployment system can release it.

Reasoning and evidence continuity is more demanding. It requires the original outcome, assumptions, dependencies, constraints, uncertainty and accumulated assurance to remain connected as the work moves.

The current market is becoming increasingly capable of workflow continuity. It remains much less mature in reasoning and evidence continuity.

Delivery models before products

The same platform may be appropriate for one delivery mode and damaging in another. The landscape therefore needs to be understood in relation to the work being performed.

Delivery against a defined outcome

Where the business outcome is known, the project should contain an agreed scope, deliverables, requirements, dependencies, milestones, resource assumptions and evidence of completion.

This does not require a Gantt chart, and it does not make the work waterfall. A sequential list of requirements is not waterfall. Understanding what must be delivered, and in what broad order, is ordinary project planning.

The engineering team should decide how the requirements are implemented. It may create stories, tasks, technical specifications or an internal sub-plan. Those are mechanisms for organising execution. They are not the requirements themselves.

The sprint, where one is useful, sits below that level. The team examines the project requirements and wider targets, determines what can be completed within the next cycle and organises the technical work accordingly.

Prototyping and discovery

Prototyping operates differently because uncertainty is part of the assignment.

The organisation may not yet know whether an idea is feasible, which design will work, what users will accept or whether the problem has been understood correctly. The prototype exists to test assumptions and reduce uncertainty.

The plan should therefore define the hypotheses, questions, boundaries and learning outcomes rather than pretend that a final requirement already exists. The team can iterate, discard work and change direction as evidence emerges.

That is also Agile.

The mistake is treating all software delivery as though it were prototyping. A defined project does not become more Agile because the requirement is vague. Nor does a prototype become better managed because somebody writes artificial user stories for outcomes that remain unknown.

AI can accelerate both modes, but it requires different conditions. In defined delivery it needs accurate requirements and sufficient system context. In prototyping it needs explicit hypotheses, constraints and learning objectives.

A platform that treats every activity as a work item moving through the same prescribed workflow is already making an assumption about how software should be delivered. That assumption should be examined rather than accepted.

How Agile became confused with its machinery

Agile emerged from experienced software practitioners who understood that engineering teams needed room to exercise judgement. Its original values were a response to delivery models that attempted to prescribe too much of the technical method from above.

The underlying division of responsibility was straightforward. Project leadership agreed the outcome, deliverables, constraints, dependencies and timing. The engineering team decided how to achieve them.

That arrangement required trust.

In many organisations, trust in engineering expertise was gradually replaced by administrative visibility. Stories, points, sprint boards, ceremonies and status fields became mechanisms through which people outside the technical work could observe and influence its internal organisation.

The sprint ceased to be merely a cycle through which a team organised itself. It became a management unit. Stories were assigned points, points were aggregated into velocity, and movement across a board was presented as progress.

This altered the relationship between the project and the team. Delivery leads descended into sprint administration. Analysts and other intermediaries began defining technical stories before engineers had established the shape of the solution. Requirements were scattered across tickets, documents, diagrams and comments, while the engineering team reconstructed the real deliverable during implementation.

Stories became either too broad to execute or so narrowly divided that none represented a meaningful result. One could not be completed without three others, while the dependency between them was known mainly to the developers expected to perform the work.

The requirement and the story had been confused.

A requirement belongs in the project plan. It should describe the business outcome, relevant rules, dependencies, constraints and evidence that will demonstrate completion. The engineering team should decide how to decompose it into technical work.

The familiar formulation, “As a user, I want…”, does not repair this confusion. It can be useful where it expresses a genuine user need. It becomes process theatre when applied mechanically to migrations, infrastructure work, refactoring, security remediation or technical conversion.

An agent needs the actual objective, context, constraints and acceptance evidence. Ceremonial wording contributes nothing when those are absent.

Agile without the ritual

A software migration I managed provides a practical example.

The project involved converting approximately 2,500 programs. We began with a four-person engineering team and used the first two weeks to establish how much work could be completed. From that evidence, we found that the number of source lines provided a sufficiently reliable basis for estimating conversion effort across the program set, despite differences in the apparent complexity of individual programs.

We used that measure to forecast throughput and determine how many programs could be completed in each recurring cycle. A separate roadmap contained the project milestones and wider commitments.

The Jira items were simply the names of the programs to be converted.

There was no reason to convert each one into an artificial user narrative. The engineering team understood the objective and the conversion method. The item identified the next bounded unit of execution, nothing more.

There were no delivery managers or analysts decomposing the technical work, and no ceremonies imposed to provide management with a view into the team’s internal activity. The project had a plan, scope, milestones and measurable outcomes. The team determined how to perform the work and reported whether it had met the agreed target.

Over four years, it was the only team in the wider environment that consistently met its commitments.

That was Agile as originally intended. The team adapted its method to the work, used empirical evidence to improve its forecasts, and retained control over execution within a clear project plan.

Jira was useful because it recorded a simple unit of work. It did not define the method, invent the requirement or become the project plan.

The distinction is critical to evaluating AI delivery platforms. A useful tool remains subordinate to the delivery model. A damaging one encourages the organisation to adapt its work to the tool.

Atlassian and the fixed format of Agile

Atlassian occupies a powerful position because Jira, Confluence and related products have become embedded in the way many organisations represent software work.

That position is not neutral.

Jira converts work into structured fields, workflow states, stories, boards, sprints and reports. Confluence stores another layer of requirements, analysis, decisions and technical explanation. Miro and similar visual tools may hold workshop output, process diagrams and preliminary thinking. Code, tests, releases and production evidence remain elsewhere.

The result is often not a coherent body of organisational knowledge. It is a collection of representations that people must continually reconcile.

Requirements are copied into stories. Decisions are buried in comments. Pages become stale. Diagrams no longer reflect the system. Dependencies are visible in one product but absent from another. The backlog can appear orderly while the underlying analysis remains incomplete.

Jira turns software delivery into structured form-filling and presents the movement of those forms as evidence of control.

Boards move, statuses change and velocity can be reported. None of those facts establishes that the requirement is accurate, the dependency model is understood or the wider deliverable remains on track.

Atlassian’s July 2026 product direction places AI agents inside this existing structure. It describes Jira as a place to plan, assign, govern and measure work across people and AI agents, while Teamwork Graph is intended to connect context held across Jira, Confluence, repositories and other systems.[1][2]

Atlassian also describes agents as participants whose work can be assigned, tracked, audited and governed inside Jira.[3]

Those are factual descriptions of the product direction. They do not establish that Jira should become the organising centre of AI-assisted software delivery.

The important question is whether agent execution should be organised around Jira work items at all, or whether project requirements, engineering decomposition and machine-speed execution need a different relationship.

An agent can complete a bounded task in minutes or hours. Forcing that task into a two-week sprint does not improve it. Monitoring the agent session from a board does not establish that the task was worth doing or accurately specified. Turning intent into a longer ticket does not guarantee that the intent has been understood.

Atlassian is using AI to extend the delivery model its products already dominate. That is commercially rational. Organisations should nevertheless examine whether the model remains fit for purpose before allowing the vendor to make itself the centre of their AI operating environment.

The repository-centred model

GitHub and GitLab begin from a different control point.

The repository contains the code, change history, branches, pull requests and an increasing amount of testing, security and release information. Both platforms are expanding their ability to host or coordinate agents across technical delivery.

GitHub allows work to be delegated to Copilot and third-party agents, including Claude and Codex, with asynchronous work returning plans, code or pull requests to the repository workflow.[4] GitLab describes its Duo Agent Platform as a means of coordinating agentic work across planning, building, security and delivery.[5][6]

The repository is a stronger technical record than a sprint board. It shows what changed and allows evidence to be associated with a specific implementation.

It still does not contain the whole project.

The repository may not contain the business purpose, project dependencies, operational history, regulatory reasoning, resource constraints or decisions that led to the change. It can become the authoritative record of what was implemented without becoming the authoritative record of why the implementation was required.

Repository-centred platforms are therefore well positioned to control technical execution and maintain provenance. They are less naturally positioned to own the full relationship between business intent and project delivery.

A sensible architecture may use the repository as the authoritative technical record while retaining requirements and project commitments elsewhere. The challenge is preserving the relationship between them without reducing it to links between tickets and pull requests.

Execution agents as replaceable capability

Claude Code, Codex, Cursor and other coding agents occupy the point where intent becomes technical action. Part 2 examined their operating models and capabilities, so there is little value in repeating their feature lists here.

Their significance for the platform landscape lies partly in their replaceability.

An organisation may use different models for different types of work, permit several agents to operate within the same repository, or replace one execution provider without redesigning the whole delivery environment.

That possibility argues against allowing the coding agent itself to become the organisational control plane. The agent should operate within an environment that supplies context, identity, authority, tools and evidence requirements. Its capability can then improve or change without taking ownership of the delivery model with it.

Open integration standards, including the Model Context Protocol, can reduce the effort required to connect agents to external information, tools and workflows.[7]

They do not determine which information is correct, what an agent should be allowed to do or how conflicting context should be resolved.

Connectivity is useful. It is not understanding, authority or governance.

Testing, assurance and the danger of shared assumptions

AI is being added to code review, test generation, security scanning, vulnerability remediation and test maintenance. These capabilities can reduce effort and improve coverage.

They can also create an illusion of independent assurance.

An agent may misunderstand the requirement and produce an implementation consistent with that misunderstanding. If the same agent, or another agent using the same context, generates the tests, the tests may confirm the same mistake.

A green pipeline does not establish that the right outcome was delivered. It establishes that the implementation satisfied the checks that were run.

A complete platform must therefore retain the relationship between the requirement, the risks identified, the evidence selected and the result obtained. It should show where independent reasoning entered the process and which important assumptions remain unverified.

Testing and security platforms are valuable parts of the lifecycle. They should not be permitted to turn the production of more automated artefacts into a substitute for assurance.

Release, infrastructure and bounded authority

Delivery and infrastructure platforms occupy a legitimate and necessary control point. Environments, secrets, deployment permissions, approvals, rollout, rollback and operational promotion all need disciplined control.

Harness calls its current offering Agent DLC, describing it as coverage of the AI Agent Development Lifecycle from building and testing through deployment, security, governance and runtime operation.[8][9]

This is primarily concerned with delivering and operating AI agents as software, although it also shows how established delivery controls are being extended into agentic systems.

Reusing proven release and infrastructure controls is sensible. AI does not remove the need for them.

It does change how authority may need to be expressed. An agent may be allowed to propose infrastructure code but not apply it. It may deploy automatically to an isolated environment but require additional evidence before production. It may read production telemetry without being authorised to change production.

Those boundaries should follow the work throughout the lifecycle. They should not depend solely on a final approval button placed at the end of a pipeline.

Production operations and the missing return path

Observability and incident-management platforms have access to something planning and coding systems do not possess: evidence of how the software actually behaves.

AI can assist with signal correlation, incident analysis, diagnosis and suggested remediation. The larger opportunity is to connect operational evidence back into the delivery model.

An incident should be traceable to the relevant requirement, assumptions, implementation, tests, agent actions and release decision. Its resolution should update future tests, architecture decisions, context and policy.

Most delivery systems still treat production as the end of a pipeline. A mature AI delivery platform should treat it as part of a learning loop.

That change is not primarily an observability feature. It requires continuity across the whole lifecycle.

Governance at two levels

As organisations adopt multiple models, agents and AI-enabled products, they need an enterprise view of what exists, who owns it, what it can access and which policies apply.

ModelOp and other AI-governance providers approach the landscape through inventory, ownership, risk classification, policy and portfolio oversight. ModelOp describes its inventory as a system of record covering machine learning models, generative AI, agents, agentic systems, vendor tools and embedded AI.[10]

That is necessary, but it is not the same as governing software delivery.

An organisation may approve an agent for engineering use and still need to determine whether a particular change was properly justified, implemented, tested and released. Agent governance addresses the AI asset. Delivery governance addresses the work performed by that asset.

A complete platform needs both views and must connect them.

Mapping the 2026 landscape

The current landscape can be mapped against the lifecycle, with suppliers extending from their established positions.

The landscape contains strong products in individual areas. The unresolved question is how they should be assembled, which functions should remain authoritative, and whether the resulting delivery model improves the work or merely creates a larger system of automated administration.

AI-enabled delivery and AI-optimised delivery

The most important distinction in the 2026 landscape is between adding AI to the current process and reconsidering the process in light of AI.

An AI-enabled process retains the existing lifecycle and inserts AI features into it. Planning tools generate stories, agents complete them, review tools analyse pull requests, test systems generate cases, pipelines diagnose failures and observability tools summarise incidents.

Each capability may be useful. The combined system may remain fragmented and badly designed.

An AI-optimised delivery model begins with the nature of the work. Defined projects retain scope, requirements, dependencies, milestones and project accountability. Prototypes retain hypotheses, boundaries and learning outcomes. Engineering teams determine how technical work should be decomposed. Agents operate within clear authority and context. Evidence accumulates throughout execution. Production outcomes return to planning and analysis.

Management controls the outcome rather than the mechanics of every task.

This is not a return to heavyweight project methods. It is a restoration of the distinction between project planning and expert execution.

What remains missing, and what a complete platform would require

The present landscape covers most individual delivery activities. Its weakness lies in the relationships between them.

Authoritative intent

The first gap is a durable representation of what the project is trying to achieve.

Planning and documentation platforms can store large quantities of material, but the requirement may still be fragmented across tickets, pages, diagrams, comments and conversations. The platform needs to preserve the project outcome, business rules, dependencies, constraints, uncertainty and evidence of completion.

This information cannot be replaced by a larger story description. It needs to remain authoritative as the work is decomposed, implemented, tested and operated.

Engineering decomposition

Business and project analysis should establish the business requirement and intended deliverable. The engineering team should determine the technical stories, tasks or internal sub-plan required to produce it.

Current platforms frequently encourage the reverse. Somebody is expected to populate a backlog before the technical analysis has established the structure of the solution.

AI could assist engineers in analysing a requirement, identifying dependencies and proposing a coherent technical decomposition. It should not be used merely to produce more stories from incomplete material.

Context that is relevant and trusted

Giving agents access to Jira, Confluence, repositories, databases, telemetry and other systems does not establish that the material is current, relevant or internally consistent.

The platform needs to retain provenance, identify authoritative sources and expose conflicts. More accessible context can otherwise produce greater confidence without greater understanding.

Coordination across agents

Several agents may analyse, implement, test, review and deploy parts of the same change. A collection of sessions and transcripts is not a shared delivery model.

The platform needs common work state, explicit authority boundaries, conflict handling and traceability across their combined reasoning and actions. It also needs to recognise that several agents using related models or shared context do not necessarily provide independent judgement.

Evidence that travels with the change

Tests, security scans, reviews, approvals, deployment records and production results are usually held in different systems.

Evidence should accumulate alongside the change and remain connected to the original requirement. Its depth should reflect the risk and consequence of the work rather than forcing every change through the same administrative process.

A low-risk, well-understood modification may need little intervention. A change affecting customer funds, safety, regulatory reporting or critical infrastructure may need independent analysis, richer evidence and explicit approval.

Outcome-level control

Management does not need continuous surveillance of every prompt, story and agent action. It needs to know whether the deliverable remains achievable, whether dependencies are resolved, whether evidence is adequate and whether risk is changing.

Detailed agent activity will be necessary for investigation, technical review and audit. It should not become the AI equivalent of managing software through ticket movement and velocity.

A mature platform should strengthen project-level visibility while preserving the engineering team’s control over execution.

Bounded authority

Agents should operate through controlled identities and permissions appropriate to the task, system and environment.

An agent may be permitted to inspect a repository but not its production secrets. It may propose a deployment but not execute it. It may make an isolated low-risk change automatically while a consequential change requires independent evidence and human judgement.

Authority should be expressed throughout the lifecycle rather than reduced to a final approval gate.

Production as part of delivery

Production telemetry, incidents, support cases and customer outcomes should alter future requirements, tests, architecture decisions and agent instructions.

The platform should preserve the return path from operational evidence to planning and analysis. Without it, the lifecycle remains a one-way automation pipeline rather than a learning system.

Clear accountability

A requirement may begin in one product, be interpreted by an agent from another provider, implemented through a repository platform, tested by specialist tools, deployed through a pipeline and monitored by an operational agent.

The distribution of work cannot be allowed to obscure ownership of the outcome.

The organisation must retain clear responsibility for the requirement, technical decision, assurance decision and release. AI can perform actions and produce recommendations. Accountability remains with the people and structures that authorised the work.

A complete AI delivery platform does not need to be a single product. Given the pace of change, dependence on one supplier may be undesirable. It does need an architecture that establishes which information is authoritative, how authority is delegated, how evidence is retained, and how the participating products and agents remain subordinate to the organisation’s delivery model.

A landscape that should be challenged

The 2026 landscape contains most of the technical components required for AI-assisted software delivery. Planning and documentation products hold organisational information. Repository platforms preserve the technical record. Agents can perform substantial engineering work. Testing and security systems can produce assurance evidence. Delivery platforms control release and infrastructure. Operational systems reveal production behaviour. Governance products provide enterprise oversight.

The existence of those components does not prove that the current model is correct.

Established suppliers are extending AI from the products and processes they already own. That is commercially understandable, but it creates a risk that AI will be used to preserve inherited structures rather than improve them.

Lean organisations and startups may be less constrained. They can design around clear outcomes, small expert teams, rapid agent execution, dynamic technical decomposition and continuous evidence without first reproducing the administrative machinery of a large enterprise toolchain.

Large organisations face more dependencies, greater risk and stronger regulatory obligations. They cannot simply discard existing controls. They can still question whether stories, points, sprint reporting, duplicated documentation and task-level surveillance are the controls they actually need.

Nothing in software delivery should be beyond criticism. Older project methods produced results and also accumulated serious weaknesses. Agile arose because engineers challenged them. Agile itself was later absorbed into practices and products that often contradicted its original purpose.

AI provides another opportunity to examine the whole lifecycle.

Part 2 asked which AI capabilities were mature enough to enter the engineering environment. The harder question now is whether the environment being built around them is itself fit for purpose.

The important choice is not which vendor has inserted AI into the greatest number of activities. It is whether the resulting delivery model retains what works, changes what no longer fits and removes structures that obscure rather than improve the work.

The defining AI delivery platform will not be the one that produces the most stories, fills the most workflow states or places an agent in every product. It will be the one that connects project intent, engineering judgement, rapid execution, evidence and operational learning while preserving clear human responsibility for the outcome.

References

[1] Atlassian (2026), ‘How we’re evolving Jira for AI-native software development’, Atlassian, 15 July.

https://www.atlassian.com/blog/company-news/ai-sdlc

[2] Atlassian (2026), ‘Jira for AI-Native Software Development’, Atlassian.

https://www.atlassian.com/software/jira/dev

[3] Atlassian (2026), ‘Atlassian Team ’26: Meet the AI-Native Organization’, Atlassian, 6 May.

https://www.atlassian.com/blog/company-news/founder-update-team-26

[4] GitHub (2026), ‘Agents on GitHub’, GitHub.

https://github.com/features/copilot/agents

[5] GitLab (2026), ‘GitLab Duo Agent Platform’, GitLab Documentation.

https://docs.gitlab.com/user/duo_agent_platform/

[6] GitLab (2026), ‘GitLab 18.8 released’, GitLab, 15 January.

https://docs.gitlab.com/releases/18/gitlab-18-8-released/

[7] Model Context Protocol (2026), ‘What is the Model Context Protocol?’, MCP Documentation.

https://modelcontextprotocol.io/docs/getting-started/intro

[8] Harness (2026), ‘Harness Agent DLC: Secure the Agent Lifecycle’, Harness, 21 July.

https://www.harness.io/blog/introducing-harness-agent-dlc

[9] Harness (2026), ‘Introducing Harness Agent DLC: New Capabilities for the AI Agent Development Lifecycle’, Harness, 21 July.

https://www.harness.io/press-and-news/introducing-harness-agent-dlc

[10] ModelOp (2026), ‘Evergreen AI Model Inventory’, ModelOp.

https://www.modelop.com/ai-governance-software/inventory

A few years ago, I interviewed a senior engineer for a role involving legacy system modernisation. He was experienced, capable and probably in his late thirties. When I mentioned legacy conversion, he immediately connected it to work he had done before, moving older .NET applications onto newer versions of .NET.

He was not wrong. A .NET Framework application that needs to be moved to .NET 8 is legacy work. It can involve dependency issues, obsolete libraries, framework changes, security concerns, build pipelines, deployment changes and extensive regression testing. It was simply not the kind of legacy work I had in mind.

I was thinking of systems written in COBOL, Fortran, MultiValue BASIC and other technologies that many current engineers have never used directly, but may still encounter through the systems built around them. Mainframe jobs, overnight batches, report writers, indexed files, variable-length records, terminal screens, extracts, reconciliation processes and operational routines developed long before modern architecture patterns became normal.

For some readers, those references will be familiar. For others, they may appear to belong to an earlier era, yet many large organisations still depend on old back-end systems while presenting a modern digital surface to customers, staff and regulators. The mobile application may be new, as may the web portal and API layer, while the systems that calculate, settle, reconcile, report and record remain much older.

Genuine legacy modernisation is therefore rarely confined to code. A ten-year-old web application may be technically outdated. A forty-year-old core system may contain the operating memory of the business, including pricing rules, settlement rules, exception handling, reporting obligations, data definitions, audit trails, manual routines and workarounds that were never documented fully anywhere else.

AI changes the discussion, although not in the simplistic way often implied. It may be able to read old code and help produce new code, but a migration approached primarily as code conversion will fail to address the harder problem. Before the system can be replaced safely, the organisation has to recover the knowledge embedded within it.

Why legacy systems survive

Legacy systems usually remain in place for understandable reasons. Some were well designed, fast, reliable and deeply tuned to the business. Some processed large volumes for decades with fewer problems than the modern layers later placed around them. Others were supported by people who knew how to operate them, how to interpret their reports, how to manage exceptions and how to recover when something went wrong.

Avoiding replacement was often a rational decision. The system processed the overnight batch, produced settlement files, balanced reports, fed downstream systems and supported daily operations. Replacement involved cost, disruption and risk, while leaving the system in place allowed the organisation to continue functioning.

The associated cost was deferred rather than removed. As the years passed, original designers left, documentation became stale, vendor knowledge faded and experienced specialists became harder to find. Maintenance became patchy while the number of surrounding dependencies continued to grow. Reports were scraped by other systems, files were collected by data warehouses, operators created routines around exceptions, and business departments built processes around outputs that may never have been intended as formal interfaces.

By the time replacement becomes unavoidable, the question is no longer simply how to convert the code. The harder work involves establishing what the system does from input to output, which behaviours remain necessary, which are obsolete, which reflect historic technical constraints, and which have become part of the organisation’s operational controls.

AI has to operate within that work. It cannot remove the need for it.

The system extends beyond the source code

Modern engineers often expect the source repository to reveal most of an application’s behaviour. That expectation becomes unreliable in older environments, where the system may be distributed across code, files, configuration, schedules, runtime settings and operating practice.

A routine may appear self-contained until it is traced in context. It may depend on a file created by an earlier overnight job. A date may be read from a control record. A value may be set by a wrapper before the program begins. A branch may exist because of a month-end exception. A report may appear to have been produced for human review, while another process scrapes the same report into a downstream warehouse. A field may seem unused because its meaning is defined outside the visible code.

In one environment, the dependency may sit in a VSAM or ISAM file, older indexed file structures used to store and retrieve records by key. In another, it may sit in a UniVerse dictionary, a VOC entry, a Proc, a phantom process or a runtime setting. The terminology varies by platform, but the underlying issue remains consistent: the source code represents only part of the operating system that the business has accumulated around itself.

The history of these technologies is relevant for practical reasons rather than nostalgia. Many of the structures created by them still shape systems that organisations depend on. Younger engineers may never have written COBOL or handled EBCDIC data, but they may still encounter files, reports, interfaces and batch processes formed by those design choices.

A variable-length IBM-style file is more than a storage detail when the record boundary determines how a settlement instruction is interpreted. An indexed file is more than an implementation choice when its access path determines which record is updated. A report layout is more than presentation when a downstream process treats it as input.

Legacy behaviour often resides in places that a modern team would not normally consider part of the application boundary.

Complexity and missing context are different problems

AI may become increasingly capable of analysing very large codebases, tracing references, comparing routines and detecting patterns across millions of lines. That capability is valuable, and there will be cases where it uncovers relationships that would take a human team considerably longer to find.

However, code volume and system understanding are not the same problem. A model may be able to analyse everything it has been given and still misunderstand the system because the decisive evidence lies elsewhere.

It cannot inspect a manual process that has not been described. It cannot discover a production-only configuration that has not been supplied. It cannot know that operations staff copy a figure from a report each morning unless that activity appears somewhere in the evidence. It cannot explain why an unusual branch exists if the production incident that created it was never recorded. Nor can it identify a downstream consumer that sits outside the material available for analysis.

A highly complex system may be analysable when the evidence is reasonably complete. A much smaller system may remain opaque when its behaviour is fragmented across code, data, schedules, people and operational habits.

Legacy modernisation is difficult partly because the meaning of the system may not exist in any single place. It has to be reconstructed from multiple sources, some of which may conflict, be incomplete or no longer be trusted.

Asking AI the wrong question

A common approach is to give AI a large code listing and ask:

Tell me what this code does.

The answer may be fluent and technically competent. It may summarise loops, branches, variables, file operations and external calls. It may infer intent from names and structure, and parts of the explanation may be correct.

The difficulty is that a coherent description of the supplied code is not equivalent to an understanding of the system. The model may explain what is visible while remaining unaware of the context that gives the code its business meaning.

A more useful instruction would be:

Review this code and summarise what can reasonably be inferred from the material supplied. Identify ambiguous sections, missing dependencies, unexplained variables, external calls, configuration assumptions and any areas that require further investigation.

The difference is more than wording. In the first case, the model is invited to complete the explanation. In the second, it is asked to distinguish between what can be established and what remains uncertain.

For legacy work, that distinction is essential. The most useful output may not be the summary itself, but the list of unresolved questions it produces.

Ambiguity should remain visible

AI systems are generally designed to be helpful, fluent and constructive. These qualities are useful, but they can also encourage a model to complete an incomplete picture. Where the evidence is weak, it may infer the most coherent explanation available and present it with more confidence than the material justifies.

Legacy analysis requires a different discipline. Where the evidence is incomplete, the uncertainty should remain explicit.

A useful analysis should separate what can be established from the supplied code, what appears likely, what depends on missing definitions and what cannot be confirmed without further investigation. It should identify calls that lead beyond the available material, values whose origins are unclear, business rules that appear to exist without sufficient evidence to explain them, and outputs whose consumers have not yet been traced.

That kind of output converts ambiguity into an investigation plan. It identifies the artefacts, people and runtime evidence needed to complete the picture.

A plainly incorrect answer is often easier to challenge than a plausible one. The greater risk lies in an explanation that is coherent enough to discourage further enquiry. When the language is clear and the reasoning appears orderly, interpretation can easily be mistaken for knowledge.

A section of code may appear redundant because no visible program calls it, while an overnight job invokes it indirectly. A report may look like a human-readable artefact while another process consumes it. A field may appear unused because its meaning is defined in a copybook, dictionary or file layout outside the code being reviewed. A branch may seem obsolete because the condition arises only at month-end, year-end, settlement cut-off or during recovery.

These are the kinds of false conclusions that matter in migration work. The danger is not confined to an isolated technical mistake. A confident but incomplete analysis can change human behaviour, reducing the willingness of the team to trace dependencies, observe runtime behaviour, examine sample data, compare historical outputs and validate business rules.

AI can assist with all of that work, but it should not create the impression that the work has already been done.

Where AI can contribute

Used within a defined scope, AI can be extremely useful in legacy analysis. It can summarise a routine after the entry point is known, trace variable usage across a supplied code set, identify unresolved external calls, compare similar programs and highlight differences. It can draft candidate documentation, inspect job schedules, suggest execution dependencies, compare input and output samples, and identify where file layouts, dictionaries, copybooks or configuration records are missing.

It can also help construct regression scenarios from known behaviours and organise technical material that would otherwise require extensive manual effort.

This work is sometimes dismissed as routine, but it consumes a substantial part of any serious legacy migration. Engineers may need to examine code, scripts, reports, schedules, data definitions, operational notes, incident histories and years of accumulated exceptions before the behaviour of the system is clear enough to reproduce or redesign safely.

AI can accelerate that process when the task is bounded and the evidence is sufficient. The quality of the evidence pack therefore becomes central. Source code alone is rarely adequate. A serious analysis may require runtime versions, configuration, job schedules, file definitions, copybooks, data dictionaries, sample inputs, sample outputs, report layouts, logs, incident records, known workarounds and explanations from people who operate or depend on the system.

Human testimony is important, but it is not infallible. Experienced staff may describe what they believe the system does, what it used to do, or what the documented process says should happen. Their knowledge should be reconciled with code, data, logs and observed behaviour rather than treated as unquestionable fact.

No single source should be regarded as definitive. Code, documentation, operational knowledge, runtime evidence and historical outputs each reveal part of the system. Reliable understanding comes from comparing them and resolving the differences.

That reconstruction establishes what the system appears to do and why. The next question is different: which of those behaviours should survive the migration.

Migration is not blind duplication

Legacy migration does not necessarily require the old system to be reproduced line by line. Doing so may preserve obsolete processes, technical compromises and behaviours that no longer serve a useful purpose.

Some behaviours have to be retained because they represent current business rules, regulatory requirements, customer commitments, accounting controls or operational safeguards. Others may be historical artefacts, workarounds for earlier platform limitations or accommodations created because downstream systems adapted to an output many years ago.

The migration task is to distinguish between them.

That requires analysis of the system from input to output. What enters the system, where does it come from, how is it transformed, which files are read or written, which reports are produced, which downstream processes depend on them, which exceptions are handled, which totals are reconciled, and which controls demonstrate that the outcome is correct?

Only after that work can the organisation decide what to preserve, redesign, replace or retire.

AI can help prepare the map. It can support analysis, comparison, documentation and test design. It cannot decide which behaviour the business is prepared to change, which controls remain mandatory or what level of migration risk is acceptable.

Those decisions are not owned by a single individual. Engineers may establish technical behaviour, operations staff may explain runtime practice and recovery procedures, business users may validate meaning and expected outcomes, and risk, finance or compliance teams may confirm controls and obligations. Accountable leaders ultimately accept the migration risk.

Legacy recovery is therefore a process of reconstructing shared knowledge from fragmented evidence.

Recovering meaning before replacing code

Legacy systems should not be treated as obsolete code waiting to be translated. They contain accumulated business memory, and that memory has to be recovered before the system can be changed safely.

AI can assist by reading code, tracing dependencies, inspecting schedules, comparing outputs, drafting documentation and helping to construct tests. It can reduce the effort required to work through large volumes of technical material and may identify relationships that humans would otherwise overlook.

Its contribution depends on how the analysis is framed. When asked to produce a complete explanation from incomplete evidence, it can reinforce misunderstanding. When asked to distinguish inference from fact, expose ambiguity and identify missing context, it becomes a valuable part of the investigation.

The first task in legacy modernisation is not to rewrite the system. It is to rediscover what the system means.

AI adoption in software delivery should not begin with a product selection or a broad promise of automation. It should begin with an examination of the work itself. Before an organisation asks whether AI can automate a workflow, it needs to understand what the workflow is trying to achieve, who depends on it, what risk it manages, what evidence it produces, and whether it still needs to exist in its current form.

That distinction matters in July 2026 because AI is now capable enough to automate many fragments of delivery work. It can summarise reports, review documents, inspect repositories, analyse tickets, generate tests, interpret logs, compare change records and help prepare operational evidence. Coding tools have also moved beyond simple code completion. GitHub describes Copilot cloud agent as working in an ephemeral GitHub Actions-powered development environment where it can explore code, make changes, run tests and create pull requests [1]. GitLab describes Duo Agent Platform as agentic AI automation across the software lifecycle [2]. Atlassian describes Rovo Dev as a context-aware AI agent for software teams and says it is available inside Jira to help move simpler backlog items toward merge-ready pull requests [3]. JetBrains describes Junie as a coding agent that can run in JetBrains IDEs, in the terminal, or headlessly in CI/CD scripts [4].

The direction is clear enough. AI is moving from the side of the work into the work itself. That creates a real opportunity, but it also creates a real risk. The opportunity is that AI can help organisations investigate, analyse and improve how software delivery actually works. It can examine tickets, reports, logs, dashboards, procedures, incidents, approvals, repositories, release records and operational data at a scale that would be difficult to manage manually. The risk is that the same capability is used to automate unnecessary work, preserve outdated procedures, accelerate bureaucratic rituals and produce more polished versions of weak evidence.

AI can help improve the delivery system, but it should not be poured over the existing delivery system as though intelligence alone will fix it. The better rule is simple: simplify first, automate second.

The simple report problem

Consider a simple workflow. An automated process produces a report. The report is emailed to John. John reviews it, adds comments, and emails it to three other people for review and sign-off.

On the surface, this is an obvious candidate for AI. AI could summarise the report, draft John’s comments, send the email to the three reviewers, chase responses, collate replies, produce a final sign-off note, update a ticket and archive the evidence. This may look like progress, especially if the same activity previously took hours or days.

But it may also be the automation of an unexamined routine.

Before replacing John with AI, the organisation should ask what the report is for. What decision does it support? Who actually reads it? What does John add that the system does not already know? Are the three reviewers accepting real risk, or are they copied because the workflow evolved that way? Is the sign-off legally required, operationally useful, or simply inherited ceremony? Could routine cases be stored as evidence without review? Could exceptions be flagged automatically? Could the source system produce structured evidence instead of a report? Could approval happen inside a workflow tool rather than through email?

The better answer may not be to replace John with AI. It may be to redesign the workflow. Routine results might be retained automatically as evidence. Exceptions might be flagged. AI might summarise only the exceptions and likely impact. An accountable owner might review cases that need judgement. Approvers might sign off only where a real decision or risk acceptance is required. Evidence might be stored in the system rather than scattered through email.

In that redesigned workflow, John may not disappear. His role may become clearer: owner of the exception process, reviewer of unusual cases, or accountable approver where judgement is genuinely required. The improvement is not that a person has been removed. The improvement is that human attention is reserved for the work that needs it.

That is not less ambitious than automation. It is more ambitious, because it questions the shape of the work rather than merely replacing one participant in it. The goal is not to make the old workflow run without John. The goal is to understand what the workflow is trying to achieve and design the simplest reliable way to achieve it.

Enterprise systems age by accumulation

The same principle applies at enterprise scale. A long-running legacy system may have been in operation for decades. It may be reliable, business-critical and deeply embedded. Over time, it produces a large number of reports. Some are emailed to users. Some are archived. Some are reviewed manually. Some are consumed by downstream processes. Some may satisfy audit, legal or regulatory obligations. Some may no longer be used at all.

Then another layer appears. A data warehouse team builds scraping software to read selected lines from some of those reports and load information into the data warehouse. Years pass. The warehouse grows to terabytes of data. People move on. Junior staff become managers. Managers leave. Executives change. Documentation becomes stale. The original reason for some reports is forgotten. Yet the workflows continue because something downstream may depend on them.

This is not unusual, and it is not necessarily evidence that anyone made poor decisions. It is how enterprise systems age. Useful outputs become dependencies. Dependencies become workflows. Workflows become assumptions. Assumptions become expensive to challenge.

AI should not be applied blindly to preserve that structure. Before automating report review, report distribution, scraping, reconciliation or sign-off, the organisation needs to understand what the ecosystem is doing. Who receives each report? Who opens it? Which reports are read by humans? Which are consumed only by automated processes? Which reports feed the data warehouse? Which scraping rules are still active? Which data elements are used in downstream reporting? Which outputs are legally required? Which exist only because they always have? Which reports duplicate data available elsewhere? Which manual checks actually prevent risk? Which are simply habits?

This is where the AI question needs to become precise. The right question is not merely “where can AI help?” It is: which AI capability can help with this task during analysis and investigation?

If the task is understanding report usage, AI may help analyse access logs, email distribution lists, archive records and downstream ingestion. If the task is understanding data warehouse dependency, AI may help compare scraping rules, report layouts, lineage metadata and downstream tables. If the task is understanding legal relevance, AI may help identify candidate obligations and related policy documents, but accountable legal, compliance and business specialists must validate the conclusion.

AI can surface questions faster. It can organise evidence. It can challenge assumptions. It can act as an expert assistant during investigation. It does not remove the need for specialist knowledge.

Modern tooling can create its own ceremony

This problem is not limited to old systems. A modernisation programme can create the same kind of accumulated complexity, although it may use more current language. An organisation may decide to improve monitoring and observability. It adopts OpenTelemetry, centralised logging, data ingestion pipelines and dashboard tooling. Multiple systems begin sending telemetry. Dashboards multiply. Licences are purchased. Teams are told the organisation now has modern observability.

OpenTelemetry is a vendor-neutral observability framework for generating, collecting and exporting telemetry data such as traces, metrics and logs [5]. Used well, this kind of instrumentation can help teams understand system behaviour, diagnose incidents and improve reliability. The issue is not the standard, the platform or the dashboard tool. The issue is whether the organisation can explain the purpose of what it has built.

A chart may show throughput. It may display 100 transactions per second, or 10,000 transactions per second. It may look impressive. It may reassure managers that the system is being observed. But what does the number mean? Is 100 transactions per second good or bad? Is 10,000 normal, exceptional or dangerous? Who looks at the chart? When do they look at it? What decision does it support? Is it used during diagnosis? Does it trigger action? Does it help teams understand customer impact? Does anyone compare it with incidents, releases or business outcomes?

A dashboard that is not used in diagnosis, decision-making, operational improvement or accountability may still be visually impressive, but it is not necessarily useful observability. It may simply be a display of collected data without a clear operating purpose.

The same applies to alerts. A team may receive more than 100 alerts a day. Some may be important. Some may be duplicates. Some may be warnings that no one understands. Some may be inherited from previous teams. Some may fire every day and be ignored. Some may exist because someone once believed they were important, but no one now knows who reacts to them or why.

If an alert is important enough to send, the organisation should know who receives it, who is expected to act, how quickly they must act, and what happens if they do not. Is it a 24-hour operational alert, or does it accumulate in someone’s inbox until morning? If no one is expected to respond overnight, is it really an urgent alert? If it is only reviewed during business hours, should it be a daily exception report instead? If it is important, where is the on-call path, escalation rule and ownership model?

AI can help investigate this. It can analyse alert history, acknowledgement patterns, incident records, escalation paths, service ownership, dashboard usage, log queries and post-incident reviews. It can help identify alerts that are never actioned, alerts that correlate with real incidents, alerts that arrive after the incident is already known, dashboards that are rarely opened, and telemetry that costs money but produces little operational value.

The point is not that dashboards, logs or alerts are bad. They are essential when they support diagnosis, resilience, compliance and improvement. The point is that they should be justified by use and outcome, not by appearance. AI should not simply generate more dashboards or triage more noise. It should help determine whether the signal should exist, who owns it, what action it requires, and what outcome it protects.

The age of the system is not the issue

A forty-year-old report and a brand-new dashboard can suffer from the same problem: no one can clearly explain who uses it, what decision it supports and what value it creates.

The age of a system is not the issue. Unexamined purpose is the issue.

This matters because technology organisations can confuse visible activity with progress. A dashboard looks like control. A large monitoring platform looks like maturity. A complex approval workflow looks like governance. A high volume of alerts looks like vigilance. A large set of reports looks like evidence. Sometimes that is true. Sometimes it is simply activity that has become difficult to challenge.

A new head of engineering may advocate a tool because it worked somewhere else. A team may build dashboards because modern engineering organisations are expected to have dashboards. A monitoring platform may expand because licences are available. A log ingestion programme may succeed technically while no one asks whether the data is being used. A reporting process may continue because it has always existed.

AI adoption should create an opportunity to examine this properly. Which tools are used? Which dashboards support diagnosis? Which alerts produce action? Which reports support decisions? Which licences are active? Which data streams are expensive but low value? Which controls reduce risk? Which procedures exist because of regulation? Which ones exist because the organisation has stopped asking why?

This is not anti-tooling. It is serious governance. AI should not only be used to justify more technology. It should also be used to question existing technology.

Change governance accumulates control layers

Change management is another area where AI should be used carefully. A change request may pass through a manager, cyber security, architecture, operations and sometimes a full CAB group. Supporting documents are attached, the same information is repeated in several places, and the change eventually receives approval.

Some of this may be necessary. Regulated environments need evidence. Cyber security review may be essential. Production risk must be understood. Rollback planning matters. Separation of duties may be required. Accountability cannot be casual.

But robustness should be demonstrated, not assumed. A mature organisation should be able to examine whether its change process is reducing risk or simply preserving a ritual that has developed over years. The useful evidence is not the number of approvals collected. It is whether those approvals improved the outcome.

AI can help examine that evidence by analysing change records, approval histories, rollback data, incident links, review comments, deployment outcomes and post-change reviews. It can identify patterns such as repeated causes of rollback, approvals that rarely alter outcomes, documents that are attached but never used, changes approved despite missing evidence, and controls that genuinely reduce production risk.

The aim is not to make rubber-stamping faster. If the process is necessary, AI can help make it clearer, faster and more evidence-based. If parts of the process are ritual, AI should help expose that before the ritual is automated.

Ask which AI capability fits the task

A serious AI strategy needs sharper questions than “where can AI help?” That question is too broad. It encourages vague adoption, tool shopping and generic productivity claims. The better question is: which AI capability can help with this task during analysis and investigation?

Different tasks need different forms of assistance. If the issue is unclear process ownership, AI may help compare process documents, tickets, approval histories and communication records. If the issue is report usage, AI may help analyse access logs, email distribution lists, archive records and downstream ingestion. If the issue is data warehouse dependency, AI may help map scraping rules, report layouts, lineage records and downstream tables.

If the issue is repeated manual intervention, AI may help identify recurring comments, exception patterns, duplicated approvals and common rework loops. If the issue is stale documentation, AI may help compare documentation with repository contents, runbooks, release notes and incident records. If the issue is alert fatigue, AI may help analyse alert frequency, acknowledgement patterns, incident correlation, escalation paths and on-call responses.

The same approach applies to cost, governance and compliance. If the issue is cost, AI may help analyse licence usage, telemetry volumes, infrastructure consumption, storage growth and support effort. If the issue is legal or regulatory relevance, AI may help identify candidate obligations and related policy documents, but accountable specialists must validate the conclusion. If the issue is change governance, AI may help compare approval steps with actual change outcomes, rollback history, incidents and review comments.

This distinction matters because AI should be selected according to the investigation task, not applied generically to the whole workflow. In some cases, the right AI role is summarisation. In others, it is classification, comparison, anomaly detection, code analysis, log analysis, document review, process mining, dependency mapping, cost analysis or option generation. In many cases, the first useful AI output is not a working automation. It is a better understanding of the problem.

AI as expert assistant, not magic solvent

In complex environments, AI is useful because it can work across large volumes of material. It can read more documents than a workshop group can reasonably handle. It can compare tickets, procedures, reports, logs, code and release records. It can find patterns that are tedious for people to assemble manually. It can draft options quickly.

But complex environments also contain specialist knowledge that may not be written down. This is especially true in legacy systems, regulated industries and long-running operational workflows. The reason a report exists may be known only to a former operations manager, a compliance specialist, a data warehouse developer or a business user who inherited a control from someone else. The reason a workflow looks inefficient may be that it protects against a risk invisible to the technology team. The reason a data extract is duplicated may be that two downstream consumers use similar fields differently.

AI can help investigate these cases, but the analysis must be validated. The right model is not AI as oracle. The right model is AI as expert assistant: fast, tireless and useful, but still requiring direction, verification and judgement. It can prepare the map. People still have to confirm the territory.

The strategy must be adaptive

There is another complication. AI capability is changing quickly, so a sensible approach from last year may already be incomplete. A tool that was previously a coding assistant may now behave more like an agent. A workflow that was manual may now be partly automatable. A policy written for chat prompts may not be sufficient for tool-using agents. A delivery process designed around human drafting may need to account for AI-generated artefacts, AI-assisted reviews and AI-prepared release evidence.

This is why the strategy cannot be a rigid target-state plan. The organisation needs principles, interfaces, accountabilities and review points that can absorb new capability as it matures.

This is where the software architecture analogy helps. In software design, dependency injection avoids hard-wiring a system to one implementation. The system depends on an interface, not a concrete class. That allows an implementation to change without rewriting the whole application.

AI delivery strategy needs a similar principle. The organisation should not hard-wire its operating model to one model, one vendor, one assistant, one workflow or one moment in AI capability. It should define where AI fits, what it is allowed to do, what evidence it must produce, who remains accountable, how tools connect, how outputs are validated, and how capability can be replaced or upgraded without breaking governance.

The aim is not to predict every future AI capability. The aim is to design a delivery model that can absorb future capability safely.

A managed change programme, not a tool rollout

AI delivery strategy should look more like a managed change programme than a software rollout. A tool rollout asks who gets access. A change programme asks what must change for the organisation to improve.

The programme should start by selecting a meaningful slice of the delivery landscape, not the whole enterprise at once. That slice might be one workflow, one system area, one release process, one reporting ecosystem, one class of maintenance work, or one delivery path from business request to production outcome.

It should then establish a baseline. How does the work happen today? Which systems are involved? Who participates? What evidence is produced? Where does work wait? Which steps are necessary? Which are unclear? Which are repeated? Which are manual? Which are high risk? Which tools are used? Which tools are paid for but barely touched? Which reports are read? Which alerts are actioned? Which approvals change outcomes?

AI can assist with that baseline by analysing artefacts, summarising evidence, identifying repeated patterns and proposing candidate improvements. Practitioners then validate the findings. From there, the organisation can decide what to simplify, what to protect, what to integrate, what to retire, what to automate and what to leave alone.

Only then should AI be applied directly to the workflow. That may mean using AI to draft exception summaries rather than routine reports. It may mean using AI to analyse release evidence rather than generate more status updates. It may mean using AI to inspect repository and pipeline changes rather than replace engineering review. It may mean using AI to identify unused reports before retiring them. It may mean using AI to help create structured evidence where email once served as the process. It may mean using AI to rationalise alerting before applying AI to alert triage.

This is slower than buying a tool and announcing adoption, but it is more likely to produce real improvement.

The adaptive pattern

Because AI is evolving, the resulting strategy should not freeze around one implementation. The organisation needs an adaptive pattern.

That pattern should define stable principles: business accountability remains clear; AI assistance is visible; evidence is retained; sensitive data is protected; specialist decisions remain human-accountable; outputs are validated; production feedback matters.

It should also define replaceable components: models, agents, workflow integrations, prompt patterns, retrieval mechanisms, tool connectors and automation rules. This allows the organisation to improve without rebuilding the strategy every time capability changes.

A good adaptive strategy says that the delivery model is stable enough to govern, while the implementation is flexible enough to evolve. That balance matters. Without stability, AI adoption becomes experimentation without control. Without adaptability, the organisation freezes itself around last year’s technology.

Conclusion

The practical starting point is not complicated. Pick one real workflow and examine it before automating it.

Choose a reporting process, a change approval path, an alert stream, a dashboard set, a release evidence process, or a legacy data feed. Ask who uses it, what decision it supports, what risk it reduces, what evidence it produces, what it costs, and what would break if it changed. Then ask which AI capability can help with the investigation: log analysis, document comparison, usage analysis, dependency mapping, cost analysis, summarisation, classification or option generation.

That is a different posture from tool adoption. It treats AI as part of disciplined improvement rather than a layer added to existing activity.

Some workflows will be worth automating. Some should be simplified first. Some should be redesigned around exceptions. Some should remain human-controlled because they involve judgement, accountability or risk acceptance. Some should be retired because their original purpose has disappeared.

The work is not glamorous, but it is where the value sits.

AI should not be treated as a magic solvent poured over complexity. Its first serious use may be to help the organisation understand itself. Only then should it be used to accelerate delivery.

References

[1] GitHub, 2026, About GitHub Copilot cloud agent.

https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[2] GitLab, 2026, GitLab Announces the General Availability of GitLab Duo Agent Platform.

https://about.gitlab.com/press/releases/2026-01-15-gitlab-announces-duo-agent-platform-general-availability/

[3] Atlassian, 2026, Auto-complete your backlog. Unleash your favourite AI models with deep context, from plan to code, with Rovo Dev in Jira.

https://www.atlassian.com/blog/announcements/rovo-dev-in-jira

[4] JetBrains, 2026, Getting started with Junie.

https://junie.jetbrains.com/docs/

[5] OpenTelemetry, 2026, What is OpenTelemetry?

https://opentelemetry.io/docs/what-is-opentelemetry/

Software delivery does not begin when a developer opens an editor.

It begins earlier, when something in the business changes. A regulator updates a rule. A payment scheme changes a requirement. A security vulnerability is discovered. A pricing model needs adjustment. A customer journey fails in production. A partner changes an API. An operational report no longer answers the question the business is asking.

At that moment, the organisation has a delivery problem.

The real question is not whether AI can help someone write code faster. That question has already been asked too often. AI can help write code, generate tests, explain errors and draft pull requests. Those capabilities matter, but they are not the real prize.

The more important question is this:

How quickly can the organisation convert a real business change into a safe production outcome?

That is the question that matters to a bank implementing a payment rule change. It is the question that matters to an insurer changing a claims rule or pricing model. It is the question that matters to a government agency responding to legislation, a retailer fixing a checkout failure, or a platform business responding to a vulnerability in a widely used dependency.

Software delivery is not merely the act of producing software. It is the mechanism by which business change becomes production behaviour.

That means AI-enabled delivery cannot be achieved by giving developers a coding assistant and declaring the organisation modern. Nor can it be achieved by adding disconnected AI features to planning tools, test tools, service desks and observability platforms. Those may all be useful, but they are fragments.

The larger challenge is architectural.

An organisation has to understand how change moves through its delivery system. It has to know how work is initiated, scoped, designed, built, tested, deployed, released, observed and improved. It then has to decide where AI should assist, who remains accountable, what evidence must be produced, and how each stage passes enough context to the next.

The promise of AI in IT is faster and better systems delivery. The danger is that organisations apply AI to isolated fragments of the process and then wonder why the whole delivery system has not improved.

Delivery is how business change becomes production behaviour

A business does not experience software delivery as code, pipelines or deployment scripts. It experiences delivery as changed behaviour.

A payment is accepted or declined. A quote is calculated differently. A customer sees a different screen. A claim follows a different rule. A report includes a new measure. A batch process runs at a different time. A fraud control blocks a transaction. A regulator receives a file in the required format.

That is the outcome.

Everything before that is the delivery mechanism.

In many organisations, that mechanism has grown over time rather than being deliberately designed. There are planning tools, ticketing systems, architecture documents, repositories, pipelines, test suites, deployment platforms, release boards, observability dashboards, incident queues and service-management workflows. Each may work locally. The problem is what happens between them.

A change begins with meaning. As it moves through the organisation, that meaning is repeatedly translated. Business need becomes initiative. Initiative becomes scope. Scope becomes requirements. Requirements become design. Design becomes code and configuration. Code becomes tests. Tests become evidence. Evidence becomes release approval. Production behaviour becomes telemetry, incidents and feedback.

At each translation point, context can be lost.

The original business reason may disappear from the story. An assumption made during scoping may never reach testing. A design decision may not be visible to operations. A test may prove the code changed, but not that the business rule was implemented correctly. A release may pass governance because every required field was completed, while the real operational risk remains poorly understood.

This is where AI has a deeper role. The opportunity is not merely to accelerate tasks. It is to reduce context loss across the delivery cycle.

The weak point is not always development

Many organisations still describe delivery failure as a development problem. The team took too long. The estimate was wrong. The code was more complex than expected. Testing found defects late. Release was delayed.

Sometimes that is true. Often it is incomplete.

A change may be slow because it entered the delivery system badly. It may have been initiated without a clear business driver. It may have been scoped without the right domain knowledge. It may have been analysed without the right technical expertise. It may have been built correctly against an incomplete story. It may have been tested against acceptance criteria that did not represent the real business outcome.

The result is familiar. Everyone can appear to have done their part, yet the delivery system still fails.

This is why AI must be applied to delivery rather than only to development. If AI is used only after the work has already been poorly framed, the organisation may simply produce the wrong output more quickly.

A coding agent can help implement a change. It cannot know that the original business request was incomplete unless the organisation gives it the context to challenge the request. A test generator can create additional tests. It cannot know that a business exception was never captured unless the exception exists somewhere it can inspect. An observability assistant can summarise production signals. It cannot know what production behaviour should have changed unless the intended outcome was defined earlier.

The deeper question is therefore not “which AI tool should developers use?”

The deeper question is:

How should the organisation design its delivery cycle so AI can help carry meaning, evidence and feedback from beginning to end?

That question is more difficult. It is also more valuable.

A practical example: the payment rule change

Consider a bank that must implement a payment rule change.

The trigger might come from a regulator, a card scheme, a payment provider, a fraud-control team or an internal risk decision. The details matter, but the delivery pattern is familiar. The bank must understand the change, determine which products and systems are affected, update rules or interfaces, test the business outcome, deploy safely, release with appropriate governance and confirm in production that the change behaves as intended.

In a weak delivery model, this starts as a vague ticket.

A business user provides a summary. A business analyst turns it into a story. The story is refined. A developer looks at the relevant code. Someone late in the process remembers that a batch report is affected. Testing proves the altered function behaves as written, but does not fully prove the payment rule across all relevant scenarios. Release evidence is assembled manually from tickets, test results and status updates. After release, operations watches technical dashboards, while the business waits to see whether the change has worked.

That is not a failure of effort. People may be working hard. The problem is structural.

The delivery system is not carrying the change clearly from start to finish.

In a stronger AI-enabled model, the same change begins differently. The initiating artefact is not just a ticket. It is a structured change brief containing the source of the change, the business driver, the compliance date, affected products, known exclusions, likely customer impact, operational constraints and open questions.

AI then assists where organisations often lose time: turning scattered input into a usable delivery shape.

It compares the change brief with previous payment changes, architecture records, known services, APIs, data stores, batch jobs, monitoring rules, defects, incidents and test coverage. It does not decide the answer. It prepares the ground so the right people can decide faster and with fewer blind spots.

The delivery owner confirms scope. The architect or senior engineer confirms impact. The engineering team uses agentic coding tools within repository rules and review controls. The testing function checks the change against the business rule, not merely the code diff. The pipeline produces build, test and security evidence. Release governance consumes that evidence rather than reconstructing it manually. Observability confirms whether the production outcome matches the expected payment behaviour. Any learning feeds back into the next payment change.

The difference is not that AI replaces the delivery organisation.

The difference is that AI is used to connect the delivery organisation.

What good looks like

For an organisation trying to improve, the starting point is not product selection. It is to draw the delivery cycle and define what happens at each stage, who is accountable, where AI can assist, and what evidence must travel forward.

A practical AI-enabled delivery model might look like this.

1. Initiate: turn pressure into a clear change brief

The business owner confirms why the change is needed. The trigger may be a regulation, a payment scheme update, a vulnerability, a product change, a customer issue or an operational failure. AI can help convert source material, meeting notes, emails, policy documents or business requests into a structured brief recording the driver, deadline, accountable owner, affected business area and unresolved questions.

This matters because poor initiation creates expensive confusion later. A weak change brief does not stay weak at the start. It spreads weakness through the whole delivery cycle.

2. Scope: define what is in and what is out

The product, delivery or domain owner confirms the boundaries of the change. AI can challenge ambiguity, compare similar prior work, identify likely dependencies and surface missing rules or exclusions. The output should be a scope statement with inclusions, exclusions, assumptions, dependencies and open questions.

If scope is treated as administration rather than decision-making, delivery inherits the uncertainty.

3. Design and impact: understand what the change touches

The architect or senior engineer confirms the technical approach and likely impact across systems, APIs, databases, batch jobs, security controls, infrastructure, reporting, monitoring and operations. AI can compare the scoped change with architecture records, repository content, interface catalogues, incident history and previous similar changes. The result should be an impact assessment and decision record.

AI should not replace architectural judgement. It should improve the quality and timing of the information on which that judgement depends.

4. Build: implement under supervision, not guesswork

The engineering owner remains accountable for implementation quality. AI can prepare implementation plans, draft code changes, generate tests, explain affected files and prepare pull requests, but it should work within repository instructions, coding standards, test expectations and architectural constraints. The evidence is the pull request, implementation notes, linked changes, test updates and review comments.

In this model, the engineer’s work moves upward: supervising implementation, challenging generated output and ensuring the change fits the system.

5. Test and evidence: prove the business outcome, not only the code change

The QA or test owner confirms that testing proves the original business intent. AI can derive test scenarios from the change brief, scope and impact assessment, then highlight missing cases, untested assumptions and gaps between acceptance criteria and coverage. The evidence should link test cases and results back to the business outcome.

For the payment-rule example, this means proving accepted cases, rejected cases, downstream files, reports and exceptions, not merely proving that one altered method returns the expected value.

6. Deploy: check the environment before release pressure begins

The platform or release engineering function confirms that the environment, pipeline, configuration and rollback position are ready. AI can inspect pipeline results, deployment configuration, infrastructure definitions, dependency status, environment differences and rollback instructions. The deployment record should capture build results, environment checks, configuration changes, rollback position and unresolved deployment risks.

Where deployment still depends on manual notes, private scripts and personal memory, AI has little reliable material to use.

7. Release: make the decision from evidence

Business and technology approvers accept the release risk. AI can assemble release evidence from the change brief, scope, design record, pull request, test evidence, security findings and deployment record, while highlighting unresolved risks and post-release watch points. The release pack should contain approvals, accepted risks, unresolved issues, rollback plan and production validation checks.

This does not remove governance. It makes governance more honest. The decision becomes less about status reporting and more about evidence.

8. Observe: check whether production behaved as intended

Operations and product owners confirm the production outcome. AI can interpret logs, metrics, traces, alerts and business signals against the expected behaviour. The production validation report should show whether the change behaved as expected, whether anomalies occurred and whether further action is required.

A dashboard that cannot be related back to the intended change is useful, but incomplete. The delivery cycle closes only when production behaviour is compared with the business outcome.

9. Learn: feed the result into the next change

Delivery leadership ensures that learning does not remain trapped in an incident ticket, dashboard or retrospective. AI can summarise production findings, identify recurring patterns, update runbooks, suggest backlog changes and improve future scoping guidance. The output might be a lessons record, an updated delivery pattern, a changed standard, a new backlog item or a revised operational control.

This is where the organisation stops merely releasing change and starts improving the way it releases change.

This model is not meant to be bureaucratic. It is meant to make the work visible. AI becomes useful because it has a defined role in a defined delivery system. It assists, drafts, challenges, compares, generates and summarises. It can automate some work, but only where the organisation has already decided the boundaries. It can accelerate delivery, but only where humans have defined the route.

The product stack must behave like one delivery environment

Once the delivery cycle is clear, products can be discussed sensibly.

A coherent AI-enabled delivery environment might include planning tools, documentation repositories, source-control platforms, agentic coding tools, CI/CD pipelines, infrastructure-as-code tooling, security scanners, observability platforms and service-management workflows.

The products do not have to come from one vendor. In most organisations, they will not. A bank, insurer or large enterprise may use Jira, Confluence, GitHub, GitLab, Azure DevOps, Jenkins, OpenShift, Kubernetes, Terraform, Bicep, ServiceNow, Splunk, Elastic, Datadog, New Relic and cloud-native services in different combinations.

The question is not whether each product is impressive in isolation. The question is whether the products behave like one delivery environment.

This is where “best of breed” needs a more disciplined meaning. It cannot simply mean buying the strongest product in every category. A strong planning tool, a strong repository, a strong pipeline tool, a strong observability tool and a strong service-management tool can still produce weak delivery if the connections between them are informal, manual or poorly governed.

For AI, those connections are the operating surface.

Current products show why this is becoming practical, but also why tool adoption alone is not enough. GitHub’s Copilot cloud agent can work autonomously in a GitHub Actions-powered environment on development tasks assigned through GitHub issues or GitHub Copilot [1]. GitLab announced the general availability of Duo Agent Platform in January 2026, describing it as agentic AI orchestration across the software lifecycle [2]. Atlassian’s Rovo Dev is positioned around code analysis, code generation, review and validation against Jira acceptance criteria [3]. JetBrains describes Junie as a coding agent that can run in JetBrains IDEs, in the terminal or headlessly in CI/CD scripts [4].

Those examples are useful because they show parts of the delivery toolchain becoming agentic. But they do not solve the wider delivery problem on their own.

The real test is whether the organisation can trace a change from its original driver to the production outcome: the brief, the scope, the decision record, the implementation, the tests, the deployment, the release approval, the production validation and the lessons learned.

If that trace exists only in people’s heads, AI will not reliably improve delivery. It will merely operate on fragments.

The toolchain must expose context

AI cannot work well from fragments.

A coding agent can work from a clear issue, repository instructions, build scripts, tests and known conventions. GitHub’s guidance for Copilot coding agent tells users to treat an assigned issue as a prompt and consider whether the issue description will enable Copilot to make the required code changes [5]. GitHub also supports repository custom instructions that provide Copilot with additional context on how to understand the project and how to build, test and validate changes [6].

That matters beyond GitHub.

It tells us that agentic delivery depends on the quality of the work definition. If the initiating artefact is vague, AI does not magically solve the problem. It may simply produce a plausible answer to a poorly framed request.

This is why initiation and scoping are central to AI-enabled delivery. They are not administrative preliminaries. They are the moment at which the organisation determines whether AI will receive a useful problem or a defective one.

The same applies further down the cycle. If architecture decisions are hidden in slide decks, AI cannot reliably apply them. If deployment knowledge lives in the memory of one engineer, AI cannot safely reason about it. If tests are disconnected from business outcomes, AI can generate more tests without increasing assurance. If observability is not tied to the expected production behaviour, AI can summarise signals without knowing whether the change succeeded.

The organisation must therefore make its delivery knowledge more explicit.

That does not mean documenting everything for its own sake. It means creating enough structured, current and governed context for AI and humans to operate from the same understanding.

Infrastructure, observability and maintenance are part of delivery memory

Infrastructure, deployment and observability are often treated as later-stage concerns. In an AI-enabled delivery model, they must be part of the change from the beginning.

A payment rule change may require no infrastructure change. It may require a configuration update. It may affect scaling, alerting, batch scheduling, downstream integration, logging, data retention or rollback strategy. The point is not that every change is infrastructure-heavy. The point is that deployment and operation are part of the delivery outcome.

Infrastructure as code helps because it makes environments inspectable and reviewable. Terraform, Bicep, Kubernetes manifests, OpenShift configuration and cloud-native deployment definitions all make the environment more visible than manual configuration. HashiCorp’s Terraform MCP server is a useful signal of where this is heading: it gives AI models real-time access to current Terraform provider documentation, modules and policies from the Terraform Registry [7].

That does not mean AI should blindly generate infrastructure. It means infrastructure becomes part of the context AI can inspect and reason about, subject to policy, review and validation.

Observability has a similar role. OpenTelemetry describes itself as a vendor-neutral open-source observability framework for instrumenting, generating, collecting and exporting telemetry data such as traces, metrics and logs [8]. That kind of standardisation matters because production signals must not remain locked away from the delivery cycle.

For the payment-rule example, observability should not only answer whether servers are healthy. It should help answer whether the business change behaved as expected. Those signals should feed back into delivery. If they do not, the organisation learns too slowly.

Maintenance belongs in the same model. Dependency updates, security patches, deprecated APIs, base-image refreshes, vulnerable packages, pipeline warnings and framework upgrades are not side work. They are continuing changes to the production system.

Dependabot, for example, raises automated pull requests to keep dependencies updated, including dependencies with known vulnerabilities [9]. AI agents can increasingly help interpret, implement and test this kind of remediation work, but that does not make maintenance safe by default.

A dependency update may be routine. It may also alter runtime behaviour, break compatibility, change transitive dependencies or affect deployment. AI-assisted maintenance must therefore sit inside the same delivery model as any other change. The organisation still needs to know what initiated the change, which systems are affected, what test evidence is required, what risk is accepted and what production signals will confirm that behaviour remains correct.

Maintenance is not separate from delivery. It is delivery under a different trigger.

Existing structures cannot simply be renamed

Tools alone will not create this environment.

A serious AI-enabled delivery model cannot be built by pushing existing titles into a new diagram. The organisation has to start with the flow of change and ask what capabilities are required at each stage.

Some existing roles may remain. Some may need to change. Some may need clearer authority. Some may become less central. Some technical roles may need to move closer to business decision-making. Some coordination roles may need to become more evidence-focused.

The structure should follow the work.

The organisation needs people who can interpret business intent, shape scope, assess impact, supervise agentic implementation, judge test evidence, manage deployment readiness, govern release risk, read production feedback and improve the delivery system.

Existing titles may provide some of that capability. Business analysts, product owners, architects, engineers, testers, platform engineers, security specialists, operations teams, release managers and delivery managers may all have a place. But the title is secondary. The capability is primary.

This is where the organisational design either supports the new delivery model or quietly defeats it.

If the organisation’s structure loses context today, AI will not automatically fix it. If knowledge appears late in the process today, AI may simply make the wrong work move faster. If sign-off is treated as a ceremony rather than an evidence decision, AI may produce better paperwork without producing better delivery.

AI-enabled delivery requires a more deliberate structure around the flow of change.

The AI delivery capability

There is also a new internal capability to build.

This should not be a remote AI bureaucracy. It should not be a committee that approves every prompt or slows teams down. But neither can AI-enabled delivery be left to scattered experiments.

The organisation needs people who understand both AI and software delivery well enough to create cohesion.

This capability should understand model selection, agent configuration, repository instructions, prompt patterns, tool integration, data boundaries, security controls, evidence requirements, testing expectations, deployment constraints, observability feedback and governance.

Its job is not to own every AI-assisted task. Its job is to make sure the organisation’s use of AI adds up to a better delivery system.

This is similar to the way cybersecurity became a discipline, but the purpose is not only protection. The purpose is delivery improvement: faster, safer and better systems change.

Without this capability, fragmentation is likely. Developers use one assistant. Analysts use another. Testers use a separate automation tool. Operations adopts an observability assistant. A platform team experiments with infrastructure generation. Each team may gain something locally, but the organisation may still fail to improve the full delivery cycle.

The promise of AI is not isolated acceleration. The promise is a better delivery system.

The first practical step

For an organisation that wants to improve but does not know where to begin, the temptation is to start with tooling. That is understandable. Products are visible. Licences can be purchased. Pilots can be announced. Teams can be given access to assistants and asked to experiment.

But that is not the best first step.

The first step is to draw the delivery cycle as it actually works today. Not the version described in a process document. Not the version used in executive slides. The real one.

A useful way to begin is to follow one recent change from the moment it was requested to the point it reached production. The aim is not to audit people. It is to see how the organisation actually moves change.

Where did the request begin? Who clarified it? How was scope agreed? Where was the design decision recorded? Who assessed impact? How did the work reach engineering? How were tests derived? How was release evidence assembled? How was production success confirmed?

This exercise is often uncomfortable because it exposes the informal structure underneath the formal one. It shows where work depends on memory, personal networks, late intervention, manual reconciliation and undocumented judgement. It also shows where the organisation already has good practices that AI could strengthen.

The purpose is not to embarrass teams. Most fragmentation is inherited, not deliberate. The purpose is to find the places where AI can genuinely improve delivery rather than merely add activity.

If initiation is weak, the organisation should start by improving the change brief. AI can help turn scattered input into a structured statement of business intent, but the organisation still needs a business owner to confirm that the statement is correct.

If scoping is weak, AI can be used to challenge ambiguity before it becomes rework. A good assistant can compare the proposed change with previous work, known dependencies and unresolved questions, but a human owner must still decide what is in scope and what is not.

If impact analysis is weak, AI should be connected to the sources that explain the estate: architecture records, repositories, interface catalogues, data definitions, batch schedules, incidents and operational runbooks. The aim is not to let AI make architecture decisions. The aim is to make sure expert decision-makers see the likely impact early enough.

If testing is weak, AI can help trace tests back to the business outcome. The question is not only whether the changed code passes. The question is whether the intended behaviour has been proved.

If release is slow or bureaucratic, AI can assemble evidence rather than produce more status updates. A release decision should consume the evidence created through delivery, not rely on people manually reconstructing the story at the end.

If operations is disconnected from delivery, observability should be linked back to the original change. A successful release is not simply one that deploys cleanly. It is one whose production behaviour matches the intended business outcome.

This is how AI adoption becomes practical. The organisation does not need to solve the whole delivery cycle at once. It needs to start where context is currently lost, evidence is weak, or human effort is spent translating between disconnected stages.

That keeps the effort grounded. It also prevents AI from becoming theatre.

A useful test for every proposed AI use case is simple:

Does this help the organisation move a real change from business trigger to safe production outcome with less delay, less rework, better evidence or clearer accountability?

If the answer is no, it may still be interesting, but it is not central to delivery improvement.

What leaders should ask now

For executives and senior technology leaders, the management conversation needs to move beyond adoption counts.

Knowing how many developers have access to AI is useful, but it says little about whether the organisation is becoming better at delivery. A high adoption number may indicate enthusiasm. It may also indicate uncontrolled experimentation. The better test is whether AI is improving the organisation’s ability to move real change through the system.

That means looking at the delivery cycle as a whole. Is business intent captured clearly enough? Is scope challenged early enough? Is impact analysis reliable? Are implementation agents working inside known constraints? Do tests prove business outcomes? Is release evidence available without manual reconstruction? Does production feedback improve future delivery?

These are not abstract governance questions. They are the questions that determine whether AI produces delivery improvement or merely AI activity.

AI theatre is easy to create. A team can demonstrate generated code. A tool can summarise tickets. A pilot can produce a promising productivity number. A presentation can show an impressive workflow. None of that proves the organisation is better at turning change into production outcomes.

The real measure is harder and more important. Can a business change move through the delivery system faster without losing control? Can the organisation reduce rework, surface risk earlier, produce better evidence, learn from production faster and improve the next change because of what happened in the last one?

That is the promise worth pursuing.

Conclusion

AI will not transform software delivery simply because developers have better assistants.

That may improve individual productivity, but the larger prize is faster, safer business change.

To reach that prize, organisations need to design delivery as an architecture of change. They need to understand how work moves from business trigger to production outcome, where meaning is lost, who is accountable, what evidence is produced and how production feedback improves the next change.

Only then do products make sense.

The first step is not to choose a tool. It is to draw the delivery cycle, expose the handoffs, define the evidence and introduce AI where it strengthens the flow of change.

Faster code is useful.

Faster, safer business change is the real measure of IT capability.

References

[1] GitHub, 2026, About GitHub Copilot cloud agent.

https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent

[2] GitLab, 2026, GitLab Announces the General Availability of GitLab Duo Agent Platform.

https://about.gitlab.com/press/releases/2026-01-15-gitlab-announces-duo-agent-platform-general-availability/

[3] Atlassian, 2026, Rovo Dev | Agentic AI for software teams.

https://www.atlassian.com/software/rovo-dev

[4] JetBrains, 2026, Getting started with Junie.

https://junie.jetbrains.com/docs/

[5] GitHub, 2026, Best practices for using GitHub Copilot to work on tasks.

https://docs.github.com/copilot/how-tos/agents/copilot-coding-agent/best-practices-for-using-copilot-to-work-on-tasks

[6] GitHub, 2026, Adding repository custom instructions for GitHub Copilot.

https://docs.github.com/copilot/customizing-copilot/adding-custom-instructions-for-github-copilot

[7] HashiCorp, 2026, Terraform MCP server overview.

https://developer.hashicorp.com/terraform/mcp-server

[8] OpenTelemetry, 2025, Documentation.

https://opentelemetry.io/docs/

[9] GitHub, 2026, Dependabot version updates.

https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-version-updates

Before moving further into infrastructure, architecture, simplification and the shape of an AI-enabled delivery platform, it is worth pausing.

The previous articles in this series have looked at how AI changes software delivery: from coding assistance, to existing-system change, to planning, requirements, testing, release evidence and governance. The direction of travel is clear. AI is no longer only a tool used occasionally by developers. It is becoming part of the delivery system itself.

That creates a different question.

What happens when an organisation begins to depend on AI not just to write code, but to help understand requirements, shape designs, create tests, review changes, prepare documentation, support release decisions and explain technical work?

At that point the risk is no longer only that AI may produce a poor answer. That risk matters, but it is not the whole problem. The larger issue is dependency. An organisation may reduce its dependence on individual developers, analysts or testers, while increasing its dependence on models, agents, prompts, vendor tools, orchestration layers and generated artefacts that it does not fully understand or control.

That is not automatically wrong. Modern IT already depends on operating systems, cloud platforms, databases, compilers, development tools, security products, managed services and specialist suppliers. Dependency is not new.

The question is whether the dependency is visible, understood, controlled and recoverable.

The central principle of this article is simple:

The more AI produces, the more the organisation must understand.

The dependency starts before code

Many people still talk about AI in software development as if the subject is mainly coding assistance. That is too narrow. Coding agents are important, but the deeper change is that AI can now influence how problems are understood before code is written.

One of the most valuable uses of AI is discovering that a problem is not ready to be coded. Given incomplete requirements, AI can help test whether the supplied information is coherent, identify missing assumptions, propose questions, explore failure scenarios and challenge whether the current description is sufficient.

That is not simply Copilot-style code completion. It is analytical support for understanding the work.

This matters because many software problems enter delivery in poor condition. A need is raised. It is converted into a story. An analyst may speak separately to several developers. Each developer answers from their own part of the system. The resulting requirement may look complete, but it may only be a collection of partial views.

When a senior engineer eventually reviews it, the weakness is obvious. The requirement has been assembled rather than understood.

AI can make that better or worse.

If AI is used by someone with strong technical judgement, it can expose gaps, test assumptions, compare solution options and improve the requirement before work begins. If AI is used by someone who only partially understands the problem, it may produce a polished but suboptimal answer. The output may look coherent because the language is clear, but the reasoning may still be shallow.

This is one of the uncomfortable truths about AI-enabled delivery. AI does not remove the value of expertise. It amplifies the quality of the person directing it.

AI can raise the floor, but expertise still sets the ceiling.

AI can make weak process look stronger than it is

Many organisations already have delivery processes that fragment understanding. A business problem is translated into a requirement, broken into stories, discussed across meetings, moved through workflow states and eventually handed to developers for implementation. The process may produce visible artefacts, but visibility is not the same as understanding.

This is where AI can be dangerous if used badly.

The weakest use of AI is to produce better-looking stories, summaries, plans and acceptance criteria from poor understanding. The strongest use is to expose where understanding is missing.

Used well, AI can challenge a weak chain of interpretation. It can ask what assumptions are being made, what happens if a step fails, which downstream systems are affected, which users or operational teams are impacted, what evidence would prove the change works, which parts of the requirement remain ambiguous, and what technical constraints have not been considered. Used badly, AI can decorate the same weak process with better language.

The risk is not only that AI produces poor work. The risk is that AI makes poorly understood work look complete.

Dependency without understanding is fragility

Traditional key-person risk is easy to understand. An organisation becomes dependent on a developer, architect, database administrator or release manager who knows the fragile integrations, undocumented decisions, operational workarounds and historical scars. If that person leaves, the organisation discovers that it had capability, but not resilience.

AI can create a similar problem in a more abstract form.

The organisation may reduce dependence on a particular person, but become dependent on an agentic process that creates designs, code, tests, documentation and release evidence. If the organisation cannot explain, reproduce, inspect or challenge that process, it has not eliminated dependency. It has moved it somewhere harder to see.

This resembles earlier waves of outsourcing. Many organisations outsourced technical capability because it appeared cheaper, faster or easier to manage. Over time, some discovered that they had also outsourced institutional memory, product knowledge and engineering judgement. They retained ownership of systems, but lost the ability to challenge suppliers, estimate work properly or understand the consequences of technical change.

AI creates a similar risk, but the dependency is stranger. It may sit across models, prompts, context stores, tool integrations, embeddings, vendor settings, agent frameworks and generated documentation. There may be no single person to question. The organisation owns the outcome, but may not fully understand the mechanism that produced it.

Reducing dependence on human developers does not automatically reduce organisational risk. It may simply transfer that dependency to an abstract system whose behaviour, constraints and failure modes the organisation does not fully understand.

A system is not resilient if the only thing that understands it is no longer a person.

Accountability requires authority, not just approval

The accountability question is unavoidable.

If an AI agent helps interpret the requirement, writes the code, generates the tests, prepares the release evidence and recommends deployment, who is responsible when the result fails?

The answer cannot be “the AI”. AI can act, recommend and produce evidence, but it cannot own consequences in the organisational sense. Responsibility remains with people and institutions: executives, product owners, engineering leaders, architects, risk owners, release authorities and suppliers.

But accountability is weak if the accountable person cannot understand, challenge or override the system they are approving.

A human “in the loop” is not enough if the human lacks the expertise, time or evidence to make a meaningful judgement. A nominal approval may only create the appearance of control. The organisation must preserve the ability to understand what was done, why it was done, what evidence supports it, what risks remain and how to recover if the AI-assisted path fails.

This has structural consequences.

If AI becomes central to delivery, the people who understand systems, models, architecture, testing, risk and operational failure cannot remain merely advisory. They need authority in tool selection, adoption standards, delivery governance and go-live decisions.

Otherwise the organisation creates a familiar failure pattern: senior leaders own the strategy, process managers own the workflow, and technical experts are consulted only after the consequences appear.

Executives do not need to become AI researchers or hands-on developers. But they do need to understand what capability they are buying, what dependency they are creating, what risks are changing and what internal knowledge must be preserved. If technical expertise is where the understanding sits, then technical expertise must also sit close to power.

Accountability without understanding is theatre. Accountability without authority is worse.

Do not repeat the agile mistake

The industry has been here before.

Agile is a real discipline. Done properly, it involves product thinking, prioritisation, feedback loops, delivery flow, technical discipline, team dynamics and organisational change. It is a specialised area, just as operations, cybersecurity or architecture are specialised areas.

But many organisations adopted the surface of agile before they understood the discipline behind it. Executives demanded speed, disruption and agility. The operating model became ceremonies, boards, roles, statuses, velocity, reporting and workflow management. In many places, the vocabulary arrived faster than the understanding.

AI could follow the same path, with higher stakes.

The AI version of ceremony without discipline will not be daily stand-ups and velocity charts. It will be agent pilots, productivity dashboards, Copilot adoption targets, AI-generated stories, AI-written summaries and automated evidence packs, all sitting on top of the same weak understanding of systems, risk and accountability.

The language will change. The operating weakness may not.

This matters because AI does not merely organise the work. It can produce the work, interpret the work and influence decisions about the work.

AI makes it harder to pretend that managing the workflow is the same as governing the work.

Review becomes more important, not less

As AI produces more delivery artefacts, review becomes more important.

This may sound counterintuitive. If AI writes code, generates tests, produces documentation and prepares risk assessments, some organisations may assume review effort should reduce. In reality, review becomes one of the main controls.

Review is where AI output becomes organisational accountability.

That review cannot be a superficial approval step. It requires engineers, architects, testers, security specialists, operations people and technical leaders who can investigate, challenge and validate. They need to ask whether the AI understood the problem, which context it used, what context it missed, which assumptions it made, what evidence supports the output and what remains unresolved.

The future IT leader does not need to out-code the AI. But they must be able to interrogate the AI-enabled delivery system.

This is where resource management has to change. If an organisation reduces engineering capability and retains mainly process coordination, it may keep visibility while losing understanding. It may know what status the work is in, but not whether the work is any good.

A delivery organisation that keeps the ceremony but loses the technical judgement will be badly exposed in the age of AI agents.

AI is becoming its own discipline

AI should not be treated merely as a developer productivity tool or a procurement category. It is becoming a distinct discipline within IT, and in many organisations it will reach beyond IT into the wider business.

The cybersecurity analogy is useful. Organisations do not usually allow generalist managers to define cybersecurity strategy without specialist input. The reason is obvious. Cyber risk is technical, fast-moving and difficult to judge from the outside. Buying security tools is not the same as understanding cybersecurity.

AI is moving in the same direction. It changes how work is produced, reviewed, explained and governed. It introduces model dependency, vendor dependency, data exposure, intellectual-property risk, accountability questions and workforce implications. It requires specialist knowledge, standards, controls, education, vendor assessment, assurance and executive accountability.

This does not mean every organisation needs a large AI department. It means serious organisations need a recognised AI capability. That might be a Head of AI, an AI centre of excellence or a strategic AI function that sits across technology, risk, operations and the business.

Its role should not be to own every AI use case. Its role should be to guide adoption, assess tools, define standards, challenge vendors, educate staff, support pilots, understand limitations and ensure the organisation does not lose control of its own systems.

If AI becomes a dependency, AI capability must become a discipline.

AI adoption cannot be left to local enthusiasm

Many organisations are already seeing AI adoption emerge informally. A team manager wants Copilot. A development team experiments with agents. An analyst uses AI to test requirements. A release manager uses AI to prepare evidence. Developers may already have personal licences for Claude, ChatGPT, Copilot or other tools, and may be asking whether they are allowed to use them for work.

That question should not be an informal corridor conversation in a serious technology organisation. It should be answered by an AI adoption framework that defines approved tools, permitted use cases, data controls, review obligations, risk thresholds and escalation paths.

The problem is not that teams want to experiment. They should. Useful AI use cases often emerge from people close to the work. The problem is fragmented adoption without due diligence. If each team chooses its own tools, standards and rules, the organisation may gain pockets of productivity while creating unmanaged dependency, inconsistent controls and unclear accountability.

No serious organisation would allow each team to invent its own cybersecurity mechanisms, choose its own controls and define its own risk appetite. AI adoption should be treated with similar seriousness.

The answer is not heavy central bureaucracy. Senior managers issuing arbitrary restrictions without understanding the tools are no better than unmanaged local enthusiasm. Good AI governance should enable adoption, not suffocate it.

The organisation needs enough central discipline to understand and manage AI risk, and enough local freedom for teams to discover where AI actually adds value.

AI should be locally useful, but strategically governed.

Risk is managed by design, not by warning

A common organisational mistake is to manage risk through slogans. With AI, that often appears as vague warnings: be careful what data you put into AI, do not expose sensitive information, always check the output, use approved tools.

Some of those warnings may be directionally sensible, but warnings are not controls.

Telling staff to be careful with AI is like leaving matches on a table with children around and saying, “Do not burn the house down.” It is not risk management. It is a warning. If something goes wrong, the organisation can point to the warning and say people should have known better.

That creates the conditions for blame, not control.

Mature risk management reduces the likelihood of an incident. It does not rely on a sign on the wall and then criticise people when the predictable failure happens.

AI risk should be managed through product selection, licensing, configuration, access management, logging, retention rules, data controls, training, review obligations and clear prohibited use cases. The organisation needs to know which products are being used, what licence terms apply, whether prompts and outputs are retained, whether organisational data is used for training, where data is processed, what security controls exist and what configuration options are available.

A personal AI licence creates a different risk again. A developer using a personal account may believe they are helping the organisation, but they may be exposing company code, logs, requirements, architecture notes or customer-related information through a channel the organisation does not control. They may also be using the product outside the intended licence terms or without the enterprise protections available under an organisational agreement.

The risk is not only data leakage. It is loss of auditability, unclear ownership of outputs, unmanaged IP exposure and dependency on an individual’s private tooling.

Shadow AI is often a symptom of governance failure. If useful tools are not provided, rules are unclear and approvals are slow or uninformed, people will find their own path. The answer is not simply to blame them. The answer is to design a controlled path that meets the practical need.

Make safe use easy and unsafe use hard.

Directives are not controls

The same distinction applies beyond AI.

Organisations often confuse issuing a directive with implementing a control. A security mechanism may be mandated because it is believed to be more secure, but if the real operating environment still permits or requires fallback paths, then the control must be assessed as it actually operates, not as management imagines it operates.

If a login mechanism is mandated but devices still require username and password after restart, and applications intermittently fall back to another authentication path, then the control environment is more complicated than the directive suggests. The problem is not necessarily that fallback exists. Fallbacks often need to exist. The problem is treating fallback behaviour as user non-compliance when the system itself is not enforcing the intended control reliably.

That lesson applies directly to AI.

An organisation can declare that only approved AI tools may be used, that sensitive data must not be entered, or that AI output must always be reviewed. Those statements may be sensible, but they are not controls unless the organisation has created the mechanisms to make them real.

You do not manage risk by declaring the desired behaviour. You manage risk by designing the environment so the desired behaviour is the normal path.

If the system allows the behaviour, the process depends on the behaviour, and the organisation has not engineered a better path, blaming the user is not risk management.

Single-AI dependency is a supply-chain risk

AI dependency is also a supply-chain issue. An organisation may become dependent on a specific AI provider, model version, agent framework, IDE, API, pricing model, safety policy, context mechanism, tool integration or permission model.

Any of these can change. A provider can alter guardrails. A model can be upgraded and behave differently. A feature can be deprecated. Pricing can change. A security policy can restrict a workflow that previously worked. A new model version may be better in general but worse for the organisation’s specific codebase, testing style or release process. A hosted agent may become unavailable at the wrong time.

Model upgrades are not automatically risk-free improvements. They are changes to part of the delivery system.

The organisation therefore needs resilience across AI capability itself. It should not depend on one AI system as the only interpreter of another AI’s work. For important changes, one agent may implement and another may review. Different models may be used to challenge high-risk outputs. Prompts, specifications, tests and artefacts should be retained in forms that another tool or human can inspect.

Trust in AI-enabled delivery should not depend on a single model, vendor or agent. AI-generated work should be understandable by humans and challengeable by independent tools.

Every critical AI-assisted process needs a fallback path

The more valuable AI becomes, the more important it is to design for life without it. That sounds paradoxical, but it is basic resilience.

If an AI agent fails, changes behaviour, becomes unavailable or produces questionable output, the organisation should slow down, not become blind. Critical delivery processes need fallback paths. That includes requirements analysis, design review, code generation, testing, release evidence, deployment support and incident response.

Fallback does not always mean returning entirely to manual work. It may mean using another model, independent review, human-readable artefacts, retained specifications, source-controlled prompts, reproducible pipelines, standard tests, manual approvals or alternative vendor tooling. The point is that the organisation should not be trapped.

A serious AI risk strategy should include model and version awareness, controlled rollout of new AI versions, regression testing of agent behaviour on representative tasks, source-controlled instructions, audit trails, permission boundaries, independent review, manual override, kill switches and exit options from a single vendor.

The issue is not whether organisations should depend on AI. They will. The issue is whether that dependency is visible, controlled and recoverable.

Conclusion

This article is not an argument against AI adoption. The opposite is true. AI will become increasingly important to software delivery, and organisations that ignore it will fall behind.

But adoption without understanding is not maturity. It is exposure.

AI changes the risk profile of software delivery because it can influence how work is understood, built, reviewed, tested, documented and released. That makes it more than a productivity tool. It makes it part of the delivery system.

That is why this risk view matters before the series moves further into infrastructure, simplification, target operating models and practical delivery platforms. The next stage of AI-enabled delivery is not simply more tooling. It is design.

Before an organisation redesigns its infrastructure, simplifies its stack or builds an AI-enabled delivery platform, it must understand the dependencies it is creating. Otherwise it may automate faster than it can govern, and depend on systems it cannot explain.

The more AI produces, the more the organisation must understand.

Software delivery has always had an uneasy relationship with the word “release”. In some organisations, a release is a carefully planned business event involving several teams, testing evidence, operational readiness, customer impact, risk acceptance and sometimes regulatory consideration. In others, a release is a small change moving automatically through a deployment pipeline after the required checks have passed.

Both models are legitimate, but they are not the same model. That distinction becomes more important as AI agents move further into software delivery. If AI can help write code, review code, generate tests, update documentation and create deployment pipelines, the natural question is what happens next. Does the change simply flow into production because the pipeline is green, or does the organisation need a broader model of go-live readiness?

This article is a point-in-time view as at July 2026. Coding agents are real, review agents are improving, agentic testing is emerging, and delivery platforms already provide stages, approvals, environment controls and progressive deployment patterns. What does not yet appear to exist as a mature, complete product is an agentic release-governance layer that understands the full complexity of a release and can assess whether the evidence supports go-live.

That gap is the subject of this article. The risk is that organisations will mistake AI-assisted workflow automation for release intelligence. Many current AI features can summarise tickets, draft implementation plans, populate change records or route approvals. That may save time, but it does not necessarily improve the decision to release. A release is not a ticket. It is a temporary system of change, risk, evidence and decision-making.

The better opportunity is to use AI to re-examine release governance itself. Before asking AI to automate an existing process, organisations should ask whether that process produces meaningful evidence, whether it improves go-live decisions, and what a better readiness model might look like.

CI/CD is not release governance

Continuous integration and continuous delivery improved software engineering by making build, test and deployment activity repeatable. They reduced manual effort, shortened feedback loops and made it easier to prove that software can move through a defined technical path. That remains a major step forward.

But CI/CD is not the same as release governance. A pipeline can prove that code compiled, tests ran, artefacts were produced, scans completed and deployment steps executed. It may enforce approvals and environment controls. Azure DevOps supports approvals and checks for protected resources such as environments, while GitHub Actions supports environments and deployment protection rules [1] [2]. These are useful execution controls, but they are not release intelligence by themselves.

Automated pipelines have also run regression tests for years. If the regression suite fails, the pipeline stops and does not promote the release to the next environment. That is valuable, but it has nothing inherently to do with AI. A passing regression suite usually means that behaviours already captured by existing tests have not obviously broken. It does not prove that the new requirement is correct, that untested business journeys are safe, that downstream data impacts are understood, that operational monitoring is ready, or that the release should be exposed to production.

AI adds little value when it merely automates what the pipeline already does. It adds value when it asks whether what the pipeline proves is enough. Agentic UAT, discussed later, is different from simply rerunning a regression suite. Its purpose is to create evidence for the release being promoted: business journeys, exception paths, downstream effects and operational signals that the existing pipeline may not already cover.

The real question is not whether the pipeline can deploy. The harder question is whether the release is safe to expose to users, customers, business processes and dependent systems. That requires a broader view of what changed, which systems are affected, which business journeys could fail, what data is touched, what previous incidents are relevant, what obligations apply, whether monitoring is ready, whether rollback is credible and whether unresolved risks require accountable human judgement.

A green pipeline may be necessary. It is not sufficient.

Where AI improves the release decision

The question should not be whether AI can be inserted into every step of the release process. Many steps are already automated and do not become more valuable simply because AI is attached to them. Pipelines already build, test, package and deploy. Change-management systems already record approvals. Monitoring tools already collect telemetry. Those capabilities remain useful, but they are not new simply because an AI agent can describe them.

AI improves release governance when it improves the quality of the release decision. It can examine whether existing evidence is sufficient for the change being promoted. It can identify missing evidence, generate or recommend additional acceptance journeys, connect information across tools, learn from past incidents, challenge inherited controls and produce a decision-quality assessment.

That assessment should be more precise than “ready” or “not ready”. A useful release model needs a small set of outcomes that can be applied consistently:

Proceed: the evidence supports go-live.

Hold: a decision, dependency, approval or external condition is unresolved.

Return: the release needs more implementation, testing, environment preparation or requirement clarification.

Escalate: residual risk requires accountable human judgement.

Rollback: production evidence no longer supports continued exposure.

That taxonomy is important because it stops AI becoming a vague confidence generator. A release agent should not merely produce a polished paragraph saying the release appears low risk. It should explain which evidence was checked, which criteria passed, which criteria failed, what remains unresolved and why the recommended outcome is proceed, hold, return, escalate or rollback.

This is also where AI differs from ordinary automation. A deployment gate can stop a release because a test failed. AI can ask whether the tests that passed were the right tests for the risk being taken. A monitoring dashboard can show an increase in errors after deployment. AI can compare that signal with the release scope, recent incidents, expected behaviour, rollout stage and rollback policy.

Before agentic release, define readiness

An AI release agent cannot reliably decide whether a release is ready unless the organisation has defined what readiness means. This sounds obvious, but it is where many organisations will struggle. Much of release governance is still based on inherited forms, tribal judgement, tool workflows and phrases such as “business sign-off”, “testing complete”, “rollback plan attached” or “approved for release”.

Those phrases may be useful, but they are not enough for an agentic control model. AI needs to know what evidence it must inspect, which criteria are mandatory, which thresholds determine pass or fail, which exceptions require escalation, and which risks can only be accepted by accountable humans.

Go-live readiness should therefore become an explicit contract between delivery, operations, security, risk and the business. For a low-risk CI/CD product release, that contract may be mostly technical and policy-driven. For a major regulated release, it may include formal business readiness, operational acceptance, customer impact, supplier coordination, regulatory considerations and executive accountability.

The readiness model does not need to be perfect at the beginning. It should improve over time as releases expose weak evidence, false positives, unnecessary checks, missing controls and risks that were not anticipated. But there must be a starting model. You cannot refine a governance model that was never defined.

AI can help build that model before it is asked to operate within it. It can analyse change records, risk registers, release packs, deployment histories, incident reports, post-implementation reviews, test results, rollback records, monitoring gaps and operational handover notes. It can look for patterns that humans may have normalised. Perhaps releases rarely fail because code does not compile, but because test data is unrealistic. Perhaps rollback plans exist but are not tested. Perhaps the same dependency causes repeated delay. Perhaps production incidents reveal that monitoring was added after go-live rather than verified before deployment.

This is not automation. It is examination. AI should first be used as an expert challenger, not merely as a workflow engine. The organisation should not begin by saying, “Here is our change process, automate it.” It should say, “Here is how we deliver change, here is where releases have failed, here is the evidence we collect, here are the risks we record, and here are the obligations we operate under. Tell us what this process proves, what it misses and what a stronger release-readiness model would look like.”

AI brings the external expertise. The organisation brings the local truth.

Two release paths in practice

The first mistake in discussing AI and release governance is to assume that every release should follow the same path. A small change to a low-risk internal service is not the same as a major change affecting payments, insurance claims, customer onboarding, pricing, financial reporting, customer data or regulatory disclosure.

For a product genuinely suited to CI/CD, the organisation may want an automated path from accepted work item to production. That does not mean uncontrolled deployment. It means the product has been designed so that changes are small, independently deployable, testable, observable and reversible.

In that model, a development agent implements the change from a defined requirement or specification. It links the change to the requirement, records assumptions, updates unit tests and produces an implementation summary. A DevOps or release-engineering agent may then create or update the pipeline. It can define build steps, dependency restore, static analysis, unit tests, integration tests, container build, security scanning, artefact publishing, environment deployment, rollback steps and post-deployment verification.

That sounds powerful, but it is still not the full release decision. If AI builds the deployment pipeline and automatically adds regression tests, it has improved the delivery path. It has not proved that the release is ready. The pipeline proves that a defined sequence of technical checks has run. The regression suite proves that behaviours already captured by tests have not obviously broken. Neither proves that the new feature meets business intent, that exceptions have been explored, that downstream impacts are understood, or that operational monitoring is ready.

The next stage is where agentic UAT becomes useful. UAT should not be treated as a human clicking exercise pasted onto the end of an automated pipeline. In an agentic model, UAT becomes a structured evidence layer. The AI runs agreed business journeys. For an appointment system, it might create a customer, search for availability, book an appointment, change the appointment, cancel it, verify notifications, inspect the audit trail, test external service failure, check recovery behaviour and reconcile downstream records.

The agent records what it did. It captures expected results, actual results, exceptions, logs, traces, screenshots where appropriate, data created, systems touched and defects raised. It then produces a release-readiness report against the agreed model. That report should not simply say that tests passed. It should explain whether the evidence supports go-live, whether the release should hold, whether it must return to development or testing, or whether residual risk should be escalated.

For some CI/CD products, machine QA may be enough. For others, a human QA or release manager may review the AI evidence pack. The point is not to have humans rediscover the evidence manually. The point is to let humans judge whether the evidence is sufficient and whether any remaining risk should be accepted.

Production deployment then uses an appropriate exposure strategy. A standard deployment may be acceptable for some systems. Blue-green deployment may be better where the new version can be prepared beside the current live version before traffic is switched. Canary release may be better where a small percentage of traffic can be exposed first. Feature flags may allow the code to deploy while functionality is enabled gradually. Argo Rollouts supports progressive delivery patterns such as blue-green and canary deployment for Kubernetes, while LaunchDarkly guarded rollouts can progressively increase traffic and pause if regressions are detected [12] [13] [14].

After deployment, the agent runs production verification. It checks synthetic transactions, telemetry, error rates, performance, business events, logs, alerts and customer-impact indicators. If production behaviour contradicts the readiness report, the system should stop exposure, rollback or escalate. Go-live is not the end of release governance. It is the beginning of production evidence.

A planned release follows a different path. It may involve several teams, multiple systems, business readiness, supplier coordination, data migration, operational training, release windows, communication plans and formal approval. In banking, insurance, superannuation, healthcare, utilities and government, some releases may also carry external obligations. A significant change in a regulated financial institution may require evidence of risk assessment, operational readiness and, in some cases, notification to a regulator before go-live.

AI does not remove those obligations. It changes how evidence can be gathered, assessed and presented. For a planned release, AI can prepare a release evidence pack from delivery records, test outcomes, security scans, operational readiness, risk registers, dependency maps, incident history, monitoring readiness and rollback plans. It can identify missing evidence, inconsistent claims, unresolved risks and previous incidents that resemble the current release.

A governance forum may still be required. The forum may be called a CAB, a release board, a go-live committee or something else. The name is less important than the function. Its purpose should be to decide whether the evidence supports release, whether residual risk is acceptable, whether timing is appropriate and whether the right people are accountable. AI can make that conversation sharper by giving the group decision-quality evidence rather than asking it to rediscover evidence manually.

Can AI release without intervention?

The most difficult question is not whether AI can press the deploy button. Technically, that is the easy part. The harder question is whether AI can be authorised to decide that the release evidence is sufficient.

The answer depends on the release class. For low-risk, well-contained CI/CD changes, AI may eventually be responsible for release without human intervention, provided the organisation has defined the rules in advance. The agent must know the required tests, acceptance criteria, monitoring thresholds, rollback conditions and escalation triggers. The release must be observable, reversible and small enough for autonomous policy to be credible.

For medium-risk releases, AI may prepare the evidence and recommend go-live, but a human or QA function may still approve the decision. The human is not manually checking every detail. They are reviewing the AI’s evidence pack, exception report and residual-risk assessment.

For high-risk, regulated, multi-system or customer-impacting releases, AI should not be the sole release authority. It can do a great deal of the work: evidence collection, incident comparison, test-gap identification, readiness scoring, exception reporting, documentation and risk assessment. But final accountability remains human.

Autonomous deployment is not the same as autonomous release responsibility. The more reversible, observable and low-risk the release, the more autonomy AI can safely have. The more irreversible, regulated, customer-impacting or system-wide the release, the more AI should act as an evidence and judgement-support layer rather than the final authority.

AI-generated release evidence should follow the same discipline as AI-generated code. It can produce scope summaries, test evidence, deployment notes, rollback plans, UAT results, exception reports, operational-readiness checks and risk assessments. That is useful, but the output must be reviewed, challenged and linked back to evidence.

The purpose is not to create better-looking paperwork. The purpose is to create decision-quality evidence for go-live. A release evidence pack produced by AI should explain what changed, which systems are affected, which tests ran, which acceptance journeys were exercised, which exceptions occurred, which defects were fixed, which risks remain, which controls are in place, whether rollback is credible, whether monitoring is ready and whether production verification has been defined.

The risk assessment should not be a generic paragraph. It should assess customer impact, operational impact, regulatory impact, data integrity risk, integration risk, security risk, rollback difficulty, monitoring coverage, similarity to previous failed releases, confidence in test evidence and residual risk after controls.

What exists now, and what is still missing

The current product landscape is fragmented. There are strong pieces in different parts of the release ecosystem, but the complete agentic release-governance solution is still emerging.

Coding agents are the most visible part of the market. GitHub Copilot cloud agent can research a repository, create implementation plans, fix bugs, implement incremental features, improve test coverage and update documentation [3]. GitLab Duo Agent Platform is described as embedding multiple agents throughout the software development lifecycle, including specialised agents for tasks such as refactoring, security scans and research [4]. Claude Code supports subagents and hooks, allowing specialised agents and workflow interventions around development activity [5] [6]. Kiro presents itself as an agentic AI environment that helps move from prompts to specs, code, documentation and tests [7].

Other agentic development products show the same direction of travel. A 2026 study of AI coding agents on GitHub describes agent-authored pull requests from OpenAI Codex, Devin, GitHub Copilot, Cursor and Claude Code across a large sample of repositories [8]. That does not mean these agents solve release governance, but it does show that agentic development is no longer speculative.

Review and testing tools form another part of the picture. mabl has positioned itself around agentic testing and describes coverage that can build, run and recover itself for teams shipping at the speed of AI coding agents [9]. Research into agentic testing also points toward multi-agent loops where test generation, execution, analysis and refinement operate together rather than as a single static test-generation step [10]. These tools are relevant because release governance depends on evidence, and evidence is only as strong as the testing, review and validation behind it.

Deployment and exposure controls provide the execution layer. Azure DevOps and GitHub Actions can control deployment through approvals, checks, environments and deployment protection rules [1] [2]. Argo Rollouts supports blue-green, canary, canary analysis and progressive delivery for Kubernetes [12]. LaunchDarkly guarded rollouts progressively increase traffic while monitoring selected metrics for regressions, and can pause a rollout if regression is detected [13] [14]. Harness describes AI-assisted deployment verification that detects variance in metrics and logs after deployment and can automatically roll back if a regression is found [11]. OpenTelemetry provides a vendor-neutral framework for generating, collecting and exporting telemetry such as traces, metrics and logs [15].

These products provide valuable fragments. They can help implement work, review work, test work, deploy work, limit exposure and observe production behaviour. What remains immature is the cross-cutting release-intelligence layer that understands the release as a whole.

That missing layer would connect the repository, pipeline, test results, change records, incident history, risk register, architecture knowledge, observability data and deployment controls. It would understand the release type, apply the organisation’s readiness model, assess the evidence and recommend proceed, hold, return, escalate or rollback.

Current products should not be dismissed, but they should not be oversold. AI that writes a change ticket faster is not handling release complexity. AI that generates a rollback paragraph is not proving rollback capability. AI that summarises a release pack is not deciding go-live readiness. Those features may be useful, but they are incremental.

The strategic opportunity is to assemble the available fragments around a better method. The organisation should not simply buy an AI feature inside an existing workflow product and declare release governance solved. It should understand which parts of the release ecosystem each tool covers, where the gaps remain, and what a genuine release-intelligence layer would need to do.

What a good solution would look like

A good agentic release-governance solution would not be a smarter change form. It would be a release-intelligence layer.

It would sit across the release ecosystem rather than inside one product boundary. It would connect to delivery tools, source repositories, requirements, test platforms, deployment pipelines, ITSM systems, risk registers, architecture repositories, observability platforms and production telemetry. It would understand the organisation’s release types and apply the relevant readiness model to each one.

For a CI/CD product release, it might focus on automated tests, agentic UAT, deployment policy, feature exposure, observability and rollback. For a major planned release, it might focus on scope, dependency, integration, business readiness, operational readiness, customer impact, regulatory obligations and accountable approval.

The agent would not invent governance on the fly. It would operate against an explicit model. It would know which evidence is mandatory, which exceptions are tolerable, which failures block release, which risks require escalation and which production signals require rollback.

It would also learn. After each release, it would compare expected risk with actual outcome. Incidents, near misses, failed deployments, rollbacks, customer complaints, monitoring alerts and post-implementation reviews would feed back into the readiness model. Over time, the model would become more specific to the organisation’s systems, risk appetite and operational history.

This is where AI becomes more than automation. It becomes a way to improve the method. If software delivery is becoming more agentic, release governance must become more evidence-driven. Otherwise the organisation will create software faster than it can safely release it.

Conclusion

The future of release governance is not more meetings, and it is not blind automation. It is better evidence, clearer accountability and faster escalation when the evidence does not support release.

For products suited to CI/CD, AI can help create a release path that moves from implementation to pipeline creation, development deployment, agentic UAT, readiness assessment, production deployment and post-release verification. For major planned releases, AI can help connect evidence across systems, teams, risks, dependencies and regulatory obligations so that human governance focuses on judgement rather than paperwork.

The key is to avoid the weakest use of AI: automating the existing process without asking whether the process is right. AI gives organisations a chance to challenge inherited release methods. It brings broad delivery knowledge. The organisation brings local truth. Together, they can define what go-live readiness means, what evidence is required and how release decisions should be made.

A green pipeline tells us the software moved through a technical path. It does not, by itself, tell us that the release is ready. That is the next problem AI needs to help solve.

References

[1] Microsoft, 2025, Pipeline deployment approvals.

https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops

[2] GitHub, 2026, Managing environments for deployment.

https://docs.github.com/actions/deployment/targeting-different-environments/using-environments-for-deployment

[3] GitHub, 2026, About GitHub Copilot cloud agent.

https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[4] GitLab, 2026, GitLab Duo Agent Platform.

https://docs.gitlab.com/user/duo_agent_platform/

[5] Anthropic, 2026, Create custom subagents.

https://code.claude.com/docs/en/sub-agents

[6] Anthropic, 2026, Hooks reference.

https://code.claude.com/docs/en/hooks

[7] Kiro, 2026, Kiro: Move beyond AI coding to agentic engineering.

https://kiro.dev/

[8] Li, H., Zhang, H. and Hassan, A.E., 2026, AIDev: Studying AI Coding Agents on GitHub.

https://arxiv.org/abs/2602.09185

[9] mabl, 2026, Agentic Testing for the Next Generation of Software.

https://www.mabl.com/

[10] Naqvi, S., Baqar, M. and Mohammad, N.A., 2026, The Rise of Agentic Testing: Multi-Agent Systems for Robust Software Quality Assurance.

https://arxiv.org/abs/2601.02454

[11] Harness, 2026, AI-assisted deployment verification.

https://www.harness.io/products/continuous-delivery/ai-assisted-deployment-verification

[12] Argo Project, 2026, Argo Rollouts.

https://argoproj.github.io/rollouts/

[13] LaunchDarkly, 2026, Guarded rollouts.

https://launchdarkly.com/docs/home/releases/guarded-rollouts

[14] LaunchDarkly, 2026, Creating guarded rollouts.

https://launchdarkly.com/docs/home/releases/creating-guarded-rollouts

[15] OpenTelemetry, 2025, Documentation.

https://opentelemetry.io/docs/

This is the fifth article in Software Development in the Age of AI, a series examining what AI is already changing in software delivery, what the current product landscape makes possible, and where the operating model may be heading next.

As with the earlier articles, this is a point-in-time assessment. The AI software-development market is changing quickly, and any serious discussion of tools, suppliers and operating models needs to be anchored to a date. This article reflects the state of AI-assisted and agentic software delivery as at July 2026. Some products will mature, some will be renamed, and some will disappear. The more important question is not whether every product feature remains unchanged, but whether the direction of travel is becoming clear.

The series has moved from coding assistance to agentic delivery, from greenfield development to existing systems, and from sprint-centred planning to outcome-led delivery. This article focuses on the smaller unit from which software delivery is built: the individual unit of work.

That unit may be called a story, task, issue, change request, backlog item or work item. The name varies by organisation and tool. The underlying idea is familiar. A bounded piece of work is defined, built, reviewed, tested and accepted as complete when it has been verified as doing what it was supposed to do.

AI does not make that lifecycle obsolete. It should not be used as an excuse to weaken it.

The more serious opportunity is different. AI can make the lifecycle tighter by allowing work to move through a controlled chain of specialised agents. One agent can examine whether the requirement is ready. Another can implement the change. Another can review the code. Another can test the behaviour. A QA audit agent can examine whether the evidence is sufficient. A human can then accept, reject or return the work with a concise record of what happened.

The future is not one coding agent building software unchecked. A more credible model is a chain of trust, in which independent agents challenge each other’s output before the work reaches human acceptance.

That distinction matters. AI can compress the delivery cycle, but compression without independent checks is not progress. It is risk moving faster.

The unit of work remains the control point

Large software projects are delivered through smaller changes. Even where a programme is planned around outcomes, milestones and dependencies, the work eventually has to be expressed in units that can be implemented and verified.

This is not merely an artefact of Jira, Azure Boards, Linear, GitHub Issues or any other work-management product. A unit of work creates a boundary around intent. It says what change is being requested, what behaviour is expected, what constraints apply and how the result will be judged.

A good unit of work does not need to follow one universal template. Some changes are naturally expressed as user stories. Others are clearer as business rules, interface contracts, migration requirements, security controls, operational behaviours or technical tasks. The form should fit the problem.

What matters is that the work is clear enough to build and specific enough to verify.

AI makes that discipline more important, not less. A human developer may receive an incomplete requirement and pause, ask questions or infer from experience. An agent may also ask questions, but it may just as easily proceed by making a plausible assumption. When software can be produced faster, unclear intent becomes more expensive.

The first discipline of agentic delivery is therefore not coding. It is ensuring that the unit of work is ready to enter the chain.

From human handoff to agentic flow

In a conventional delivery process, a unit of work moves through a recognised path. It is defined, developed, reviewed, tested and accepted. The exact roles vary. One team may have separate developers, testers and business owners. Another may rely heavily on automated tests and peer review. A regulated environment may require formal QA evidence and audit records.

The logic remains consistent. The work is not complete simply because someone has built something. It is complete when it has been verified as doing what it was supposed to do.

AI should preserve that logic.

The practical change is that several stages in the flow can be performed or assisted by independent agents. A requirement review agent can examine the work before development begins. An implementation agent can build the change. A developer review agent can inspect the code. A test agent can verify behaviour against the original requirement. A QA audit agent can review the evidence and publish concise findings. The human reviewer still accepts, rejects or returns the work.

The sequence becomes:

Defined → requirement reviewed → built → developer reviewed → tested → QA audited → human accepted

This is not a new definition of done. It is a more automated and better documented route towards the existing definition.

The critical design principle is independence. The agent that writes the code should not be the only judge of whether the code is sound. The agent that generates tests should not be the only judge of whether the tests prove the requirement. The chain needs separation of responsibility.

Requirement review: is the work ready?

The first agent in the flow should not write code. It should ask whether the work is ready to build.

A requirement review agent examines the unit of work for ambiguity, missing business rules, unresolved dependencies, contradictory assumptions and weak acceptance conditions. Its purpose is not to answer every business question. It usually cannot. Its value is that it can expose the questions that must be answered before implementation starts.

Consider a simple requirement:

Customers can cancel an appointment.

That is understandable, but it is not yet sufficient. A requirement review agent should ask whether all appointment types can be cancelled, whether a cancellation window applies, whether the provider must be notified, whether the appointment slot becomes available again, whether payment or refund behaviour is involved, whether repeated cancellation attempts are allowed, and what audit record must be kept.

The output should be concise:

Requirement review result: Not ready for implementation.

Reason: Cancellation window, provider notification and audit behaviour are not defined.

Required clarification: Confirm the cancellation rule by appointment type, define downstream notification behaviour and state whether the availability slot is reopened immediately.

This is where AI can improve the lifecycle before any code is produced. It can reduce the risk that implementation starts from a requirement that sounds clear only because different people have filled in the gaps differently.

Kiro is one of the clearer current examples of this direction. Its specification workflow moves through requirements, design and tasks, with approval points between the stages, and its Quick Plan mode is intended for work that is already better understood [1][2]. GitHub Spec Kit takes a related specification-driven approach, treating structured specifications as the basis for technical planning and implementation [3][4]. Linear Agent and Atlassian Rovo approach the problem from work context and organisational knowledge, helping teams act on issues, projects, Jira and Confluence context rather than beginning from a blank prompt [5][6].

The market is not settled, but the direction is visible: better agentic delivery begins before code generation.

Implementation: build within boundaries

Once the unit of work is sufficiently defined, an implementation agent can build the change.

This is currently the most mature and competitive part of the market. GitHub Copilot cloud agent, Claude Code, Cursor, Devin Desktop, Kiro, GitLab Duo Agent Platform and Rovo Dev all represent different approaches to agentic implementation, from repository-centred coding agents to integrated development environments, command-line agents and broader software-development platforms [7][8][9][10][11][12][13].

The implementation agent should not receive an open-ended instruction if the work matters. It needs boundaries: the approved requirement, the relevant parts of the codebase, architectural constraints, interfaces that must not be changed, expected tests and the evidence required for review.

A weak instruction is:

Add cancellation.

A useful instruction is:

Implement customer appointment cancellation for appointments more than 24 hours away. Preserve the appointment record, update its status to cancelled, reopen the provider availability slot, write an audit entry and trigger the existing notification interface. Do not modify the identity service or payment interface. Add tests covering valid cancellation, late cancellation rejection and repeated cancellation attempts.

The implementation agent should also be allowed to stop. If the existing codebase cannot support the requested behaviour safely, or if the requirement contradicts another rule, the correct output is not a clever workaround. It is a blocker or clarification request.

This is why agentic development should not be judged only by how much code it can produce. The better question is whether the agent can operate within a controlled boundary and return the work when the boundary is unsafe or unclear.

Developer review: is the implementation sound?

Developer review remains distinct from testing.

Testing asks whether the software behaves as required. Developer review asks whether the implementation is technically sound. That includes structure, maintainability, error handling, security, performance, duplication, naming, architectural consistency and whether the code is likely to become a burden later.

Several products are moving into this layer. GitHub Copilot code review can review pull requests and suggest changes. Qodo positions itself around pull-request review, standards enforcement and code-governance workflows. Atlassian has published work on RovoDev Code Reviewer inside its own engineering ecosystem, and GitLab Duo Agent Platform positions agents across planning, coding, security and deployment [14][15][16][11].

This does not mean agentic review is solved. Research on code-review agents suggests that automated review is promising but still incomplete, and that agents may identify different issues from human reviewers rather than simply replacing them [17]. That is an important warning. A review agent should be a control point, not theatre.

A useful developer review finding might say:

Developer review result: Return to implementation.

Reason: The appointment status update and availability reopening are performed as separate operations without a clear consistency model. A failure during the second operation could leave the appointment cancelled while the slot remains unavailable.

Required correction: Apply the status update, availability reopening and audit insert within the same transaction, or document why the existing architecture requires a different consistency approach.

This is not QA audit. It is technical peer review. A change can pass behavioural tests while still being poorly engineered. It can also be well engineered while still missing the business requirement. The controls need to remain separate.

Testing: does the behaviour match the requirement?

The test agent verifies the work against the original requirement.

That phrase matters. The test agent should not merely test what the implementation agent happened to build. It should test what the unit of work required.

Depending on the change, the test agent may generate or run unit tests, integration tests, API tests, user-interface tests, regression tests or contract tests. It may create positive cases, negative cases, boundary cases and repeated-action scenarios. It may also compare the implementation with existing behaviour to detect unexpected side effects.

For appointment cancellation, the test agent might verify that a valid cancellation succeeds, a late cancellation is rejected, repeated cancellation does not corrupt state, an audit record is created, the availability slot is reopened and a notification request is sent through the agreed interface.

The tooling here is broader than AI coding agents. Playwright supports browser automation for testing and agent workflows. Pact is a well-known consumer-driven contract testing tool for checking service interactions. Postman, Cypress, mabl, Testim, Tricentis and other testing products occupy different parts of the test automation landscape, while CI/CD platforms run these checks as part of delivery pipelines [18][19].

AI can help generate and maintain tests, but the discipline remains the same. The tests must prove something that matters. Poorly directed AI can produce tests that confirm the implementation rather than challenge it.

If the tests fail, the work returns to implementation. If the tests reveal that the requirement is still ambiguous, the work returns to requirement clarification. A strong test agent is therefore not merely a test generator. It is a verifier against intent.

QA audit: is the evidence sufficient?

The QA audit agent is the least mature part of the chain and possibly the most interesting.

Testing may show that particular checks passed. QA audit asks whether the verification is sufficient. It examines the requirement, implementation summary, developer review findings, test scenarios, test results, excluded scope and unresolved assumptions. Its question is broader:

Does the evidence show that this unit of work does what it was supposed to do?

This is not the same as code review and not the same as test execution. It is evidence review.

The audit agent should be independent of the implementation and test agents. It should be able to pass the work forward, fail it, or return it to requirements, implementation or testing.

A concise audit record might look like this:

QA audit result: Pass with observation.

Requirement reviewed: Customers may cancel appointments more than 24 hours before the scheduled time.

Evidence checked: Pull request changes, unit tests, integration tests, developer review findings and requirement trace.

Findings: Valid cancellation, late cancellation rejection and repeated cancellation attempts are covered. Appointment status, audit entry and availability reopening are verified. Notification dispatch is tested through the existing interface mock.

Observation: Refund behaviour is not tested because it is explicitly outside this unit of work.

Recommendation: Ready for human acceptance.

This record is the bridge between automated verification and human judgement. The audit agent’s job is not only to pass or fail the work. It must explain what it checked, what it found, what remains unresolved and why the work should proceed or be returned.

Current products do not yet provide this as a mature, standard category. Some capabilities can be assembled using Claude Code hooks, GitLab Duo Agent Platform, CI/CD workflows, review agents, test reports and custom prompts. Research on AI harness engineering points in a similar direction by arguing that agent systems need structured task specification, verification, observability, permissions and auditable episode records rather than just a final patch [20].

This gap matters. It may become a major platform opportunity. The next important supplier may not be the one that writes the most code. It may be the one that best converts agentic activity into evidence humans can trust.

Human acceptance remains the final control

Agentic delivery should not be confused with unsupervised delivery.

A human reviewer remains necessary where judgement, authority, accountability or business context is required. This may be a product owner, business representative, technical lead, QA lead, architect or accountable manager, depending on the nature of the change.

The purpose of the agent chain is not to remove that person. It is to make their decision better informed.

By the time the work reaches human acceptance, the reviewer should have the original requirement, the implementation summary, the developer review result, the test evidence, the QA audit findings, any unresolved assumptions and a recommendation. The reviewer can still reject the work, ask for clarification or send it back. Acceptance should not become a rubber stamp simply because an agent produced a confident summary.

Used properly, the agent chain reduces noise rather than accountability. It allows humans to spend more time on judgement and less time reconstructing what happened.

Documentation becomes part of the work

One of the weaknesses of many delivery processes is that documentation is reconstructed after the work is complete. Someone updates a ticket, writes a change summary, records test evidence or prepares release notes after the event. That creates gaps, especially when the work is complex or has moved through several hands.

An agentic lifecycle can produce documentation as the work moves through the flow.

The requirement review agent records ambiguity and readiness. The implementation agent records what changed. The developer review agent records technical findings. The test agent records scenarios and results. The QA audit agent records whether the evidence is sufficient. The human reviewer records the acceptance decision.

The aim is not to produce a large bureaucratic archive. The aim is to create concise, useful records that answer the questions a team, auditor or future maintainer will later ask.

What was requested? What changed? What was reviewed? What was tested? What evidence was checked? What remains unresolved? Who accepted the work, and on what basis?

That is documentation with a purpose.

The CI/CD connection

The unit-of-work lifecycle is only the first layer. Once a change has been accepted, it still has to move through the engineering pipeline.

Continuous integration and continuous delivery, commonly called CI/CD, are the practices and automated pipelines used to integrate code, build it, test it, package it and deploy it. These pipelines already perform a large amount of automated checking in many organisations. AI can extend that automation by creating branches, preparing pull requests, summarising changes, generating release notes, coordinating checks and assisting with scheduled releases.

The flow might be:

Accepted unit of work → feature branch → pull request → automated checks → merge decision → release candidate → scheduled deployment → post-release verification

The supplier landscape again broadens beyond coding agents. Azure DevOps, GitLab CI/CD, GitHub Actions, Harness, CircleCI and similar platforms already provide substantial delivery automation. Harness describes its platform as applying AI across DevOps, testing, application security and cost optimisation, while GitLab positions Duo Agent Platform across the software lifecycle [21][11].

The warning is important. Automation should not mean uncontrolled movement. A branch should not merge merely because an agent opened a pull request. A release should not proceed merely because a pipeline can deploy it. Required checks, review conditions, security scans, approval gates and deployment windows still matter.

AI can help move work through the pipeline. It should not erase the gates that make the pipeline safe.

System-wide verification

In a large enterprise ecosystem, an individual unit of work can be complete and still not be safe to release.

This is a crucial distinction. Unit-of-work verification proves that the change satisfies its immediate requirement. Pipeline verification proves that the code can be built, checked, merged and deployed through the approved engineering process. Neither automatically proves that the wider business and technical ecosystem still behaves correctly.

A change to appointment cancellation may pass its own tests and code review. It may still break reporting, reconciliation, notifications, provider availability, audit extraction or a downstream billing process. Enterprise systems are networks of processes, data flows, interfaces and operational dependencies. Correctness at the local level does not guarantee correctness at the system level.

That is why large ecosystems need system-wide simulated testing. These tests exercise realistic business journeys across multiple systems. They may include integration scenarios, contract tests, synthetic transactions, data reconciliation, performance checks, failure and recovery scenarios, operational monitoring and post-deployment smoke tests.

AI can help create, run and interpret these simulations. It can generate scenarios, compare downstream records, inspect logs, identify unexpected differences and summarise whether the system behaved as expected.

But the discipline is the same as before: the test must prove the relevant outcome, not merely produce evidence that looks impressive.

A story can be done locally and still not be safe globally. That is not a contradiction. It reflects the difference between completion of a unit of work and confidence in a release.

Where the market is mature, and where it is not

The current landscape is uneven.

Implementation agents are the most visible and commercially active category. Tools such as Claude Code, Cursor, Devin Desktop, GitHub Copilot, Kiro, Rovo Dev and GitLab Duo are all competing to take larger pieces of coding work.

Specification-led development is also becoming more serious, with Kiro and GitHub Spec Kit showing that the market recognises the danger of prompt-first implementation.

Developer review is emerging through products such as GitHub Copilot code review, Qodo, RovoDev Code Reviewer, GitLab Duo and other automated review tools.

Testing remains fragmented. AI can generate tests, but organisations still depend on established testing frameworks, API tools, contract testing, browser automation, data checks and CI/CD environments.

The weakest area is independent QA audit. This is the layer that asks whether the evidence actually proves the requirement and whether the work is ready for human acceptance. Today, that usually has to be assembled from custom agents, workflow rules, prompts, test reports and pipeline data.

That weakness is significant because it exposes the central issue in AI-enabled delivery. The problem is no longer simply whether an AI agent can produce code. The problem is whether the delivery system can prove that the change is correct, reviewed, tested, auditable and safe to move forward.

The emerging model

The unit of work is not disappearing. The established lifecycle remains valid: define the work, build it, review it, test it and accept it when it has been verified as doing what it was supposed to do.

AI changes how that lifecycle can operate.

It allows the work to move through a tighter chain of specialised agents. It allows each stage to produce concise evidence. It allows failed work to be returned earlier and more consistently. It allows human reviewers to see a clearer record of what was requested, what was changed, what was tested and why the work is being recommended for acceptance.

The danger is that organisations will use AI to compress the lifecycle while weakening the checks. The better direction is the opposite: use AI to make the lifecycle more independent, more traceable and more disciplined.

At the story level, that means defined, built, reviewed, tested, audited and accepted. At the pipeline level, it means controlled movement from accepted change to release. At the enterprise level, it means proving that the wider system still works through realistic simulation.

AI does not remove the need for delivery discipline. Properly designed, it can make that discipline much harder to fake.

Glossary

Agentic delivery

A delivery model in which AI agents can analyse, plan and perform multi-step work using tools, context and feedback.

CI/CD

Continuous integration and continuous delivery. The automated engineering pipeline through which code is integrated, built, tested, packaged and deployed.

Contract testing

A testing approach that verifies whether one system or service meets the expectations another system has of it.

Developer review agent

An agent that reviews implementation quality, maintainability, security, performance and architectural fit.

QA audit agent

An agent that reviews whether the evidence is sufficient to show that the work satisfies the original requirement.

System-wide simulation

Testing that exercises realistic business journeys across multiple systems, interfaces, data flows and operational behaviours.

Unit of work

A bounded piece of software change, such as a story, issue, task, change request or backlog item.

References

[1] Kiro, 2026, Specs.

https://kiro.dev/docs/specs/

[2] Kiro, 2026, Specs Just Got Faster and Smarter.

https://kiro.dev/blog/faster-smarter-specs/

[3] GitHub, 2026, Spec Kit.

https://github.com/github/spec-kit

[4] GitHub, 2026, Spec-Driven Development.

https://github.com/github/spec-kit/blob/main/spec-driven.md

[5] Linear, 2026, Linear Agent.

https://linear.app/docs/linear-agent

[6] Atlassian, 2026, Rovo: Unlock Organisational Knowledge with GenAI.

https://www.atlassian.com/software/rovo

[7] GitHub, 2026, About GitHub Copilot Cloud Agent.

https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[8] Anthropic, 2026, Claude Code Subagents.

https://code.claude.com/docs/en/sub-agents

[9] Anthropic, 2026, Claude Code Hooks.

https://code.claude.com/docs/en/hooks-guide

[10] Cursor, 2026, Cursor.

https://cursor.com/

[11] GitLab, 2026, GitLab Duo Agent Platform.

https://about.gitlab.com/gitlab-duo-agent-platform/

[12] Cognition, 2026, Devin Desktop.

https://devin.ai/desktop/

[13] Atlassian, 2026, Rovo Dev.

https://www.atlassian.com/software/rovo-dev

[14] GitHub, 2026, About GitHub Copilot Code Review.

https://docs.github.com/en/copilot/concepts/agents/code-review

[15] Qodo, 2026, The Qodo Code Review Experience.

https://docs.qodo.ai/code-review

[16] Tantithamthavorn, K. et al., 2026, RovoDev Code Reviewer: A Large-Scale Online Evaluation of LLM-based Code Review Automation at Atlassian.

https://arxiv.org/abs/2601.01129

[17] Zhang, Y. et al., 2026, Code Review Agent Benchmark.

https://arxiv.org/abs/2603.23448

[18] Microsoft Playwright, 2026, Playwright.

https://playwright.dev/

[19] Pact, 2026, Pact Docs: Introduction.

https://docs.pact.io/

[20] Zhong, H. and Zhu, S., 2026, AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents.

https://arxiv.org/abs/2605.13357

[21] Harness, 2026, AI for DevOps, Testing, AppSec, and Cost Optimisation.

https://www.harness.io/

This is the fourth article in the series Software Development in the Age of AI.

The first three articles examined how AI has already changed software development, what the product landscape looked like in July 2026, and why existing systems require tighter boundaries than greenfield work. The next question is not simply how agents write code. It is how their work should be planned.

Most software delivery methods in use today were designed around a fixed human team with limited capacity. Work is analysed, converted into stories, placed in a backlog, divided into sprints and assigned according to what the team is expected to complete within a defined period.

AI changes several of those assumptions at once.

A team of five engineers remains a team of five people, but it is no longer limited to the amount of investigation, coding, testing and documentation those five people can perform manually. Agents can examine different aspects of a problem concurrently, create tests while implementation proceeds, explore alternative designs, generate documentation and prepare infrastructure definitions.

The team still has constraints. Human attention, architecture, integration, business decisions and assurance do not disappear. But the relationship between team size and productive capacity changes substantially.

This creates a contradiction in the market.

AI can be used to automate the existing human delivery process by generating more stories, producing subtasks, updating boards and reporting sprint progress. It can also be used to question whether that process should remain the centre of software delivery.

Understanding AI’s role in planning in July 2026 therefore requires more than listing product features. It requires examining whether current products merely reproduce familiar practices or begin to establish a genuinely different operating model.

Planning is not the same as organising a sprint

A sprint is a mechanism through which a team selects and organises a limited amount of work for a short period. Scrum describes Sprint Planning in terms of the sprint’s value, the work that can be completed and how the developers intend to create the resulting increment [1].

That is useful for team execution. It is not a substitute for project planning.

A project plan must define the outcome being pursued, the deliverables required to achieve it, the dependencies between them, the decisions that must be made, the milestones that demonstrate progress, the risks that threaten delivery and the evidence that will establish completion.

A sprint can contribute to a milestone. It is not the milestone.

This distinction has become blurred across much of the technology industry. A project is represented by an epic, the epic becomes a collection of stories, and those stories are spread across sprints. Progress is then interpreted through velocity, ticket completion and movement across a board.

The team may complete hundreds of work items while a critical interface remains unresolved, an external supplier has not delivered, the migration cannot be reconciled or the complete business outcome has never been demonstrated.

The problem is not Agile itself. Nor is it the sensible practice of breaking complex work into smaller units. The problem is allowing the team’s internal method of organising work to replace project management.

That matters more once agents become part of the delivery team because their internal work can be created, changed and executed far more dynamically than a human-managed sprint backlog.

AI changes the planning constraint

Traditional sprint planning is based partly on the expected throughput of a fixed human team.

That assumption becomes less reliable when agents undertake a significant share of the production work. A developer can ask one agent to investigate an unfamiliar interface while another generates tests and a third examines existing data structures. Implementation, documentation, infrastructure and test preparation can overlap to a degree that was previously impractical.

The team has not acquired unlimited capacity. It must still direct the agents, examine their conclusions, resolve conflicts and review what has been produced. External dependencies and difficult business decisions may remain slower than the code.

But historic velocity becomes a weaker predictor of what the team can deliver.

A piece of work that previously required two months may sometimes be implemented in several days. It may still take longer to clarify the requirement, obtain access to an external system, complete security review or achieve business acceptance. Those are now more likely to define the schedule than the number of coding stories a team can complete in a fortnight.

The planning question therefore begins to change.

Instead of asking primarily how many units of work fit into the next sprint, the organisation needs to ask whether the outcome has been defined clearly enough, which dependencies control the sequence, what can safely proceed in parallel and what evidence will be required before the next milestone is accepted.

AI does not make project planning less important. It makes the weaknesses of resource-centred planning more visible.

Clear analysis becomes more valuable, not less

Faster implementation increases the cost of unclear thinking.

A vaguely written requirement might once have been clarified gradually over several sprints. Developers would ask questions, examine current behaviour and make assumptions as the work progressed. This was inefficient, but the pace of implementation left time for uncertainty to be discovered.

An agent can begin producing a solution almost immediately. If the organisation has not decided who owns the data, what should happen when an external service fails, how duplicate requests are handled or which exceptions must be preserved, the AI may still produce an answer. It may simply be the wrong answer.

The first use of AI in planning should therefore be to challenge the proposed work rather than immediately implement it.

An agent can examine an outcome from business, technical, security, data and operational perspectives. It can identify contradictions, missing rules, unresolved dependencies and acceptance conditions that cannot yet be tested.

Its role is not to declare the correct business answer. It is to make incomplete analysis harder to conceal.

A strong business analyst may be valuable precisely because they possess detailed domain knowledge, understand the organisation’s needs, can extract information from third parties and know which exceptions matter. A delivery lead may add value by coordinating project milestones, suppliers, decisions, dependencies and risks.

Those contributions are different from rewriting requirements into a prescribed story format or administering the internal work of an experienced engineering team.

AI is likely to expose that distinction. Roles that improve understanding, judgement and coordination remain important. Roles whose principal output is ceremony become harder to justify when much of that ceremony can be automated.

The relevant question is not the person’s title. It is whether they add knowledge, judgement, authority or coordination that the delivery team does not otherwise possess.

Requirements should fit the problem

The familiar user-story template, “As a user, I want…” can be useful when it genuinely describes a user need. It becomes less useful when every kind of work is forced into the same structure.

A service rule such as:

As a user, I want transactions validated so that invalid transactions are rejected.

is less precise and less testable than:

Before processing a transaction, the service must confirm that the account exists, remains active and is authorised for the requested transaction type. Invalid requests must return the agreed error response and must not create downstream records.

The second statement is easier to analyse, design and test because it describes the required behaviour directly.

An integration, data migration, security control or operational requirement may each require a different form of specification. The objective should be to make the outcome and constraints unambiguous, not to demonstrate compliance with a template.

AI-assisted planning should therefore be judged partly by whether it improves the quality of the requirement or merely generates more polished work items.

Sequential outcomes and parallel execution

AI does not remove sequence from a project.

A system’s purpose and boundaries may need agreement before its interfaces can be finalised. Integration cannot be accepted before both ends of the contract exist. Operational readiness cannot be demonstrated before logging, alerting and recovery procedures have been established. Release cannot proceed before business and security acceptance are complete.

These are real dependencies.

What changes is the amount of work that can occur concurrently between those milestones.

While business rules are being clarified, agents can inspect existing systems and supplier documentation. Once the system boundary is agreed, several agents can explore architecture, data, security and test design in parallel. Implementation agents can work on separate components while review agents compare the result with the specification.

The work then converges at an agreed milestone.

This suggests a planning model based on sequential outcomes and parallel execution.

The plan retains a roadmap of deliverables and dependencies. The delivery team dynamically determines how the work will be undertaken.

That resembles competent project planning more than it resembles a static sprint backlog. It also resembles the original Agile principle of a self-organising team more closely than some heavily administered implementations of Agile do.

What products provide in July 2026

No single supplier currently provides a complete planning environment in which a business outcome becomes an analysed specification, a dynamic agent plan, an implementation, a body of acceptance evidence and an executive project view.

The pieces do exist, but suppliers are approaching the problem from very different starting points.

Those differences matter. The products adopted now may shape how organisations understand AI-enabled planning for years.

Atlassian: bringing agents into Jira

Atlassian is extending the existing Jira model to include agents.

In February 2026 it introduced agents in Jira in open beta, allowing them to be assigned work, mentioned in comments and incorporated into workflows. Atlassian presents Jira as the central place for coordinating human and agent activity, while Rovo supplies enterprise search, chat and configurable agents across Jira, Confluence and connected sources [2][3].

This is a practical development for organisations already committed to the Atlassian platform. Rovo can retrieve organisational context, summarise work, create or update content and participate in automated processes.

It can also reduce some of the administrative effort surrounding Jira.

But its basic direction is clear. Atlassian is placing AI inside the existing work-item, workflow and board model. It is making the established process more capable rather than questioning whether tickets and boards should remain the principal representation of delivery.

That is not a minor distinction.

As a dominant supplier, Atlassian has the market position to influence how CIOs define AI-enabled planning. If the industry accepts that it means agents creating stories, updating Jira and operating inside workflows, the existing paradigm may be preserved before alternatives have had a chance to mature.

The risk is that automation of the current process will be mistaken for transformation of the process.

Linear: directly challenging issue tracking

Linear is taking a more provocative position.

In March 2026 it published an argument titled Issue Tracking Is Dead, stating that issue tracking had been designed around a hand-off model in which engineering capacity was scarce and work needed to be routed carefully between roles. Linear argues that the next model should be organised around context and agency rather than the traditional issue queue [4].

Linear Agent can analyse workspace context, customer requests, roadmaps, projects and code. It can create and update projects and issues, synthesise information and take action [5][6].

Linear also describes workflows in which customer requests or Slack discussions can move towards implementation through connected product and coding agents [6].

By June 2026, Linear was promoting Coding Sessions through which its agent could take a defect from triage towards a reviewed code change without the work leaving Linear [7].

Linear has not eliminated issues. Its platform still contains them and can track agent activity in ways similar to human work [8].

Nevertheless, it is one of the few suppliers explicitly challenging the assumption that traditional issue tracking should remain the centre of development. That makes it significant even if its emerging model is not yet a complete replacement for project planning.

Linear may prove to be an early example of a supplier willing to challenge the structure from which its own category emerged.

GitHub: specification-led engineering

GitHub is approaching planning from the source and engineering side.

Spec Kit is an open-source toolkit for specification-driven development. Its stated model places the specification at the centre of delivery, with implementation generated from a structured description rather than treating the specification as temporary documentation that is discarded once coding begins [9][10].

That is a meaningful shift.

The process begins by clarifying intent and producing a technical plan before implementation. It is closer to proper analysis than the practice of creating a short ticket and expecting the development team to discover the rest.

GitHub Copilot’s cloud agent can then receive bounded work, examine a repository, modify code in a controlled environment and create a pull request. It can be initiated from GitHub and integrated with Azure Boards, Jira, Linear, Slack and Microsoft Teams [11][12].

GitHub therefore provides several important components: specification, repository context, agent execution and reviewable source change.

Its limitation is that the centre of gravity remains the repository and pull request. It does not provide the complete project-planning layer required to govern suppliers, business milestones, risk, deadlines and acceptance across a large programme.

Spec Kit is also still evolving, particularly around how specifications are maintained over time and how completed work is reflected back into the enduring system definition [13][14].

It is nevertheless one of the clearest current attempts to improve the quality of what agents are asked to build.

Kiro: requirements, design and tasks as a controlled flow

Kiro, developed by AWS, is another important example because it has made specification-driven development a central product capability rather than an optional toolkit.

Kiro turns a prompt into structured requirements, a design and implementation tasks before generating code. Its standard specification workflow moves through requirements, design and tasks, with approval points between them. It also offers a faster planning mode for work that is already well understood [15][16].

Kiro can then produce code, tests and documentation from that structure. AWS describes it as an agentic development platform intended to move work from prototype to production through specification-led development [17].

This directly addresses one of the major risks of agentic development: allowing implementation to begin before the requirement and architecture have been sufficiently examined.

Kiro still decomposes work into tasks, but the tasks are produced from a specification rather than treated as the starting point. That is a subtle but important difference.

Its current focus is still development rather than enterprise project governance. It does not replace a project plan covering commercial dependencies, business decisions and executive milestones.

But it represents a supplier moving away from prompt-first coding and towards analysis-led agent execution. That direction deserves attention.

Anthropic: flexible agent planning without a management model

Claude Code provides planning, repository analysis, command execution, hooks and specialised subagents.

Built-in subagents include exploration and planning roles, and organisations can define custom agents for particular activities. Hooks can run commands, checks or model-based reviews at defined points in the agent lifecycle [18][19][20].

This makes Claude Code suitable for a self-organising engineering model.

An organisation can establish agents for architecture, backend implementation, testing, infrastructure, security review and documentation. Those agents can divide and revise work dynamically without requiring every activity to be created manually as a Jira story.

Anthropic does not provide the project-management layer around that activity. The organisation must decide how milestones, decisions, risk and acceptance are recorded.

That is both a limitation and a strength. Claude Code does not force the delivery process into a particular work-management product, but it also does not supply the complete governance model.

Microsoft: breadth without a single planning model

Microsoft has many of the pieces required for agent-assisted delivery.

Azure Boards can send work items to GitHub Copilot’s cloud agent and connect the resulting pull request back to the original item [21].

Azure DevOps Pipelines can continue to provide build, test and deployment controls, while Microsoft’s wider environment includes enterprise knowledge, cloud infrastructure, security products and operational tooling.

Microsoft’s advantage is the breadth of its platform. It can potentially connect organisational information, planning records, repositories, testing, deployment and operations.

The problem is that these capabilities remain distributed across products. The organisation must still decide what belongs in the project plan, what belongs in Azure Boards, what remains in the repository and how evidence from pipelines and testing is brought back to the milestone.

Microsoft is well placed to provide a more unified agentic planning model. As of July 2026, it has not yet established one clear enough to replace the existing work-item-centred approach.

What the current landscape tells us

The market is not moving in one direction.

Atlassian is adding agents to the dominant ticket and workflow model.

Linear is openly questioning traditional issue tracking while embedding context-aware agents across product and engineering work.

GitHub and Kiro are making specifications more important and using them to control agent execution.

Anthropic provides flexible multi-agent engineering without prescribing how the project should be governed.

Microsoft has much of the required platform capability but has not yet unified it into one recognisable planning paradigm.

This is not merely a contest between products. It is a contest between interpretations of how AI should change delivery.

What can be assembled today

An organisation does not need to wait for a complete new category of product. It can create a practical agent-assisted planning model now, provided it does not allow one existing tool to define the entire process.

The starting point should be a project outcome, not a collection of stories.

Consider a simple appointment-booking service. The initial statement might be:

Deliver a secure service through which customers can locate an available appointment, book it, receive confirmation and change or cancel the booking. Providers must be able to maintain availability, and the system must prevent conflicting reservations.

That is still not enough to begin implementation safely.

The first agent instruction should ask for analysis:

Review this outcome and identify unresolved business rules, data ownership questions, dependencies, security concerns, failure conditions and acceptance scenarios. Do not propose an implementation until those unresolved decisions have been listed.

Spec Kit, Kiro, Claude Code or a capable planning assistant can help with that exercise.

The agent may identify questions concerning identity, time zones, cancellation periods, concurrency, audit history, notification failures, privacy obligations and the source of truth for the appointment record.

A person with sufficient knowledge and authority must answer them. That may be an engineer, architect, business analyst, subject-matter expert or business representative. The title matters less than whether the answer is reliable.

The project can then define a small number of meaningful milestones. These may cover agreement on the service rules and boundaries, demonstration of the complete booking journey, validation of external integrations and failure handling, operational readiness, security acceptance and final business approval.

The agent team can generate whatever internal work is required to achieve those outcomes.

It may produce dozens or hundreds of tasks. Those tasks can remain visible for traceability, but leadership should not have to manage them.

A bounded implementation instruction might be:

Implement appointment search and booking within the approved architecture. Do not change the identity service or notification contract. Prevent conflicting reservations at the database boundary. Add unit, integration and concurrency tests. Raise a pull request containing the implementation, test results and any unresolved assumptions.

The coding agent can implement that scope. The repository records the change. The pipeline records whether the solution built and passed its tests.

The milestone is not complete until the agreed end-to-end outcome has been demonstrated.

Three workable product combinations

An organisation already committed to Atlassian could retain Jira for project-level deliverables, external dependencies, decisions and significant defects. Confluence or repository-held specifications could contain the fuller requirements and rules. Rovo could search organisational knowledge and reduce routine administration, while GitHub Copilot or another coding agent performed bounded implementation work.

The important change would be to avoid using AI merely to generate a larger backlog.

A Microsoft and .NET organisation could use Azure Boards for milestones and major dependencies, GitHub for code and controlled specifications, GitHub Copilot for bounded agent execution and Azure DevOps Pipelines for build, testing and deployment evidence. This would preserve existing enterprise controls while reducing the importance of sprint-level administration.

An engineering-led organisation seeking a more significant change could use Linear for contextual product and milestone coordination, Spec Kit or Kiro for structured analysis, and Claude Code or GitHub Copilot for multi-agent execution. Pull requests, automated tests and milestone reviews would provide the principal technical evidence.

None of these is a complete new planning system. Each is an assembly of current capabilities.

That is the current state of the market.

Testing and evidence should shape the plan

When implementation becomes faster, testing cannot remain a final activity or a collection of stories created after coding.

The method of verification must be considered while the requirement is being analysed.

AI can help derive scenarios, identify missing cases, generate contract tests, prepare varied data and compare an implementation with its specification. It can also expose where a requirement cannot yet be tested because the expected result has not been decided.

A milestone should therefore define the evidence required for acceptance.

That evidence might include automated tests, validated interfaces, reconciled data, security results, operational telemetry and successful execution of representative business scenarios.

The milestone is complete because the outcome has been demonstrated, not because every internal task is marked done.

The executive view should become simpler

A CIO or delivery executive should not need to inspect the detailed task structure produced by an agent team.

The useful view should show the agreed outcomes, the current state of each milestone, unresolved decisions, dependencies, significant risks, available evidence and any change to the expected date.

Detailed agent activity should remain available for audit and investigation. It should not become the primary management measure.

The relevant questions are straightforward.

Has the milestone been achieved? If not, what is preventing it? Which decision or dependency is outstanding? What evidence remains incomplete? Has the delivery forecast changed?

The number of stories completed is not an answer to any of those questions.

Will a better planning platform emerge?

The technical ingredients of a different model now exist.

Agents can challenge requirements, generate structured specifications, create plans, divide work, operate in parallel, modify repositories, run tests and produce reviewable evidence.

What is missing is a mature platform that unifies those capabilities around project outcomes rather than tickets.

Such a platform would maintain a live model of the outcome, dependencies, decisions, risks, milestones and acceptance evidence. It would allow agents to create and revise their own internal task graph without making that graph the centre of executive governance.

It would preserve traceability without requiring management to supervise every unit of work.

Linear is currently the most explicit in challenging the old issue-tracking assumption. GitHub and Kiro are addressing the weakness of under-specified work. Anthropic enables flexible execution. Atlassian is likely to remain highly influential because Jira is already embedded throughout the industry.

The decisive question is not whether a technically better model can emerge.

It is whether CIOs will recognise it.

Many technology leaders follow accepted industry structures because those structures are familiar, widely purchased and supported by an established labour market. Agile terminology, Jira workflows and the roles surrounding them have become embedded so deeply that they are often treated as the natural shape of software delivery rather than choices.

AI creates an opportunity to challenge that orthodoxy.

A bank, insurer, retailer or government department should design its technology organisation around its business, systems and risk. It should not inherit an arbitrary operating structure because it happens to be the prevailing doctrine of the software industry.

The supplier that creates a convincing outcome-led planning platform may have a major opportunity. But incumbents will retain the advantage if CIOs ask only how AI can improve the workflows they already own.

Where planning is headed

As of July 2026, AI-assisted planning remains incomplete.

Current products can clarify requirements, search organisational context, generate specifications, create plans, assign or generate tasks, run coding agents and return pull requests. They can help parallelise execution and produce technical evidence.

They do not yet provide a complete replacement for project planning and governance.

The direction, however, is becoming clearer.

Planning is likely to move away from manually defining every unit of implementation and towards defining outcomes, constraints, dependencies and acceptance. Agents will increasingly determine how the internal work should be organised and revised.

Static backlogs may give way to live delivery models. Sprint capacity may become less important than decision latency, integration readiness and the ability to verify results. The role of leadership will move further away from supervising activity and towards governing outcomes.

AI can be used to preserve the current system by making ticket creation, backlog management and sprint administration more efficient.

It can also be used to build something better.

The market has not yet decided which interpretation will prevail.

Glossary

Acceptance evidence

Tests, demonstrations, records or other verifiable material showing that an agreed outcome has been achieved.

Agentic delivery

A delivery model in which AI agents can analyse, plan and undertake multi-step work, use tools and revise their actions as results emerge.

Backlog

An ordered collection of potential work awaiting selection or execution.

Cloud coding agent

An AI agent that can undertake software work in a remote environment, modify a repository, run commands and prepare a pull request.

Milestone

A significant project outcome or decision point that must be achieved before delivery can progress as planned.

Specification-driven development

An approach in which a structured specification becomes the primary source from which technical plans and implementations are produced.

Sprint

A fixed period during which a Scrum team attempts to produce an agreed increment of work.

User story

A short description of desired functionality, commonly expressed from the perspective of a user.

References

[1] Schwaber, K. and Sutherland, J., 2020, The Scrum Guide.

https://scrumguides.org/scrum-guide.html

[2] Atlassian, 2026, Introducing Agents in Jira.

https://www.atlassian.com/blog/rovo/ai-agents-in-jira

[3] Atlassian, 2026, What Is Rovo?

https://www.atlassian.com/software/rovo/guides/end-user-guide/what-is-rovo

[4] Saarinen, K., 2026, Issue Tracking Is Dead. Linear.

https://linear.app/next

[5] Linear, 2026, Introducing Linear Agent.

https://linear.app/changelog/2026-03-24-introducing-linear-agent

[6] Linear, 2026, How We Use Linear Agent at Linear.

https://linear.app/now/how-we-use-linear-agent-at-linear

[7] Linear, 2026, AI and Coding Sessions.

https://linear.app/now/ai

[8] Linear, 2026, AI Agents in Linear.

https://linear.app/docs/agents-in-linear

[9] GitHub, 2026, Spec Kit.

https://github.com/github/spec-kit

[10] GitHub, 2026, Spec-Driven Development.

https://github.com/github/spec-kit/blob/main/spec-driven.md

[11] GitHub, 2026, About GitHub Copilot Cloud Agent.

https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent

[12] GitHub, 2026, Starting GitHub Copilot Sessions.

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/start-copilot-sessions

[13] GitHub, 2025–2026, Spec Kit discussion: Evolving Specs.

https://github.com/github/spec-kit/discussions/152

[14] GitHub, 2025–2026, Spec Kit issue: Completing the Spec-Driven Development Workflow.

https://github.com/github/spec-kit/issues/675

[15] Kiro, 2026, What Is Kiro?

https://kiro.dev/

[16] Kiro, 2026, Specs.

https://kiro.dev/docs/specs/

[17] Amazon Web Services, 2026, Kiro.

https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-kiro.html

[18] Anthropic, 2026, Create Custom Subagents.

https://docs.anthropic.com/en/docs/claude-code/sub-agents

[19] Anthropic, 2026, Hooks Reference.

https://docs.anthropic.com/en/docs/claude-code/hooks

[20] Anthropic, 2026, Common Workflows.

https://docs.anthropic.com/en/docs/claude-code/common-workflows

[21] GitHub, 2026, Integrating Copilot Cloud Agent with Azure Boards.

https://docs.github.com/en/enterprise-cloud@latest/copilot/how-tos/use-copilot-agents/cloud-agent/integrate-cloud-agent-with-azure-boards

The most impressive demonstrations of AI-assisted software development usually begin with a clean problem.

A user describes an application, selects a technology stack and asks an AI agent to build it. The agent creates the project structure, user interface, application programming interfaces, database model, tests and deployment configuration. Within a relatively short period, something recognisably useful exists.

This is genuine progress. It is also the most favourable environment in which to assess AI.

The agent is helping to create the system, so it does not first have to discover where all the boundaries lie. It can establish the repository structure, select libraries, define interfaces and apply consistent conventions from the beginning.

An existing system presents a different problem.

The structure is already there, but it may not be completely visible. Source code may contain only part of the product. Important behaviour may also reside in configuration, shared libraries, databases, infrastructure, scheduled processes, commercial products and operational procedures.

This creates a more demanding question than whether an agent can generate code:

Can an AI agent understand an existing system well enough to change it safely?

As of July 2026, the answer is sometimes yes. But the responsibility given to it must be bounded by the evidence it can examine and by the organisation’s ability to verify the result.

What can actually be done today?

AI development tools have moved well beyond autocomplete and conversational assistance.

A cloud coding agent is an AI system that can undertake a development task in a remote environment. Unlike an assistant that merely suggests code inside an editor, it can inspect a repository, modify files, run commands and prepare proposed changes for review.

GitHub Copilot’s cloud agent can examine a repository, work on a task in an isolated environment and prepare a pull request. A pull request is a proposed set of changes submitted for review before being incorporated into the main codebase [1].

The agent can also receive tasks from systems such as Azure Boards and Jira. In Azure Boards, a work item can be sent to the agent, which then prepares a pull request. In Jira, the agent can use the issue title, description, comments, labels, custom fields and acceptance criteria as part of the task context [2][3].

Claude Code offers a similar model. It can inspect code, edit files and run development commands. It also supports planning before implementation, permissions that restrict what it may do, and hooks that can run checks or other actions at defined points in its lifecycle [4].

These are current capabilities, not predictions.

A current agent could reasonably be assigned a task such as:

Add a new endpoint to this .NET service, update the data model, implement validation, write unit and integration tests, run the solution and prepare the changes for review.

Where the solution is coherent, the development environment can be reproduced and the expected behaviour is testable, an agent can perform a substantial part of that work.

It can inspect related classes, follow established conventions, modify several files and respond to compilation or test failures. The result still requires review, but this is no longer simply assisted typing. It is a form of delegated engineering.

A current agent can also undertake a narrower maintenance task:

Trace how this error code is produced within the claims service, document the execution path, add a regression test and change its handling without modifying the public interface or shared libraries.

The difference between those two instructions is important.

The first gives the agent room to construct a bounded feature within a known structure. The second defines the service, the behaviour, the exclusions and the method of verification. That is the safer pattern for existing systems.

For a new system, an agent can often be given relatively broad responsibility for constructing much of the framework. For an existing system, the organisation usually needs to define the scope, available evidence, exclusions and verification method before allowing it to act.

A repository is not the product

A repository is the version-controlled collection of source code, project files, configuration and related material used to develop software. It has become the natural working unit for coding agents because its contents can be searched, changed and tested.

But a repository is an engineering container. A product is a runtime system of code, data, configuration, infrastructure, interfaces and operational behaviour.

Even a reasonably modern .NET solution may not make its runtime composition completely obvious.

Project references and package dependencies can normally be read directly. However, many .NET applications use dependency injection, a technique in which software components are supplied with the services they need, often when the application starts or when a particular request is processed.

Registrations may be distributed across Microsoft’s built-in dependency-injection framework, Autofac modules, assembly scanning, decorators, feature flags and environment-specific configuration.

An agent may identify several implementations capable of satisfying an interface without establishing which implementation is actually selected in production for the transaction being changed.

Shared packages introduce another boundary. An application may reference an internal organisational library that automatically registers authentication policies, logging behaviour, database conventions, middleware or background services.

Standard platforms and shared libraries are generally beneficial. They reduce unnecessary variation and allow developers and AI systems to work from known conventions.

However, standardisation must not become concealment. A shared library can create dependencies across dozens of applications. A change that appears local in one repository may have consequences throughout the organisation.

Distributed systems create a similar difficulty. A service may occupy a small, well-organised repository while the complete product depends on interfaces, event formats, identity services, message ordering, retry policies and operational assumptions spread across many teams and suppliers.

Repository scale is not product scale.

Giving an agent access to more repositories may improve its evidence base, but access alone does not create a complete operational model. An agent that has inspected five repositories has not necessarily understood the business process connecting them.

Understanding the boundary matters more than understanding everything

An agent does not need to understand the entire enterprise before it can make a useful change.

Human developers rarely possess that level of knowledge either. Software engineering depends on separation of concerns because complete understanding is impractical.

A developer integrating with a payment service does not need to understand every part of the provider’s settlement engine. The developer does need to understand the contract at the boundary: how requests are formed, how success and failure are represented, how authentication works, when retries are safe, how duplicates are handled, which events and records are produced, and what must happen when the result is uncertain.

Where those contracts are explicit and dependable, both people and AI can reason locally.

Safe change does not require complete understanding of the whole system. It requires sufficient understanding of the change boundary and confidence that the surrounding contracts can be trusted.

Complexity is not necessarily the problem. Complexity that remains behind a dependable interface can be contained.

The problem is complexity that leaks across the boundary. An apparently local change may depend on an undocumented database trigger, an unversioned file format, a manual reconciliation process or another system that interprets the same data differently.

Discoverability is therefore becoming an important quality of system design.

Explicit dependencies, versioned interfaces, standard project structures, meaningful telemetry and automated tests make software easier for people to maintain. They also create a much better environment for AI.

Instructions can guide an agent, but they do not create understanding

Some development teams place an AGENTS.md file in a repository.

This is a plain-text instruction file intended for coding agents. It can explain how the repository is organised, which commands should be used to build and test it, which conventions should be followed and which areas should not be changed.

That is useful, but it should not be mistaken for proof that the agent understands the system.

A 2026 study evaluated whether repository-level instruction files improved coding-agent performance. It found no statistically significant overall performance improvement from either automatically generated or developer-written instruction files. Developer-written files produced a small average improvement, but not one that was statistically conclusive. Both types caused agents to take more steps and increased average inference cost by roughly 20 per cent or more [5].

The researchers also found that the agents generally followed the instructions. The lack of improvement was therefore not simply caused by agents ignoring the files.

The conclusion is not that repository instructions have no value. They can provide important commands, restrictions and organisational conventions.

The conclusion is narrower:

A document explaining how an agent should work is not evidence that the agent understands everything it may affect.

The same principle applies to architecture documents, diagrams and internal knowledge bases. They provide evidence, but they may be incomplete, outdated or inconsistent with the operating system.

Current research is beginning to test maintenance, not just isolated fixes

Early evaluations of coding agents often concentrated on isolated defects. The agent was given a defined issue, allowed to modify a repository and then judged on whether the tests passed.

That is useful, but maintaining software is not a series of unrelated puzzles. Each change inherits the decisions and weaknesses of the changes that came before it.

Recent research is beginning to examine this longer-term problem.

SWE-CI is a research benchmark designed to evaluate whether coding agents can maintain repositories through extended sequences of change rather than complete a single isolated repair. Its 100 tasks are based on real repository histories averaging 233 days and 71 consecutive commits [6].

SWE-Chain evaluates agents through linked software-package upgrades. Each agent-produced version becomes the starting point for the next upgrade, allowing earlier errors and design decisions to affect later work. The study found that current agents still struggled to complete successive upgrades without breaking existing behaviour [7].

SWE-Cycle examines a wider issue-resolution process. It separately tests whether agents can reconstruct the development environment, implement a change and generate verification tests. It also combines all three into an end-to-end task beginning with a bare repository rather than a prepared environment. Performance dropped sharply when agents had to complete the entire cycle without human scaffolding [8].

These benchmarks do not show that coding agents are ineffective.

They show why completing one task successfully does not establish that an agent can maintain a product through repeated releases.

An agent may produce a change that passes today’s tests. The cost of its design decisions may become apparent only when the next feature, migration or upgrade is attempted.

Existing systems contain more than source code

Older systems are not necessarily poorly designed.

Many have delivered stable services for decades and embody business knowledge that newer applications have not yet acquired. Their difficulty for AI lies partly in the form and distribution of the evidence.

A legacy procedural application may contain thousands of lines of relatively linear code. It may appear unsophisticated by modern standards, but its execution path can sometimes be easier to trace than that of a much smaller application assembled dynamically from frameworks, configuration and remote services.

Code volume and comprehension difficulty are not the same thing.

The larger challenge is that an older application is often only one component of an operational environment.

A Unix estate may include shell scripts outside the main source repository, cron schedules, enterprise job schedulers, daemons, file transfers, database procedures, environment-dependent configuration, programs that invoke operating-system commands, proprietary terminal menus, manual utilities, reconciliation routines and recovery procedures. Some processes may run only monthly, annually or following an unusual failure.

An agent examining the main application repository could produce a coherent explanation while missing an essential part of the product.

Existing-system understanding is not simply code analysis. It is reconstruction of an operational model from incomplete and distributed evidence.

Evidence must be separated from inference

A responsible agent should distinguish between what it has established and what it has merely inferred.

An AI system should never present its understanding as broader than the evidence it has examined.

This matters because generated explanations can be highly coherent. A polished diagram or confident narrative may create more trust than the underlying investigation justifies.

In a new system, the agent may have helped create most of the relevant structure. In an existing system, failure to find a dependency does not establish that the dependency does not exist.

The ability to recognise incomplete understanding is more important than the ability to produce a complete-looking diagram.

This is also why AI should be treated cautiously as an oversight or assurance mechanism in a poorly understood estate.

It may be valuable for investigation, documentation and evidence gathering. It should not be treated as an authoritative supervisor merely because it can process large volumes of technical information.

Could AI eventually inspect the complete environment?

It is technically feasible that a future AI system could be given controlled access to a Unix environment and examine it as a working operational system.

It could inspect processes, schedules, executables, configuration, logs, file activity, system calls, database connections and network flows. By observing representative transactions, it could progressively reconstruct relationships that were never documented.

It might eventually report that a menu selection invokes one program, which reads a configuration file, calls a shell script, updates a database and creates a file that another service processes overnight.

That would be more powerful than repository analysis alone.

It would also be an expensive and potentially dangerous way to understand a system.

Low-level monitoring can expose credentials, access tokens, customer information, proprietary data, operational commands and weaknesses in the security architecture. The discovery agent would itself become one of the most privileged and sensitive components in the environment.

Even a long observation period might fail to capture annual jobs, emergency recovery procedures, exceptional business cases or manual intervention.

The agent would therefore need to distinguish between behaviour it directly observed, behaviour it inferred, paths that were never exercised and evidence it could not inspect.

More importantly, an organisation should ask whether this represents the best use of AI capability.

An agent that must trace system calls and network traffic to understand ordinary application behaviour is performing archaeology. That may be necessary during modernisation, but it should not become the preferred engineering model.

AI should accelerate good engineering, not make poor engineering indefinitely tolerable.

The sustainable response is to build systems with explicit dependencies, stable interfaces, standard platforms, consistent telemetry and repeatable delivery processes.

Build well and standardise the engineering environment, and AI becomes a productive partner. Build opaque systems and AI first has to spend its effort discovering what should already have been visible.

What bounded use looks like in an older system

The conclusion should not be that AI must be kept away from older software.

It should be given work that reflects what can actually be established.

A poorly bounded instruction might be:

Analyse the billing system, remove the legacy dependency and modernise the application.

This assumes that the agent will find every use of the dependency, understand why it exists and identify every affected consumer.

A more defensible instruction would be:

Within the invoice-generation component, identify calls to library X involved in PDF creation. Document each call site and the tests covering it. Do not change shared packages, database structures, public interfaces or batch jobs. Identify any behaviour that cannot be verified from the repository and propose a replacement approach for review.

The second instruction defines the component being examined, the dependency of interest, the expected evidence, the prohibited changes and the limit of the agent’s authority.

The agent can search references, trace code paths, inspect tests and prepare a limited proposal.

It may also add characterisation tests. These are tests written to record what an existing system currently does before its behaviour is changed. They do not necessarily prove that the present behaviour is correct, but they help prevent accidental changes to behaviour that users or other systems may depend upon.

Current products support parts of this model.

GitHub Copilot’s cloud agent works through a proposed pull request rather than silently incorporating changes into the primary branch. Claude Code can be placed in planning mode, configured with permissions and connected to hooks that inspect or restrict actions [1][4].

These controls do not guarantee that the agent is correct. They make it easier to contain the work and preserve human accountability.

Why greenfield is different

The greenfield advantage is not simply that the code is new.

The organisation can define the environment in which AI will operate.

It can require standard repository and solution structures, approved libraries, explicit dependency registration, versioned interfaces, reproducible development environments, infrastructure as code, consistent telemetry, automated testing and clear component ownership.

An agent can then construct much of the framework within those rules.

It can generate the initial solution, routine application components, tests, deployment definitions and delivery configuration. Human effort can concentrate on architecture, business outcomes, security decisions and review.

This does not make the resulting system automatically safe or maintainable. AI can build a badly specified system very quickly.

But the organisation can create the boundaries and verification mechanisms before complexity becomes embedded.

AI can help define the boundaries of a new system. In an existing system, it must not be trusted to assume that it has found them all.

That is the essential difference.

Packaged products create a different AI opportunity

Many organisations do not develop most of their core systems.

They operate commercial products for banking, insurance, finance, human resources, workflow, customer management and other functions.

In those organisations, AI may have limited ability to change the underlying product. Its role shifts towards the surrounding engineering work: integration, workflow coordination, data transformation, reporting, reconciliation, observability, operational investigation and testing across product boundaries.

The organisation may own relatively little of the core software while remaining responsible for making several commercial products operate as one coherent business process.

AI can help compare interface definitions, analyse data structures, generate adapters, examine logs and design operational queries.

Observability platforms provide current examples.

Observability is the ability to understand the state and behaviour of a system through evidence such as logs, metrics, distributed traces and events.

New Relic AI allows users to ask questions in ordinary language and uses available telemetry to help investigate errors, performance and other operational conditions. It can generate explanations, summaries, charts and tables, and help identify services that are not covered by alerts [9].

New Relic also provides a public-preview service using the Model Context Protocol, usually abbreviated to MCP. MCP is a standard through which an AI system can connect to external tools and sources of information. New Relic’s MCP service allows supported agents to query observability data [10].

Splunk’s AI Assistant for Observability Cloud provides a natural-language interface for investigating system behaviour. It can generate SignalFlow queries and charts, suggest suitable standard metrics and refine the result through further prompts [11].

These are practical capabilities available now.

They are not yet the complete model that should eventually emerge.

An observability platform should ultimately be able to examine a newly ingested log schema, identify fields representing transaction volume, latency, outcomes and errors, and propose suitable dashboards and alerts. Where business meaning is unclear, it should ask questions rather than guess.

For example, it might identify transaction type, processing duration, source system, status, error code and correlation identifier. It could then propose failure-rate and performance dashboards before asking whether a particular status represents a system fault or an expected business rejection.

That work can already be performed collaboratively. An engineer can supply representative logs and system context to an AI assistant, interpret the fields with it and jointly design New Relic or Splunk queries, alerts and dashboards.

What remains largely manual is providing the business meaning, validating the conclusions and implementing the complete operational design.

AI’s wider role in IT

The wider direction should not dominate this article, but it is already becoming visible.

AI’s role in information technology will not be confined to writing software.

Work-tracking systems can now supply tasks directly to coding agents. Observability products expose operational telemetry to AI assistants. The same analytical capability can assist with requirements discovery, project planning, story and acceptance-criteria creation, tender-document analysis, product comparison, service-request triage, alarm correlation, incident investigation and operational reporting.

AI can help identify evaluation criteria before a tender is issued. It can analyse vendor submissions, locate omissions, compare commitments and generate clarification questions.

It can help classify service requests, identify duplicates, retrieve relevant knowledge and route work to the likely support team.

It can correlate alarms with deployments, logs and service dependencies to help an investigator determine whether several alerts represent one underlying incident.

These uses are increasingly practical, although their reliability depends heavily on the quality of the available evidence and the organisation’s ability to verify the result.

The same rule applies outside software development:

The authority given to AI should not exceed the quality and completeness of the evidence available to it.

Modernisation as capability preservation

Legacy modernisation is often presented as a contest between old and new technologies.

That is not the strongest argument.

An older system may remain reliable and economically useful. Replacing it merely because it uses an unfashionable language or architecture can introduce unnecessary cost and risk.

The more serious concern is the loss of organisational capability.

Older systems often depend on a shrinking number of people who understand their language, environment, business rules and operational history. When those people retire, the organisation loses more than programming knowledge. It loses the reasons behind exceptions, workarounds and recovery processes.

Opaque and fragmented systems also receive fewer of the benefits available from AI-assisted development, testing, impact analysis and operations in structured environments.

Modernisation does not have to begin with a wholesale rewrite.

It can begin by documenting current behaviour, capturing the knowledge of experienced staff, adding characterisation tests, identifying interfaces and data flows, exposing stable boundaries, standardising telemetry, making dependencies explicit and separating critical functions from the wider estate.

This progressively creates an environment in which both people and AI can operate with greater confidence.

The longer an organisation waits, the more likely it is that modernisation will begin after the knowledge needed to do it safely has already started to disappear.

Where to begin

For an organisation considering its first serious use of AI in software delivery, the safest starting point is not an unrestricted attempt to understand the entire estate.

The better starting point is a bounded problem with an identifiable repository or component, a clear expected outcome, a working build and test process, limited external consequences, an experienced reviewer and a change that can be reversed.

A suitable initial task might involve improving test coverage, documenting a component, tracing a defined error path or adding a modest feature to a well-structured service.

The organisation should avoid beginning with instructions such as “modernise this complete system”, “remove this dependency everywhere”, “divide this application into microservices”, “migrate this platform” or “identify every operational risk”.

Those requests combine discovery, architecture, implementation and assurance while assuming that the agent has access to all relevant evidence.

It probably does not.

The objective of the first adoption stage should not be to prove that AI can replace a development function. It should be to establish where it produces dependable value, what context it requires and which controls make its work reviewable.

Where the boundary sits in July 2026

AI can now undertake substantial software-development work.

Within a structured repository, an agent can investigate a task, propose an implementation, modify several files, execute commands, run tests and prepare a pull request.

It can also assist with constrained maintenance, work-item execution and operational investigation.

What current capability does not justify is unrestricted authority over a poorly understood system whose important behaviour may exist outside the evidence available to the agent.

For new systems, AI can be given broad responsibility for constructing much of the framework, provided the organisation establishes the architecture, standards and verification controls.

For existing systems, its role should be bounded by explicit scope, defined exclusions, accessible evidence and independent validation.

AI can help solve many software problems. It should not be assumed to understand or solve all of them.

Greenfield is the easy case because the boundaries can be created deliberately.

Existing-system change is harder because the boundaries must first be discovered, and an agent must not be trusted to assume that it has found them all.

Glossary

AGENTS.md

A plain-text file placed in a software repository to give coding agents project-specific instructions, such as build commands, conventions and restrictions.

AI agent

An AI system that can pursue a task through several steps, use tools, examine results and decide what to do next.

Characterisation test

A test written to record the current behaviour of an existing system before it is changed.

Cloud coding agent

An AI development agent that works in a remote environment, where it can inspect code, modify files, run commands and prepare changes for review.

Dependency injection

A software technique in which components receive the services they depend on, often through configuration performed when the application starts.

MCP, or Model Context Protocol

A standard that allows AI systems to connect to external tools and sources of information.

Observability

The ability to understand a system through evidence such as logs, metrics, traces and events.

Pull request

A proposed collection of code changes submitted for review before being incorporated into the main codebase.

Repository

A version-controlled collection of source code, project files, configuration and related software-development material.

SWE-CI

A research benchmark that evaluates whether coding agents can maintain software through an extended sequence of changes rather than complete one isolated task.

SWE-Chain

A research benchmark that evaluates agents through successive software-package upgrades, where the outcome of each change becomes the starting point for the next.

SWE-Cycle

A research benchmark that evaluates coding agents across environment reconstruction, implementation and test generation, both separately and as a complete issue-resolution process.

Telemetry

Operational data produced by a system, including logs, measurements, traces and events.

References

[1] GitHub, 2026, About GitHub Copilot cloud agent.

https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[2] GitHub, 2026, Integrating Copilot cloud agent with Azure Boards.

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/integrate-cloud-agent-with-azure-boards

[3] GitHub, 2026, Integrating Copilot cloud agent with Jira.

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/integrate-cloud-agent-with-jira

[4] Anthropic, 2026, Claude Code overview, common workflows, settings and hooks.

https://docs.anthropic.com/en/docs/claude-code/overview

https://docs.anthropic.com/en/docs/claude-code/common-workflows

https://docs.anthropic.com/en/docs/claude-code/settings

https://docs.anthropic.com/en/docs/claude-code/hooks

[5] Gloaguen, T. et al., 2026, Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?

https://arxiv.org/abs/2602.11988

[6] Chen, J. et al., 2026, SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration.

https://arxiv.org/abs/2603.03823

[7] Lam, M.H. et al., 2026, SWE-Chain: Benchmarking Coding Agents on Chained Release-Level Package Upgrades.

https://arxiv.org/abs/2605.14415

[8] Guan, H. et al., 2026, SWE-Cycle: Benchmarking Code Agents across the Complete Issue Resolution Cycle.

https://arxiv.org/abs/2605.13139

[9] New Relic, 2026, Meet New Relic AI, your observability assistant.

https://docs.newrelic.com/docs/agentic-ai/new-relic-ai/

[10] New Relic, 2026, New Relic AI Model Context Protocol.

https://docs.newrelic.com/docs/agentic-ai/mcp/overview/

[11] Splunk, 2026, Splunk AI Assistant in Observability Cloud and Use AI Assistant to build charts in Splunk Observability Cloud.

https://help.splunk.com/en/splunk-observability-cloud/splunk-ai-assistant/ai-assistant-in-observability-cloud

https://help.splunk.com/en/splunk-observability-cloud/create-dashboards-and-charts/create-charts/use-ai-assistant-to-build-charts

The first article in this series argued that software development had already moved beyond code completion. That change is now easier to see. Leading tools can examine repositories, plan changes, edit multiple files, execute commands, run tests and prepare pull requests. Some remain closely supervised by a developer. Others accept a task and work asynchronously in a separate environment. More recent systems allow several agents to work concurrently or assign different responsibilities to specialised agents.

The market has therefore reached a point where enterprises must make practical choices. The question is no longer whether developers should have access to AI assistance. It is which capabilities are sufficiently useful and dependable to become part of an organisation’s engineering environment.

That decision is more difficult than comparing benchmark scores or demonstrations. Enterprise development does not take place inside a blank editor. It depends on requirements, work planning, repositories, internal libraries, build systems, infrastructure, security controls, release processes and production operations. A tool may be excellent at generating code while fitting poorly into the environment in which that code must be reviewed, tested, deployed and maintained.

The products are also changing rapidly. GitHub’s cloud agent can research a repository, prepare an implementation plan, change files on a branch and return the result for review [1]. Claude Code operates across a codebase through the terminal and supported development environments [2]. OpenAI’s Codex has expanded across local, cloud and multi-agent operating modes, including an application designed to coordinate agents working in parallel [3].

Google provides a particularly clear example of the instability of this market. On 18 June 2026, Gemini Code Assist IDE extensions and Gemini CLI stopped serving requests for the Individuals, Google AI Pro and Google AI Ultra tiers. Affected users were directed to Google’s unified multi-agent platform, Antigravity, and Antigravity CLI. Gemini Code Assist Standard and Enterprise remain available, with IDE agent mode still identified as a preview capability [4][5].

These examples establish that agentic development is operational. They do not establish that it is uniformly reliable, suitable for every type of work or ready to control the complete software lifecycle.

This article is therefore a dated assessment. It examines the market as it exists in July 2026, rather than the market vendors expect to exist later. It distinguishes capabilities ready for broad adoption from those more appropriate for bounded use, controlled trials or continued observation.

The governing question is:

Which products and operating models, as of July 2026, show sufficiently consistent and reliable improvement to justify a strategic enterprise decision?

The answer will not necessarily be a single supplier. Interactive development, repository analysis, delegated implementation, interface design, infrastructure automation and assurance are different functions. An organisation may find that the strongest practical approach combines two or more products, provided their responsibilities are clear and the integration burden remains manageable.

New development and changes to existing systems

AI development products are often demonstrated by asking them to create something new. A prompt describes an application and the system produces a user interface, application logic and perhaps a deployable prototype.

This is useful, but it represents only one form of software development.

The other is changing a system that already exists. For established organisations, this is often the more common and more consequential problem.

Building something new

New development begins with an intended outcome. The organisation can define the architecture, application, infrastructure and operating model around that outcome without first recovering years of previous decisions.

AI can assist throughout this process. It can analyse an initial requirement, identify missing decisions, propose alternative designs, generate application code, develop tests and prepare infrastructure definitions. Where the requirement is clear and the selected technologies are well supported, a working application can be produced quickly.

The broad sequence is relatively direct:

Intent → analysis → design → implementation → validation → deployment

This is one reason demonstrations of AI development can be so persuasive. There is comparatively little inherited complexity, and the system can select familiar frameworks, patterns and libraries.

The difficulty is that a functioning demonstration is not necessarily a production system. It may show that a customer journey works without showing that the application is secure, maintainable, accessible, resilient or affordable to operate. It may use libraries inappropriate for the organisation, ignore established architectural standards or conceal important assumptions inside generated code.

Rapid construction reduces the time required to reach a first result. It does not remove the work needed to determine whether that result should be operated and supported.

This distinction is particularly important when assessing design and application-generation platforms. A disposable prototype, a useful implementation starting point and a maintainable production application are different outcomes. The fact that all three may look similar on a screen does not make them technically equivalent.

Changing what already exists

An existing system presents a different problem. Before making a change, the developer or agent must establish what is already there, how it behaves and what else depends upon it.

The source code may be only one part of that system. Its behaviour may also depend on database procedures, scheduled processing, configuration, cloud services, infrastructure definitions, identity rules, external interfaces and operational practices. Some of these dependencies may be documented. Others may be discovered only through logs, incidents, change history or the experience of people who have supported the system for years.

The sequence is therefore longer:

Observe → reconstruct → assess impact → propose change → implement → validate → release

Current repository agents can already inspect a codebase, coordinate changes across several files and execute development commands. GitHub’s cloud agent can investigate a repository and create proposed changes on a branch [1]. Claude Code is designed to work across a codebase rather than respond only to the contents of an open file [2]. Codex can operate through local and cloud environments and coordinate several agent threads in parallel [3].

These capabilities are significant, but repository access is not the same as product understanding.

An agent may correctly identify the code that appears to implement a function while remaining unaware of an external batch process, a reconciliation step or an operational dependency. It may know how the application is built without knowing how it is actually deployed. It may produce a change that passes the available tests while failing to account for an interface used by another system.

The more useful enterprise test is therefore not simply whether an agent can modify a repository. It is whether the agent can understand enough of the deployed product to explain what needs to change, what else may be affected and where its conclusions remain uncertain.

To do that well, an agent may need access to more than source code. Relevant context could include deployment definitions, database schemas, interface specifications, infrastructure code, architecture decisions, operational documentation, telemetry, incident history and previous change records.

The desired output is not merely a patch. It is a reasoned account of the existing behaviour, the proposed change, its likely consequences and the evidence supporting that conclusion.

For an established enterprise, this may prove more valuable than rapid greenfield generation. Much of its software expenditure concerns maintenance, integration, regulatory change, migration and gradual modernisation. A product that performs impressively when creating new applications but struggles to understand an existing estate may be useful without being suitable as the organisation’s primary engineering platform.

The market is no longer one market

The phrase AI coding tool now covers products that operate in substantially different ways.

Some remain close to the developer. They sit inside an editor or terminal, respond to instructions and allow the user to examine each step. Their value comes partly from capability and partly from the fact that the developer remains in the loop. An incorrect assumption can be corrected before it becomes a large change.

Other products operate at repository scale. They can inspect several parts of a codebase, execute commands and coordinate changes across files. This allows them to complete more substantial tasks, but it also increases their dependence on repository quality, tests, documentation and clear organisational conventions.

A further group works asynchronously. The agent is assigned a task, operates in a separate environment and returns a branch or pull request. GitHub’s cloud agent follows this pattern, allowing work to occur in the background before the developer decides whether to create a pull request [1]. Codex also supports cloud-based delegated work and parallel agent threads [3]. These systems alter the relationship between developer and tool because the developer is no longer observing every step.

Asynchronous work can be valuable for bounded activities such as adding tests, carrying out a contained refactoring, updating documentation or implementing a clearly specified feature. It is harder to justify where the task is broad, the product poorly understood or the consequences of failure are significant.

Multi-agent systems add another layer. Several agents may work on independent tasks, propose alternative implementations or take specialist roles in architecture, implementation, testing and review. OpenAI’s Codex application explicitly supports parallel agent threads. GitHub permits specialised custom agents to be configured for different development tasks [3][6]. Google describes Antigravity as a central platform for launching, monitoring and orchestrating agent activity [7].

This makes a multi-agent software process technically possible. It does not mean that a group of agents automatically functions like a mature engineering team.

Several agents can share the same misunderstanding. They may use related models, read the same context and reinforce the same assumption. Parallel work is useful when tasks are genuinely separable. Specialist review is useful when the reviewer has a different objective and an independent basis for judgement. Simply adding more agents does not create independent assurance.

Design and prototyping platforms occupy a different part of the market. Their strength lies in turning an idea into a visible interface or functioning demonstration quickly. The enterprise question begins after that point. Can the resulting application follow the organisation’s design system, enter normal repository workflows, use approved components, satisfy accessibility and security requirements and remain maintainable after the initial generation?

Open-source and self-managed agents offer another set of trade-offs. They can provide greater control over execution, models and organisational data. They may also require substantial engineering effort to secure, maintain and integrate. An open-source licence does not itself guarantee portability. An implementation may still depend on a particular model provider, plugin ecosystem or small group of internal specialists.

The final category is orchestration. This concerns how agents connect with repositories, development tools, organisational knowledge and execution environments. Open protocols such as the Model Context Protocol can make those connections more consistent, while vendor-specific agent frameworks provide additional coordination and policy controls.

Technical connectivity, however, is not governance. An enterprise still needs to determine what an agent can see, which actions it may perform, what credentials it may use and how its decisions will be recorded.

Google’s current position illustrates why these categories cannot always be mapped neatly to one product. Antigravity and Antigravity CLI represent its newer multi-agent direction for users displaced from the former individual Gemini Code Assist and Gemini CLI access model. Gemini Code Assist Standard and Enterprise continue to provide enterprise IDE assistance, including an agent mode that remains in preview [4][5][7].

This transition is not merely a change of product name. It demonstrates why an enterprise cannot assess a fast-moving platform from a feature page without also examining its access model, release path and product continuity.

The market is therefore better understood as a set of operating models than as a single contest between coding products.

The relevant question is not which tool has the longest feature list. It is which form of assistance is appropriate for the work, risk and delivery environment of the organisation using it.

What should count as maturity?

The speed of product development creates a problem for enterprise evaluation. A capability may appear in a demonstration, enter preview shortly afterwards and become widely accessible within months. None of those stages proves that it performs consistently enough to support an important engineering process.

Capability must be judged by what a product can complete repeatedly, not by its best recorded performance. A tool that sometimes produces an exceptional result but frequently requires major correction may be valuable to an experienced developer. It is a weaker basis for a standardised enterprise process.

Integration is equally important. The product must work with the organisation’s actual repositories, development environments, private dependencies, pipelines, cloud services and security controls. A tool that performs extremely well inside one supplier’s environment may be a poor strategic choice for an organisation with a mixed estate.

Operational control becomes more important as an agent receives greater authority. A repository agent may read proprietary source, execute commands, access package feeds and create branches. An infrastructure or deployment agent may require credentials capable of changing environments.

The organisation therefore needs control over identity, permissions, network access, secrets, execution isolation, data retention, costs and audit records. The ability to produce a correct change is only one part of operational readiness.

Product continuity matters alongside formal release status. Google’s June 2026 transition illustrates the difference. Agent mode remains a preview capability for Gemini Code Assist Standard and Enterprise, while the individual and consumer-paid access routes were discontinued and redirected to Antigravity [4][5]. A CIO therefore needs to assess not only whether a feature is generally available or in preview, but whether the surrounding product, access model and migration path are stable enough to support training, policy and long-term integration.

Evidence presents another difficulty. Vendor documentation can establish that a feature exists. It cannot establish that the feature delivers sustained productivity, quality or maintainability across different organisations.

Current evidence must also be dated carefully. A study published in 2026 may have examined tools from early 2025. In a slower-moving field, that might still be representative. In agentic development, it may describe a substantially earlier generation.

For that reason, this assessment gives greatest weight to evidence examining recent tools, real repositories, accepted changes, maintenance outcomes and repeated use. Earlier findings remain useful, but they should be identified as historical evidence rather than treated as a direct measurement of July 2026 capability.

The final assessment will not reduce each product to a single score. A product may be suitable for broad interactive use while its asynchronous features remain appropriate only for bounded work. A design platform may be excellent for prototyping while being unsuitable as the source of a production application.

The recommendations will therefore use practical categories: broad adoption, bounded operational use, controlled pilot, prototyping only or continued observation.

That approach is less dramatic than declaring a winner. It is also more useful to an organisation deciding what it can responsibly deploy now.

Four levels of enterprise value

The market is currently rewarding visible capability faster than operational maturity. That makes it important to distinguish four different levels of value.

An impressive demonstration establishes that a capability is technically possible. It may show that an agent can create an application, repair a failing build or complete a substantial repository change. It does not establish how often the result will be acceptable or how much review will be required.

A useful tool improves the work of an individual developer or team. It may accelerate investigation, generate routine implementation, explain unfamiliar code or reduce repetitive effort. The developer remains responsible for determining whether the output is correct.

A reliable operational capability performs consistently enough to become part of an established engineering process. Its access is controlled, its activity is auditable, its failures are understood and its output enters normal testing and review.

A strategic platform goes further. It is sufficiently capable, stable, integrated and replaceable for the organisation to build part of its future operating model around it.

Many current products have reached the second level. A growing number have reached the third for selected work. Far fewer have demonstrated that an enterprise should reorganise its development environment around them.

That is the standard against which the current market should be judged.

References

[1] GitHub (2026) ‘About GitHub Copilot cloud agent’. GitHub Documentation. Available at: https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[2] Anthropic (2026) ‘Claude Code overview’. Claude Code Documentation. Available at: https://docs.anthropic.com/en/docs/claude-code/overview

[3] OpenAI (2026) ‘Introducing the Codex app’. Available at: https://openai.com/index/introducing-the-codex-app/

[4] Google (2026) ‘Gemini Code Assist consumer accounts’. Google for Developers. Available at: https://developers.google.com/gemini-code-assist/docs/deprecations/code-assist-individuals

[5] Google (2026) ‘Use the Gemini Code Assist agent mode’. Google for Developers. Available at: https://developers.google.com/gemini-code-assist/docs/use-agentic-chat-pair-programmer

[6] GitHub (2026) ‘Creating custom agents for Copilot cloud agent’. GitHub Documentation. Available at: https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/create-custom-agents

[7] Google (2026) ‘Getting started with Google Antigravity’. Google Developers Codelabs. Available at: https://codelabs.developers.google.com/getting-started-google-antigravity

Summary

Many organisations are still debating artificial intelligence in software development as though the central decision were whether developers should be given access to GitHub Copilot. By July 2026, that conversation is too narrow.

AI development systems can now inspect repositories, trace behaviour across files, plan changes, run commands, create tests, investigate failures and prepare pull requests. Some work asynchronously. Others can manage several engineering tasks in parallel or create specialist subagents for research, implementation and review [1][2]. GitHub has also begun separating its role as the repository and workflow platform from the question of which model performs the work, allowing Claude and Codex to operate alongside Copilot through a common development environment [3].

The change reaches far beyond backend coding. AI can participate in requirements analysis, system discovery, interface design, interactive prototyping, architecture, assurance, deployment and operations. The unit of automation is moving from a line of code to an engineering workflow.

None of this makes autonomous software development safe. Coding agents can misunderstand requirements, create superficially plausible designs and approve the same mistaken assumptions that produced the code. Several agents may broaden the analysis, but agreement between them is not proof. Builds, tests, security controls, production evidence and accountable human decisions remain essential.

The strategic question for CIOs is no longer whether to permit an AI coding assistant. It is how to redesign software production so that people and specialised AI systems can analyse, design, prototype, build, challenge, test and operate software without abandoning engineering discipline.

An organisation that has distributed Copilot licences but has not reconsidered the wider lifecycle has adopted a useful tool. It has not yet developed an AI software strategy.

The cost of waiting is not merely slower coding. It is slower discovery, slower modernisation and a widening gap between organisations that can coordinate agentic work and those still processing every engineering task sequentially.

The discussion has moved on

The first generation of coding assistance was easy to understand. A developer began writing a method and the system suggested the next line. It generated boilerplate, explained an unfamiliar function or drafted a basic unit test. The developer remained close to every action, deciding whether to accept each suggestion.

That experience shaped the executive conversation. The questions were about procurement, source-code exposure, licences and whether developers would save enough time to justify the cost. Those questions still matter, but they no longer describe the technology’s reach.

Modern coding agents can be given an outcome rather than a sequence of edits. They can examine the repository, identify the relevant components, make coordinated changes, run the build and return a candidate result. OpenAI’s Codex app is designed around multiple agent threads, while Codex subagents can divide a task among specialist roles and gather the results [1][2]. Claude Code supports separate subagents with their own instructions and tool access, allowing focused investigation without forcing every intermediate step into one context [4].

Google’s Jules follows the asynchronous model. It works against a GitHub repository in a cloud environment, performs tasks such as writing tests, fixing defects and updating dependencies, then returns the proposed change for review [5]. GitHub’s Agent HQ takes a different but equally important step. Claude, Codex and Copilot can participate through the same issue, pull-request and Visual Studio Code workflow [3].

That does not establish a permanent winner. It changes the architecture of the decision. The repository platform can remain stable while the intelligence performing the work becomes replaceable.

The practical consequence becomes clearer when two organisations face the same six-month modernisation program. One still treats AI as autocomplete and assigns every repository review, prototype, test suite and migration task sequentially to human teams. The other uses bounded agents to map dependencies, generate characterisation tests, create competing interface prototypes and prepare parallel pull requests, while people retain approval.

Even if the second organisation rejects half the generated work, it may still expose risks and viable options months earlier. The first organisation has not taken a safer path. It has chosen to operate with less discovery capacity, slower feedback and a growing knowledge disadvantage.

From assistant to temporary technical team

The next change is not simply a more capable single agent. It is the ability to assemble a temporary technical team around a piece of work.

Consider a proposed retry mechanism for a payment interface. An implementation agent might favour three attempts with exponential back-off. An architecture agent might argue that retry policy belongs in a shared integration layer. A test agent might identify the dangerous case in which the remote system completes the payment but its acknowledgement is lost. A security agent might find customer information in the retry log, while an operational agent warns that mass retries could worsen a partial outage.

The agents do not need to reach consensus. Their value lies in exposing different assumptions, risks and alternatives before a decision is made. A responsible developer, technical lead or architect can accept the proposal, amend it, reject it or escalate an unresolved business question.

For routine and tightly bounded work, an orchestration agent may eventually make some of those decisions under policy. For high-risk systems, accountability should remain with a named person or authority.

Anthropic’s experiment using 16 Claude agents to construct a Rust-based C compiler illustrates how far parallel agent work can be pushed. Across almost 2,000 sessions, the agents produced roughly 100,000 lines of code and a compiler capable of building the Linux kernel for several architectures [6]. It was an experiment, not a model for unreviewed enterprise delivery. Its significance is that multi-agent construction is no longer hypothetical.

A strong multi-agent process is not a machine committee. It is structured technical decision-making. The agents bring forward perspectives, the pipeline produces evidence and the organisation assigns authority.

Copilot is a tool, not the strategy

Copilot deserves credit for making AI coding assistance familiar inside enterprise development. Its integration with GitHub, Visual Studio and Visual Studio Code makes procurement and deployment comparatively straightforward.

Convenience does not prove that it is the strongest tool for every task. Developers regularly encounter code that is generic, overcomplicated, poorly aligned with the repository or simply wrong. The same criticism applies, in different circumstances, to every major coding system. Performance depends on the underlying model, the surrounding agent software, the context supplied, the quality of the repository and the nature of the task.

A CIO should therefore separate three decisions.

The first is the engineering control plane: the repositories, issues, branches, pull requests, builds, approvals and audit trail through which software moves. GitHub may remain the right platform even when Copilot is not the preferred coding intelligence.

The second is the intelligence layer: the models and agents used for analysis, design, implementation, testing or review. This layer is changing too quickly to hard-wire one vendor into every workflow.

The third is assurance: the builds, tests, security controls, architecture decisions and accountable approvals that determine whether a proposed change is acceptable. The system that writes the code should not automatically become the authority that approves it.

This separation gives a company a practical way forward. It can preserve a stable repository and governance model while changing models as capabilities, costs and risks evolve.

Software development begins before coding

Much of the public discussion starts at the point where a developer writes code. Many software failures begin much earlier.

A requirement may be ambiguous. Two departments may use the same term differently. The proposed interface may not reflect the actual work. A new service may duplicate an existing capability. A technically elegant implementation may solve the wrong problem.

Faster code generation does not repair those mistakes. It accelerates them.

AI can contribute earlier by examining meeting notes, process documentation, existing systems and previous changes. It can propose acceptance criteria, expose contradictions and identify questions that require a business decision. It can trace how a transaction moves across applications, databases, files and scheduled processes, giving an experienced engineer a faster starting point for investigation.

The same principle applies to interface design. AI can turn a written requirement into several competing user journeys and working prototypes. Product owners and users can navigate realistic flows, encounter validation messages and expose missing decisions before the organisation commits heavily to architecture and production code.

This is more important than generating an attractive screen. A prototype can reveal duplicated data entry, poor recovery from errors, inaccessible interactions, weak mobile behaviour or a workflow that simply does not match the way staff perform the job.

The prototype should not automatically become the application. Generated interfaces may contain brittle state management, duplicated components, inaccessible controls and styling that ignores the organisation’s design system. Designers remain necessary, but their work shifts towards defining principles, understanding users, judging alternatives and protecting coherence across products.

The full lifecycle is now in scope

The emerging model reaches across the whole software lifecycle. Business intent is converted into requirements and discovery. Design alternatives become interactive prototypes. Architecture and implementation agents produce candidate solutions. Independent assurance examines functionality, security, accessibility and operations. Deployment and production evidence then feed the next round of decisions.

This circular model matters. Software is not finished when a pull request is merged. Production behaviour, support incidents, user feedback and operational cost must influence later requirements, redesign and modernisation.

Agents can help generate pipelines, investigate failed builds, analyse logs and prepare remediation. They can maintain technical documentation as systems change. They can compare current behaviour with a replacement system during a migration. They can also create new failure modes, particularly when given excessive permissions, weakly controlled external access or misleading instructions.

The wider the agent’s reach, the more important the surrounding controls become.

Legacy estates are where the model is tested

Legacy estates are where the three-part model becomes most important, because the control plane is often fragmented, the intelligence layer lacks reliable context, and assurance is weakest precisely where business risk is highest.

The .NET examples used here are illustrative rather than prescriptive. The same pattern applies to Java, COBOL, mainframe, packaged, database-centric and mixed-language estates.

The AI industry often demonstrates a new application built from a blank page. Most CIOs manage a very different environment, where modern and legacy systems coexist across multiple repositories, delivery tools and operating environments.

A typical established organisation may have modern .NET services beside older .NET Framework applications, SQL Server databases, stored procedures, batch processes, file transfers, desktop software, cloud services and on-premise infrastructure. Test coverage is uneven. Documentation is incomplete. A few experienced staff may hold knowledge that never reached a formal specification.

This is not a side issue. It may be one of the strongest uses of AI.

An agent can help inventory the estate, map dependencies, identify unsupported frameworks and trace business rules across application code and stored procedures. It can draft characterisation tests that capture existing behaviour before a change is attempted. It can generate a modern interface prototype and compare the outputs of old and replacement components.

The value is not that the agent knows the business better than the people running it. It reduces the cost of reaching the point where those people can make informed decisions.

Legacy systems also expose the limits of automation. Their behaviour may reflect historical regulation, customer exceptions, data-quality problems and manual workarounds that are not visible in source code alone. An agent can describe what the code appears to do. It cannot assume that the implementation contains the complete intended rule.

Responsible modernisation therefore remains incremental. The organisation inventories the system, recovers dependencies and rules, creates tests, considers architecture and interface alternatives, converts bounded components and reconciles old and new behaviour before cutover.

This is also where the control plane, intelligence layer and assurance model prove their value. The control plane records the change. The intelligence layer can be swapped or compared. Assurance determines whether the result is sufficiently understood to proceed.

What has genuinely changed by July 2026

The evidence now supports several firm conclusions.

Agents can perform sustained repository tasks rather than returning a single code suggestion [1][4][5]. Work can be divided among parallel or specialised agents [2][4][6]. Different vendors’ agents can operate through a common repository workflow [3]. Agent harnesses are becoming platforms that other tools can embed, rather than remaining closed features inside one editor [7].

The movement is also crossing the boundary between professional developers and the wider organisation. OpenAI reports Codex being used to create internal applications, dashboards, incident material and other outputs that previously required a conventional hand-off to a software team [8]. This is a vendor account and should not be mistaken for independent proof of universal productivity. It does show that the scope of the technology is expanding.

What has not changed is equally important. Software still fails when the organisation misunderstands the problem, tolerates fragmented architecture, treats security as an afterthought or allows systems to evolve without accountable ownership.

AI magnifies the engineering organisation beneath it. A disciplined company can use it to shorten discovery, explore alternatives, improve testing and modernise systems. A disorganised company can generate more duplicate services, inconsistent code and technical debt than its people can understand.

The decision facing CIOs

The response should not be a vast purchase of whichever product currently has the strongest demonstration. Nor should it be an endless pilot that avoids making any strategic commitment.

A credible starting position is to treat AI as a lifecycle transformation rather than an editor feature. The organisation should keep its engineering control plane stable, approve a small and replaceable portfolio of agents, and evaluate those agents against its own repositories and representative tasks.

The test set should include work that matters to the organisation: explaining a legacy transaction flow, diagnosing a known defect, creating characterisation tests, generating an interface prototype within the design system, modernising a component and repairing a delivery pipeline.

The company should measure accepted outcomes rather than usage. Licence activation, prompt counts and generated lines of code are weak indicators. More useful measures include reviewer effort, defect escape rate, time to understand an unfamiliar system, cost per accepted change, test coverage gained and performance after several months of maintenance.

Application risk should determine autonomy. An internal reporting tool and a payment-processing system should not operate under the same permissions. Low-risk tasks may eventually proceed automatically when every control passes. High-risk work should retain explicit human approval.

Most importantly, accountability must remain clear. An agent may analyse, propose, implement and review a change. It does not carry the organisational consequence when that change fails in production.

Conclusion

Software development has already moved beyond Copilot.

Autocomplete remains useful, but it no longer defines the frontier. AI systems can investigate repositories, perform multi-step work, create pull requests, operate asynchronously and contribute across requirements, design, prototyping, implementation, assurance and operations.

The larger change is not simply that machines can produce more code. It is that software work can be reorganised among people and specialised agents, with different views brought forward before an accountable decision is made.

The future software team may not be one developer using one assistant. It may be a human-led organisation capable of assembling temporary groups of agents for each problem, testing their proposals against evidence and converting the chosen approach into controlled, reviewable software.

The organisations that benefit will not necessarily be those that buy the most licences. They will be those that redesign software production without abandoning the disciplines that make software trustworthy.

Next in the series

The State of AI Software Development in July 2026

The next article will map the current market and distinguish between interactive assistants, repository agents, asynchronous agents, parallel-agent systems, design and prototyping platforms, open-source alternatives and enterprise orchestration tools. It will also separate what is usable now from what remains experimental, immature or speculative.

References

[1] OpenAI (2026) ‘Introducing the Codex app’. OpenAI, 2 February. Available at: https://openai.com/index/introducing-the-codex-app/

[2] OpenAI (2026) ‘Subagents’. OpenAI Developers. Available at: https://developers.openai.com/codex/subagents/

[3] GitHub (2026) ‘Pick your agent: Use Claude and Codex on Agent HQ’. GitHub Blog, 4 February. Available at: https://github.blog/news-insights/company-news/pick-your-agent-use-claude-and-codex-on-agent-hq/

[4] Anthropic (2026) ‘Create custom subagents’. Claude Code Docs. Available at: https://docs.anthropic.com/en/docs/claude-code/sub-agents

[5] Google (2025) ‘Jules, our asynchronous coding agent, is now available for everyone’. Google Blog, 6 August. Available at: https://blog.google/innovation-and-ai/models-and-research/google-labs/jules-now-available/

[6] Anthropic (2026) ‘Building a C compiler with a team of parallel Claudes’. Anthropic Engineering, 5 February. Available at: https://www.anthropic.com/engineering/building-c-compiler

[7] OpenAI (2026) ‘Unlocking the Codex harness: How we built the App Server’. OpenAI. Available at: https://openai.com/index/unlocking-the-codex-harness/

[8] OpenAI (2026) ‘Codex for every role, tool, and workflow’. OpenAI, 2 June. Available at: https://openai.com/index/codex-for-every-role-tool-workflow/