The future developer journey: AI-ready delivery starts with knowledge

UBS had a strategy with several initiatives to prepare software delivery for working with AI. I led the research to test it against what developers actually experience, and to show where to focus.

Project details are described in general terms to respect confidentiality.

Approach

• 24 interviews with developers across the delivery lifecycle.
• Jobs to be done plus a satisfaction and importance questionnaire on a 5-point scale. Every rating came after an open question about the developer’s experience, so each score carried the story behind it.
• Root-cause analysis to separate symptoms from underlying gaps.
• Mapping across the lifecycle, grouped into core capability areas, then translated into a target state and prioritised recommendations.

What developers told us

Four friction themes came up again and again:

1. Understanding the system too late: architecture, dependencies and ownership become clear only once work is underway.
2. Rebuilding in parallel: teams reinvent similar things because how data, interfaces and ownership connect is never written down.
3. Reactive compliance: compliance issues surface late, and which requirements apply often feels like a black box.
4. Manual coordination: dependencies are aligned through meetings, tickets and chats.

The areas developers rated most important but least satisfying told the same story: finding documentation, seeing dependencies and architecture, predictable validation, confidence in releases, environment setup, clear requirements and confidence while coding.

The insight: it’s implicit knowledge

Developers described their pain in very different ways, but it traced back to the same root.

Knowledge was held in people’s heads and conversations, and scattered across compliance, security, architecture, data and requirements. Nothing brought it together before work began, and there was no shared, machine-readable model of the system.

Why the obvious answers weren’t enough

AI coding assistants, more automation and better-organised work all help locally. But without system context they only make the same gaps move faster: code without architecture awareness, tests that don’t reflect real behaviour, compliance checks that still arrive after decisions. The research shifted the question from “where can AI write code?” to “what does the system need to know, and when, so people and AI can work reliably?”

These findings align with how Google describes the new software delivery lifecycle in The New SDLC With Vibe Coding (Osmani, Saboo and Kartakis, 2026): the real skill is context engineering, know-how is packaged as agent skills, and a harness of guardrails and feedback loops surrounds the model.

The target state

At every stage of delivery, knowledge arrives before decisions instead of after them: developers plan with a view of impact and dependencies, build against clear agreements between systems, start in ready-made environments, test against real system behaviour, get compliance feedback while they work, release without manual coordination, and learn continuously from production.

Outcome

• The findings ratified the strategy of a key strategic initiative and refocused it on the blind spots the research uncovered, above all a shared, machine-readable model of the system.
• The platform engineering team now uses the results, and work towards the target state is underway.
• The findings inform how the organisation plans future ways of working with AI.

What happened next

The first gap to be addressed is making integrations explicit: work has started on a central catalogue of APIs, so teams can find what already exists, how it connects and who owns it, instead of rebuilding it. It tackles the “rebuilding in parallel” theme directly, and it is a first step towards a shared, machine-readable view of the system.

What I learned

• Learn the language fast. Ramping up quickly on developer vocabulary and the system landscape was essential to being taken seriously and asking the right questions.
• Know what interviews can’t show. Contextual inquiry was requested but not feasible. Interviews show where it hurts; observing real work would show how it plays out. Next time I would push for at least a few observation sessions.