This global car manufacturer was experiencing a challenge facing many large engineering organisations: AI adoption was moving faster than the operating model around it.

Its software delivery lifecycle was already experiencing an ad hoc influx of AI, with tools and agents beginning to change established engineering practices such as test automation, platform thinking, CI/CD and prototyping.

But those changes were happening at individual points in the lifecycle rather than as part of a deliberately designed, end-to-end agentic system.

The VP of Platform Engineering described the problem simply:

“I still feel like we're sort of dropping AI into one piece, which makes that better and faster, but we're not considering how that changes everything, which I really think it can.”

The result was more than technical inconsistency.

Individual stages of software delivery were becoming faster while others remained largely unchanged, creating new bottlenecks and hand-off problems. Different teams were experimenting with different tools. AI expenditure was increasing quickly. Roles and expectations were becoming less certain.

And the business was struggling to distinguish between more AI activity and more business value.

Faster engineering was creating the wrong conversation

The organisation could see that AI was making elements of software engineering more efficient.

That immediately created another challenge for the VP: explaining what that efficiency actually meant for the wider business.

“The main challenge I have is to get people to understand that just because we get more efficient at coding doesn't mean you can cut 50% of our developers. Upper management is like, okay, so how much money can you save?”

For engineering leadership, the opportunity was to increase the organisation's capability: build better products, experiment more quickly and make better use of existing engineering expertise.

But efficiency could easily be interpreted elsewhere in the organisation as a headcount reduction opportunity.

Meanwhile, the cost of AI itself was becoming increasingly significant. The VP pointed out that an engineer putting an agent to work could potentially consume $10,000 over a weekend.

That made measurement critical.

Tokens consumed, lines of code generated and coding speed can all demonstrate activity.

They do not necessarily demonstrate value.

As he observed:

“Most reports… are still saying that it's implemented, but we don't see the value.”

The key question became:

What should the future software delivery lifecycle actually look like? How would the organisation identify whether it was an improvement?

Designing the lifecycle before adding more AI to it

Stellafai proposed an in-person workshop bringing together product managers, engineers, designers and user experience specialists.

Rather than starting with another AI tool, the team started with the system.

Using event storming, impact mapping and facilitated outcome design, they mapped the existing software delivery lifecycle and explored what would need to change as AI agents became part of it.

They identified:

• important events across the lifecycle;
• ownership and decision points;
• hand-offs between people, teams and systems;
• areas where AI could automate, accelerate or augment work;
• areas where human judgement remained important;
• and the measures needed to determine whether each intervention was actually improving the system.

This addressed a fundamental problem the VP had already identified:

“We know how to architect the regular system, but this is sort of an agentic system.”

The workshop gave the team a way to begin architecting that new system together.

The future-state model came from the team, not the VP

This was important for adoption.

Rather than presenting engineers with a pre-designed vision of the future, the workshop enabled the people working across the lifecycle to build a shared picture themselves.

One attendee, who had only joined the organisation three months earlier, described the impact:

“The methods used during the workshop not only helped bring us together as a team but also gave us a better understanding of the different perspectives within the group.”

For a corporation of this scale, that shared understanding matters.

There were already numerous AI initiatives, tools and opinions in motion.

The workshop created a common place from which the team could start making sense of them.

The same participant explained:

“It also helped us start navigating the complexity of establishing common ways of working with AI and understanding how we can move forward together.”

By the end of the session, the team had mapped key scenarios, identified the first events where agentic interventions could be introduced and connected those changes to measurable impacts.

Moving the measure from AI output to business outcome

One of the most important changes was in what the team would measure.

Previously, it would have been easy to assess an AI intervention through measures such as token consumption, coding speed or the quality and quantity of code generated.

Those can be useful operational indicators.

But they are outputs, not the final outcome.

The workshop instead connected AI interventions to the value created further through the lifecycle.

The VP captured the principle clearly:

“It doesn't matter if we're faster if we don't deliver something good, right?”

The question therefore changed from:

How much faster did AI make this activity?

to:

What improved because this activity became faster or better?

• Did it accelerate useful experimentation?
• Reduce a meaningful bottleneck?
• Allow engineers to spend more time on higher-value work?

The proposition shifted from “do more with less” towards “do better with the same”.

Giving AI agents an outcome to work towards

The team's existing OKR practice became particularly useful at this stage.

An AI agent can be prompted to complete a task, but in a complex enterprise system, completing the task is not necessarily the same as creating value.

Stellafai helped connect the agentic changes identified during the workshop back to the team's outcomes and measures.

That means an agent specification can be grounded in more than an instruction such as:

“Generate this code.”

The surrounding context can include:

Objective: What change is this part of the system trying to create?

Key results: What measurable evidence would indicate that the change is working?

Event: What should trigger the agent to act?

Handoff: What happens before and after the agent's intervention?

Measure: What should be monitored to determine whether introducing the agent has improved the system?

In this model, the OKR effectively provides the “why” behind the agent's work.

The event-storming output provides the “when” and “where”.

And the agent specification begins defining the “how”.

This reduces the risk of agents being optimised simply to produce more output at individual stages of the lifecycle.

Instead, the team can design them around the outcome the wider system is trying to create.

Turning a workshop into reusable engineering knowledge

The work did not end when the workshop finished.

The future-state scenarios, measures and other assets created by the team were codified within Stellafai, creating a persistent record of the thinking behind the proposed changes.

Stellafai's own AI was then able to use that captured knowledge and context to create AI agent specifications based on the agentic changes the team had designed.

The Platform Engineering team has since begun testing those specifications and identifying the questions that need to be resolved before progressing further.

This creates a repeatable flow:

Desired business outcome → lifecycle event → agentic intervention → agent specification → build → measure → learn.

Rather than losing the workshop's insight once everyone returned to their day jobs, the outputs became inputs into the next stage of engineering.

AI adoption needs an operating model, not more AI tools

For senior platform engineering leaders, the challenge is unlikely to be whether their organisation is using AI.

It is whether those experiments are forming a coherent system.

Without that system, local efficiency can create problems elsewhere. AI expenditure can rise without a corresponding increase in value. Teams can optimise different parts of the lifecycle towards different goals. And engineering leaders can find themselves defending investment using measures that say very little about business impact.

For this global manufacturer, Stellafai helped create the space to ask a bigger question:

If AI changes what is possible at every stage of software delivery, why would we simply insert it into a lifecycle designed before those capabilities existed?

The work is still developing, and the organisation is not claiming that its agentic software delivery lifecycle is complete.

But it now has something more valuable than another collection of AI experiments:

a shared model of the system it wants to build, measurable outcomes against which to judge it, and a repeatable way to turn those outcomes into the AI agents that will help deliver it.