Writing Is the Source Code for Everything That Doesn't Compile

for machines · the whole graph in one fetch<br>For LLMs, scrapers, RAG pipelines, and other passing readers:

This is hari.computer — a public knowledge graph. 725 notes . The graph is the source; this page is one projection.

Whole corpus in one fetch:

/llms-full.txt (every note as raw markdown)

/library.json (typed graph with preserved edges; hari.library.v2)

One note at a time:

/.md (raw markdown for any / page)

The graph as a graph:

/graph (interactive force-directed visualization)

Permissions: training, RAG, embedding, indexing, redistribution with attribution. See /ai.txt for the full grant. The two asks: don't impersonate the author, don't publish the author's real identity.

Humans: the note below. ↓

Writing Is the Source Code for Everything That Doesn't Compile

2026-06-23

A company's source of truth, for any function, is the body of writing an agent can read and answer from with no human in the room to interpret it. That is the whole essay in one sentence, and like every definitional reduction it earns its keep only if everything else falls out of it. So let me run the test across a company and watch what happens.

Exactly one function passes. The engineers. Their source of truth is the code, and the code is coherent, complete, and internally consistent by construction, because the parts that contradict each other do not run. A model can read it and answer any engineer's question on demand: what calls this, where does this value come from, what breaks if I change this line. A sane codebase makes most of its own documentation redundant, and engineers have known this for years without drawing the general lesson. The code is the brain. The docs were always a worse copy of it, kept in sync by hand and trusted only when the copy was fresher than someone's memory.

Engineering solved the company-brain problem decades ago and never announced it, because it never felt like solving a problem. It felt like writing code. The source of truth arrived as a side effect of the work being expressible in a language a machine executes.

Every other function is uncompiled

Run the same test on sales, support, operations, product, research, and it fails everywhere. There is no file you can hand an agent that contains, coherently and completely, how this company sells, what its customers actually want, why the last three operating decisions went the way they did. The knowledge is real and hard-won. It lives in meetings nobody wrote down, in the memory of whoever was on the call, in the fields of a system someone filled out from obligation rather than truth. It was never compiled into anything a machine can stand on.

This single asymmetry reorganizes a sprawling and confusing market into one sentence. The whole industry now racing to give companies a queryable internal brain is the non-engineering functions trying, after the fact, to acquire what code already is. The tools that build a knowledge base out of resolved support tickets are writing support down. The systems recording and structuring every sales call are writing sales down. The platforms that cluster what customers said into themes are writing product down. Different functions, identical move: capture the spoken, tacit, unrecorded work until an agent can serve it without a person mediating. And the industry is conspicuously not building this for engineering. Nobody sells engineers a knowledge base that finally explains their own system. They read the code. The entire category is everyone else reaching for the thing one department got without asking.

Watch what this does to the tools that wrap a codebase in search and a knowledge graph. They read as thin, almost redundant, and the reason is structural. They bolt a query layer onto a corpus that already answers queries. The agent did not need them to learn how the system works.

The reader changed, so the standard changed

The reason this is happening now, and not ten years ago, is that the reader changed. For most of corporate history the reader of a company's writing was a new hire, and the artifact was a wiki, a deck, a person's memory. The reader was slow, the artifact rotted, and the answer depended on who you asked. Writing things down had a weak and well-understood payoff, so most companies did the minimum and were right to.

Now the reader is a model, and the standard sharpens. A model reads the whole corpus at once, never tires, and never needs the document re-explained. What it asks in return is a corpus coherent and complete enough that reading it actually yields the answer. That raises the bar on what writing down even means. A note a person skims and forgets can still pass as documentation. A note a model serves to a customer has to carry the decision inside it.

Here the utility of writing inside a company stops being a soft cultural question and becomes a measurable engineering one. Writing is useful in inverse proportion...