Post 1 of 8 in the series on rebuilding a bank’s software development factory for the agentic era.

3 years ago I wrote a long guide about designing a software development factory for a bank. 9 streams, Team Topologies, the Accelerate capabilities, DORA metrics, an IT-GOV function holding the control catalogue, and a fictional composite called XYZ Financial Services carrying the case study. People still send me questions about it, which is either a good sign or a sign that nobody has written a better one.

I am going to spend the next eight posts rebuilding that design for coding agents. Before any of that, something needs saying that most writing on this subject refuses to say.

The Software Factory that was built 3 years ago still works.

Team Topologies still explains why XYZ’s payments squad should not have to file a ticket with the risk team to ship. The Accelerate capabilities still predict delivery performance better than any AI adoption metric anyone has published. The twelve-step Azure DevOps lifecycle, with its approval gates between test, UAT, and production, is still the reason the last BaFin ICT inspection produced observations rather than findings. None of that has been obsoleted by a model release, and an organisation that throws it away in order to look modern will spend the next two years rebuilding it under a different name.

So what did change?

The interesting part is not the code

Code generation is the least interesting thing about this shift, and I say that as someone who spends most of his week on it.

What changed is that the coordination work a factory’s structure exists to perform can now be done by a system that reads the delivery artifacts directly. Knowing what is being built, what is blocked, what depends on what, which change threatens which control: all of that used to require people summarising artifacts to each other in meetings, because no other mechanism existed.

Block published an essay earlier this year, “From Hierarchy to Intelligence,” which makes the argument better than I can. Their claim is that organisational hierarchy is an information routing protocol built around one human constraint, the span of control, and that AI is the first technology capable of performing the routing function itself. Every previous attempt to escape the tradeoff, from the matrix to Spotify squads to holacracy, reverted or failed to scale, because narrowing the span of control means adding layers, and adding layers slows information down. There was never an alternative router.

That is a claim about organisational design, not about developer productivity. It is also the claim a supervised bank has the hardest time acting on, and most of what I write in this series is about why, and what to do instead.

Three things moved at XYZ. I want to take them one at a time because they have different remedies.

The factory’s knowledge of itself leaves people’s heads

In 2023, XYZ’s factory knew about itself in three places.

Dashboards fed from Jira and Azure DevOps carried lagging aggregates. FactSheet documents, maintained by IT-GOV, carried what each project claimed about itself at review time, which is not the same as what was true. And the real model, the one anyone actually used to make a decision, lived in the heads of team leads and delivery managers.

That third place is why every non-trivial decision required a meeting. The meeting was not for deciding. The meeting was for assembling the people who collectively held the picture, so that a decision became possible at all.

A delivery world model with read access to Azure Repos, Pipelines, Boards, the change and incident record, and the CMDB holds that picture continuously and answers questions against it. The status meeting stops being how the organisation knows things. At best it becomes how the organisation decides things, which is a much smaller meeting with different people in it.

Everything Block says about middle management follows from that one shift, and I will get to it properly in post three, including the part where it collides with MaRisk and does not survive intact.

The unit of work moves from the ticket to the specification

In 2023 the unit of engineering work was a person picking up a story. In 2026 the unit is a specification that either a person or an agent executes, and the economics have inverted along the way.

Agents produce diffs faster than humans can review them. So the bottleneck moves upstream, into writing unambiguous intent, and downstream, into verifying outcomes. The middle, the typing, is where the agent lives. I benchmarked the spec-driven frameworks here in July and the finding that stuck with me was mundane: it is easier to review a one-page markdown spec than an 800-line diff, and teams are shifting from code review to plan review because a change is cheap in a spec and expensive in code.

There is a third reason that matters more in a bank than either of those, and it is the one I would put in a board paper. A spec that lives in git, links requirements to tasks to commits, and survives the chat session is an artifact an auditor can walk end to end. A prompt history is not.

Spec-driven development arrived in the general market as a quality practice. In a supervised institution it arrives as a traceability practice. That changes who sponsors it, which changes whether it gets funded.

The binding constraint moves from capacity to context

This is the one I keep having to explain twice.

In 2023 the factory’s constraint was engineering capacity, and the roadmap was a negotiation over that scarce capacity. For a growing class of changes, that is no longer true. The constraint is context: whether the system executing the change can know what the code means, which business rule it implements, which obligation the module discharges, and what evidence a change to it must produce.

Capacity can be bought. Context cannot. It has to be manufactured.

At XYZ, most of it currently sits in Word specifications from 2011, in SharePoint minutes whose action items link to nothing, and in the working memory of the three engineers who understand the portfolio accounting core. That system has been in production since 1997. It values every position the bank holds and feeds every client report the bank sends. The three people who know why it rounds the way it does are 58, 61, and 54.

I find that fact more interesting than any benchmark, because it has a clock on it.

The asymmetry that makes copying Block a mistake

Here is where the essay stops transferring, and it is worth being precise about why rather than waving at regulation.

Block gets its world model close to free. They are remote-first, and as the essay says plainly, everything they do creates artifacts: decisions, discussions, code, designs, plans, problems, progress, all already recorded and machine-readable. The raw material exists because of how they work.

XYZ is a hybrid European private bank where decisions are made in rooms, minuted in prose, filed by date, and semantically anchored in long-tenured staff. The architecture decision that determined how the onboarding service handles PEP screening was taken in a Thursday design board, written into a Word file, and stored in a folder organised by month, with no link to the epic it governs or the service it constrains. Roughly half of the risk team’s non-functional requirements exist only as recollection, which is why they surface at UAT, every time, to everyone’s surprise, forever.

Point a world model at XYZ today and it will faithfully model the artifacts and miss most of the decisions.

So before XYZ can have an intelligence layer worth the name, it has to build the precondition Block inherited. I call it the evidence plane and it sits underneath everything else in the architecture: decisions as structured records linked to the work they govern, specifications as versioned artifacts with explicit deltas, requirements traceable through tasks to commits to deployments, the obligations register expressed as data rather than as a spreadsheet maintained by one person in compliance.

This is the workstream transformations skip. It looks like documentation, and documentation never gets funded.

The way to keep it funded is to refuse to describe it that way. Without it, agents work blind, the delivery world model models artifacts rather than decisions, and evidence generation stays a manual exercise performed three weeks before every review. Its business case is written entirely in the currency of the layers above it.

The question I am not answering yet

Block’s essay ends by asking every other company a question, and it is a good one. What does your company understand that is genuinely hard to understand, and is that understanding getting deeper every day? If the answer is nothing, then AI is only a cost optimisation story for you.

Their answer is the economic graph: both sides of millions of transactions, observed in real time.

XYZ’s answer cannot be that, and pretending otherwise produces a bad architecture, because it points the investment at customer data that European purpose-limitation law will not let a software factory use for this purpose anyway. A bank’s factory has a different compounding asset, and identifying it correctly determines where the money goes for the next two years.

I will give my answer at the end of the series and defend it. The short version is that it is not the code, and it is not the customer data either.

What the next 7 posts cover

The token bill. What happened at XYZ when management told everyone to use AI massively, adoption went where the message pointed it, and the consumption invoice arrived. The crisis room, the governance body, and my claim that token spend is a lagging indicator of context quality, which means cutting the budget does not fix it.

What survives contact with a regulator. Block’s model taken apart element by element and sorted into three buckets: transfers directly, transfers with modification, does not transfer. Each placement argued against a named requirement. This is the post I expect to get argued with, which is the point of writing it.

The evidence plane and the two world models. The target architecture in full, with a diagram you could hand to a designer.

Teams that own context, and the ceremonies that die. What Team Topologies becomes when boundaries are drawn around context ownership rather than communication bandwidth, plus a verdict on each Scrum ceremony and a routine feature traced end to end through the target factory.

The harness decision. Why I would pick one primary harness and defend that choice on governance grounds rather than on code quality, how autonomous agent lanes get admitted one at a time, and why an agent that cannot run the code is worth much less than the demo suggests.

Tests that lie, incidents that narrow, controls that execute. The distinction between a test that describes what the code does and one that describes what it should do, why agents are excellent at the first and dangerous at the second, and what a bank’s control catalogue has to become when the actor is not a person.

Where the seniors of 2032 come from. Every task a junior engineer used to learn on is now agent work. Nobody is going to decide to stop hiring juniors. It will happen by deferral, one budget cycle at a time, and the bill arrives six years later.

Next post is the token bill, because it is the one most people reading this are living through right now.