Patchwerk, one year on

A year ago, Patchwerk was a bet. (Publicly it's Project Coral; inside the bank we call it Patchwerk.) The wager was simple: that software engineering could move past the lone coding assistant towards systems of agents, tools and people working together — and that the hard part wouldn't be the model. A year of running it across the bank has settled that. The bet paid off, and the hard part was never the model.

From demo to plumbing

Patchwerk used to be a thing we'd show people. Now it's a thing they use without noticing. On any given day it opens pull requests, reviews other people's, flags repositories drifting from standard, and clears the repetitive work that never reaches the top of anyone's list. It's no longer an experiment on the edge of engineering. It's part of the plumbing.

The numbers are the part that still catches us out. Patchwerk is available to every engineer in the bank and runs across more than 2,300 repositories. In the last three months it surfaced over 12,800 technical-debt issues, raised more than 8,100 pull requests, and reviewed more than 17,300. Almost none of that is greenfield. It's maintenance, standardisation, remediation, uplift — the work that's always important and always last in the queue. That's the work it turns out to be good at.

Capability stopped being the point

When we first wrote this up, the field was mostly individual copilots and early agent experiments. It caught up fast. Copilots are table stakes now, the tooling vendors have all moved towards autonomous workflows, and the ecosystem has converged on conventions like AGENTS.md and agent skills. That convergence quietly settled an argument we didn't know we were having: generating code is no longer the differentiator. Everyone can generate code. The differentiator is whether a system of agents can be trusted to operate inside a real engineering organisation — and a regulated one at that.

One agent is a tool. Many agents is an organisation.

The unit that scales turned out not to be a cleverer agent but a set of specialised ones, each with a defined role, equipped with skills, and constrained by policy. Some of those skills are estate-wide; others belong to a single repository, team or stack. An engineering organisation isn't one homogeneous surface — it's a patchwork of shared platforms and local context — and the agents have to mirror that or they're useless the moment they leave the demo.

The first version created the toil it was meant to remove

Early Patchwerk needed too much wiring. To get anything out of it, a team had to assemble context, prompts, configuration and hand-offs — work to prepare the automation, rather than automation that already understood enough to be useful. We'd faithfully recreated the toil we set out to delete.

The fix was to stop waiting to be asked. Patchwerk now subscribes to a stream of events from systems like GitHub — a dependency advisory, a failing quality gate, a change in review state — and works out for itself whether and how to act, with the repository's state and the bank's policies folded in before it moves. Listening broadly and acting selectively is the most important thing the platform ever learned to do.

Four things a year taught us

Multi-pass beats single-shot. Real engineering work isn't linear. It's interpret, attempt, check, reconcile, review. One agent producing one answer in one pass is impressive and brittle; break it into stages where each intermediate output is inspected and fed forward, let a human in at the right moment, and it survives conditions a single shot never would.

Building orchestration is easy. Operating it is not. Wiring workflows together with modern frameworks is a weekend's work. Making them behave when a step half-succeeds, returns low confidence, or runs on stale context is the actual job. Past a certain size the system stops resembling an application and starts resembling an organisation — so you design it like one.

Trust and governance matter more than model horsepower. An agent you can't audit, attribute, or safely delegate to doesn't create durable value, however capable it is — it costs more time than it saves. A more constrained system with clear authority boundaries, inspectable actions and predictable behaviour gets adopted, because people know where they stand with it. We relearned this one constantly, usually the hard way.

Adoption is won through fit, not firepower. Engineers don't adopt a system because it's clever. They adopt it when it's legible, reliable, low-friction, and shaped like the way they already work. The hardest problem was rarely getting an agent to make a change. It was building the conditions in which the change was welcome.

Where it goes next

Patchwerk's job is shifting from doing the work to deciding who does it. It still writes and reviews, but more and more its value is in routing — the right agent, the right skill, the right policy, at the right point in the lifecycle. That matters most where coordination by hand is hardest: bank-wide migrations, dependency and platform uplift, remediation campaigns across a large and uneven estate. The further-out version is an engineering layer that reads the signals across the whole SDLC, triggers the right capability, surfaces the right decision, and keeps the controls intact — not replacing engineers, but coordinating a system that has grown too big to hold in one head.

A year in, we're more convinced of the direction and less impressed by the demos. The future of AI in engineering isn't a better autonomous coder. It's policy-aware, event-driven systems that can be trusted to run across the whole lifecycle. Trust, not capability, is the scarce resource now — and it's the one worth building for.

Adapted from the Project Coral write-ups on the CommBank Technology blog, built by the Patchwerk team. Opinions are our own, not the Group's.