When Coding Gets Cheap, How Do We Engineer "Consensus"?

This is a discussion note, not a conclusion.

The short version: once coding agents execute reliably, the least reliable part of the pipeline may be the specification humans write for them, and the part nobody has engineered yet is the comprehension and consensus that happen before the agent starts.

It starts from what I've been doing with harnesses lately and ends with a pile of questions I can't answer yet. In between is a long back-and-forth with the coding agent I had open, which kept attacking my ideas.

Writing it down first.

The least reliable part of the system may have moved

Over the past year I've put a lot of effort into harnesses: have the agent understand the repository, then plan, run tests after each change, check for regressions, do code review, re-plan on failure.

Building one from zero and then cutting it in half are really about the same thing: if you're willing to spend a bit more compute, tokens, and time, the agent's execution can indeed be constrained into something more and more reliable.

That's also what made me notice something odd.

If the agent is getting more reliable at executing tasks, does the least reliable part of the whole system become the specification humans write for it?

Put another way: if we never made the thing clear in the first place, the better the agent executes, the more efficiently it may build the wrong thing.

Looking back at my own harness, Stage 1 has always had a "human-input gate": the planner lists the questions a human has to decide, and nobody starts breaking out the feature list until that list is empty.

That gate has always been there.

But it's also the least engineered step in the whole pipeline.

Everything after the gate has sensors, traces, hard boundaries. The gate itself is usually one person glancing at a plan and saying:

Fine.

Which made me wonder: have we spent all our engineering effort after the gate, without ever seriously working on the reliability of the gate itself?

"Approved" doesn't mean "we agree"

Most coding-agent workflows today still start from a GitHub issue or a Jira ticket.

The issue may have requirements, background, acceptance criteria, implementation notes, edge cases, past discussion. The agent reads that text and gets to work.

There's a big assumption buried in here:

This issue accurately expresses what everyone actually wants.

It often doesn't.

The author has a mental model, and some of it is lost when it becomes text. Another engineer reads it and forms their own version. The agent reads it again and forms a third.

Author's intent
      ↓
Written issue
      ↓
Reviewer's understanding
      ↓
Agent's understanding
      ↓
Implementation

Every layer can lose information.

And right now we spend most of our engineering effort on the last hop:

Agent's understanding → Implementation

while rarely asking about this one:

Human intent → Shared understanding

Is that hop reliable at all?

Imagine someone hands you a long ticket: a dozen paragraphs, a stack of acceptance criteria, forty comments. Then asks:

Looks good?

You skim it, roughly get it, and reply:

LGTM.

Procedurally, consensus has been reached.

But there are two completely different kinds of "yes" hiding in there.

The first:

I didn't see any obvious problems, so I agree.

The second:

I understand what state this change moves the system from and to, and what stays the same. I confirm this is what we want.

The second one is what I actually care about.

For now I'll call it informed consensus.

It mattered before, but it may matter more in the coding-agent era.

A vague issue handed to an engineer might take two days of implementation, with questions coming back the whole time. The same issue handed to an agent has it editing dozens of files two minutes later.

Once implementation gets cheap, "did we actually confirm what we're building" becomes a bigger and bigger line item in the cost structure.

First stepping stone: does UML come back?

UML was the first thing I reached for.

For a simple reason: whenever I discuss software design, sequence diagrams are the thing that actually helps.

The same payment-retry flow takes several paragraphs in prose. As a sequence diagram it forms a mental model in seconds.

UML's historical problem was that producing and maintaining it cost too much.

People had to learn it, draw it, and remember to update it when the code changed. Eventually the diagrams drifted from the code, engineers stopped trusting them, and everyone went back to:

Just read the code.

AI changes that cost structure.

The future might look like:

Human conversation
      ↓
Agent generates diagram
      ↓
Humans review
      ↓
Agreement
      ↓
Coding agent implements

People don't even need to know how to draw UML.

The agent produces the representation. People only need to read it and confirm:

Yes, that's what I want.

So at first I thought UML might come back as a good intermediate representation between people and coding agents.

Thinking further, I started doubting myself.

It's easy to assume:

Diagrams are easier to understand than text.

But that's not necessarily true.

UML is itself a language.

A simple sequence diagram may be intuitive, but a complex class diagram or state diagram still has to be learned. AI pushing the cost of drawing UML toward zero doesn't push the cost of reading UML toward zero.

That turned the question.

What I actually want to solve was never:

UML or natural language?

It's:

For a specific change, which representation lets the people involved build a sufficiently correct shared understanding at the lowest cognitive cost?

UML is one candidate.

Others: natural language, before/after, given/when/then, examples, state machines, API contracts, executable tests.

Different changes may deserve completely different representations.

And maybe that's exactly where AI is valuable: we don't have to pick the representation up front. AI can pick it for us.

Current state and change intent are two different things

One more distinction worth separating early.

A software system needs two different kinds of representation.

The first describes:

What does the system look like now?

That's the long-lived current state model that evolves with the codebase.

The second describes:

What are we about to change?

That's what an issue is really doing. I'll call it the change model for now.

Current state
      ↓
Change proposal
      ↓
Human consensus
      ↓
Agent implementation
      ↓
Verification
      ↓
New current state

The change model doesn't need to live forever.

Its only job is to let the people involved confirm:

Yes, this is the change we agree should happen.

Then the agent executes.

When it's done, the target state becomes the new current state.

That's far more realistic than trying to UML an entire codebase.

Second stepping stone: 30 seconds

If the scarce resource is really human attention, should an issue have an attention budget?

For example:

An engineer should be able to understand an issue's change intent in 30 seconds.

The point isn't 30 seconds.

Thirty is a deliberately aggressive number.

The point is treating human attention as an engineering constraint for the first time.

Not 30 seconds to understand the implementation, not to understand every edge case, but only to understand:

What is changing?

For example:

Retry payment once on timeout

Order Service       Payment Service
      |                     |
      |------ Pay --------->|
      |<----- Timeout ------|
      |------ Retry ------->|
      |<----- Success ------|
      |-- Complete Order    |

Rules:
  Retry only on timeout
  Maximum retry: 1
  Never retry declined payment

Only when everyone involved can quickly say:

I know what you're changing, and I agree.

does the agent start.

Then I started attacking my own idea

Thirty seconds can manufacture an illusion of understanding

Same payment-retry example.

Everyone sees:

timeout → retry once

and nods.

But one engineer may immediately ask:

What counts as a timeout?

TCP timeout, HTTP 504, or SDK timeout?

What if the payment actually succeeded and only the response was lost?

Does the retry double-charge?

Is the payment API idempotent?

Suddenly we realize the 30-second version was easy to understand precisely because the hard information had been deleted.

Compression reduces cognitive load.

But compression removes information.

If what got removed was decision-critical information, all we did was let everyone reach a wrong consensus faster.

So the goal can never be:

Compress the spec to 30 seconds.

The real question has to be:

How far can change intent be compressed without losing decision-critical information?

Some complexity simply can't be compressed

Repeated text, unnecessary background, messy structure, historical discussion: that's accidental cognitive load, and it can be reduced.

But authentication, distributed transactions, migrations, backward compatibility are complex on their own.

That's intrinsic complexity.

AI can reduce the first kind. It can't pretend the second doesn't exist.

The question actually worth researching is:

How do we minimize accidental cognitive load without hiding intrinsic complexity?

That's already far stricter than "30-second issues".

Splitting it up isn't automatically the answer either

If a change can't be understood in 30 seconds, the natural move is to split it into small changes.

Each one is easy to understand.

But understanding every part doesn't mean understanding the whole.

A → B makes sense.

B → C makes sense.

C → D makes sense.

And nobody understands the overall behavior of A → D.

If such agreement units exist, they probably have to be hierarchical:

          Change narrative
                 │
      ┌──────────┼──────────┐
      ↓          ↓          ↓
   Unit A      Unit B      Unit C

Understand the overall intent first, then go into the local piece you need to confirm.

Atomic comprehension can't replace system-level comprehension.

Even "shared mental model" may be the wrong target

Why does everyone need the same mental model?

The product manager doesn't need to understand cache invalidation.

The security engineer doesn't need to understand UI animation.

The backend engineer doesn't need to know every product detail either.

What's needed may not be:

Everyone has the same mental model.

but:

Everyone has a sufficient and compatible mental model.

Those are very different.

AI could even generate different views of the same change:

                 Change
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
     Product     Backend    Security
       View        View        View
        │          │          │
        └──────────┼──────────┘
                   ↓
          Compatible consensus

The PM sees behavior.

Backend sees the sequence.

Security sees the trust boundary.

Everyone sees something different, but nobody conflicts on the key intent and constraints.

That may be what consensus actually is.

The strongest objection: if it's cheap, why not just build it and look?

This is the counter-argument I found hardest to take.

The other consequence of cheap coding is that trial and error gets cheap too.

If the agent can build it in three minutes, why bother with representations and consensus beforehand?

Let it build.

The running behavior, the tests, the demo, even the diff: those are the most honest representation there is.

If it's wrong, throw it away.

I sat with this, and part of it is right.

For small, reversible changes, the implementation itself may be the best change model. No diagram beats a demo you can click on.

But it doesn't dissolve the problem. It relocates it.

First, someone still has to look.

Reading the diff, watching the demo, deciding "is this what we wanted" still takes human attention. And for a non-trivial change, reading a diff across dozens of files may cost more than reading a good change model.

Second, what's already built creates anchoring.

A running implementation makes it very easy for the reviewer to slide from:

Is this what we actually wanted?

to:

Is this version acceptable?

Build-then-look slides into build-then-agree.

Third, some changes can't be casually tried.

Schema migrations, external APIs, billing logic, anything with side effects: the premise "if it's wrong, throw it away" doesn't hold.

So after the detour, the question is still:

At the point of decision, how much attention does a human need to spend before it's enough?

Build-then-look only changes where the representation comes from.

Maybe the best change model isn't written up front at all. Maybe the agent produces a disposable implementation first, and the representation is compressed backward out of the diff and the behavior for people to confirm.

I haven't tried that path.

But it made me more sure of one thing: what's worth studying isn't any particular representation. It's the human cost of understanding before the decision point.

Where this currently lands: Minimum Viable Consensus

Let me give it a provisional name:

Minimum Viable Consensus, MVC.

Before a coding agent is allowed to execute a change, what is the least the people involved need to know in order to safely say:

I understand, and I agree we should do this.

The minimum matters.

It isn't maximum understanding.

It doesn't ask everyone to understand every implementation detail.

It looks for sufficient understanding.

Below that point, the risk is too high.

Above it, we're probably wasting scarce attention.

That adds two stages worth engineering to the software engineering pipeline:

Intent
  ↓
Representation
  ↓
Comprehension
  ↓
Consensus
  ↓
Execution
  ↓
Verification

Most harness engineering today lives in the last two.

As agents get stronger, maybe we should start taking the middle two seriously.

It also made me rethink what AI is for here.

We keep asking how much code AI can generate.

But another capability may matter just as much:

Can AI turn complex software intent into the representation best suited to one specific person?

That isn't summarization.

A summary optimizes for length.

What we actually want to optimize is:

How much decision quality each unit of human attention buys.

AI can read the customer conversation, the requirements, the architecture, the existing code, past decisions, tests, constraints, and produce a short behavior change for the PM, a sequence diagram for the backend engineer, a trust-boundary change for security.

And if the change is too complex, AI should refuse to compress further:

This change cannot be safely represented within the requested attention budget.

This one genuinely needs five minutes.

That would be a good outcome, not a failure.

When coding gets cheap, what gets expensive?

One of the most expensive resources used to be an engineer's implementation time.

A feature might take a few engineers days or weeks, so a few hours of requirement discussion never stood out.

But when implementation goes from three days to thirty minutes, and from thirty minutes to three minutes, specification, review, decision, alignment, and human attention take up a larger and larger share of the cost structure.

The bottleneck may shift from:

How fast can we build it?

to:

Do we actually agree on what to build?

We've already started using harnesses, evaluation, tracing, testing, and verification to systematically raise agent reliability.

The next question may be:

Can we measure and engineer human consensus just as systematically?

The next generation of harness shouldn't only manage what happens after the agent starts coding.

It should probably also manage:

Before the agent is allowed to start, did the humans reach sufficient understanding and consensus?

Questions I can't answer yet

Which representation works for whom? For the same change, a sequence diagram helps the backend engineer and maybe not the PM. Is there a pattern here, or does AI have to guess case by case?
How do you measure "sufficient understanding"? The one experiment I can think of is a prediction task: after reading the representation, answer "what does the system do on input X", "which component should change", "which constraint must not break", then compare against ground truth. But does that really stand in for understanding?
What does the curve between attention and decision quality look like? 15 seconds, 30 seconds, 60 seconds, 2 minutes, 5 minutes: how does comprehension accuracy change? Is there an obvious diminishing-return point?
Where's the threshold for refusing to compress? On what basis does AI say "this change needs five minutes"? Who calibrates it?
Where's the boundary between build-then-look and agree-then-build? Reversibility is obviously a variable, but how should reversibility itself be judged?
How do local consensus and system-level understanding coexist? If a large change is split into multiple agreement units, who makes sure the overall narrative didn't disappear in the split?

None of these have answers yet.

But the more I think about it, the more it seems that once coding agents make implementation cheap, the scarce thing slowly changes places.

Not code.

Human attention.

And the informed consensus that attention buys.