Journal

AI-Assisted
Architecting

The unit of work moved

Longer autonomous runs made human input rarer, later, and higher-stakes — which moves the binding constraint from review capacity to the supply of well-formed direction.

← Journal

For most of the last two decades, the smallest thing a senior engineer could usefully hand to someone else was a task. Below that threshold, explaining cost more than doing. That floor has moved. An assistant given a sufficiently well-formed statement of intent now works productively against it for hours, and a growing number of teams have reorganized around exactly that: the specification is the artifact people maintain, models write against it, and models contribute back to it.

The first-order consequence is discussed everywhere. The second-order one is more interesting and gets much less attention.

As the autonomous stretch lengthens, human input does not disappear. It becomes rarer, later, and considerably higher-stakes. What is scarce stops being review capacity and starts being direction — the well-formed intent that determines what the next several hours produce. Throughput becomes a function of how many good directional inputs a team can form, and how much of each one survives to shape the next.

Which exposes an odd gap in the tooling. The plan is a file: versioned, diffable, reviewable, merged. The reasoning that produced the plan is a chat transcript. We made the output durable and left the input transient.

Arboretum starts from a different assumption: the level and the angle at which you engage with a body of work should be something you choose, and what you do at that level should stay where you put it. The examples below are a codebase's documentation, because that is the material most readers can check against their own experience. Nothing in the mechanism is about code.



What actually got scarce

It is tempting to describe this as an attention problem and reach for the usual language about focus. That framing is wrong in a way that matters.

The problem is structural. When every local decision has to come back to the same person, that person becomes the serialization point — and the cost is not that they work slowly. It is that everything else waits, and that each decision they make is formed without sight of the others.

Longer agent runs sharpen this rather than relieving it. They raise the value of each directional input, because more work now depends on it, and they lower the tolerance for a queue, because the run is idle while the queue drains.

Note what the aim is not. It is not less human judgment. Judgment is the input that got more valuable, not less. The aim is to spend it on the decisions that need it, at a scope where it can be exercised well, rather than on relaying the ones that don't.


Serialization is a topology problem

Two coordination shapes: the same five questions, handled sequentially and handled as one prepared unit
Two coordination shapes: the same five questions, handled sequentially and handled as one prepared unit

Five questions about one system. Handled sequentially, they pass through one person five times, and each answer is formed in isolation from the other four. Composed first, they pass through once.

The saving that matters is not the four round trips. It is that a person looking at five related questions together can give one coherent answer, where the same person looking at them one at a time gives five local ones. Cross-cutting constraints only exist at the width where they are visible. Below that width they are not smaller — they are absent.

It is worth being precise here, because the tempting overstatement is easy to disprove. This is not a claim that conversational tools are inadequate; a chat can be handed a long, carefully batched prompt, and nobody needs a product for that. The difference is where the batch comes from. Composing a prompt is authorship. Composing a review is selection — from situated contributions that already exist, at whatever scope the question turns out to have, by whoever is looking at it.


Why an address changes the economics

Forty-one notes grouped by page, purpose, status, and named review
Forty-one notes grouped by page, purpose, status, and named review

A remark typed into a session is text plus whatever context the window happened to be holding. A contribution here is text plus a position — this block, in this section, on this page, in this zone — carrying a purpose, a status, and optionally membership in a named review.

Those are not four features. They are an address, and an address is what lets contributions from different people and different assistants, made weeks apart, be reconciled rather than merely accumulated. Two remarks about "the auth model" collide. A note on the credential-lookup row of an enforcement table and a note on a dispatch endpoint's code block do not — they concern different things, and the record knows it.

The anchor is not a line number, which would rot on the next edit. Each note records a content fingerprint of the block it attaches to, along with its section path and the fingerprints of its neighbours, and re-resolves itself as the document changes. That is the difference between a filing convention and a mechanism.

The strategic consequence is worth stating plainly. Addressed contributions compose without a coordinator. Unaddressed ones need a person to sort them, which puts the serialization point back exactly where you were trying to remove it.


Scope as a control surface

Nine selected notes composed into one named architecture review
Nine selected notes composed into one named architecture review

Here is a question that no single page contains: is the composed principal carried and enforced everywhere it has to be?

Answering it means looking at an isolation model's enforcement table, at an admin surface that is deliberately not user-scoped, at the canonical shape of a history stream key, at how execution contexts are keyed, and at a relay feature that one page excludes from shared deployments while another page's setup path mounts it without mentioning the exclusion. That last item is an inconsistency between two documents. It is not visible from either one.

Now the inverse: one note on one sequence diagram, opened to full depth, with the question, the answer, the correction and the decision all remaining at the coordinates of the thing they concern.

Wide and deep are settings of the same dial, and the dial is the product. What you do once you have set it is deliberately not one thing — hand the unit to an assistant, refer to it from your own harness and never open the application, bring in a colleague instead of a model, record a decision so the reasoning survives being questioned in three months, or ask for something to be explained in place and choose not to keep it. That last one matters more than it sounds: persistence being a choice is part of the design, not an exception to it.


What durability is actually worth

Not "we keep a record." Three specific things.

The argument travels with the branch. The notes are ordinary files in the project tree — a JSON document per page, beside the material it annotates, holding messages, purposes, statuses, review names and anchors. A review prepared on a feature branch arrives with that branch and can be examined like anything else in it.

The next actor starts from the reasoning, not just the conclusion. This is the compounding one. A plan tells you what was decided. The record beside it tells you what was considered and rejected, which is the part that stops the same ground being re-litigated every time someone new arrives — model or human.

It is inspectable and movable. Plain JSON with a documented shape: readable, diffable, scriptable, convertible. That is a lower bar than "no lock-in," and it is the bar that is actually met.


What this does not solve

It does not judge whether a contribution is right. A note marked for verification records that someone asked for verification. The status on it reflects a person's decision, not a fact about the system.

It does not reconcile disagreement. When two actors conflict at the same location, the review is where that becomes visible — not where it resolves. Making conflict findable is the useful part.

It does not guarantee a composed unit is complete. A prepared review can come back with a real objection, and often should. What it avoids is the objection arriving five separate times, out of order, with no memory of the previous four.

It does not create the discipline. This is the honest organizational limit. Nothing here composes a review on its own. A team that never raises the scope of its engagement will get a tidier place to put comments and none of the benefit described above. The tool removes an obstacle; it does not supply the intent.


The constraint on this kind of work is no longer how fast the code gets written. It is how well and how often a person can say what should happen, at a level where saying it once is worth several hours of someone else's work — and whether what they said is still there afterwards.

Arboretum does not take the human out of the work. It lets the human choose where their judgment enters it.


Provenance: the screenshots come from one of our own project workspaces, populated for these articles with forty-one representative annotations across three named reviews rather than accumulated in daily use. Every count, badge and label is as captured on 2026-08-11.