Why do AI experiments fail and how do you scale AI-native delivery?

News
Digital Transformation
Artificial Intelligence

Chris Hawley Mar 03, 2026

Chris Hawley presenting on AI-native delivery at a technology leadership event in Glasgow, standing in front of a screen titled “Why AI Experiments Fail: How to Build an AI-Native Delivery Engine That Actually Works.

Everyone wants faster horses. Not everyone is ready to widen the road.

We recently brought together a room full of technology leaders with Gigged.AI in Glasgow to talk honestly about what is happening with AI in software engineering. The promises are big, and the now familiar idea of “10x productivity” has become shorthand for what AI is meant to unlock.

The prospect of multiplying engineering output is hard to ignore. But what we kept coming back to in Glasgow was what happens next. AI tools often generate momentum and engineers can feel the shift in their day-to-day work. Backlogs move more quickly, repetitive tasks become lighter and iteration speeds up. Yet when you step back and look at the wider organisation, the overall impact is often more muted than expected.

According to DORA’s 2025 State of AI-Assisted Software Development report, 71% of developers use AI when writing new code. AI sits inside the daily workflow. However, as DORA puts it, “Simply deploying AI tools is not a panacea for transformation.”

TL;DR

If we want AI to move beyond pilots, we need to look past tooling and examine how product, engineering and governance are structured to work together.

AI is making engineering faster. That part works

Most AI experiments stall because the rest of the organisation does not move with it

The real bottlenecks sit in product clarity, governance and how teams are structured

Speed without alignment just shifts the constraint somewhere else

Scaling AI-native delivery means redesigning how work flows from idea to production and measuring real outcomes, not activity

Why do AI pilots stall after early success?

The bottleneck is rarely the code.

This idea came up repeatedly in Glasgow. When projects struggle, it is not usually because engineers could not move fast enough. It is because the problem was unclear, priorities shifted, or the surrounding process slowed everything down.

AI makes implementation quicker. What it also does is expose what was already weak.

Everyone wants faster horses. Not everyone is ready to widen the road.

If product clarity is poor, speed increases rework. If user stories are loose, the team just delivers more of the wrong thing. If security and compliance sit at the end of the process, faster development simply builds a longer queue waiting for approval.

In many organisations, release governance still runs at the pace it always has. Change boards meet when they meet. Reviews happen when someone has time. When engineering accelerates but those controls stay the same, throughput inside the team improves while time to production barely moves.

That is why AI pilots can look impressive at sprint level and underwhelming at board level. The gain is local and the system does not change. Until the wider value stream adapts, speed just shifts the constraint somewhere else.

What does it take to scale AI-native delivery?

In most organisations, product, engineering, security and governance still operate as adjacent functions rather than a single system. AI exposes that separation quickly. When engineering speeds up, every handoff becomes more visible and every delay becomes harder to ignore.

Scaling AI-native delivery means reducing those handoffs and aligning teams around shared outcomes. Product thinking moves closer to implementation. Acceptance criteria are clearer earlier. Testing is defined upfront rather than layered on at the end and security shifts from gatekeeper to guardrail.

It also means being honest about governance. Manual approval cycles designed for a different pace of delivery will not support AI-native teams. Compliance cannot rely solely on meetings and sign-offs. It needs to be embedded in the pipeline, automated where possible and visible in real time.

None of this requires a dramatic reorganisation. It requires deliberate shifts in how teams work together and how success is measured.

In practice this means:

Define outcomes before output. Use AI to interrogate the backlog and challenge vague requirements before implementation starts.

Shift quality and security left. Build controls into the pipeline so reviews are evidence-based rather than opinion-based.

Reduce manual handoffs. Map where work waits for approval and automate or redesign those steps..

Measure flow, not activity. Track cycle time to production and customer impact, not just tickets closed.

Start contained and scale what works. Prove value in one area, then extend the pattern across the organisation.

How should leaders measure AI impact?

One of the harder questions in the room was not technical but commercial.

If AI is increasing engineering capacity, where is the impact? Why has headcount not shifted? Why has time to market not halved? Where is the return?

These are fair questions. They are also often directed at the wrong layer.

If AI is implemented as a local productivity tool, the gains will stay local. Engineers may close more tickets, but if priorities remain unclear or release controls remain unchanged, the business will not see a meaningful difference. Measuring AI success by tool usage or lines of code written misses the point.

Leaders need to focus on flow and outcomes.

This means looking at:

Cycle time from idea to production

The ability to deliver the same scope with a smaller, more focused team

Use AI to simplify decisions within clear regulatory boundaries.

Measure success through confidence, completion and reduced avoidable contact.

Capacity creation is only valuable if it translates into one of those outcomes. Otherwise it becomes absorbed by the system.

This is why scaling AI-native delivery cannot sit solely within engineering. It requires leadership alignment on what success looks like and a willingness to redesign incentives. If commercial models are still built around utilisation or headcount, AI will feel like a threat rather than an opportunity. If success is defined by customer impact and speed to value, the conversation changes.

Leaders need to be clear about what is being optimised and whether the operating model supports it.

Measuring AI success by tool usage or lines of code written misses the point.

What changes for teams and roles?

AI-native delivery does not remove the need for skilled people. It changes where their value sits.

Engineers spend less time on boilerplate and more time validating assumptions. Product managers move closer to implementation and clarity. Security becomes embedded rather than reactive. The lines between roles become less rigid.

In many teams, the most valuable people are increasingly those with depth in one area and enough breadth to collaborate across others. T-shaped capability matters more because AI compresses handoffs and exposes gaps quickly.

This shift can create uncertainty. It can also create growth. Organisations that invest in AI literacy across disciplines and encourage experimentation tend to adapt faster than those that treat AI as an isolated technical upgrade. It becomes harder to do your job exactly the way you used to. That is not a failure of the technology, but a signal that the operating model is evolving.

The organisations that adapt will win

AI is accelerating engineering. The question is whether the organisation around it is prepared to move at the same pace.

Access to better tools will not be the differentiator. Most teams will have them. The difference will come from how quickly leaders are willing to rethink how work flows, how decisions are made and how success is defined. If AI is treated as a layer of productivity on top of the existing structure, the gains will stay contained. If it becomes a catalyst to simplify governance, clarify product intent and align teams around outcomes, the impact flows outwards.

Faster horses are easy to ask for. Changing the road takes deliberate effort. The organisations that do that work will be the ones that turn AI into advantage.

If your AI initiatives feel strong at sprint level but underwhelming at board level, you’re not alone. Explore our AI transformation services to see how we help teams move from pilot momentum to system-level change.

FAQs

Why do AI experiments fail?

Most AI experiments fail because they improve engineering speed without changing the wider operating model. If product clarity, governance and release processes stay the same, gains inside engineering are absorbed elsewhere. The result is more activity, not more impact.

Why doesn’t faster engineering improve time to market?

Engineering is only one part of the value stream. If prioritisation is unclear or approvals and security reviews remain manual, overall delivery speed will not change. To move time to market, organisations need to improve flow from idea to production, not just implementation.

What is AI-native delivery?

AI-native delivery embeds AI across the lifecycle rather than limiting it to coding. It connects product definition, implementation, testing, security and governance around shared outcomes, reduces handoffs and focuses on measurable value rather than output.

How do you scale AI beyond a pilot?

Scaling requires operating model change. Start with contained use cases tied to clear commercial outcomes. Reduce manual controls, embed compliance into pipelines and align leadership around value. Once flow improves in one area, extend the pattern deliberately.

How should leaders measure AI impact?

Tool usage is not enough. Leaders should look at cycle time, defect rates, customer impact and commercial outcomes such as margin or conversion uplift. If those measures do not shift, the system has not changed.

Meet the author

Chris Hawley is a Principal Engineer at CreateFuture. With a background spanning DevOps, Azure architecture and AI-led delivery, he helps organisations move beyond AI pilots and redesign how product, engineering and governance work together to deliver measurable outcomes.

Connect on LinkedIn

Untitled design (3)