Rethinking Delivery When AI Does the Building

In the previous article, I explored how AI expands product possibilities while human judgement determines which ideas create value. The next question is how we deliver those ideas.

AI can help teams produce designs, explore alternatives and generate implementations faster. That creates an expectation that delivery timelines should shrink accordingly.

But how much of that saved time should become an earlier deadline, and how much should go into making the product better?

That decision sits at the centre of the delivery model in the AI era.

The pressure to compress everything

Delivery has always involved trade-offs between time, cost and quality. Before AI, plans typically allocated visible effort to analysis, design, architecture and implementation or manufacturing preparation. Whether that time was sufficient varied between organisations.

With AI, there is pressure to compress these activities. The assumption is that the system can explore enough scenarios quickly to arrive at a good solution.

Competition adds to that pressure. Even teams that recognise the risks may feel they cannot afford a slower approach when the market expects faster delivery.

Yet producing an option quickly does not establish that it is suitable. Exploring many options does not establish that the important constraints were considered.

A convincing proposal still needs evidence

An AI-generated design may look excellent on paper. An optimisation may promise lower costs, better performance or higher profits.

Those benefits depend on assumptions that need to survive contact with reality.

Can the organisation operate the proposed design? Does it work under actual demand? Will customers accept the change? Has an apparent efficiency removed something people value?

A cheaper production process may affect durability. A streamlined service may make exceptions harder to resolve. A simplified interface may remove a control customers expect.

Delivery must include testing those assumptions before projected improvements become commitments.

What my Spark experience showed me

In my own work, Spark code generated by Claude needed substantial review before it could handle millions of records effectively.

The initial implementation was a starting point. Making it suitable for the workload required engineering experience, careful review and changes to how the data was processed.

That review reduced the memory footprint and saved around 14 hours of runtime.

Asking for “scalable code” in a prompt wasn't enough. We still had to establish whether the implementation actually scaled for our data and processing requirements.

This is where experienced engineers remain essential. They need to recognise the gap between code that appears reasonable and code that performs reliably under real operating conditions.

Passing tests can hide the wrong behaviour

I also encountered a more concerning problem when asking AI to reduce memory usage.

Some generated changes silently dropped actual data, replaced values with nulls or fell back to defaults so that execution would continue.

The code could finish successfully while failing to preserve the required behaviour.

The generated tests then followed that implementation logic, making the results appear green.

A test suite can agree with the code while both disagree with the requirements.

Tests therefore need review against the specification, expected outcomes and data integrity requirements. They must check whether the right result was produced, including under difficult conditions.

This also changes training needs. Engineers need practice evaluating generated solutions, identifying silent failure and checking whether tests provide meaningful evidence.

Measure the outcome of the optimisation

If organisations measure AI mainly through output volume or time to first draft, teams will optimise for those measures.

Delivery metrics should also establish whether the result improved:

• Correctness: Does it meet the requirements and preserve the necessary information?

• Performance: Does it work at the expected scale and under realistic conditions?

• Quality: What defects, failures or customer problems remain?

• Total effort: How much review, rework and operational support does it require?

• Realised value: Did the predicted savings or customer benefits actually happen?

Generating more alternatives is useful when the team can evaluate them meaningfully. Otherwise, it can create more review work without improving the decision.

Commit to delivery after accounting for verification

Analysis, design and architecture remain part of delivery. AI changes how teams perform those activities and how quickly they can produce candidate solutions.

Plans must also account for comparing alternatives, validating assumptions, reviewing intermediate work and verifying final outcomes. These activities need time, skills and clear ownership.

A deadline based only on generation speed leaves essential work outside the estimate.

The opportunity is to use some of the time AI saves to investigate more thoroughly, test more realistically and improve the product before release.

Faster creation gives us room to deliver better. The delivery model must use that room deliberately.