When the cells overlap

In one SAFe programme, with teams in several countries, I first led the platform team: the backend, where the concerns were architecture, layers, big data and performance. We cared about clean APIs, deployments that wouldn't break the bank, and taking every millisecond we could out of a database query. We didn't think a great deal about the screens.

Then I became development manager and architect for a whole product line, and saw what our clean APIs had been doing to the UI teams. To deliver what the product owner had in mind, one page could make dozens of separate calls to the data service. Each was fast on its own, and about 90% of what came back was thrown away to render a single total or status. Requirements weren't reaching platform as use cases. By the time they got to the core they'd been broken down into structural asks. UI said they needed different APIs, platform said the APIs were right for the data model, and the parallel and chained calls nobody had planned for produced race conditions, and screens showing cached values next to half-updated ones. Bad bugs turn up anywhere, but that join was where they turned up most often and most predictably, and nobody owned them, because each side was right about its own half.

Cross-training each team in the other's work wasn't what fixed it. The narrative shifted, slowly. Stories going into the platform team had to carry the UI's wireframes with them, and the grouped and chained data the screens needed moved into a middle layer, run by platform but shaped by where the UI's needs were sharpest, while the core APIs and data model stayed clean. There was still conflict. But platform got a real view of which data mattered day to day, stability improved over time, and that middle layer opened the way to headless use that had been too complex to picture before, and in the end to a web front end replacing the old fat client.

Around all of that were days when architects brought a dozen sub-teams from different product lines into one room to work through where their plans touched, and the roles SAFe keeps for the joins: technical, solution and principal architects, each holding the connections at a different scale so the cells could stay small.

A context window behaves a lot like one of those cells, but it fails at the joins differently. In early September I split the admin console out of the public site into its own app, and the shared components moved into a new package. Tailwind, which builds the styles, only scans folders it has been told about. The brief already said so, for the older shared package, and the session doing the move followed that rule where it was written without carrying it over to the new one. On deploy, styling broke on both sites: diagrams lost their layout, icons came out oversized, and the hub's warning colour vanished, because it had only ever been defined in the public site's stylesheet.

The game I'm building, Sword Beyond Worlds, had the same thing happen half a dozen times at once. By July, several shoreline effects (wet sand, foam, the water fading over the beach, how far waves ran up, the dunes flattening near the sea) all measured distance from the same shore, and each had been given its own width by a session that could see its own effect and not the others. Each one looked right on its own, and the beach never quite agreed with itself.

In both cases the session did good work inside what it could see, at full speed, right up to the edge of what it had loaded, and nothing about that edge felt like one from the inside. Teams at a seam feel it. The UI and platform teams kept arguing, which was slow and uncomfortable, and it was also how the problem came to light. A session gets no friction at the edge and keeps nothing it doesn't write down, so the warning has to be built in, as a test that fails or a boundary it can't reach across. It also rereads its whole brief on every turn, which is how a 99,000-token file came to cost something on every request.

The shape I steered this project into will look familiar to anyone who has run a programme that way. In October the eight largest documents became short indexes, each pointing at topic files of no more than about 20 KB, so a task reads one topic instead of a whole area. Rules that cut across every area became tests wherever they could. One reads the source of every admin page, route and server action and fails the build if any of them doesn't start with a permission check. Another checks that every page has a row in the table that says who may see it. Names that several areas share, like the list of data sources and what each reading measures, live in one file the code has to import from. None of that depends on a session remembering anything. The root brief now holds only what every area needs: security, conventions, and the gotchas that have caught more than one session (the Tailwind one is there now).

The principal architect role stays with me: deciding which area new work belongs to, noticing when a request is about to cross three of them and splitting it up, and clearing the session when one job finishes and the next has nothing to do with it.

Experience taught me to write code that's efficient, both for the runtime and for whatever it's hosted on. A lot of what's been built here goes against that deliberately. I wrote in The rule was about cost all along about AI making the building cheap. This is the other half of it: spending memory, storage and extra hops at run time so each area stays small enough for a session to hold whole. The middle layer between platform and UI was the same kind of decision, an extra hop kept on purpose so the core could stay clean.

The admin console is an entire second web app with its own container, so no misconfiguration could ever expose an admin page on the public site, and a session working on admin rarely needs to know how the public site renders. Commands to the house go through the data service, an extra hop that logs everything and refuses anything not on its list (more on that in Volume zero). The split documents exist twice, as topic files for Claude and stitched back into whole documents by a script, because a rebuild runbook in twelve pieces isn't much use at two in the morning. The game keeps two versions of the world: a density field for the ground, and the tiles as the logical map that objects, pathfinding and impassable areas use, with one place every height or slope question has to go through. On the starting isle the field takes about 31 MB once loaded and 133 ms to mesh on one core, where the old tile heights for its 2,814 tiles came to well under 1 MB.

Storage is the same trade, and it pays off because of another way an AI differs from a team. The data service keeps every reading it has ever polled, with no rollups and no retention window. Nothing in the house reports when the heating is on, but the half-hourly gas readings have been kept since the start, and with the hot water on an immersion, a day that uses six kWh or more of gas is a heating day. Nobody was ever going to sit down and read two months of half-hourly gas and room temperatures by hand. Claude read the lot in one conversation, picked out the heating days and set them against how each room behaved, on a question I hadn't thought of when the data started arriving. A summary designed up front would only have kept what I expected to want. (Why that kind of reading stays out of the dashboard is in The feature I deleted.)