The backend study made a claim that invites one obvious objection. Over a long run of AI written changes it found that a mutative architecture, Spring MVC, lets change concentrate and its structure drift, while an additive architecture, OfficeFloor, holds its placement steady. The objection writes itself. OfficeFloor is mine. I designed it to be additive, so of course it behaves the way I say additive code behaves. A result about an architecture its own author built is a weak result, however clean the numbers are.
The new experiment is built to remove that objection. On the front end it introduces a second additive architecture that I did not write, did not design, and have no stake in: TanStack. Its router and its query layer are composition first. You add a route, a loader, a component, and you wire them in beside what is already there rather than reaching into a shared file that every feature edits. That is additive by someone else's hand. If additive code resists erosion only because I happened to build the additive thing, then TanStack should erode like anything else. If additive code resists erosion because of what additive composition is, then TanStack should hold too. That is the test.
It is worth being precise about who wrote what. On the front end both candidates are third party: TanStack is the additive one, Angular is the mutative one, and I wrote neither. On the back end OfficeFloor is mine and plain Spring Boot is the mutative comparison. So the additive claim no longer rests only on code I authored. The whole front end axis is independent of me, and the additive side of it is a popular framework a lot of teams already ship.
Four stacks, two layers
The study crosses two front ends with two back ends, so every combination of additive and mutative exists at each layer.
| OfficeFloor back end (additive) | Spring back end (mutative) | |
|---|---|---|
| TanStack front (additive) | additive both ends | additive front, mutative back |
| Angular front (mutative) | mutative front, additive back | mutative both ends |
The application is the same in every cell. It is one small business app, clients, jobs and invoices, grown from almost nothing by the same sequence of plain English change requests. Nothing about the domain or the requests changes between stacks. Only the architecture underneath changes, which is the whole point of treating architecture as the independent variable.
What the cross can show that a single pair cannot
A single additive against mutative pair tells you the two differ. It cannot tell you why. Is the difference a property of the architecture type, additive or mutative, wherever it sits in the stack, or do the front and the back influence each other so that the combination matters more than either layer alone? One pair cannot separate those. A two by two can.
Three questions fall straight out of the grid.
- Does a mutative front end drift whether the back end is additive or mutative? That is the Angular row read across.
- Does a mutative back end drift whether the front end is additive or mutative? That is the Spring column read down.
- When additive meets mutative across the stack, do the two layers simply add up, or does one drag the other? That is the off diagonal.
If plasticity is purely a property of the type, the prediction is tidy. The additive cell stays flat, the mutative cell drifts, and the two mixed cells land in between in proportion to how much mutative code each carries. If instead the layers influence each other, the mixed cells will not sit where simple addition predicts. A mutative back end might pull an additive front out of shape as the front keeps reaching across to it, or a disciplined additive front might hold a messy back end partly in check. Either way the off diagonal is where that would show, and it is exactly the cell a single pair never gets to measure.
Why a whole stack and why 250 changes
The backend study changed one server behind a fixed API. This one grows a whole application, the database schema, the server and the user interface together, from a near empty start, one plain English request at a time. The tests are the only thing held steady through all of it. They drive the running app through named test anchors and assert on what a user sees, so the entire stack beneath them can be rewritten and the same test still judges it. The coding agent works blind, seeing only the current request and its own test, never the ones that came before, so it cannot pattern match its way through the sequence.
And it runs for 250 changes rather than 60. The backend study could not decide between two readings of its own result, that concentration genuinely compounds into damage over a long horizon, or that the effect is real but mild, because sixty changes on one endpoint may simply be too short to tell. A longer horizon is the way to settle that. The changes are also deliberately concentrated on one part of the app, the invoice and money logic, so pressure piles up in one place instead of spreading thinly across many screens where nothing ever gets hard. At the end of each act a fresh reader with no memory is asked to read the code cold and list every rule the money logic now applies, which gives a running measure of how completely and how cheaply the accumulated logic can still be understood.
What would prove me wrong
The experiment is set up to report any of several outcomes, not just the one I expect. If TanStack erodes like Angular, then the additive claim was really an OfficeFloor claim, and the general version does not survive contact with a framework I did not write. If the mixed stacks land exactly where simple addition predicts, then the layers are independent and there is nothing cross cutting to find. If nothing has pulled apart by 250 changes, then the horizon is still too short or the effect is mild after all. Each of those is a real result and each is one the harness will show plainly.
As with the rest of the series, the harness, the per checkpoint commits and the raw capture for every chain are public, and the whole study re-runs against any model. The stacks are built, the first full run is starting, and I will post the numbers as the chains finish.
Test Harness
The four stacks are:
No comments:
Post a Comment