Imagine a change to a fee calculation in an advice platform. A ticket asks for an updated rule. An AI coding agent reads the repository, changes the calculation and opens a pull request before lunch.
The speed is appealing. The reviewer still needs to know which fee schedule was authoritative, how the change treats an expired consent, whether historical calculations move, and what happens if the deployment needs to be reversed. A passing unit test cannot answer questions nobody put into the test.
For AI software delivery in financial services, a person needs to be able to inspect the decision and its evidence before the change reaches production. The agent can do substantial engineering work. Signing it off remains a separate job.
Write down the decision before the code
A ticket often contains a desired behaviour and very little else. "Update the fee logic" might be enough to start a conversation with the engineer who knows the system. It is a poor instruction for a system that will work for hours without asking.
The first useful artefact is a small, reviewable specification. For the fee example, it would identify the source of the rule, the records and services affected, examples of correct results, the known exceptions, and the person authorised to settle any ambiguity. If the existing code disagrees with the policy document, that disagreement belongs in the open. The agent should not choose a winner by inference.
Some requirements are technical; others are business decisions. A calculation can be numerically correct and still apply to the wrong customer population. An agent may discover a discrepancy, write a failing test and propose an interpretation. The product or business owner must resolve the rule.
Faster execution makes an unclear instruction more expensive. The ambiguity can spread across more files before anyone sees it.
The evidence behind an AI-written pull request
For the fee change, the reviewer needs a short release record containing:
- A short statement of the intended behaviour, the source used to define it, and any question left for the business owner.
- The affected paths: data read, records changed, external services called and permissions required. A reviewer should be able to see whether the work has escaped its intended boundary.
- Tests that show ordinary cases and the awkward ones. That may mean expired consent, a corrected record and a repeated request, depending on the product.
- The result of checks run outside the agent's own narrative: builds, tests, security checks and, where appropriate, a comparison against known production behaviour.
- A release and recovery note. If the change touches stored data or a live calculation, the team needs to know what can be rolled back and what cannot.
The human reviewer can then judge the change on its merits. "The agent says it tested everything" is not evidence. Test output, a reproducible scenario and an explicit unresolved question are.
For a bank, insurer or super fund, this is also how engineering and risk staff stay in the same conversation. A reviewer does not need to read every prompt the agent used. They do need a trace from the agreed rule to the code change and the test that exercises it.
Make the next change easier without trusting the wrong memory
Software delivery has a memory problem. Architecture decisions sit in documents, exceptions in tickets and the reason for a particular workaround in a colleague's head. Coding agents can search a repository, but the repository rarely contains the whole decision.
A useful delivery setup makes prior decisions and known failure cases available at the point of work. It records which guidance was used and when it was last checked. A superseded decision should not be treated as current simply because it was retrieved confidently.
There is a related idea in Ramp's description of Glass: make work that one person has figured out reusable by the next. The principle applies to engineering, with an important condition. Treat a past successful pull request as a precedent, then check whether its source of truth has changed since it merged.
That is why a team's tests, decision records and ownership matter more than a fashionable choice of agent framework. They let the next engineer, human or AI, understand what the organisation has already settled and where it still needs a decision.
Start with one release that matters
The phrase "AI software factory" can invite an expensive infrastructure discussion. A ticket-to-pull-request system can include specifications, validation and human approval. A firm can test the approach on a narrower release before building the whole delivery system.
Pick a bounded change in a system with an owner and an existing release path. Record the time from agreed requirement to approved release, the time spent in review, defects found before and after release, and the cost of the AI-assisted work. Compare those with a credible baseline. Counting generated lines or opened pull requests will miss the hours spent untangling a bad change.
If the first agent-built release exposes weak tests or missing architecture knowledge, fix that part of the delivery system. It will benefit the next human-written change too.
If your team has a backlog of changes it hesitates to release, our product and platform work can start with one: a defined scope, evidence a reviewer can use and a handover the team can keep.