Simplify Before You Automate: Building an Adaptive AI Delivery Strategy

Part 9 of the Software Development in the Age of Al series

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/