--- title: Boxes and Lines date: 2026-04-23 description: A child draws boxes and lines on the kraft paper at a coffee shop. We spent seventy years building elaborate machinery to get back to what she drew. Maybe now we can stop. keywords: AI, Category Theory, Programming, Philosophy, History of Computing, Actor Model, Agentic AI, Compiler series: just-boxes-and-lines part: 1 --- **A Child is Doodling in Crayon on Paper at a Coffee Shop.** She draws a box. Labels it *me*. Draws another box — *mom*. Draws a line between them. Thinks for a second, draws an arrow on the line. Points from mom to her. Draws a third box — *dog* — and a line from her to the dog. Sits back, satisfied. She has explained something. The diagram is complete. Nobody taught her this. She didn't learn the words for it — "object," "relationship," "directed graph." She learned that you can draw a thing, draw another thing, and draw what goes between them, and that this, somehow, is enough to say almost anything. That you can keep going. Boxes inside boxes. Lines between lines. The whole world fits on a coffee shop table if you have enough crayons.
She draws a box. Labels it me. Draws another box — mom. Draws a line between them. Thinks for a second, draws an arrow on the line. Points from mom to her. Draws a third box — dog — and a line from her to the dog. Sits back, satisfied. She has explained something. The diagram is complete. Nobody taught her this. She didn't learn the words for it — object, relationship, directed graph. She learned that you can draw a thing, draw another thing, and draw what goes between them, and that this, somehow, is enough to say almost anything. That you can keep going. Boxes inside boxes. Lines between lines. The whole world fits on a coffee shop table if you have enough crayons. (Note: The irony that the lines on the original image Nano Banana created were pointing the wrong way is an example of the confusion of going from text to models...)
Generated with Google Gemini / Nano Banana 2
Now her father leans over. He's an engineer. He takes a crayon and adds a box: *work*. Draws a line from *me* to *work*. Draws a line back from *work* to *me*, labels it *paycheck*. Draws a box for *mortgage*, connects it to *paycheck*. Draws the house. Connects the house to the mortgage, to the family, back to him. The child watches. She recognizes exactly what he's doing. It's the same thing she was doing. Across the coffee shop, a doctor is waiting for her drink. She has a notepad. She's writing, not drawing — but the structure is the same: *patient presents with X, which connects to Y, which suggests Z, but Z is complicated by W.* She's drawing a diagram in prose. The subway map on the wall. The org chart in the boardroom. The recipe on the box. The legal contract with its chains of if-then. The flowchart someone drew on a whiteboard to explain why the system is broken. All of them: boxes and lines. --- ## The Coffee Shop as a Sketch In 2004, [Gregor Hohpe](https://www.enterpriseintegrationpatterns.com/gregor.html) published a short, precise article in IEEE Software called ["Your Coffee Shop Doesn't Use Two-Phase Commit"](https://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf). The observation was deceptively simple: Starbucks doesn't hold up the entire queue while waiting for each transaction to finalize. Orders are placed, work begins, exceptions are handled by compensation rather than rollback. The barista doesn't undo the espresso if you change your mind about milk — she makes a new drink and discards the old one. The shop runs on eventual consistency, not strict atomicity. Seventeen years after Hohpe's thought experiment, AWS made it literal. [Serverlesspresso](https://serverlessland.com/reinvent2021/serverlesspresso) — a real event-driven coffee ordering system built with Step Functions and EventBridge — first served drinks at [AWS re:Invent 2021](https://github.com/aws-samples/serverless-coffee). By 2022 it had processed over 20,000 orders at technology events worldwide and [featured in Werner Vogels' keynote](https://aws.amazon.com/blogs/compute/introducing-serverlesspresso-extensions/). The architecture costs about one dollar a day to run. When the process composes correctly — eventual consistency, compensation, no Two-Phase Commit — the cost drops to nearly nothing. A few years later, Hohpe took the same observation further: in a post he called ["Of Boxes and Lines"](https://www.enterpriseintegrationpatterns.com/ramblings/38_interaction.html), he argued that we should "turn the lines into boxes" — make the interaction itself a first-class object, not just a connector between things. The line (or morphism as it is formally called) deserves to be as real as the thing it connects. What Hohpe was describing, in the language of distributed systems, was the same as the child's drawing in crayon: a process that works because its steps *compose*. Customer places order — morphism. Barista receives order — morphism. Preparation transforms inputs to outputs — morphism. Delivery closes the loop. Substitution (oat milk instead of dairy) is a transformation between two paths to the same result. The shop functions because the output of each step is exactly what the next step requires as input, and because when that assumption breaks, the shop has a defined protocol for recovery. Brendan Fong and David Spivak's *Seven Sketches in Compositionality* ([arXiv:1803.05316](https://arxiv.org/pdf/1803.05316)) provides the formal language for this: Category Theory, the branch of mathematics that studies how objects and the relationships between them compose. Their demonstration — that real-world systems from database migrations to resource flows to collaborative design are already categorical structures — is the rigorous grounding for what Hohpe showed informally and what the child drew instinctively. The coffee shop isn't *like* a diagram. It *is* one. Not because someone designed it that way. Because composition — the property that A→B→C gives you A→C — is how anything actually gets done. The mathematics was always there. The formalism just names it. --- ## The 1940s Clerk as the Categorical Representation In the early days of computation, "computer" was a job title. Human computers — often women, working in organized rooms from printed instruction sheets — performed calculations by hand. When Turing described his theoretical machine in 1936 and [von Neumann](https://en.wikipedia.org/wiki/Von_Neumann_architecture) designed the first electronic stored-program computers in the 1940s — a CPU, memory, and a sequential fetch-decode-execute cycle — they were modeling those clerks. Not abstractly. Literally. The machine had registers (the clerk's working memory), a stack (the scratch pad), a program counter (the instruction sheet), and memory (the filing cabinet beside the desk). The filing system came with it, borrowed directly from the office. Files. Folders. Directories that contained folders. Drives that contained directories. The entire hierarchical metaphor of digital storage is a two-dimensional projection of a physical file room — the kind with rows of cabinets, color-coded tabs, and a sign-out sheet by the door. We encoded the spatial logic of a mid-century office into the architecture of every computer built since, and then encoded it again into every operating system, and then again into every cloud storage provider. The metaphor traveled because the architecture enforced it. This was not inevitable. The stored-program von Neumann architecture was one answer to the question of how to build a general-purpose computing machine. Analog computers — which represented quantities as continuous physical signals rather than discrete symbols — were a serious competitor well into the 1960s. Differential analyzers could solve differential equations that would have taken a digital computer hours. They encoded meaning directly in the physical relationships between their components: the gear ratio *was* the derivative, not a representation of it. They lost not because they were wrong but because they were hard to reprogram and couldn't be made general enough cheaply enough. The clerk model won on economics, not on epistemic grounds. [Lisp machines](https://en.wikipedia.org/wiki/Lisp_machine) — purpose-built computers designed at MIT and Xerox PARC in the 1970s to run symbolic computation directly, without translating through Von Neumann abstractions — were another attempt at a different foundation. They were killed not by inferiority but by the economics of commodity hardware improving faster than specialized silicon could justify its cost. The AI winter of the late 1980s finished them off. The pattern repeats: a genuinely different model loses to the incumbent's momentum, and the Von Neumann abstraction stack gets another layer built on top of it. The irony is that the alternatives keep arriving anyway. Modern processors execute multiple instructions simultaneously across SIMD vector units. GPUs run tens of thousands of parallel threads — massively parallel architectures that look nothing like a clerk processing items sequentially. The neural network itself is a computational substrate where the weights are the program and inference is the execution. Distributed systems coordinate computation across thousands of machines with no shared memory at all. Neither GPUs nor neural networks fit the Von Neumann model. Both now run significant portions of the world's computation. The hardware has been escaping the metaphor for decades. The abstractions we write against have not. --- ## All of This Has Happened Before In the early 1960s, [Kenneth Iverson](https://en.wikipedia.org/wiki/Kenneth_E._Iverson) was developing [APL](https://en.wikipedia.org/wiki/APL_(programming_language)) — a mathematical notation for describing computations on arrays as first-class objects. APL treated whole collections as single entities that could be transformed, composed, and operated on in parallel. An APL expression that reverses a sorted list and finds its median is a single composed operation, not a loop. The semantics were compositional: operations on arrays *were* morphisms, and composition *was* the programming model. APL was strange to most programmers of its era and remained a specialized tool. The idea was right. The timing was not. A decade later, [Alan Kay](https://en.wikipedia.org/wiki/Alan_Kay), then at [Xerox PARC](https://en.wikipedia.org/wiki/PARC_(company)), invented what he called object-oriented programming. His model, realized in [Smalltalk](https://en.wikipedia.org/wiki/Smalltalk), was built around a biological metaphor: objects as cells. Each cell maintains its own internal state. Cells do not share state directly. They communicate exclusively by sending messages to each other. A message arrives, the receiving object decides what to do with it, updates its own state, and may send further messages. Nothing else. No shared memory. No global state. No reaching in. Kay has been explicit, for decades, that what the industry calls "object-oriented programming" — the class hierarchies, the inheritance chains, the mutable shared state of C++ and Java — is not what he had in mind. ["I'm sorry that I long ago coined the term 'objects' for this topic,"](http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html) he wrote in 1998, "because it gets many people to focus on the lesser idea. The big idea is messaging." The thing that got shipped as OOP kept the vocabulary and discarded the insight. We got the boxes without the arrows. [Carl Hewitt](https://en.wikipedia.org/wiki/Carl_Hewitt) arrived at the same structure from a different direction. His [Actor model](https://en.wikipedia.org/wiki/Actor_model), developed in 1973 at MIT, defined computation purely in terms of actors: autonomous entities that receive messages, update their private state, create new actors, and send messages to other actors. That's the entire model. No shared state. No synchronous calls. No global memory. Actors are objects. Messages are morphisms. Computation is composition of message chains. Hewitt and Kay, independently, described the same categorical structure a decade before Category Theory was widely applied to programming language semantics. --- ## And We Have Proof [Joe Armstrong](https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)) and his colleagues at Ericsson needed to build a telephone switching system that would not fail. Not "rarely fail." Not "fail gracefully." Would not fail — at the level of reliability that the phone network required, where carrier-grade reliability was the target and a software bug could interrupt emergency calls across a country. They built [Erlang](https://www.erlang.org), and under it the [BEAM](https://en.wikipedia.org/wiki/BEAM_(Erlang_virtual_machine)) virtual machine. The architecture was pure actor model: lightweight processes communicating exclusively by message passing, with no shared state between them. When a process fails — not if, when — a supervisor process detects the failure and restarts it. The system is designed around the assumption of failure, not the prevention of it. "Let it crash" is not a slogan; it is the engineering philosophy. WhatsApp ran on Erlang. They achieved two million concurrent connections per server — numbers that would have required hundreds of servers on conventional architectures. [RabbitMQ](https://www.rabbitmq.com) runs on Erlang. Discord ran its real-time messaging layer on [Elixir](https://elixir-lang.org), which runs on BEAM. The infrastructure of significant portions of the internet's real-time communication runs on a platform whose foundational design decision was: objects plus messages, no shared state, composition all the way down. This is not a coincidence. It is the same structural insight that Turing's tape, read categorically, already contained: marks on a tape are objects; transitions are morphisms; computation is composition. Hewitt named it. Armstrong implemented it at scale. The BEAM VM proved that this structure runs reliably, cheaply, and at a concurrency that the von Neumann clerk model cannot approach. --- ## Sketching on Turing's Paper Tape The Turing machine is not, by itself, a categorical structure. It is a procedural one: a head reads a symbol, applies a rule, writes a symbol, moves. The symbols have no inherent relationships. The machine doesn't know that two symbols represent the same concept expressed differently, or that a sequence of transitions corresponds to a single semantic operation. But the tape is *capable* of carrying that structure. If the marks on the tape are not arbitrary symbols but objects — carrying their relationships with them, aware of what they connect to — and if the transitions are morphisms — aware of what they preserve — then the Turing machine becomes something more than a procedure executor. It becomes a meaning processor. It can still compute everything a Turing machine can compute. But now the computation respects the structure of the problem, not just the sequence of steps. This is what Kay described in Smalltalk. It is what Hewitt formalized in the Actor model. It is what Armstrong proved in production on BEAM. And it is what the Categorical Token Runtime proposes to bring to the level of language representation itself: not just computation as message-passing objects, but *meaning* as message-passing objects. Concepts are actors. Relationships are messages. Understanding is what happens when the messages compose. We have been one abstraction layer away from this for seventy years. The clerk is still sitting at the desk. --- ## Understanding Human Representations is Hard for Machines (and Humans) We have known this for fifty years. We solved it, or tried to, by building a bridge on the machine's side of the gap — syntax, formats, query languages, form fields, command-line flags. We trained people to cross that bridge before the machine would serve them. We called this training "computer literacy" and treated it as progress. It wasn't progress. It was a tax. Consider the toll in concrete terms. A tradesperson spends roughly an hour a day translating the day's work into whatever software is tracking it. Over a year, that's more than six full working weeks. Not six weeks of doing the job they're expert in. Six weeks of translating between what they know and what the computer can receive. A physician speaks an observation at the end of a patient visit — not the diagnosis, not the billable code, but the thing she noticed that might matter in six months. The electronic health record has no field for it. The observation evaporates. Some of those observations would have changed diagnoses. The cost is measured in delayed treatment, repeated tests, missed early detections. The signal was there. The physician noticed it. The tool couldn't hold it. This is the translation tax. It falls on everyone who knows something the computer can't receive. It falls most heavily on the people whose knowledge is deepest and whose access to technical fluency is most limited. --- ## But This Didn't Work the Last Time, Why Now? In the early 2000s, the [Object Management Group](https://www.omg.org) launched Model Driven Architecture. The premise was exactly right: separate the model — what a system *does*, expressed as diagrams — from the implementation — *how* it does it on a specific platform. Write the model once. Generate implementations for any target. The spec and the diagram would be the same artifact, and that artifact would run. It didn't work. Not because the idea was wrong, but because it was optimized for the wrong constraint. The modeling languages — UML, the Meta-Object Facility — became as complex as the code they were meant to replace. The generated code was brittle. Developers found it easier to work directly in the language and discarded the models. Model Driven Development solved the right problem by adding a worse problem on top of it: the models required humans to author and maintain them, and humans found the models harder than code. Between MDD and SDD, there was a third attempt: the Domain Specific Language. If general-purpose code was too low-level and UML too abstract, the answer was a language precisely fitted to a specific domain. SQL for data. HTML for structure. CSS for presentation. Terraform HCL for infrastructure. Regex for pattern matching. Each one a notation purpose-built for one problem, easier to author than the general-purpose alternative. DSLs worked better than MDD because they were narrower. A SQL query is easier to read than a procedural loop over a database cursor. A Terraform configuration is easier to reason about than the API calls it generates. The domain-specific notation reduced the translation tax within its domain. But DSLs are still notation. SQL is still text a parser recovers structure from. And DSLs proliferate — every platform, every domain, every team invents one. The developer who knows SQL, HCL, Dockerfile, Makefile, Gradle, Ansible YAML, Kubernetes manifests, and GraphQL schema hasn't escaped notation. They've learned ten different notations and ten different parsers. The DSL explosion is the MDD problem recurring at smaller scale. Specification Driven Development, which emerged in 2025, inverted the problem. Where MDD was precise but illegible, SDD is legible but imprecise — more human-readable, less information-rich, the ambiguity pushed downstream into inference. Write requirements in natural language. Have an AI implement them. Let the spec be the primary artifact; treat the code as disposable. Humans can author natural language; they could not author UML. When the implementation breaks, regenerate it from the spec. But SDD still carries the same assumption MDD did, just better hidden: the spec must be in human language, and the implementation must be in code, because *humans need to understand what the system does*. The translation between them — meaning → natural language → AI → code → execution — is the new bridge. Shorter than the old one. Still a bridge. And human language, as it turns out, was never a precise categorical substrate to begin with. We have better ways to describe the system. --- "Green" represents something physical. Photons — specific wavelengths of electromagnetic radiation, roughly 520 to 560 nanometers — bounced off a surface and hit a detector. If the detector is a retina, cone cells generated electrical signals. If it's a camera sensor, photodiodes did the same. What happened next — in the nervous system or the image processor — was interpretation: a collapse of that continuous physical signal into a category, a label, a name. The photons aren't green. The electrical signal isn't green. *Green* is what we call the interpretation. The problem is, although we can specifically define the color green, [we have no way to know if what we see is the same as anyone else that sees green (or doesn't)](https://www.allaboutvision.com/conditions/color-blindness/tritanopia/). But "green" doesn't always mean "the color". We borrowed it for health — a person who looks green is unwell, their skin no longer signaling what healthy tissue signals. We borrowed it for inexperience — a green recruit is unformed, not yet matured, like fruit that hasn't ripened. We borrowed it for permission — a green light says proceed, by analogy to growth and safety. We borrowed it for politics, for finance, for envy, for a room backstage in a theater, for a brand, for a philosophy of living on the earth. Each borrowing made sense in context. Each one moved "green" further from the original signal and deeper into a different categorical system, with different objects, different relationships, different morphisms connecting it to everything else. The word "green" now participates simultaneously in the categorical representations of color theory, biology, medicine, agriculture, traffic systems, political philosophy, finance, theater, environmental science, and idiom — each a distinct category, each with distinct rules about what green connects to and what follows from those connections. The token is the same. The categories are not. When a human says "green," context resolves which system is active — most of the time, well enough. But "well enough" is probabilistic, not structural. There is no formal mechanism in the word itself that says *this green belongs to Category\_Health, not Category\_Color*. The disambiguation happens in the reader, not in the representation. This is why human language is not a precise categorical substrate. It is a compression — evolved, borrowed, extended, metaphorically transferred across millennia — of many overlapping categorical systems packed into a shared token space. Every word carries this sediment. LLMs are trained on it. They learn the statistical distribution of tokens across all their contexts and become remarkably good at inferring which meaning is active. But statistical inference about which category is probably active is not the same as formal membership in a specific category with known morphisms. The imprecision is inherited, not resolved. A system built on human language as its semantic foundation inherits every one of those ambiguities — including the ones that collapse silently, in contexts where the inference was confident and wrong. That is the ceiling both MDD and SDD were hitting without knowing it. MDD tried to escape natural language and built something too precise for humans to use. SDD embraced natural language and inherited everything imprecise about it. The categorical representation is the third path: precise without requiring humans to author formal notation, because the structure is extracted from whatever the human provides — not assumed to already be in the words. --- ## Why Does a Computer Need Our Shorthand? The idea hit me in May of 2024 — almost two years before I left. I was still in the role: head of a Product and Technology Innovation Lab at a major corporation, the capstone of a thirty-year career. [I posted it publicly in October 2025](https://brianln.ai/ai-reflections), still in the job, framing it as a question: if AI can generate and maintain software in any language based on detailed specifications, why does it need our shorthand? Code is shorthand. It exists because humans needed a compact, readable notation for instructions that machines could also execute. The machine doesn't need the shorthand. We gave it ours because *we* needed to read it back. The answer people give when you ask is: *"So we can understand what it does."* That answer is true. And if you stop there, it sounds like a reason to keep everything as it is. But notice what it implies. Every abstraction in our software stack — every framework, every pattern, every query language, every modeling notation — exists to serve one constraint: human legibility. So humans can tell a computer what to do. Not correctness. Not composability. Not machine efficiency. Human legibility. If you have ever tried to read anyone else's code, or read your own more than three months after you wrote it, you understand the categorical meaning of "legible". The entire architecture of software complexity is a user experience decision made in 1960 that was never revisited in the large, because every generation of tools inherited it and optimized for it. Because "programming" is hard. Because it gives (some of us) meaning. Agentic Intelligence is changing this in a specific and underappreciated way. Not because it can generate code faster in our shorthand, though it can. Because it can see the boxes and lines directly — diagrams, flowcharts, natural language descriptions of process, voice memos, clinical notes, architectural sketches, workflows, relationships, boundaries — and extract their categorical structure. The objects. The morphisms. What connects to what, and what flows from that. It can do this across representations, across languages, across domains, and maintain coherence between them. At scale, for the first time, the translation from human meaning to machine-executable structure does not require a human to write the shorthand. All it takes is for us to stop optimizing for human understanding and start optimizing for semantic meaning and intent with formal categorical representations. --- ## My First Paid Programming Job Consider the curly brace. The position of `{` in a program never mattered to the machine. The machine parsed it, built a syntax tree, discarded the notation entirely, and compiled the tree. The brace existed to tell the human where a scope began and ended — a two-dimensional token, ink on a screen, for the human's eye. The machine saw an abstract structure. It always saw an abstract structure. We just routed everything through a notation legible to humans first, because humans were the only ones who could do the routing. The same is true of every delimiter, every keyword, every formatting convention in every programming language ever written. Indentation in Python. Semicolons in C. `BEGIN`/`END` in Pascal. These are not semantic structures. They are rendering conventions for two-dimensional human reading. The tree was always underneath. The machine always only cared about the tree. Now consider what happens to every program written in every Von Neumann language before the machine runs it. The source text is lexed — the `{` separated from the `}`, the whitespace and formatting discarded. The tokens are parsed — assembled into a tree that represents the structure the programmer intended. The tree is lowered into an intermediate representation where high-level abstractions are stripped away and what remains is a graph of typed values and operations. That graph is optimized: dead code eliminated, loops unrolled, function calls inlined. The optimized graph is compiled to machine code, linked with other compiled units, and in many runtimes compiled again at execution time by a JIT compiler that has learned the actual runtime behavior. Every step in that pipeline is the machine trying to reconstruct the structure the programmer was pointing at through the notation. The lexer removes the formatting the human needed to read the code. The parser recovers the tree the formatting was encoding. The IR lowering extracts the operations the tree was describing. The optimizer finds the structure the operations were approximating. The JIT finds the actual execution pattern the static structure was predicting. All of it — seventy years of compiler engineering, some of the most sophisticated software ever written — is infrastructure for undoing the notation and recovering the diagram. The whole pipeline is just trying to draw boxes and lines without boxes or lines. I know this pipeline from the inside. My first paid programming job was writing a compiler for [STEP](https://en.wikipedia.org/wiki/ISO_10303) — the Standard for the Exchange of Product model data, [ISO 10303](https://www.iso.org/committee/54158.html) — a language designed to represent CAD/CAM models: the geometry of physical objects, their assemblies, their tolerances, the manufacturing processes that would produce them. [STEP Tools, Inc.](https://www.steptools.com) had been working to implement and extend this standard since its earliest days. STEP is, without anyone having called it that at the time, a categorical definition of the shape of things and how to make them. Objects. Relationships. Composition. The standard defines what a cylindrical surface *is*, how it connects to an edge, how an edge connects to a face, how a face connects to a solid — boxes and lines, all the way down, for the physical world. And my job that summer was to write the compiler that translated it. To lex the STEP files, parse the schema, build the intermediate representations, generate output a downstream system could consume. I learned compiler theory well that summer. I built algorithms to walk the graph of the categorical representation of major international standard information representations to validate them against their own categorical rules expressed in STEP. What I didn't recognize until much later was the irony: the representation I was compiling *from* already had the categorical structure. The representation I was writing the compiler in and validating the representations in was in the Von Neumann categorical notation the machine required. The compiler was the tax, paid in code, to cross the gap between a clean categorical model and a machine that couldn't receive it directly. --- ## The Pivot and the Projection The Von Neumann model in the code is not what the computer ultimately executes. It never was. The computer executes the structure that the compiler constructed from the shorthand notation. If that structure can be represented directly — if the categorical foundation can be expressed without the notation as intermediary — then the compiler pipeline doesn't disappear, but its role inverts. Instead of recovering structure from notation, it projects structure onto substrate. The language evolution — assembly, C, C++, Java, C#, Python, JavaScript, TypeScript, Go, Rust, and whatever comes next — has always been moving upward: more abstraction, more expressiveness, more human legibility, all on top of the same foundation. Stacks and registers. Better ways to write assembly language. The pivot moves differently: back to the foundation first, then outward to any substrate. Not a new language in the lineage. A different relationship to the lineage entirely. [LLVM](https://llvm.org), a compiler backend for many programming languages, is already a substrate projector — not universal, but broad. Project a representation to LLVM Intermediate Representation (IR) and it can be compiled to any CPU architecture the LLVM backend supports: x86, ARM, RISC-V, WebAssembly, and more. It doesn't cover every possible substrate, but it covers the substrates that run the infrastructure we actually use most often. A categorical representation of meaning, expressed as a graph of objects and morphisms, projected to LLVM IR, runs on any hardware LLVM knows how to target. The same representation. Many substrates. And beyond LLVM: the neural network itself is a substrate. A Large Language Model's Neural Network weight space is a projection surface. Categorical structure can be projected not just into code that executes on silicon, but into the geometry of a model that reasons about meaning. The categories are the foundation. The languages are projections. LLVM is one projection mechanism. The substrates are whatever we choose to map them onto. --- ## Coding is Dead Not programming. Not problem-solving. Not the work of understanding a system deeply enough to specify what it should do. That work is harder than ever and more valuable. What is going away is the specific act of translating that understanding into text-based notation of symbols chained together into sequences that a compiler can parse — the curly braces and semicolons and import statements and type signatures that exist not because the machine needs them but because we built the machine to need them, because we built the machine around a metaphor that required them. Every framework ever written was built on top of that notation. Every design pattern is a workaround for a limitation of the languages that the notation made possible. Every best practice — DRY, SOLID, separation of concerns — is advice for managing complexity that the notation introduced. The abstractions stacked up not because the problems were irreducibly complex but because each generation of tools inherited the metaphor and optimized within it. The notation was the constraint. The constraints bred the ecosystem. The ecosystem looks like necessity. It isn't. The notation was always the clerk's scratch pad. The meaning was always in the structure underneath. We just couldn't give the structure to the machine directly. Now we can. The scratch pad is optional. --- ## No-Code is the Substrate This is also the definition of the "no-code" platform. That category of tools has been proving the concept for a decade: you don't need to write syntax to build software. [Bubble](https://bubble.io), [Webflow](https://webflow.com), [Zapier](https://zapier.com), [Retool](https://retool.com) — demonstrated that the underlying structure (data models, event handlers, conditional logic, integrations) could be expressed without code. The same was true for 4GL tools and "low-code" tools before that. The problem was never the idea. The problem was the interface. You still needed to know which dropdown held the onClick handler, which panel exposed the conditional branch, which screen in which menu connected the data binding. The no-code platform removed the notation tax and replaced it with a navigation tax. Fifty clicks instead of fifty lines instead of ten boxes and lines. The structure was always available. Finding it still required learning someone else's map of it. The agentic intelligence layer simplifies the mapping requirement. You describe what you mean — in natural language, in a diagram, in a voice memo, in whatever form meaning takes for you — and the system captures the categorical representation. The onClick handler is a morphism — a connection of the kind [described earlier](#the-coffee-shop-as-a-sketch), a relationship that relates one Object to another. The data binding is a Functor: a structure-preserving map between two parts of the system. The conditional branch is an object with two outgoing edges. You don't need to know what those things are called. You need to know what you want to happen. The no-code platform was right about the destination and wrong about the interface. This is the interface it was waiting for. And unlike the platform, it doesn't just build what you described. It reasons about what you meant — and asks about what you forgot to say. --- ## The Questions You Didn't Know You Needed to Answer I spent a long time working in code. In software. In architecture. In systems modeling and thinking. I spent a lot of time asking questions. The funny thing is that there are not that many you need to ask in the grand scheme of things. It is a sparse set of Objects and Morphisms we need to capture. In a GUI application you define an onClick handler. The system recognizes it as a morphism: user intent arriving through a pointing device, triggering a state change. And then it asks — because it can see the shape of the thing, not just the surface of it — *what if there's no mouse? What if there's no touch screen? Are there other interfaces that would work here — voice, maybe, or keyboard, or an API call from another system? What if the person can't see the thing to click?* The click was never the point. The click was one instantiation of the morphism in one substrate. The system knows what the morphism connects to, where it comes from, what it enables. It can see the other substrates. It can ask whether you want them. And it doesn't stop at the interface. The same categorical reasoning applies everywhere the structure touches the world. The morphism you drew assumes the message arrives — but what if it doesn't? The [fallacies of distributed computing](https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html) — first catalogued by Peter Deutsch at Sun Microsystems — are eight assumptions programmers have been encoding silently into software since the 1990s: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology doesn't change. Every one of them is a morphism that can fail. A system reasoning categorically can see them. It can ask: *you've modeled this as a direct connection — what happens when it isn't? Do you want retry logic here? Compensation? A dead letter queue? Why are you sending this to the server 10,000 times a minute?* Not as a checklist. As a consequence of the structure you expressed. The cost of running the system is a morphism too — resources consumed per operation, budgets that constrain which projections are viable. The system can ask what you're willing to pay, and surface the tradeoff between the projection that runs fastest and the one that runs cheapest. Scale is a natural transformation — a map between two ways of running the same structure, the same categorical skeleton projected onto one instance, ten instances, a thousand, with different consistency and latency characteristics at each level. The system can ask whether you want to scale up, out, or down, and show you what each projection preserves and what it sacrifices. The same structure projects onto different persistence substrates too. The objects and morphisms you described don't care whether they land in a relational database, a document store, a graph database, a key-value cache, or an event stream. Those are projections — different ways of rendering the same categorical structure onto different runtime surfaces, each with different performance characteristics, different query shapes, different operational costs. A system that holds the structure can ask which projection fits the access pattern you actually have, not the one you assumed when you picked Postgres because you always pick Postgres. This is what it means to work at the level of meaning rather than notation. A linter finds syntax errors. A type checker finds structural inconsistencies. A system that reasons categorically finds *implications* — things that follow from the structure you expressed that you may not have intended to leave out. The question about voice isn't a feature suggestion. It's the system telling you something true about what you built: that you modeled a concept, not a click, and concepts have more projections than the one you drew. This is the inversion. The Von Neumann model forced you to choose the substrate first — you picked your language, your database, your deployment target — and then encoded your meaning into whatever notation that substrate required. The categorical model holds the meaning first and projects onto substrates as needed. The choice of projection becomes a runtime decision, not an architectural commitment made before you understood the problem. --- ## So What Happens When This Changes and the "Tax" Disappears Domain expertise compounds. When the friction between what you know and what the system can receive approaches zero, the full value of the knowledge becomes available. The best clinicians get better outcomes, not just better notes. The best engineers find bugs faster, not just search more cleverly. The best tradespeople spend their freed time on more work, not less paperwork. There's a structural shift underneath this. Right now, access to the full capability of computing systems is filtered by syntax fluency. By "experts" who cast spells incanted in magical sequences of symbols. Remove that filter and the bottleneck shifts. The question becomes: do you know what you want? Can you express it with enough structure that the system can find the meaning? This is a different question from "do you know the syntax." It is more correlated with the ability to think and reason in system than with facility with a particular tool or dialect. The child at the coffee shop can already answer it. She always could. --- ## But the Risks!? A system that users trust to preserve meaning — but that only approximates preservation — will fail silently in high-stakes domains. The physician who trusts the system to have captured her observation may not know when it didn't. In medical, legal, and safety-critical contexts, "approximately correct" is not always distinguishable from "correct," and the difference matters. Human verification is not a fallback. It is the design. Systems that make it easier to capture and rationalize intent and meaning are actually safer. Concentration is the structural risk. If meaning at infrastructure scale flows through a single shared vocabulary — a dictionary of concepts that all domains translate into and out of — then whoever controls that vocabulary controls a remarkable amount of power. This is the dynamic of every infrastructure standard in history. The question is not whether to acknowledge it but whether to govern the vocabulary as a public good before it is captured as a product or a patent... Symmetric amplification is the dynamic with no clean mitigation. Everything that makes it easier to express intent and have systems act on it makes this easier for everyone. The distance between intent and action shrinks for all actors. That has huge economic and societal impacts that we are just beginning to imagine. And the fourth risk is the most human. People who stop maintaining syntax skills become dependent on the system being right. The fallback degrades. This is worth naming explicitly before it becomes invisible. I'm sure there are some people who still understand actual shorthand (other than coders). I for one am ready to let that particular space in my head go. --- ## The Crayons and Paper are Still on the Table The child has long since grown up. She's a doctor now, or an engineer, or a plumber, or a barista who knows the shop's entire operational flow in her body and can't express it in a form any system can receive. She still thinks in boxes and lines — we all do, we can't help it, it is the shape of meaning — but she has spent her career translating that structure into whatever format the computer in front of her could receive or into memos and papers and lossy representations of meaning. The translation cost her something. Not everything. But something. Three months ago I left a dream job. I was at the center of the "AI Transformation" of a large enterprise. I was talking to thought leaders and business leaders across the industry. I was at the tip of the spear, in the middle of the conversation. People thought I was crazy for leaving (that's a different post). The question I'd been carrying for two years — *why does the machine need our shorthand?* — had accumulated a career of evidence behind it, enough to write something longer than a question. This is that piece. Leaving the job gave me the space to write it. Helping others understand it and leverage it and becoming the best version of themselves is why I left. Not one company, the world. There is a new "Art of the Possible" and it leads you to re-assess everything you thought was possible. Everything you thought was real? The way you measure value in yourself and in others. The categorical definition of reality. The answer isn't that humans don't matter. It's that the constraint we've been optimizing for — human legibility of the intermediate representation — is not the same as meaning, intent, and understanding. The coffee shop doesn't need Two-Phase Commit to function. It doesn't need the barista to read the database schema. It needs the process to compose: the steps to connect, the outputs to become inputs, the exceptions to have recovery paths. The formal structure that makes this possible has been sitting in the mathematics since the 1940s. The "Von Neumann Tax" is not inevitable. It was a design choice. A categorical definition of how to "compute" inherited from the metaphors of the day. That led to representations humans could understand and write in our limited ability to express and compilers could parse. That time is ending. The crayons are still on the table. Time to clean off that whiteboard that has had those same diagrams and scribbles on it for months now. It's time to go back to the boxes and lines. Which raises the question the child at the coffee shop would ask: *if the diagram is the program, what does the computer look like that can read it?* *— Brian L-N, April 2026*