AI can write the code. Can your business deliver the change?

The customer is still waiting

Imagine a customer cannot see where an order is. A team asks AI to help create an update. The first version may arrive quickly. But the team still needs to know who owns the delivery promise, which information is reliable, what the update is allowed to show, how to check it and what to do if it fails. If those answers are unclear, faster code has not made life better for the customer.

That is the gap this article is about. The question is not only “How much code can AI write?” It is “How reliably can we turn a real need into a useful change—and learn from what happens next?”

Anthropic’s AI-native SDLC playbook, published in August 2026, looks at that whole journey through six stages: Plan, Design, Build, Test, Deploy and Maintain. Its message is that AI affects more than the act of writing code, and people remain accountable for decisions that need judgment. It is a useful way to frame the conversation, but it is Anthropic’s own vendor-authored playbook—not an independent maturity standard or a reason to choose one vendor. [1] [2]

DORA’s 2025 research offers a helpful counterweight. It reports that AI use was associated with faster delivery and better product performance, but also with lower delivery stability. The lesson is not that AI will produce the same result in every business. It is that more changes need reliable ways to check, release and recover from them. [3]

The whole journey matters

Software development lifecycle, or SDLC, is simply the route from an idea to a change in a live service—and what the organisation learns afterward. The stages below are connected. They are not meant to create six new departments or a longer approval chain.

AI can help prepare work, check it or carry out well-bounded tasks at any point in this loop. People still own the outcome, decide when an exception matters and review high-impact choices. Each step should leave enough information for the next person to continue—and for the team to understand later why a decision was made. Anthropic’s playbook describes this as a chain of shared work and review records. [1]

What “getting the house in order” really means

This is not a call to replace every system or launch a huge transformation program. It is about removing the guesswork from everyday work so a team can make changes safely and predictably, whether or not it uses AI.

For each important service, the basics are human ones:

• Someone owns the result. The team knows who the service is for, what better looks like and who makes the trade-offs.
• People can find the facts. Priorities, decisions and constraints are easy to locate. The team knows which other systems or suppliers a change may affect.
• The work is small enough to check. Changes are clear, the software can be built consistently, and useful checks catch problems before customers do.
• Tools have boundaries. People know what information an approved AI tool may use, what it may do and when it must stop for a person.
• Someone can see what happened. After release, the team can tell whether the service is working, who responds to trouble and how to reverse or contain a change.

Security belongs throughout this work, not only at the end. NIST’s Secure Software Development Framework is a set of public recommendations that can be fitted into an organisation’s existing development process. [5]

A maturity path, not a league table

Not every product needs the same level of control. A small internal tool and a service customers depend on every day have different risks. Use the stages below to decide what would help next—not to score teams against one another.

1. Informal exploration. People are trying tools in different ways. Start by choosing one task, naming who owns it and recording how it works today.
2. Supported use. The organisation provides approved tools and simple rules for information and access. A person remains responsible for the result.
3. Repeatable delivery. Teams can describe, build and check changes in a dependable way. Useful knowledge no longer lives only in one person’s head.
4. Measured and risk-aware use. The checks match the impact of a change. Routine work can move with less manual effort; sensitive or consequential decisions get clear human review and a recovery plan.
5. Value-led improvement. Time saved is directed toward better customer outcomes, stronger services and work that makes the business distinctive. The organisation keeps learning instead of automating for its own sake.

This is not a race toward full autonomy. Anthropic says its plays are modular, so teams can start where their own needs and readiness point them. [2]

From saved effort to higher-value work

The path up the value chain is not “AI writes more code, so the business is worth more.” It is more practical than that: less time lost on repeated tasks can mean more dependable changes. More dependable changes can help teams hear from customers sooner. That gives people more room to solve problems customers care about.

That room might go toward making a service easier to use, fixing a recurring customer frustration, improving resilience, reducing the cost of an ageing system or testing a new idea. These are possibilities, not guaranteed returns. The business still has to choose the right problem and check whether the change helped.

Four ways a medium-sized business can start

A medium-sized organisation does not need to copy a large company’s technology department or buy a new tool for every problem. It can start small and choose the route that fits the gap.

• If the basics are unclear, fix one service first. Name its owner, trace the people and systems it relies on, find where work gets stuck and improve that point.
• If one task is repetitive and low-risk, run a contained pilot. Agree what the AI may access, how a person will check the result, what success looks like and what to do if it goes wrong. Compare it with today’s process before expanding.
• If several teams hit the same friction, share the fix. A small group can offer reusable examples, safe defaults and practical help. Its purpose is to make teams’ work easier, not to become another sign-off desk.
• Buy, partner or build with intent. Buy common tools when their protections fit. Bring in a partner to fill a temporary skills gap and transfer the knowledge. Build something custom only when a distinctive business need justifies the cost of maintaining it.

Whichever route it takes, the organisation should keep its useful knowledge, checks and decisions in a form it can carry forward. That reduces the risk of losing what it has learned when tools change.

Show progress without gaming the numbers

Before a pilot, write down how the work happens today. Depending on the service, useful measures might include the time from agreeing a change to releasing it, how often a release needs urgent repair, how quickly the team recovers, the amount of rework and whether customers are better served.

DORA’s guidance recommends looking at delivery speed and instability together, in the context of each service. It warns against turning one measure into a target or comparing teams doing very different work. The aim is to find a bottleneck and improve it—not to reward more code, more AI use or more releases for their own sake. [4]

So before asking “Which AI tool should we buy?”, try this: pick one important service, name the person accountable, find one recurring point of friction and record what it costs the team or its customers today. Fix that friction. Then test where AI can safely help.

That is how I would judge readiness: not by how many people have an AI tool, but by whether the business can turn an important customer need into a dependable result—and explain what it learned along the way.

References

1. [1] Anthropic — The AI-native SDLC playbook
2. [2] Claude Academy — What changes and where to start
3. [3] Google Cloud — Announcing the 2025 DORA Report: State of AI-Assisted Software Development
4. [4] DORA — Software delivery performance metrics
5. [5] NIST — Secure Software Development Framework Version 1.1