Who Stands in Front — Closing Six Months of Evidence

In June 2026 this magazine closed its first six months with "The Age of Domain Experts". The conclusion was one sentence — the person who knows best what to build stands in front.

That piece was a synthesis that folded the previous five articles into a paragraph each. Synthesis is a correct form. The problem was that the summarised things had no evidence. Gather five absences and you have five times nothing. We rebuilt everything first, and now we fold.

What this piece stands on is fifteen samples. All of them build, all of them run, and every one with a screen has had that render confirmed. One is attached to two real boards on the desk.

What was actually proved

Here are the propositions of the six-month-old piece, rewritten to keep only what was confirmed.

A screen is a definition, and a definition is small. One screen is one to two kilobytes. The three screens a shop server hands to the kiosk, the POS and the kitchen came to 3,555 bytes together. (Only the Screen Thaws)

Choosing a transport does not split the code. The same client attached to an STM32 over USB serial and an ESP32 across Wi-Fi. What differed was one bridge program. (Boards Hand Over Their Screens)

Swap the hardware and the rules survive. Replacing a Celsius sensor with a Fahrenheit model and adding two more nodes changed not one character of the server code or the rules. (Swap the Sensor, the Control Stays)

The screen changes with no build. Editing 2,940 bytes of JSON to 2,934 showed up in 83 milliseconds, and the compiler never ran. (A Folder of JSON Is the App)

A capability you did not build cannot be reached. What is not in the tool list was never called — not by a person pressing, not by a model choosing. (What You Do Not Expose Protects the App)

But the conclusion was only half right

This is where this piece parts from the one six months ago.

That piece put all its weight on the threshold being lower. The two-tenths wall came down, so the person holding the eight tenths stands in front.

Building it, the threshold really was low. The club dues tool was forty-five lines. One fragment of a growing rule was seven lines.

But that alone does not put you out in front.

Building seven field tools, the same thing was the problem every time. Not the low threshold — whether it could be trusted.

• When "average 18 days" appeared on the farmer's screen — how to tell whether it came from the records or was typed in by somebody
• When the teacher saw eight out of twenty — why eight
• When the accountant saw 27 April — statutory date, weekend slip, or typo
• When the sole trader saw the top of the list — why that is at the top
• When reading the inherited notebook — who knew what and when, and whether a line proved wrong had been erased

They are all the same question. Is the reason next to the result.

And that is harder than the threshold. The tool lowers the threshold for you; the reasons have to be put in by the maker. The screen renders just as nicely without them. So they do not get put in.

Especially for someone building alone

There is one more thing the piece six months ago missed.

A domain expert building their own tool also means there is nobody to catch it when it is wrong. A company's tool has review, has QA, has the next person to hold it. Your own tool has you.

So the thing done most across these fifteen samples was not making screens. It was putting conditions into the verification.

The last row is the cheapest in this table and worked the most often. A screen not drawing while the PNG comes out fine happened three times. The log was clean every time.

That table is a set of files, not sentences

Those eight lines are not this piece's summary of anything. Each one sits inside a sample's verify.sh as a condition that fails the run, and a sample that breaks it does not pass.

Take the first one. It decides whether the grower's "eighteen days" is computed or written down.

AVG=$(grep -o "average from records: [0-9.]*" captures/run.log | awk '{print $4}')
if grep -RIn --exclude-dir=captures -F "$AVG" farm_server/bin farm_log.mbd bundle_host/lib; then
  echo "   the average $AVG appears literally in the source — it must be computed"
  exit 1
fi

It takes the number that reached the screen and looks for it across every source file. If it is found, the run fails. It does not check that the result is right; it checks where the result came from.

The other seven sit in the same place.

The last one is the shortest.

DISTINCT=$(ls -l captures/*.png | awk '{print $5}' | sort -u | wc -l | tr -d ' ')
[ "$DISTINCT" -eq 3 ] || { echo "   $DISTINCT distinct sizes out of 3 — a screen rendered blank"; exit 1; }

It only looks at file sizes. And it is the two lines that caught the three occasions noted above — a screen can render blank while the PNG is written normally and the log reads fine. A PNG existing is not evidence that a screen was drawn.

What these two lines cannot catch is worth writing down too. Anything with differing sizes passes, so three wrong screens pass. This verification gate stops a blank screen, not a wrong one. Wrong screens are stopped by the seven above, each on its own domain.

The real size of "the order inverts"

Reusing the phrase from six months ago: for a long time the domain expert explained from behind while the developer built in front.

Having built it, we rewrite that order like this.

What stands in front is the judgment. Not the person.

• The farmer's judgment was written in seven lines, and it carries not one character of a part number, so it outlives the hardware
• The teacher's standard is a list of strings, so she can reread and edit it herself
• The accountant's rule is stored and the date is computed
• The factory engineer's checklist is compared against the original by the verification, so it cannot be summarised

And nowhere in those four is there a passage where the expert wrote code. The judgment was moved into a form short enough to write down, and somebody had to make that form. In this series that somebody was me.

So put precisely, it is this. It is not that the domain expert stands in front, but that the domain expert's judgment stands in front and everything else steps back behind it. Making that place is still somebody's job — only that job has become thinner than it was.

What we cut from the six-month-old piece

We cut the six figures' outcome numbers. "In ten minutes", "got his midnights back", "thirty notebooks into one screen". Those numbers were not measured off specific individuals. All seven pieces are the same shape, constructed and built, and each says so in its first paragraph.

This is not a small correction. The argument of the field strand is permission — "you can do this too" — and permission rests on the reality of the case. Repeating the same sentence without having confirmed that reality is not permission, it is advertising.

So what this synthesis folds also narrows. Not "people did it" but "a tool like this looks like this, is this short, and is trustworthy under these conditions".

We also cut the self-description "these are not metaphors". This time they are not metaphors either — they are the real shape, constructed, and we said so.

What the next six months pay back

Of what the piece six months ago left open, this is what the next six months pay back.

• "Say it and it becomes a screen" — the conversion from a person's words into a definition. In all seven pieces I did that step by hand. This series did not build that conversion.
• Offline and cache — still no measurement where the launch issue gave an answer.
• App store policy — interpretation with no guideline cited.
• Running cost — every server in this series was a local process.
• A model's accuracy at choosing tools — the model in the LLM piece was a deterministic stub.
• The second and third layers of experience — facts becoming technique, technique becoming prediction. A sample run for a few days cannot show it.
• Whether a domain expert can handle this format directly — what is confirmed is that forty-five lines are readable; how long it takes somebody seeing it for the first time requires giving it to such a person.

The range of this sample

The four honesty notes from six months ago stand. Developers do not disappear, not everything becomes a tool, drawing the boundary is itself domain knowledge, and what got easier is the hands, not the responsibility.

That last sentence was confirmed hardest this time. Across fifteen builds, what got easier was the hands that put a screen up, and what got harder was the responsibility of checking for yourself whether that screen can be trusted.

And we add what we learned this time.

This piece has no new sample. A synthesis's job is not to build something new but to stand on what is already built. The problem with the piece six months ago was that it pretended to stand on nothing; this time there are fifteen.

Most of those fifteen are simulators too. Only one is attached to real hardware; the rest are simulators written in C or synthetic data. Each piece says so.

Standing in front

The piece six months ago closed by saying this was not an end but a beginning.

Six months on, having rebuilt what was begun, we rewrite that sentence like this.

The threshold came down. Forty-five lines and seven lines are the evidence.

But a low threshold does not guarantee a good tool. What you need after crossing it is the habit of keeping the reason next to the result, and no tool does that for you.

So what the person standing in front needs is not coding but a way of doubting their own tool. What this series actually produced was not fifteen screens but fifteen forms of doubt — a way of writing down what must be true as a pass condition.

A number that came out of the records and a number somebody typed in look identical on screen. The person who has a way to tell them apart is the one who stands in front.

---

makemind.dev "Horizon" — Every measurement quoted comes from the samples published alongside.