Speaking at ChurConf Sydney: explicit function orchestration and the data behind it

A short note. I am speaking at ChurConf in Sydney in November, and the talk rests on an experiment I have just finished and written up.

The talk

Code Your AI Agent Can Actually Read: Explicit Function Orchestration in Spring Boot.

The argument is that how you structure a Spring Boot application decides how legible it is, to a person and now to an AI agent, and that making the orchestration of functions explicit rather than leaving it implicit in a mutative controller changes what an agent can safely do to the code. The talk shows explicit function orchestration inside Spring Boot and why that placement of logic holds up when an agent starts changing it.

• When: 18 to 19 November 2026
• Where: Stone and Chalk Tech Central, Sydney
• Conference: au.churconf.com

The data behind it

The talk is not an opinion piece. I have just finished an experiment and published the paper, so the claims come with empirical backing.

An AI agent implemented sixty accumulating change requests on one REST endpoint, under two architectures, a mutative Spring controller and an additive function injection pipeline, with the model held fixed and ten runs per cell. The question was simple. When you change what the agent is told, does the structure of the code move?

The finding is that the amount of complexity is conserved. The finished codebases carry roughly the same amount of complexity whichever architecture they use and whatever the agent was told. What moves is placement, where that complexity sits, and the two architectures do not move alike. Under every external lever I tried, from a bare change request up to handing the agent the disclosed structural cost function, the mutative controller's placement moved while the function injection pipeline's placement did not. On the placement metrics the mutative arm travelled between about three and ten times as far as the additive arm.

That is the point I want to land. The function injection architecture is not perturbed by prompting. Its placement of logic is set at the structural level, by the architecture, not at the level of whatever last prompted the agent. Prompting pushes a mutative controller around. It does not push an additive pipeline around, because there is nowhere for the pushing to land. Architecture is the lever, not the prompt.

The one thing that did move the additive arm was a second AI agent reviewing each change and reasoning about cohesion itself, and it moved it on one family of metrics only, with the cost reported in full. That is the other half of the paper's title.

Read it

• The paper, Conserved amount, negotiable placement. Prompting perturbs one architecture, an AI reviewer both, is published with DOI 10.5281/zenodo.23190619.
• It is the latest in a series on this blog about how software architecture shapes AI driven code degradation.
• The harness, the per checkpoint commits, and the raw capture for every run are public, and the whole study re-runs against any model with one flag.

If you are at ChurConf, come and find me. This is the work the talk is built on, and I am happy to discuss any of it in person.