AI-First Software Modernisation

Executive Summary

Everyone wants AI agents running their business. Almost no platform is ready for them.

The numbers back this up. 88% of organisations now use AI in at least one business function, yet only 39% report any impact on earnings at the enterprise level. In no single business function do more than 10% of organisations report scaling AI agents. Nearly everyone has adopted AI. Far fewer are getting value from it.

The root cause is rarely the AI itself. AI is an amplifier. It speeds up well-structured systems and disciplined teams, and it amplifies coupling, poor test coverage and knowledge gaps just as efficiently. So genuine AI adoption is not a technology purchase. It is a modernisation journey: a strategic evolution of your software and the way you build it.

That journey rests on two foundations: an AI-ready system, which provides a modular and observable architecture for AI tooling and agents to operate safely, and AI-accelerated engineering, which offers the practices and processes that enable your teams to build, change, and ship with AI without the platform falling behind. Neither alone gets you there.

This guide sets out our approach to building both. Four steps, from discovery and assessment through engineering foundations and system modernisation to AI-native workflows, delivered incrementally with measurable value at every stage. It covers the technology, the people and the processes, grounded in the software craftsmanship that has defined our modernisation work for over a decade.

We have been running AI-First Software Modernisation efforts for our clients. The gains are real, but they are earned. This guide shows you how.

The problems 

There are telltale signs that AI adoption is not going well. Most organisations we speak to recognise several of them.

The business case doesn’t add up. Everyone is adopting AI. You have demos that show promising improvements, and AI token usage is through the roof, but actual commercial outcomes are either elusive or marginal. There are a lot of little improvements to the product and processes, but has the return been worth the investment?

Chaotic use of AI. Everyone is using their own tools and approaches. No one fully understands the risks. You know what you are spending on AI tooling now, but not how those costs will behave as usage grows.

Code reviews are the new bottleneck. Your senior developers are spending more time reviewing code generated by AI-agents and AI-assisted junior developers. They are not happy because they’re becoming a bottleneck, and it is taking their focus away from addressing the hard challenges.

Too coupled. You see a lot of prototypes, but they either never make it to production or they work outside your main systems, duplicating features or re-routing behaviour around them. It can look like you are slowly migrating to something more modern. Without a clear plan, though, you are simply reducing cohesion and making future changes more difficult and risky.

Too untested. The defect rate has started to creep up, even though your test codebase is growing faster than ever. It is now very easy to generate tests from existing code. But are they testing the correct behaviour, or simply reflecting what is already there? Tests that encode wrong assumptions add complexity and give you false confidence.

A mandate without a map. The size of the change sets is increasingly disproportionate to the size of the intended behavioural change. Everyone can now restructure the codebase almost at the speed of thought, and every developer can pursue their pet ideas. Your codebase becomes a battleground for everyone’s individual will. Not a new problem, but one that used to be constrained by typing speed.

Knowledge distribution running thin. The faster we churn out code without discipline, the faster we lose confidence in the codebase. The proportion of code no longer understood by anybody, what we call cognitive debt, keeps rising. Everyone becomes increasingly reliant on trusting the AI to do the right thing: cognitive surrender.

Modernisation that made things worse. You have tried modernisation accelerated by AI, and watched it create more complexity than it solved. Meanwhile your engineers spend more time working around the platform than building on it.

These symptoms share a diagnosis. A lack of return on AI investment exposes weaknesses in the operating model. Because AI amplifies whatever it touches, looking at your organisation through the lens of AI adoption shows you exactly where the operating model needs to evolve.

The whiplash effect. A study of engineering organisations adopting AI at scale found coding tasks up 210%, bugs per developer up 54%, and 31% more pull requests merged without any review. This acceleration-instability whiplash appears regardless of baseline engineering maturity. McKinsey’s latest global survey reaches a similar conclusion: at most organisations, the move from pilots to scaled impact is still a work in progress.¹

The opportunity 

AI presents an opportunity to evolve customer journeys, business workflows, and the software development lifecycle (SDLC) itself.

The opportunity is not to use AI to make existing things a little better. It is to rethink how software supports the way the business delivers value to its customers, and how teams build, change and operate that software. These two connected dimensions translate into concrete commercial results. Intelligent business workflows drive product innovation and internal efficiency. Improved productivity within the SDLC speeds up time to market and reduces the cost of change. Together they create a direct path to increased revenue and improved profit.

Intelligent business workflows

Everyone is building AI-powered features into existing products. Mostly, they are add-ons that provide marginal improvements to existing customer journeys. There is nothing wrong with that. It creates useful gains and improves parts of the experience.

The bigger opportunity is to build systems that adapt their behaviour to the needs of the customer. A chatbot that simply triages the customer to a particular department is not enough. A system that understands what the customer wants, brings together the right information and services, and proactively helps them complete their task within the same context: that is an integrated, adaptive customer experience.

Building features like this is not just a question of adding a dynamic AI-generated UI. It needs an operating model where software, data, architecture, governance and business processes are aligned to support that behaviour. Done well, it leads to new and improved products, better customer journeys and more efficient internal processes.

Improved productivity

The bottleneck in software delivery has always been the speed at which we can understand, write, change and verify code safely. AI can relieve these bottlenecks across the whole SDLC: ideation, analysis, design, development, testing, deployment and operations.

This is more than using AI as a coding assistant. Continuous agents can work alongside the team to analyse systems, suggest improvements, generate changes, verify quality and help operate software. In that sense, AI extends Continuous Delivery towards Continuous AI. The result is faster time to market and a lower cost of change.

The combined effect

These two areas reinforce each other. Intelligent business workflows create the opportunity for new products and better experiences. Improved productivity gives you the ability to build, change and operate those capabilities quickly and safely. Together, they increase revenue and improve profit.

Codurance didn’t just help us modernise; they gave us a platform that could actually support the AI ambitions we had. The craft they brought to the codebase was the foundation everything else was built on.

CTO, Global Insurance Platform

AI-adoption maturity

Maturity models for AI adoption are nothing new. They usually chart a path from individual, ungoverned, tactical use towards a collaborative, governed, strategic vision. That progression is useful for setting direction. But most models describe a linear journey along a single dimension, and in doing so they conflate two distinct initiatives that need to support each other.

We assess maturity along two interacting dimensions: AI-ready systems, which align with the next valuable increment of business change, and AI-accelerated engineering, which supports the delivery of that change.

AI-ready systems

A mature AI-ready system is not a chatbot bolted onto an existing UI. It is an environment designed for adaptive, integrated and governed behaviour, and it sets you up for agent-first systems later.

• Observable and modular architecture. The system is modularised into domains that AI agents can discover and consume, and it is fully observable. Telemetry covers infrastructure health, behaviour, latency, and the quality of AI-driven interactions.

• Governed data foundation. Agents are only as reliable as the data they act on. A governed source of truth, with knowledge held in forms agents can retrieve and trust, underpins everything else.

• Security, compliance and data classification. Guardrails are built into the architecture. Data classification policies make sure sensitive data is masked or anonymised before it reaches a model, backed by automated access controls and compliance checks that run continuously, not periodically.

• Cost and usage transparency. Instead of token usage through the roof, every AI interaction maps to a business outcome. Granular cost visibility gives you real budget discipline and a credible way to measure ROI.

• Model and deployment flexibility. Models are selected and routed by task rather than locked to a single provider, and the system runs where the business needs it: cloud, hybrid or on-premise, with credible exit paths.

AI-accelerated engineering

AI-accelerated engineering applies AI across the SDLC to increase speed while raising quality. It is disciplined, high-performance engineering with clear governance.

• Approved toolchain and policy. Teams work within a curated, approved AI toolchain. The AI policy is not a document gathering dust; it is built into the toolchain as guardrails that define acceptable use and risk boundaries.

• Quality discipline with AI in the loop. AI output is validated against intended behaviour, and AI-written code is held to the same craft standards as any other. Continuous delivery keeps changes small, safe and frequent.

• Software designed to ease AI comprehension. Code structured to establish good patterns for AI to follow. Concise machine-consumable documentation and focused commands to reduce the context an agent must load for improved speed, reliability and token efficiency.

• Deterministic commands and tools to complement AI. Tests, compilers, linters, static analysis or other deterministic tools complement AI usage where they are more efficient, effective, and increase token efficiency.

• Measurement and human oversight. AI investment is traced to delivery and commercial metrics, not activity. Accountability stays with people, with clear approval points where it matters.

• Portfolio oversight and risk management. Treat AI initiatives as an investment portfolio. Leadership prioritises high-impact use cases, audits for shadow AI, and makes sure delivery lines up with the target operating model.

• A culture of enablement. Active Communities of Practice share learnings, demos and failures. Reusable patterns and playbooks, such as prompt templates, skills, validated architecture blueprints and automated security test suites, make best practice the path of least resistance.

AI Integration & Product Strategy

For SMEs with limited technical resources and smaller engineering teams, the decision to use third party AI or Large Language Model (LLM) services versus building solutions in-house involves balancing speed, cost, control, and risk.

The Strategic Choice: Build vs. Leverage

• Building a foundational LLM from scratch is neither financially viable nor strategically wise for SMEs. This path requires massive cleaned and curated datasets, specialised GPU infrastructure, deep technical expertise, and millions in ongoing operational costs.
• However, building smaller, task-specific AI models (e.g., classifiers, recommenders, forecasting models) using open-source frameworks (like Scikit-learn, PyTorch, or TensorFlow) is often a practical and high-ROI approach for narrow, well-defined problems.

For general-purpose LLM capabilities (summarisation, code generation, etc.), the clear strategic path for SMEs is to leverage pre-trained foundation models. Competitive differentiation is achieved by customising these models with proprietary data, primarily through two key approaches:

• Retrieval-Augmented Generation (RAG): This technique keeps proprietary data external to the model. The LLM retrieves relevant context from a database at query time, allowing it to answer questions based on internal documents or customer data without retraining.
  

  Example: A legal tech SME could integrate RAG with its contract database to provide tailored summaries or clause suggestions using an open-weight model.

• Fine-Tuning Open-Weight Models: SMEs can fine-tune models such as Llama 3, Mistral, or Falcon using their own domain- specific data. This creates a specialised model aligned with the company’s language, style, and workflows.
  Example: A customer support platform might fine-tune an open-weight model to handle product-specific queries in its support chatbot.

These approaches allow SMEs to use their proprietary data moat to build differentiated solutions while avoiding the astronomical costs of model training. 

Balancing Agility, Cost, and Risk

Leveraging third-party APIs drastically shortens Time to Value (TTV) and shifts R&D requirements from heavy CapEx to predictable, scalable OpEx. SMEs can prototype and deploy features in weeks, not months. However, this agility comes with strategic trade-offs:

Vendor Lock-In: Relying heavily on a single AI provider (e.g., OpenAI, Anthropic, or Google) creates dependency risks. Pricing models may change, rate limits may tighten, or the provider could discontinue certain APIs.

Data Privacy and Compliance Risks: Using third-party APIs can raise concerns about how customer or proprietary data is transmitted, stored, and used. SMEs in regulated sectors must ensure compliance with standards such as GDPR or HIPAA.

Service Availability and Latency: Outages or service degradations from the provider can directly impact customer-facing applications, leading to operational downtime.

To mitigate these risks, SMEs should:

• Abstract model integration behind an internal API layer so providers can be swapped with minimal disruption.

• Adopt a multi-vendor strategy (e.g., supporting both OpenAI and Anthropic endpoints).

• Use open-weight models where feasible for privacy-critical workloads.

• Maintain local RAG pipelines so that proprietary data remains within the company’s control.

Cost, Control, and Long-Term Strategy

• Short-Term: Third-party APIs are cost-effective for experimentation and MVPs.

• Medium-Term: As usage scales, API costs can become significant, especially for inference-heavy applications. At that point, SMEs might consider self-hosting open-weight models for predictable costs and greater control.

• Long-Term: A hybrid approach that uses commercial APIs for generic tasks and in-house fine tuned models or RAG for proprietary data often strikes the optimal balance between cost, agility, and risk management.
  
  

Our maturity scale 

We evaluate both dimensions against five capability levels:

Our approach: AI-First Software Modernisation 

The potential for AI to transform business is undeniable. Capitalising on it is far from simple. It demands the same strategic mindset as software modernisation, and we believe true AI adoption is fundamentally a modernisation journey. That is why we call strategic AI adoption AI-First Software Modernisation.

Any technology investment must support value creation. But knowing what you want is not enough. Execution needs a detailed understanding of what good looks like, where you are now, and what the next step is, with feedback built into every increment.

Our approach is an incremental journey from strategy to measurable business value. It starts with discovery and assessment, which sets the direction for both engineering foundations and system modernisation. Those two run in a tight and continuous feedback loop, and build towards an agentic, AI-ready software architecture: the foundation on which AI-native product features and workflows are built. What we learn building those features flows straight back into the architecture and the next modernisation increment.

Value does not wait until the end. It arrives as three overlapping streams. Improved productivity ROI starts almost as soon as the engineering foundations work begins. Improved quality and AI-readiness ROI follows as modernisation makes the system safer to change. AI-native business workflow ROI arrives last, and is the biggest prize. Each stream keeps compounding, and together they add up to measurable ROI.

Step 1: Discovery and assessment. We assess your current system and SDLC maturity against your business objectives, and identify the specific blockers to modernisation and AI readiness. The outcome is a prioritised, sequenced roadmap. For each increment, foundational work is scoped to exactly what that increment needs. No more.

Step 2: Engineering foundations. We embed the practices that make safe, fast change possible: test coverage through TDD and characterisation testing, observability, and improved CI/CD cadence. Each improvement immediately unlocks bolder structural change.

Step 3: System modernisation and AI-ready architecture. Embedded craftspeople work alongside your teams to incrementally decompose monoliths and evolve the system towards a modular, observable, AI-ready state, always in the context of the next AI-native goal.

Step 4: AI-native workflows. Agent integration patterns, MCP servers and event-driven contracts are introduced as the system becomes ready to support them. As agents operate in practice, their requirements feed the next modernisation increment.

The journey is not linear or one-off. Step 1 is revisited after every delivered increment, and
Steps 2 and 3 reinforce each other continuously.

We have spent over thirteen years modernising complex legacy systems across financial services, insurance, healthcare and beyond, applying software craftsmanship: incremental delivery, no big bang, no multi-year programmes that go dark, and no full rewrite. Our craftspeople embed in your teams, and the skills and practices stay when we leave.

The rest of the guide is a deeper explanation of these steps.

Step 1: Discovery and assessment

Discovery and assessment identifies the specific opportunities, constraints and priorities for AI adoption in your organisation. The maturity model tells us what good looks like in general; this phase applies that to you.

The work has three parts. First we set the direction: what the business needs AI to deliver, and what winning looks like. Then we map the current state. Finally we decide the target state: the next maturity level worth reaching, not a distant ideal. The roadmap, the main output of this phase, is the sequenced path between the last two.

Setting the direction

We start with the business, not the technology. A short series of focused sessions with your leadership aligns everyone on what AI needs to deliver and what winning looks like. Two workstreams:

Strategic context and business alignment. We align on board-level expectations and how AI fits the value story: where margin is under pressure, what AI needs to deliver to be commercially viable, and the ROI and success criteria for the engagement.

Competitive benchmarking. A grounded analysis that separates real, shipped capabilities from industry hype, and identifies the defensible advantages your rivals cannot easily copy.

Together, these tell us what AI needs to deliver for the business and the constraints we have to respect. What they do not yet tell us is where you are starting from. That is the next job.

Understanding the current state

Direction in hand, we turn inwards. We map the current state of your software architecture, platform, development processes and delivery practices. These live within the wider context of your operating model, so we also map how your business flows work today and how technology supports them.

Two workstreams get this assessment past surface claims:

AI initiatives and roadmap audit. An honest look at what is genuinely delivering value: which features are live, which are prototypes, which are shelved ideas. We also separate what is bought (third-party dependency) from what is owned (your own IP and data advantage).

Platform, data and infrastructure mapping. We trace the data flow end to end and evaluate your readiness to put AI into production: governance, lineage, quality controls and data ownership, and whether your data architecture holds AI back or enables it.

A note on scope. We do not reorganise departments or change business governance frameworks. We do analyse the operating model, covering structure and governance, the service blueprint, technology and data, people and culture, and KPIs, because it tells us where AI and modernisation deliver the most value. Our focus stays on the technology and data foundations and the service blueprint. That said, the artefacts we produce along the way often prove valuable well beyond the modernisation programme itself.

Our analysis looks at the organisation through four foundational pillars: Architecture, Platform, Practices and Processes. These pillars support the 2 foundations for AI-native business and product as visualised below.

Supporting pillars for AI-ready systems and AI-accelerated engineering

During the analysis, the artefacts produced depend on your needs and the scope of the engagement:

We map the findings to a maturity profile that everyone understands and agrees with. That shared baseline is what the next evolutionary step is planned from. There are a number of detailed artefacts produced which are then condensed into an executive summary that aims to create alignment on the more pertinent points.

Example assessment output: current state

Current state: SDLC & engineering practices · Maturity profile: Emerging (Level 2)

Our current SDLC is characterised by localised AI adoption: engineering teams use AI tools in an ­
ad-hoc, individual fashion. This has unlocked pockets of productivity, but lacks the unified governance, security guardrails and quality assurance needed to scale AI-accelerated delivery safely.

Chaotic tooling: no curated, approved AI toolchain; developers experiment with disparate tools, producing inconsistencies in code quality, security posture and data handling.

Reactive quality assurance: we generate tests and code faster, yet defect rates are rising.
AI-generated tests reflect existing assumptions rather than verifying intended behaviour, building cognitive debt.

Shadow AI: prototypes are built outside primary CI/CD pipelines, fragmenting the architecture.

Siloed knowledge: effective prompts, patterns and lessons live with a handful of power users, so capability depends on individuals rather than the organisation.

No oversight: AI-generated change reaches production without agreed approval points, and when something goes wrong accountability is unclear.

Missing feedback loops: we cannot map AI token investment to delivery performance gains such as deployment frequency, lead time, or MTTR.

Strategic impact: staying at this level amplifies undisciplined work. Technical complexity grows without a matching increase in delivery velocity or quality, and the stability of critical operational systems is at risk.

Deciding the target state

To decide the target state we bring the first two parts together: the direction set with the business, and the honest picture of where you are now. The business roadmap is accompanied by a technical roadmap that evolves the system and practices in step with business needs, without running so far ahead that technology change loses its connection to ROI.

The same four pillars structure the target state. Architecture spans how software supports the service blueprint, how it is modularised into domains, and how teams are organised around it. Platform covers how software operates across environments, and the automation that builds, tests, deploys and provisions. Practices and processes embody the quality and discipline of the SDLC, what DORA calls the capabilities of high-performing teams: continuous integration, continuous deployment, fast feedback, infrastructure as code, and more.

AI-native systems bring their own concerns, and the target state adapts them into the foundational pillars. The diagram below summarises them.

On the AI-ready system side: agentic capabilities, agent-consumable interfaces and a governed data foundation in the architecture, with the control plane, observability and security to run them on the platform.

On the AI-accelerated engineering side: the practices that keep quality high with AI in the loop, and the processes that direct, measure and govern the whole. None of this is built up front. The roadmap sequences these concerns, and the system evolves to address each one as and when the next increment needs it. Steps 2 and 3 unpack the two foundations in detail.

Target-state artefacts mirror the current-state analysis: a target service blueprint and value proposition showing where AI replaces, augments or creates value; a target application portfolio and architecture roadmap, including a Wardley map of what to commoditise versus what to build; target context and data flows; governance and policy roadmaps; an enablement and upskilling plan; and target KPIs with a reporting framework. A decision and trade-off log preserves the reasoning behind every significant choice.

Example assessment output: target state

Target state: SDLC & engineering practices · Maturity profile: Developing (Level 3)

To evolve from Emerging to Developing we move from ad-hoc individual experimentation to a strategic, governed approach, establishing foundational consistency without needing full-scale enterprise transformation.

Curated AI toolchain: sanctioned, secure, performant tools with room to experiment within guardrails.

Intentional AI testing: AI outputs validated against intended behaviour; AI-generated tests held to the same review and CI standards as human-written code.

Structured experimentation: AI usage tracked through departmental OKRs, correlating tool usage with lead time and deployment frequency.

Knowledge consolidation: Communities of Practice share validated prompt templates, skills, blueprints and lessons learned, so knowledge is distributed rather than siloed among power users.

Deliberate oversight: clear approval and escalation points for AI-generated change; accountability stays with named people, not tools.

Strategic impact: we move from amplifying chaos to accelerating disciplined delivery. AI becomes a multiplier for our engineering standards, productivity gains become measurable, and the codebase stays secure, maintainable and well understood.

The three parts come together in the roadmap: a sequenced path from current state to target state, heading in the direction the business set. It is supported by a maturity diagnostic, a prioritised AI opportunity map sized and sequenced by ROI and feasibility, a platform and data readiness view, and a gap analysis with KPIs and success criteria for each increment.

Questions to ask your team

Which of our AI initiatives are live in production, and which are prototypes or demos?

Can we trace what we spend on AI tooling to any delivery or commercial metric?

What would be the assessment if we faced a due diligence audit for an exit?

What would we stop doing if we saw the evidence?

Step 2: Engineering foundations

We embed the practices and processes that make safe, fast change possible. Foundation work is always scoped to what the next system modernisation increment needs, and each improvement immediately unlocks bolder structural changes.

Low test coverage is the single most common blocker to safe modernisation, and to safe AI adoption. This is no coincidence: 90% of developers now use AI at work, yet 30% report little or no trust in the code it generates.² The safety net that lets humans change code confidently is exactly the safety net that lets AI-generated change land safely.

The bottleneck has moved from writing code to gaining confidence in it. An agent can generate a thousand lines in minutes; reviewing them properly can take longer than writing them by hand. Without a safety net, your senior engineers become full-time reviewers, and the review queue becomes the new constraint.

This step builds the second foundation: AI-accelerated engineering. The diagram below shows its concerns across the practices and processes pillars. The work here concentrates on the practices that unblock everything else: intentional AI testing, code stewardship, a curated toolchain and continuous delivery discipline. The people-centred concerns, from knowledge sharing to enablement and oversight, are picked up in People, culture and knowledge, and measurement and feedback in Measuring success.

Building the safety net. We rapidly improve coverage using characterisation testing, which captures the system’s actual behaviour so legacy code can be changed without fear. With legacy systems the hard part is rarely the syntax; it is preserving decades of accumulated business behaviour, thousands of implicit rules written down nowhere. Characterisation tests capture those rules before anything is allowed to change them. We coach TDD, and use mutation testing to check that tests verify intended behaviour rather than merely reflecting what exists. This directly tackles the “too untested” problem: test suites that grow quickly but prove nothing.

Code stewardship. AI-written code is reviewed and owned like any other; the craft standards do not change with the author. We help teams focus review effort where the safety net says risk is highest, so seniors stop rubber-stamping volume and start catching what matters. Ownership stays with the team that merges the change, not with the tool that wrote it.

A curated toolchain. We help you converge on a sanctioned, secure set of AI tools, with room to experiment inside guardrails. We do not use AI where deterministic tooling can provide the answer. Tests, compilers, type checkers, linters, static analysis and security tools give agents fast, reliable feedback without consuming model reasoning.

Context Engineering. We structure repositories so agents can understand the product, domain and architecture without repeatedly reconstructing that knowledge from source code. Product specifications, executable examples, architecture decisions, usage guidance, domain terminology and engineering conventions are kept concise, current and accessible to both humans and AI.

Observability. You cannot operate AI agents on systems you cannot observe. We instrument platforms with structured logging, distributed tracing and real-time dashboards. This is the telemetry that will later tell you whether AI-driven change is helping or hurting.

Delivery cadence. We improve CI/CD pipelines and release cadence so that smaller, safer changes flow to production more often. DORA’s research is clear on this point: AI amplifies the strengths and weaknesses of your existing engineering practices, and without these disciplines it increases delivery instability even as throughput rises.²

This phase runs in a tight feedback loop with system modernisation (Step 3). The two happen largely in parallel.

Case study: 60% faster to production. An embedded SaaS provider couldn’t absorb AI-accelerated output The platform was too untested to take the volume of change safely. Codurance embedded TDD, rebuilt the test pyramid and modernised the pipeline, cutting time to production by 60% in six months.

Questions to ask your team

What proportion of our critical paths are covered by tests we trust?

If an AI agent merged a change right now, how would we know whether it broke something?

Which AI tools are our teams actually using, and how many of them did we approve?

How long does a one-line change take to reach production, and why?

Step 3: System modernisation and AI-ready architecture

Embedded craftspeople work alongside your teams to incrementally decompose the monolith and evolve the system towards a modular, observable, AI-ready state. Each increment is shaped by the next AI-native goal, and surfaces the next round of engineering foundation work needed. We avoid work that the current increment does not require.

Context is the biggest technical bottleneck in AI-assisted engineering today. An experienced engineer carries years of accumulated knowledge: why the system evolved the way it did, which approaches failed, where the hidden business rules live, what the regulator expects. AI only sees what you give it. Much of this modernisation work is really about turning that implicit knowledge into something explicit that agents can consume: clean domain boundaries, executable specifications, documented architecture, discoverable APIs and observable behaviour.

This step builds the first foundation: the AI-ready system. The diagram below shows its concerns across the architecture and platform pillars. The work described here tackles the ones every increment depends on: bounded domains agents can reason about, agent-consumable interfaces, event-driven integration, a governed data foundation and an observable platform. The rest, from model strategy to the control plane, durable workflows and the agent security surface, arrive as the AI-native workflows in Step 4 demand them, not before.

Modular systems AI can reason about. We decompose monoliths using the Strangler Fig pattern and Domain-Driven Design, into well-bounded, independently deployable services that humans and AI agents can both safely change. Bounded contexts matter doubly in an AI-first world. They limit the blast radius of any change, and they give agents a domain model small and coherent enough to reason about reliably.

Clean contracts and event streams. We redesign around API-first principles and event-driven architecture, exposing clean contracts and real-time event streams that agents can subscribe to and act on. MCP servers are emerging as the standard surface through which agents discover and consume these capabilities. Designing for them now saves you retrofitting later.

A data foundation agents can trust. Agents are only as good as the data they act on. We evolve the data architecture towards a governed source of truth: clear ownership and quality standards, lineage from source to agent, and knowledge held in structured, semantic and retrieval-ready forms. Without this, every AI initiative rediscovers the same data problems from scratch, and the answers agents give cannot be traced or trusted.

A platform ready for AI workloads. Cloud-native infrastructure that scales for AI workloads without compounding spend, instrumented end to end. This matters more than ever: DORA finds platform engineering now nearly universal, at 90% adoption, with a quality internal platform the essential foundation for turning AI investment into performance.²

The result is not just cleaner architecture. It is a system where the cost of change drops steadily, and that is precisely what makes previously prohibitive modernisation work commercially viable in the AI era.

Case study: 90 → 0 concurrent incidents. A financial services monolith was averaging ninety concurrent incidents. Domain-Driven decomposition into bounded contexts brought that number to zero over twelve months, producing a system that humans and AI agents can both safely change.

Questions to ask your team

• • Could an AI agent discover what our system does without reading the source code?

  • Where are our domain boundaries, and does the code actually respect them?

  • If an agent answered a question from our data today, could we trace where the answer came from, and would we trust it?

  • Which parts of the estate does everyone avoid touching, and what does that cost us?

Step 4: AI-native workflows

Agentic readiness is always in the context of what you want to achieve. The concerns Step 3 deliberately deferred arrive here, as the workflows demand them: a model strategy that keeps you portable across providers, the control plane that governs what agents may do, durable workflows with human-in-the-loop approval, and the hardened security surface that agents operating in production require. As agents operate in practice, their requirements surface gaps in API surfaces, data, observability and architecture that feed directly into the next system modernisation increment.

This is where the two foundations pay off together. Intelligent business workflows, from adaptive customer experiences to automated internal processes and agents orchestrating decisions across the enterprise, become achievable because the system is modular and observable, and because engineering can ship AI-accelerated change safely.

Modernisation is an evolutionary process, not a destination. Once each increment is delivered, we close the loop and recalibrate through three continuous feedback mechanisms:

Operational feedback loops (Architecture & Platform). AI-aware observability tells you whether the architecture is genuinely supporting adaptive behaviour. Are services discoverable and consumable by agents? Is the platform delivering cost-effective performance?

Capability evolution (Practices & Processes). Playbooks are updated with what worked and what didn’t. Communities of Practice share validated patterns and guardrails, preventing the cognitive surrender that grows when teams increasingly lean on agentic AI.

Knowledge loops. Insights from live AI interactions feed back into portfolio analysis and risk plans, so the next roadmap increment is based on real-world evidence rather than the original assumptions.

Case study: from 1 to 1,000+ customers. A PE portfolio company’s platform failed on every second customer. Codurance rebuilt the foundations in-team, incrementally, with no full-rewrite. Within nine months the platform supported over a thousand customers, and the business was exit-ready.

Questions to ask your team

What is the first business workflow we would trust an agent to run, and what is stopping us today?

Which decisions in that workflow must stay with a human, and is that enforced anywhere?

When an AI feature misbehaves in production, how quickly do we find out, and from whom?

What did our last increment teach us that changed the next one?

People, culture and knowledge 

Technology is only one of the three threads. AI-First Modernisation succeeds or fails on whether people change how they work, and whether knowledge keeps flowing as delivery speeds up.

The cultural problems are the ones described at the start of this guide. Cognitive debt: the proportion of code understood by nobody keeps growing. Cognitive surrender: teams stop verifying and start blindly trusting. Both are cultural problems before they are technical ones,
and both respond to the same treatment: make understanding a first-class deliverable.

Communities of Practice give teams a forum to share wins, failures and validated patterns,
from prompt templates, skills, to architecture blueprints and security test suites. Knowledge gets distributed rather than concentrated in a few power users, and best practice becomes the path of least resistance rather than an act of discipline.

Embedded coaching and knowledge transfer. Modernisation only sticks when your teams own it. Our craftspeople embed in your engineering teams rather than working next to them: pairing, coaching TDD, and passing on the everyday SDLC discipline that lets AI-accelerated change actually reach production. The skills and practices stay when we leave. Dependence on us does not.

Upskilling with intent. An enablement plan ties training to the roadmap. Teams learn characterisation testing when the increment demands it, and agent integration patterns when the system is ready for them. The skills that matter are changing too: decomposing problems well, designing architecture, reviewing AI output critically, and making sound trade-offs. AI raises the value of engineering judgment; it does not replace it. DORA’s AI Capabilities Model points the same way: a clear AI policy, a healthy data ecosystem and a user-centric focus do far more to amplify AI’s benefits than buying more tools.²

Human oversight as a habit. The approval and escalation points that govern agent-driven change are only as good as the people who own them. We help teams agree where a human must stay in the loop, who is accountable for what an agent does, and when to escalate. Oversight becomes a working habit, not a checkbox at the end of a pipeline.

Clear ownership. Teams stay aligned to the domains they own, and that ownership extends to the agents, data and outcomes within them. When an agent misbehaves in production, it is immediately clear whose problem it is.

None of this requires reorganising your company. It requires deliberate investment in the practices, forums and coaching that keep humans confidently in command of an accelerating system.

Measuring success

Continuous measurement is what separates an evolutionary programme from a leap of faith. It is also how you avoid the acceleration whiplash of jumping between unverified prototypes.³

Our approach describes three ROI streams that arrive at different times and show up in different numbers. Each needs its own yardstick.

Improved productivity ROI arrives first, as the engineering foundations take hold. Measure it with DORA’s throughput metrics: lead time for changes and deployment frequency. The question is simple: are we shipping faster, and is the cost of change falling?

Improved quality and AI-readiness ROI follows as modernisation makes the system safer to change. Measure it with DORA’s stability metrics: change failure rate and MTTR, alongside defect rates and incident counts. Faster delivery only counts if it stays reliable, and this is the stream that catches whiplash early.

AI-native business workflow ROI arrives last and is the biggest prize. Measure it in business terms: revenue from new AI-driven capabilities, cost per process handled, customer outcomes, and the quality of agent interactions in production, judged by continuous evaluation against intended behaviour rather than anecdote. This is where AI investment must ultimately show up.

Across all three, measure outcomes rather than activity. Token usage and lines of code generated tell you AI is busy, not that it is paying off. Report these metrics on a consistent cadence, then close the loop:

Review. Run modernisation retrospectives after every major increment, and ask the uncomfortable question: did AI-accelerated practices actually reduce friction, or did they just move the bottleneck? Which ROI streams moved, and which stalled?

Refine. Adjust the roadmap based on evidence. If an architectural domain is struggling to support agents, move its modernisation up the queue. If a practice is producing defects, pivot before scaling it across the organisation.

Here is an illustrative starting-point scorecard of the kind discovery produces, showing the shape of the journey ahead. It captures the readiness of the platform, and a first baseline for each of the three ROI streams using numbers most teams can pull together in days:

Illustrative example. Recommended start: test coverage and observability. Estimated to Level 3: 4 to 6 months; to Level 4: 12 to 18 months. Every engagement is scoped to your platform, codebase and objectives.

Getting started  

Most organisations know they need to modernise, but aren’t sure which problems to tackle first, or how to connect platform investment to the AI outcomes the business is asking for.

Start with an AI in Engineering Assessment: a two-week, evidence-based review of your SDLC maturity and your codebase and data readiness. You get a scored gap analysis across the four pillars and a prioritised modernisation roadmap before you commit to a programme.

From there, typical engagements include embedded AI champions, Codurance craftspeople embedded in your teams to accelerate agentic AI adoption across the SDLC with the engineering discipline to keep it safe. Once the foundations are in place, agentic AI design and delivery takes you from a scoped proof of concept through to production, with governance built in from day one.

Book a discovery call: hello@codurance.com

Sources and further reading   

1.  McKinsey & Company, The State of AI (Global Survey), 2025 

   (mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)

    

2. Google Cloud / DORA, State of AI-assisted Software Development, 2025 (dora.dev)

    Faros AI, AI Engineering Report 2026: The Acceleration Whiplash, 2026 (faros.ai)

    

3. GitHub Next, Continuous AI, 2025 (githubnext.com/projects/continuous-ai)

    

4. Nicole Forsgren, Jez Humble and Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018

5. Simon Wardley, Wardley Maps: Topographical Intelligence in Business, 2016 (learnwardleymapping.com)

6. Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004

7. Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002

8. Martin Fowler, Strangler Fig Application, (martinfowler.com), 2004

9. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003

10. Anthropic, Model Context Protocol specification, (modelcontextprotocol.io), 2024

About the Author 

As Co-Founder and Group CEO of Codurance, Mash Badar combines over 25 years of ­enterprise technology experience with a deep passion for software craftsmanship. He ­specialises in aligning business strategy with technology, helping clients build scalable solutions and ­resilient ­engineering teams. Pragmatic and outcome-focused, Mash is dedicated to embedding ­sustainable practices that ensure long-term organisational success.  During his diverse career, he has succeeded in invigorating large ailing software projects as well as creating highly effective software teams and departments. His broad and deep technical knowledge, organisational skills, craft focus, and empathy to people involved have been integral to his success. He has worked in many roles for charities, investment banks, consultancies, government, media and cloud providers. He prides himself at being a hands-on software developer and believes that software development skills are very hard to learn and the best way to maintain them is to apply them.