Our previous article looked at generative AI as an accelerator across the software delivery lifecycle. The conclusion was pragmatic: AI improves analysis, design, development and testing, and it removes none of the need for engineering discipline, quality controls or human accountability.

That leaves a harder question. If AI changes how quickly parts of software delivery can be done, do we use it to run the existing process faster, or do we reorganise the process itself?

If we designed our delivery process today, knowing what AI can do, would we design it in the same way?

At Paylume, this question has shaped how we have been building and testing our own AI-assisted delivery approach. Rather than looking at isolated use cases, we have focused on the complete delivery chain and on what changes when implementation becomes much faster than before.

We have been testing this approach on our own work, and the rest of this article uses duplicate payment detection as a concrete example. The feature identifies and stops payments that appear to repeat one already submitted or processed, giving us a practical thread to show how our AI-assisted delivery approach works in practice.

Faster implementation shifts the bottleneck

AI turns a specification into working software quickly. That changes the dynamics of delivery, because faster implementation is not the same thing as faster delivery of the right product.

In a traditional project, an unclear requirement creates friction. A developer hits something ambiguous and stops. A question goes into Jira, Teams or a refinement session, and somebody decides before the work continues. Inefficient, but the ambiguity becomes visible.

An agent behaves differently. Faced with the same gap, it picks a reasonable interpretation and carries on. The resulting code can be clean, well structured, documented and covered by passing tests, while resting on an assumption nobody/no human approved.

Agents can be instructed to stop when something is unclear, and ours are. The harder problem is that an agent only flags an ambiguity it recognises as one. The dangerous assumptions are the ones plausible enough not to be questioned.

Take duplicate detection alone. What counts as the same amount when the currencies differ? Which date do we compare? Does the look-back window run on calendar days or business days? What happens when two identical payments arrive in the same second? Several answers are technically defensible. That does not make them correct for the product, the scheme or the regulator.

In payments, reasonable does not always mean correct, and plausible does not mean compliant.

As implementation gets cheaper, the bottleneck moves upstream. Specification quality, explicit decisions, edge cases and validation rules matter more, because a wrong assumption now becomes convincing software in minutes.

Three ways to build the same feature

We built duplicate detection three times.

A traditional delivery approach: two weeks. This figure is a comparable estimate drawn from our historical delivery of features of this size, not a run we executed in parallel.

Our AI-assisted methodology, end to end with humans in the loop: two days. That covers the full chain: business requirements, use cases, architecture decision records, implementation, QA tests and the human decisions in between.

Asking an agent directly to build the feature: thirty minutes.

The thirty-minute version ran, and it looked good. It also had no business requirements, no use cases, no ADRs and no QA tests, and it had silently resolved decisions we would not have resolved that way, including no handling for two identical payments arriving at the same moment, which is precisely the case the feature exists to catch.

We are not going to claim that review would have caught all of it. Some of those gaps would have surfaced in review. Others we found only because the clarification phases forced them into the open: we discovered edge cases through the process rather than checking them against a list we already had. That was the part we did not expect.

AI can get you to an implementation extremely quickly. It does not automatically get you to the right implementation.

Values an agent is not allowed to guess

Speed on its own is not the interesting result. What made the two-day run comparable in quality to the two-week one is that specific expert habits are written into how the agents work, the questions experienced payments people ask, and the values they refuse to guess.

Our Business Analyst agent cannot invent payment limits, cut-off times, timeouts, retry rules, thresholds, reason codes or currency rules. Those values trace back to an authoritative source or to an explicit decision from a business owner. Where the source is missing, the gap is surfaced instead of filled.

The same rule governs field-level specifications for ISO 20022 messages: the specification is built from the relevant message version together with the applicable scheme implementation guideline, or it is blocked.

In practice, that produces questions like the one our BA agent raised about ReqdExctnDt in pain.001. The field can be provided either as a date or as a date-time, so we needed a consistent representation to compare and store both formats.

For the date-time form, we chose to preserve the calendar date expressed in the payment instruction rather than convert the timestamp to UTC first. As a result, 2026-05-27T00:30:00+02:00 is stored as 2026-05-27, not 2026-05-26.

Trivial once stated. But duplicate detection compares execution dates across two payments, and an implementation that normalises to UTC will fail to match a pair that should match, or match a pair that should not, for any payment submitted in the early hours of the day. The agent did not resolve that itself. It asked, and a human answered.

Controls that also apply to us

Human control matters, and human in the loop should not mean an expert manually redoing everything the agent produced. If somebody repeats the analysis or reads every generated line, the gain is gone. So we automate the checks that can be automated: deterministic validation, independent review by a second specialised agent, verification against an authoritative source. People concentrate on judgement and accountability.

One consequence we did not design for is that the controls catch us too.

During the same build, a human confirmed that the existing non-functional target of 50 TPS with P95 under 300 ms still held with the duplicate check active. The process did not accept it. As stated, the target was untestable: measured against an empty table it would have passed meaninglessly, because the cost of the look-up is a function of the history it scans. The requirement stayed partially covered, its blocking item repointed to an open issue, until a human supplied the number that was actually missing — 20 million stored records, 3.5 million of them inside the default seven-day window.

An experienced engineer waved something through. A control designed to keep agents honest kept us honest instead.

Connecting the chain

Most of what we changed sits between roles rather than inside them. What matters is what survives between stages.

The decision on ReqdExctnDt has to reach implementation and QA. The performance requirement has to retain the dataset assumptions that make it testable. A clarification made during analysis should not disappear into a conversation and have to be rediscovered later.

So the outputs of one stage become controlled inputs to the next. Decisions, assumptions and unresolved questions travel with the feature, reviews happen at defined points, and people are brought in where judgement is required.

The by-product is traceability. Requirements, clarifications, decisions, reviews and implementation stay linked, with no separate documentation exercise at the end. Six months later, why it behaves this way, has an answer that does not depend on who still remembers.

What this changes for the delivery teams

Giving teams access to capable tools is useful. The larger opportunity is in the delivery system around them. If implementation becomes dramatically faster, the quality of the decisions taken before implementation is what limits the result. If AI supports every role, the handovers matter as much as the roles. And if an agent can produce a plausible decision in seconds, payments expertise and authoritative sources have to be built into the process rather than applied at the end.

If AI adoption is measured in time saved, the thirty-minute run wins every time. That is why time saved is the wrong measure. What changed for us was not the speed of implementation, but where the decisions get made, who makes them, and whether anyone can still see them six months later.