In healthtech, context is the bottleneck, not the code

Most engineering leaders will tell you that deploying AI into their teams has increased coding velocity with more mature teams seeing better testing and confidence in what they’re deploying. This is all true for the most part, but this isn’t always materialising into better, stable products for their customers or higher release cadence. So what does good look like going into 2027 and where are the risks teams need to be aware of?

If you’re not familiar with the DORA report, it pulls from surveys of nearly 5,000 tech professionals and is a good measure on where the industry is moving and the common issues that teams see across the world. What’s striking is that the latest DORA report shows increases in delivery velocity and product performance,  but actually contributes to a downward trend in delivery stability.

Reading into why this happens, the central finding is that deploying AI doesn’t magically fix a team, but it does amplify what is already there and accelerates one particular facet of a team’s performance. Where your SDLC is weak and your teams are measured purely on feature delivery, pushing things faster just produces more instability.

That is the whole argument for regulated health, compressed down to a single statement. 

If your organisation already struggles to state what a feature is for, who it is safe for, and which clinical workflow it sits inside, AI will help you produce more software that nobody can defend. The constraint has not gone. It has moved to the place where health businesses are weakest: context.

The acceleration is real, and so is the wobble

It is worth being honest about how contested the productivity picture still is. METR’s randomised controlled trial of experienced open-source developers found that, with early-2025 tools, developers took 19% longer to complete real issues on repositories they knew well, whilst believing AI had sped them up by around 20%. METR has since said its follow-up experiment gave an unreliable signal, and it is changing the experiment design, so nobody should treat 19% as a law of nature.

But the direction is consistent across both studies, and it is not the direction the vendor decks point in. AI is at its weakest on mature, entangled systems where the relevant knowledge is implicit. That describes almost every health estate I have worked in: an EHR-anchored architecture, a decade of local customisation, interfaces whose behaviour is documented mainly in the memory of the person who built them.

Code was never the hard part

Think about what a single feature in a regulated health product actually requires before a line of code is justified.

• Its intended purpose, stated precisely enough to determine whether it is a medical device at all
• Its clinical risk, and the hazards it introduces or mitigates
• The data boundary: what is identifiable, what is special category, what may leave the estate
• The consent and role state it depends on
• The workflow it interrupts, and how that workflow varies between sites
• The audit trail it must leave behind
• The regression surface it touches, including the integrations nobody owns

A coding agent can produce a plausible implementation without any of that. It will not stop and ask. It will fill the gap with the most statistically ordinary assumption available, and in health the ordinary assumption is frequently the unsafe one.

Handover, not prompting

A useful mental model here is to think of the ward rather than the software factory.

A locum can be excellent and still be dangerous on a ward with poor handover, because competence without context is just confident action on the wrong information. Medicine did not respond to that by banning locums. It responded by industrialising handover: structured formats, mandatory fields, an explicit statement of the situation, the background, the assessment and the recommendation.

AI agents are like permanent locums. They arrive with real capability, no institutional memory, and no instinct for when to stop. The answer is the same answer. Not better prompting, better handover.

This is why I think “AI-ready tickets” is an under-sold idea rather than a process nicety. The quality of context you can hand over is now a hard cap on the quality of what gets built. In most health organisations that context exists, but it lives in a clinical safety officer’s hazard log, an interface spec from 2011, a consultant’s head, and a Confluence page three reorganisations out of date.

Why health pays a higher price

In most sectors, missing context produces rework. In health it produces an evidence gap, and the evidence is the product.

The MHRA’s guidance on software and AI as a medical device takes a risk-based, total-product-lifecycle approach, with traceability and predetermined change control plans at its centre. The draft Medical Devices (Amendment) Regulations 2026, published in May 2026, would formalise PCCPs for AI and software devices and strengthen post-market surveillance obligations, and the MHRA has confirmed a dedicated framework for AI in medical devices under the Life Sciences Sector Plan. Alongside that sit IEC 62304’s lifecycle and traceability expectations and, for anything deployed into the NHS, the clinical safety obligations under DCB0129 and DCB0160.

Read those together and the implication for an AI-first SDLC is uncomfortable. You are not only required to build the right thing. You are required to be able to show, later and under scrutiny, why it was the right thing, what you knew when you decided, and what changed since. Generated code that arrives without generated rationale is not a shortcut. It is a deferred, compounding documentation liability with a regulator attached.

One clear caveat: none of the above is regulatory advice. Classification, risk categorisation and change control decisions need your regulatory and clinical safety leads, not an engineering blog and certainly not a model.

What good looks like

The teams handling this well are not the ones with the most AI-generated code. They are doing six fairly unglamorous things. 

1. Treat context as an engineered asset. Intended purpose, data classification, role model, workflow states and integration contracts belong in version control, next to the code, in a form both humans and agents can read. If it only exists in a slide, it does not exist.
2. Make the ticket the handover. Every unit of work carries its clinical risk level, data class, acceptance criteria, hazard references and analytics expectations. Vague in, vague out, and in health vague out is a safety finding.
3. Move the clinical voice upstream. We have seen across a decade of health builds that programmes go materially better when a clinician acts as the de facto product owner rather than a sign-off gate at the end. Knowing what not to build is worth as much as knowing what to build.
4. Classify change by clinical risk, not by size of diff. A three-line change to a dosing calculation is not a small change. Route review rigour by consequence.
5. Scale assurance deliberately, not hopefully. If engineering throughput rises, QA, code review, clinical safety review and release control have to rise with it. Otherwise you have simply relocated the queue and made it harder to see.
6. Measure stability, not output. Tokens consumed and percentage of AI-generated code are vanity numbers. Change failure rate, escaped defects, rollback frequency and time to restore tell you whether the acceleration is real.

The honest version

I do not think AI-first delivery is optional in health, and I am not making a case for caution as a strategy. Teams that stay out of this will be outbuilt, and slowness has its own patient cost. The waiting list does not care about your risk appetite.

But the promise on offer is not “the same process, faster”. It is a redistribution of difficulty. The implementation burden falls, and it falls onto the part of the organisation that was already the weakest link: the ability to say clearly what we are building, for whom, under what clinical assumptions, and how we would prove it.

If AI is an amplifier, then the question for a health business is not whether the team is using it. It is what, precisely, the team is amplifying.