AI Changes the Cost of Coordination, Not Just Creation

START WITH THE MECHANISM

Interactive companion and laboratory update: 12 November 2026. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates.

THE FULL INVESTIGATION

AI Changes the Cost of Coordination, Not Just Creation

Dates and technology context

This is a retrospective editorial timeline. Topic context: 24 June 2026. First publicly available: 12 November 2026. Current text, visuals and laboratory revisions were prepared on 12 November 2026.

The four later sections use November2026 implementations to illustrate coordination obligations; no June2026 organizational study is claimed.

Prepared on 12 November 2026, this retrospective essay considers organizational change as of 24 June 2026; the earlier date is a context, not a publication claim.

Imagine a small company in which everyone can create software. The sales team builds a forecasting tool. Operations generates a dashboard. Finance creates an approval workflow. A founder prototypes a customer portal over a weekend.

This hypothetical company may have gained real capability. Problems that once waited for a development queue can now receive immediate attention. People close to the work can express needs through functioning examples rather than lengthy requests.

The company has also acquired a new coordination problem. Its tools may define the same customer differently, duplicate data, depend on incompatible assumptions, and require maintenance that nobody planned to provide.

Cheaper creation does not merely reduce an existing cost. It changes how many things are created, who creates them, and which relationships must be managed afterward.

My argument is that the economic unit should be a maintained outcome, not a newly generated artifact. AI can improve that outcome substantially, but only if we account for the work that moves into selection, integration, review, and operation.

A local solution can create a shared obligation

In the hypothetical company, the operations dashboard begins as a personal convenience. It reads a spreadsheet and displays a few useful indicators. Colleagues start relying on it. A manager includes its numbers in a weekly meeting. Soon, the dashboard influences decisions that its creator never intended to support.

The tool has crossed a boundary. It is no longer merely a private artifact. Other people's work now depends on its definitions, availability, and correctness.

That transition creates obligations. Someone must know where the data comes from, how often it updates, what the numbers mean, and what to do when they look wrong. If the creator leaves or changes roles, the organization needs a way to continue or retire the tool.

These obligations arise from use, not from the amount of effort spent writing the software. A tool generated in an hour can become operationally important. A complex prototype may remain disposable.

The relevant question is therefore when an artifact becomes a commitment. An organization that can identify that transition can introduce proportionate ownership without burdening every experiment with production process.

An organization that ignores the transition may accumulate dependencies faster than it develops the ability to maintain them.

Coordination is work about relationships

01 / See the idea

Creation adds relationships to maintain

Enlarge diagram

Software components have relationships to other components, data, users, and rules. Teams must decide which relationships are stable enough to depend on and who can change them.

Consider two hypothetical tools that both calculate active customers. One includes accounts with a login in the last month. The other includes organizations with a paid subscription. Each definition can be useful. Trouble begins when their results are compared as though the labels mean the same thing.

No improvement in code generation alone resolves that disagreement. The organization must decide which definition serves which purpose and communicate the difference.

The same issue appears in interfaces. A generated integration can assume that a field is always present, while the source system treats it as optional. A workflow can assume that an approval is final, while another process allows it to be revoked.

Coordination makes those assumptions explicit and negotiates the commitments between people or systems. It includes technical contracts, but also decisions about ownership and acceptable consequences.

AI can help describe, compare, and check these relationships. It can also produce more relationships to manage. The net effect depends on how the organization structures the work, not merely on how quickly the next component can be created.

The review queue is a transfer of effort

Suppose a hypothetical team uses assistance to produce twice as many proposed changes. That does not tell us how many more accepted changes it can deliver. The reviewers must still assess the behavior, resolve conflicts, and integrate the result.

If review capacity remains unchanged, the queue may grow. If reviewers shorten their work to keep pace, the organization may accept more uncertainty. If the proposals are clearer and smaller, review may become easier. All three outcomes are plausible; the organization needs observation to determine which occurs.

A useful empirical reminder comes from METR's July 2025 study: measured task completion and developers' expectations of acceleration diverged in a bounded setting. It does not establish a general coordination cost, but it cautions against treating perceived local speed as the whole result. METR's original study.

The practical implication is to follow the work beyond the person using the assistant. Who receives the output? What must they do before it becomes useful? What additional obligations remain after acceptance?

A productivity gain should not disappear merely because its costs occur in another person's calendar.

Smaller organizations can gain more options

02 / A concrete example

The same label can mean different populations

Enlarge diagram

There is a strong positive case here. A small team may use AI to perform work that previously required more specialized people or a larger budget. A founder may test a product idea before hiring. An internal team may automate a neglected process.

That expansion of feasible options is different from making an existing organization proportionately faster. It can still be economically important.

The mistake would be to infer that fewer people means coordination has vanished. A single founder still coordinates with customers, suppliers, platforms, payment providers, and the assumptions embedded in the software. Some relationships become external rather than disappear.

The founder also carries several roles that a larger organization might distribute: deciding what to build, checking whether it works, responding to failures, and maintaining the promise made to users. AI may assist each role without making their priorities identical.

This does not make a small company an inferior model. It makes role clarity important even when several roles belong to the same person.

A useful question for a founder is which obligations can be kept narrow enough to remain manageable. Serving a specific problem well may produce a stronger business than accepting every feature request that has become cheap to implement.

The constraint can move from development capacity to the ability to make and maintain coherent promises.

More software is not always more capability

When creation becomes easy, an organization can respond to every inconvenience with a new tool. Sometimes that is exactly right. Sometimes it replaces a process disagreement with another interface.

Imagine a hypothetical approval process that is slow because nobody knows who has authority over a certain class of requests. Generating a workflow may make the ambiguity visible, but it cannot resolve the authority question by itself. If the tool simply routes the request through more people, it may formalize the confusion.

The useful sequence begins by identifying the decision the process must make. Only then should the organization decide which parts need software.

The same principle applies to information problems. A new dashboard may not help if the organization has not agreed what the metric means or what action should follow a change. The software can display uncertainty attractively without reducing it.

This is a reason to preserve non-software options. A clarified policy, a removed approval step, or a shared definition may solve the problem more directly. AI can help develop those options too.

The benefit of cheaper creation should be greater freedom to choose the appropriate intervention, not an obligation to create more artifacts.

Introduce a threshold for shared dependence

A practical organizational rule can distinguish exploration from commitment. Let people experiment freely within appropriate boundaries. When others begin relying on an artifact, require a small transition into shared ownership.

That transition could identify the owner, the intended users, the data sources, the meaning of important outputs, and the route for reporting a problem. It should also state whether the artifact is temporary and what would justify retiring it.

The process should be proportionate. A small internal convenience does not need the same treatment as a customer-facing service. But both benefit from knowing whether anyone is expected to maintain them.

The transition also provides an opportunity to consolidate. Several tools may solve overlapping problems. Combining them may reduce confusion, or it may create unnecessary coupling. The decision should follow the actual relationships and user needs rather than a preference for centralization.

AI assistance can make this transition easier by producing documentation, identifying dependencies, and suggesting checks. Those outputs still need verification where they establish a shared commitment.

The objective is to keep useful experimentation cheap while preventing accidental reliance from becoming invisible operational debt.

Measure the system that receives the output

03 / Watch the mechanism

Reliance is a threshold for ownership

Enlarge diagram

Static view. Play to see how the mechanism unfolds.

An evaluation of AI-enabled work should include creation, acceptance, and continued use. For a generated internal tool, ask whether it solves the intended problem, whether its users understand its limits, and whether its owner can maintain it.

For a development team, observe the movement of work through review and integration. Look for repeated clarification, growing queues, or changes that are easy to generate but difficult to understand. Also look for genuine gains: clearer proposals, faster investigation, and fewer avoidable handoffs.

These observations should guide design changes. Smaller changes may improve review. Shared definitions may prevent conflicting dashboards. A clearer retirement policy may reduce the number of forgotten tools.

The result may be less dramatic than a claim that one person can replace an entire department. It can be more useful because it identifies the specific relationships that technology has improved and those that still require attention.

No organization should assume that coordination costs always rise. Some will fall. The point is to measure the transfer rather than declare it absent.

A proposal needs an owner before it needs more detail

Contemporary laboratory note, prepared 12 November 2026. The next four sections connect this organizational argument to later reference implementations. They are current commentary, not observations attributed to the June context date.

Consider a hypothetical assistant that drafts changes to five fields in an operational record. One field belongs to a support team, another expresses a finance rule and a third controls downstream access. The proposal can be syntactically correct while crossing several authority boundaries. Sending the complete record for approval may make the review look simple, but it hides which person is responsible for which commitment.

A better proposal could identify the field, current version, suggested value, supporting evidence and decision owner. That representation is a design proposal, not a claim that an organization has deployed it. Its purpose is to expose the coordination work before the change becomes an apparently unified object. The assistant may help prepare all five changes, but preparation does not give one reviewer authority over every field.

The important distinction is between making a proposal easy to produce and making it easy to accept responsibly. A longer explanation does not necessarily reduce the second cost. A reviewer may need one specific missing condition rather than another page of reasoning. If the proposal identifies its owner and its acceptance predicate, the next action becomes clearer even when the prose becomes shorter.

This also changes how rejection should be interpreted. A rejected field may reveal an incorrect assumption, an unresolved ownership conflict or a proposal that arrived after the record changed. Those are different outcomes. Treating every rejection as a failure of the assistant would obscure the workflow; treating every rejection as valuable human oversight would excuse avoidable defects. The proposal should retain enough identity to explain what changed and why.

The organizational counterpart is modest but consequential. Do not create one enormous approval object merely because a model can generate it in one turn. Preserve the boundaries at which different people can make meaningful decisions. Shared work becomes easier to coordinate when a person can accept one warranted change without accidentally endorsing several unrelated ones. That is a concrete way for better structure to reduce coordination rather than merely moving it into another meeting.

A browser race is a small model of an obsolete commitment

01 / See the idea

Three boundaries before accepting a result

Enlarge diagram

The executed Blazor component laboratory makes three boundaries unusually visible: admission, waiting and authority to update the screen. In its controlled test, four input events in immediate mode reached HTTP four times. A four-event burst under debounce reached HTTP once. Three older responses were then deliberately completed after the current response and were ignored. These are actual application observations, not a study of how people type or how an organization works.

The organizational analogy is useful only if we keep that limit. A software revision number is not a human priority, and a debate cannot be resolved by incrementing an integer. But both settings need a way to recognize that work accepted earlier may no longer represent the current request. A proposal can be correct for an old objective and inappropriate for the one now being pursued.

Imagine a hypothetical team asking for a dashboard, then changing the decision the dashboard is supposed to support. An assistant continues generating the original design because the work is already underway. The output arrives polished and complete. Rejecting it may feel wasteful, so the team adopts part of it despite the changed need. The wasted effort is not the only cost; an obsolete request has acquired influence because it produced a tangible artifact.

The browser application refuses that particular pattern mechanically. A late response cannot overwrite current state merely because it finished successfully. The organizational equivalent is an explicit check that the proposal still belongs to the accepted objective. This is a governance choice, not a claim that human coordination can be automated with the same code.

The lab also exposes an adverse result: aborting a browser wait did not stop the controlled server operation from completing. In organizational terms, withdrawing interest does not erase commitments already made elsewhere. A canceled initiative may still have invoices, integration changes or dependencies to unwind. The useful lesson is to distinguish stopping attention, stopping execution and reversing consequences. A single status labelled canceled can hide all three, leaving other people to discover which meaning was intended.

A queue record is evidence of movement, not proof of productivity

02 / See the idea

Actual command outcomes, bounded meaning

Enlarge diagram

The reference review-queue laboratory records actual commands with their revision, start, end and acceptance events. The observed sequence contains three commands, two accepted results and one rejected result. The roles are fixture roles, and the durations are command durations. No human review time or workforce productivity effect was measured.

That restriction is part of the result. It would be easy to draw a timeline, call the gap review latency and imply that the application demonstrated faster collaboration. The packet instead preserves the difference between a machine-executed acceptance predicate and a person's judgement. The same visual shape can represent very different work, so the event names and actors matter as much as the timestamps.

For a hypothetical team, a useful queue study would need to define what ready means, who can accept a proposal, which revisions invalidate earlier review and how reopened work is counted. It would also need to distinguish waiting from active evaluation. A long elapsed interval could reflect a blocked dependency, a reviewer doing other work or a difficult decision. The interval alone does not identify the cause.

This is why counting proposals or completed checks cannot establish an organizational gain by itself. An assistant can increase the arrival rate while leaving acceptance unchanged. It can also produce clearer evidence that makes acceptance easier. Both are plausible. The observation needed to distinguish them concerns the receiving workflow, including the quality and continued usefulness of accepted changes.

The practical value of a modest event packet is that it prevents several claims from being merged prematurely. We can know that a command completed, know whether a defined predicate accepted its output and still leave human benefit unknown. That is progress, not an embarrassing omission. It identifies the next question honestly. An organization that preserves these distinctions can learn from its own work without turning every instrumented action into a productivity story.

Coordination can become cheaper, and sometimes should disappear

The strongest objection to this essay is that it risks protecting existing coordination structures simply because they already exist. Some approval chains are redundant. Some interfaces between teams survive only because earlier tools made direct collaboration difficult. If AI helps people understand a problem together or makes a check reliable enough to automate, the correct outcome may be fewer handoffs, not a more carefully documented queue.

That is a genuine possibility. The argument is not that every relationship needs more management. It is that changing a relationship requires knowing which obligation it carried. Removing a review step may be sensible if the step repeated a deterministic check now performed reliably elsewhere. Removing it because its participants seem slow, while leaving its decision authority unresolved, is a different action.

A hypothetical team could examine a recurring approval by asking what decision it makes and what evidence can change that decision. If nobody can answer, the step may be a candidate for removal. If the answer concerns a narrow rule, the team might encode that rule and retain escalation only for exceptions. If the answer concerns competing business commitments, automation may prepare the decision without owning it. These options should compete on their actual consequences rather than on a preference for either central control or radical autonomy.

Small organizations may have an advantage here because one person can hold several roles and resolve a conflict directly. They can also hide the conflict by never naming the roles. The distinction becomes visible when a decision must be handed to someone else, repeated under pressure or challenged after a failure. Role clarity is useful even when it fits on a small page rather than an organizational chart.

The best outcome of cheaper creation may therefore be a simpler system of commitments. Fewer tools with clearer purposes. Fewer approvals with better-defined authority. Smaller proposals whose effects can be understood. The objective is not to maximize the number of relationships managed successfully; it is to maintain the relationships the outcome actually needs. AI assistance can contribute by making those relationships legible, proposing alternatives and testing narrow contracts. Whether coordination becomes cheaper remains an empirical question for the organization, not a property guaranteed by the presence of the tool.

Build fewer promises than you can generate

AI expands the supply of possible implementations. A responsible organization must still decide which ones deserve to become commitments.

That decision is where product judgment, engineering discipline, and operating responsibility meet. It asks whether the result is worth maintaining, whether its relationships are understood, and whether someone can explain what happens when it fails.

The next time a team celebrates how quickly it created something, ask who will depend on it next month. What will those people need from its owner? Which new coordination task did the artifact introduce, and which old one did it remove?

Those questions do not diminish the achievement. They reveal whether the achievement has become a durable capability or merely a fast beginning.