Trains of thought: everything

One language, transpiled to all the others

2026-11-03T00:00:00Z

LCD, the language I never wrote

Thought 2001, written November 2026. Programming languages.

Around 2001 I was fed up with writing the same business rules over and over.

They were never interesting rules. How an invoice is totalled. Which orders need someone to approve them. When a discount applies. The kind of thing a business could explain in a paragraph and then spend a decade being slightly wrong about. The trouble was not writing them. The trouble was writing them again, and again, because each execution environment that needed the rule ran on a different technology stack.

There would be a copy in C. Several copies in C++, because C++ was not one environment but several: MFC had its own idea of what a string was, Qt had another, and plain C++ with the standard library had a third. There was Java on the application server, and PL/SQL in the database, because the batch jobs and the reports ran next to the data. And probably Pascal, since Delphi was what a lot of people built their clients in.

Every copy was written by hand, sometimes by me and sometimes by someone else, in a different idiom, with different defaults for rounding, for null, for what dividing two integers means. On the day they were written they agreed. From then on they drifted. A fix in one copy was a bug report waiting to happen in all the others.

What I wanted was obvious, or felt obvious: write the rule once, in one language, and have it turn up in every one of those environments as code that belonged there.

I called it LCD.

The day job

LCD came straight out of my day job.

From 1998 to 2002 I worked at OZ, on iPulse, a communication and presence system: buddy lists, who is online, messaging, routing. My part was the plumbing underneath, the RPC system. Marshalling code, proxies and stubs, parsers, network streaming, and code generators, for several programming languages and environments at once. Most of it was in C++, Perl and Java.

A code generator for RPC is a machine for writing one thing once and getting it in several languages. You describe a message, and out come a C++ struct, a Java class and whatever Perl wants instead, with the code that turns each of them into bytes and back. The shape of the data is the same everywhere because nobody wrote it more than once.

The RPC layer talked to many different contexts, and every one of them needed the same logic. The generators gave them that logic without anyone writing it twice. If that worked for the RPC logic, it could work for the business rules too.

The name

Lowest common denominator is usually an insult. Here it was a specification.

The language would contain what every target could express, and nothing else. If C++ and Java could both do something, and do it the same way, it was in. If one of them couldn't, it was out, or it was given a meaning that both of them could carry. And the same test would have to hold for every other language: Python, which was already around, C#, which arrived the year after, then Go, TypeScript and Rust, and behind them the niche and the obsolete, the languages that still quietly run a payroll somewhere. The name was meant to keep me honest: whatever LCD was, it was not going to be a superset with a large runtime pretending to be every language at once.

Transpiled, obviously

I was pretty obsessed with transpiling it. Not compiling it to some common machine, not running it on a virtual machine of its own: turning it into source code in each target's own language.

That was not the fashionable answer in 2001. The fashionable answer was Java's: one runtime, everywhere, write once and run anywhere. Oracle had even put a Java virtual machine inside the database. The PL/SQL kept coming anyway, because the people who worked in the database wrote PL/SQL, and their tools, their debuggers and their habits all assumed it.

So the output had to be code that the people in each environment would own. A Java developer should open the generated file and see Java, the kind a careful colleague might have written. A database developer should see a PL/SQL package. Nobody downstream should have to know that LCD existed in order to read, debug or profile what it produced.

I had a less practical hope for it, too. Code formatters weren't in everyday use yet, and linters were a rarity out in the boondocks of Reykjavík, so a code review could turn into a flamewar over braces, indentation and names. If every environment got the code in its own style, why not every person? Write the code the way you like it, read it the way you like it, and there is nothing left to argue about.

Part 2 is about why this one choice turned out to shape almost everything else.

What I knew

Looking back at the list of languages I had used by then, I can see why I never believed in one denominator for everything.

I had written C++ for years, in more than one job, and Java and Perl in the one I had then. Along the way, at school, at work and in between, I had spent time with COBOL, Ada, Prolog, Lisp, assembly, BASIC, Pascal and LPC, the language the LPMud game servers ran on. Plus C, of course, and, because work demanded it, PL/SQL.

If you take the common denominator of all of those, you get very little. Prolog has no assignment. COBOL, at the time, had no functions you could define yourself. SQL has no steps at all, only sets. Assembly doesn't have types. A language that worked in all of them could describe data and almost nothing else.

I knew that. The interesting question was never whether one LCD could cover everything. It was how far one could get, and with what.

What it was meant to be

LCD was imperative: variables, assignment, conditions, loops, functions and procedures, records. All the traditional concepts, nothing exotic. Its memory was managed, which in those days meant one of two things: Java's garbage collector, or reference counting in C++. It had the classical data types and the kind of standard library you would expect to find anywhere: text, numbers, dates, collections.

It was for business logic. It would not draw windows, open files or talk to the network. The program around it would do that, and hand LCD what it needed to make a decision.

And it was meant to be transpiled into C, C++ in its various frameworks, Java, and every other programming language, past, present or future. Perl was on my mind as well, the way it was on everyone's mind in 2001: as the nightmare you woke from at three in the morning, crying, in a cold sweat, having dreamt that you had to change somebody else's regular expressions. LCD was going to let Perl sleep.

Why it stayed a dream

It never got further than that. No grammar, no transpiler, no decisions about how to close the gaps between targets: their type systems, their memory models, their ideas of what a record or a list is. I didn't write anything down.

I dropped it for an unglamorous reason. It wasn't something I wanted to spend my time on, and in those days it would have taken a massive amount of time. One person, several transpilers, a runtime library for every target, and no way to know whether any of it was right until all of it was finished.

Why write it down now

Because the idea never went away.

It has kept coming back ever since, these days as a language I call Y. I have never seriously sat down and built it. I have started it and shelved it more times than I can count. The oldest attempt that left anything in writing is YAPL, from 2019, which early on described itself as a transpiler to "all machines": LCD again, nearly twenty years later, under a different name. The latest version of Y has put transpiling, and the features that languages have in common, back in the spotlight, and that has had me reminiscing about LCD.

The rest of this series works out what LCD would have had to be:

One language, transpiled to all the others. This part.
Levels of denominator. Why one lowest common denominator was never going to be enough, and what to do instead.
Where the languages disagree. Division, rounding, null, and the empty string that Oracle thinks is nothing.
The cost, then and now. Why it would have taken years, and why that reason is mostly gone.

Levels of denominator

2026-11-03T00:00:00Z

Why one lowest common denominator was never going to be enough

Thought 2001, written November 2026. Programming languages.

I was not under the delusion that the same LCD would work with everything.

PL/SQL makes the point by itself. It was on the list for one reason: the product I was working on used it. It is Oracle's own proprietary language, and outside Oracle's databases nobody in their right mind writes it. It is SQL with loops, records, collections and exceptions bolted on, so you can write procedural code in it if you must, but its idea of data is rows. Nothing in it is shared the way objects are shared in Java: you assign a record and you get a copy. Put PL/SQL in the same bucket as Java and C++, and the denominator shrinks to whatever PL/SQL can do. Leave it out, and you have left out the database, which is where a lot of the rules had to run.

What I thought instead was that there could be levels of common denominator. I was mostly thinking about imperative languages, and about whether the idea could spread further than that.

The ladder

Here are the levels. Each one is the common denominator of a smaller family of languages. Each level contains the one below it.

Level 0: data. Booleans, integers, decimals, text, dates, enumerations, records, lists and maps. No null. This is what my RPC code generators at OZ already did: describe a shape once, and get it in every language. Almost everything can carry level 0, because it is just declarations.

Level 1: calculations and decisions. Functions of values, with no state and no loops: arithmetic, conditions, choices, failures, and the pure parts of the standard library. This reaches further than you'd think. Every imperative language can do it. So can PL/SQL. So can an SQL query, as an expression. So can COBOL, with COMPUTE and EVALUATE. So can Lisp, and so can Prolog, as a predicate that never backtracks.

Level 2: structured imperative. Local variables, assignment, loops, procedures, and records and collections passed around by value. This is the procedural core: C, C++, Java, Pascal, Ada, PL/SQL's procedural half, the structured dialects of BASIC, and COBOL within its limits. SQL drops out here, because SQL doesn't do steps.

Level 3: managed references. Values that are shared between owners and change in place, with their lifetime managed by a garbage collector or by reference counting. Java, C++ with reference-counted handles, Delphi, Perl and Lisp can do this. PL/SQL drops out here.

That last level is the language I wanted: imperative, with managed memory. The levels below it are what you get when you ask how much of it survives in environments that can't manage memory that way.

A module would say which level it needs, and the transpiler would refuse anything above that. A target would say which levels it can carry. A rule written at level 1 could then be used from level-3 Java code and from an SQL query in the database alike. The discipline for whoever wrote the rule would be simple: use the lowest level that can say it, because that is the level that reaches the most places. Most business rules are decisions and calculations. Most of them would have lived low.

What a level 1 rule looks like

LCD never got a syntax, so the examples in this series borrow Y's.

module pricing
level calculations


-- A price after a discount, to the cent.
--   why: The order screen, the invoice run and the month-end report must show the same price.
function discounted(amount is decimal(12, 2), rate is decimal(5, 4)) returns decimal(12, 2):
    return round_half_away_from_zero(amount * (1 - rate), places: 2)

In the database, a level 1 function doesn't need to be a function at all. It can be an expression in a query, and run over every row at once, which is where the database earns its keep:

SELECT order_id, ROUND(amount * (1 - rate), 2) AS discounted
FROM   order_lines;

In COBOL it becomes a small subprogram, with overflow reported through a status field:

       PROCEDURE DIVISION USING AMOUNT RATE RESULT STATUS-CODE.
           MOVE 0 TO STATUS-CODE
           COMPUTE RESULT ROUNDED = AMOUNT * (1 - RATE)
               ON SIZE ERROR MOVE 1 TO STATUS-CODE
           END-COMPUTE
           EXIT PROGRAM.

The rounding mode in the LCD version is not an accident. Rounding half away from zero is what Oracle's ROUND and COBOL's ROUNDED both do natively, so neither of them needs any help. Pick a different mode and you'd need a library in each of them to do it for you. Part 3 is largely about choices like that one.

Who carries what

This is roughly how the languages I knew in 2001 would have sorted themselves. A full mark means the language carries the level natively. A half mark means it can, with a runtime library or within limits. A cross means it can't.

Language	0 Data	1 Calculations	2 Structured	3 References
C	✓	◐	✓	◐
C++, in each framework	✓	✓	✓	✓
Java	✓	✓	✓	✓
Pascal (Delphi)	✓	✓	✓	◐
Ada	✓	✓	✓	◐
PL/SQL	✓	✓	✓	✗
SQL	✓	✓	✗	✗
COBOL	✓	✓	◐	✗
BASIC	◐	✓	◐	✗
Lisp	✓	✓	✓	✓
Prolog	✓	✓	◐	✗

C gets a half mark at level 1 because it has no decimal type, so money needs a library. COBOL gets a half mark at level 2 because its tables have fixed sizes and, in the COBOL of that time, nothing could call itself. Prolog gets one because loops have to become recursion and assignment has to become new names.

Why transpiling forces the levels

This is where the obsession with transpiling comes back in.

If LCD had been compiled, levels would hardly matter. A compiler can put any program on any machine, because in the end every target is machine code. One denominator, the whole language, would have done.

A transpiler can only produce what the target language can say, and say readably. The common denominator that matters is one of expression, not one of execution. And expression is exactly where language families differ: SQL can say a calculation beautifully and a loop not at all, and Java can say almost anything but says a decimal calculation in a way nobody would call beautiful.

So the levels are not a compromise forced on the design. They fall straight out of the decision to transpile.

The same decision shapes everything else. Transpiled code is code people own. It has to read as if a careful programmer of that language wrote it, with its own types, its own loops and its own way of failing. Names have to survive unchanged, so that a search for a rule finds every copy of it. Each generated function has to say where it came from, and nobody edits it by hand. Whatever a target lacks, such as decimals in C, has to come from a small library written in that target's own language and shipped as source beside the generated code. And the whole thing has to fit into each environment's build as it already is: the C++ goes through the C++ build, the PL/SQL is installed like any other package.

Spreading further

The other half of the thought was whether LCD could spread beyond the imperative family. Each direction would have needed something different.

Sets. Level 1 already reaches into SQL, as an expression in a query. A level of set operations, such as filtering, joining, grouping and summing lists of records, would sit beside level 2 rather than above it. It would transpile into SQL and Lisp naturally, and into loops everywhere else.

Logic. Level 1 maps onto Prolog predicates. What Prolog adds, searching and backtracking, has no counterpart anywhere else, so it would stay out. The interesting direction is the other one: LCD's rules written out as Prolog facts and clauses could be asked why a decision came out the way it did.

Lisp. Lisp could carry every level, and its macros could be LCD's transpiler for Lisp. It is the one target where LCD would have been a library rather than a code generator.

Assembly. Assembly can run anything and explain nothing. LCD's whole promise was readable code in each environment, so assembly would have been a compiler's job, never LCD's.

Next, in part 3: what happens inside a level, when the languages that are supposed to agree simply don't.

Where the languages disagree

2026-11-03T00:00:00Z

Division, rounding, null, and the empty string that Oracle thinks is nothing

Thought 2001, written November 2026. Programming languages.

Levels decide which languages have to agree. They don't make them agree.

Take any two languages that both carry level 1 and write the same innocent-looking expression in each. Surprisingly often you get two answers. Each answer is reasonable, each is documented, and each has been relied on by somebody for years. None of them is wrong. They are just different, and a rule that gives different answers in different places is exactly what LCD existed to prevent.

So inside each level there is one more test, applied to every feature: do all the targets that carry this level give it the same meaning? If they do, it's in. If they can with help, it's in, and a small runtime library supplies the help where it's missing. If they can't agree, LCD has two options. It can pick one meaning and say so out loud, in the name of the operation. Or it can leave the feature out.

Most of LCD's character would have come from that last case. Here is how.

Dividing two integers

C, C++ and Java truncate: 7 divided by 2 is 3. Pascal keeps the two apart: div for integer division, and /, which always gives a real, 3.5. PL/SQL's / gives 3.5 too. Perl gives 3.5 as a floating-point number. Ada truncates, but distinguishes rem from mod, which disagree as soon as a negative number turns up.

LCD's answer: no / on integers at all. Division says how it rounds: divide_truncated, divide_floor, divide_exact, the last of which fails if anything is left over. It's longer to type. Nobody ever has to wonder.

Rounding

Java's BigDecimal offers every rounding mode you could want. Oracle's ROUND rounds half away from zero, as does COBOL's ROUNDED. Delphi's Round rounds half to even, the banker's way. C leaves it to you.

So rounding names its mode too: round_half_even, round_half_away_from_zero. Where a target lacks the mode you asked for, the runtime library implements it in that target's own language. That's why the level 1 example in part 2 chose half away from zero: the database and COBOL could both do it without help.

Null

In SQL, NULL means unknown, and unknown spreads. Compare a null with anything and the answer is unknown, and an IF whose condition is unknown quietly takes the ELSE branch. Java and Pascal have null references, which do something much louder. C has null pointers, which do whatever they like.

LCD would have had no null. If something can be absent, its type says so, and the code has to say what happens in each case. Where LCD code meets its host, the transpiled code checks every value on the way in, so a NULL from the database becomes a failure with a name, rather than a quiet wrong turn.

The empty string

Oracle stores the empty string as NULL. This is not a bug. It is how Oracle has always worked, and it's documented, and it has surprised people for decades.

In LCD, text is never absent, although it can be empty. The PL/SQL runtime would have had to represent empty text in a way that could never turn into NULL on the way through.

What counts as true

C has no boolean type of its own and treats zero as false. Many BASICs use -1 for true. Perl treats "0" and "" as false, along with a few other things you have to learn the hard way.

In LCD only a boolean can decide an if. There is no truthiness to translate, so there is nothing to get wrong.

Overflow

Signed overflow in C is undefined, which means the compiler may assume it never happens. Java wraps around without a word. PL/SQL and Ada raise an error. Pascal raises one only if overflow checks are switched on. COBOL quietly cuts off the digits that don't fit, unless you asked for ON SIZE ERROR.

In LCD, overflow is a failure, everywhere. The C runtime checks for it, so that C behaves like the others.

Where strings start

PL/SQL's SUBSTR, COBOL and Pascal's strings start counting at 1. C, C++ and Java start at 0.

LCD has to pick one and transpile it for the others. I'd have picked 1, because business people count from 1. In Y I ended up with something better: every index carries its unit, so a position can't be confused with a count.

Names

PL/SQL, Pascal, Ada and COBOL don't care about case. PL/SQL names stopped at 30 characters, and so did COBOL's. COBOL wants hyphens where everyone else wants underscores. And every language reserves a different set of words.

So every LCD name is lowercase with underscores, at most 30 characters long, unique even if you ignore case, and not a reserved word anywhere. COBOL gets hyphens instead of underscores. Y still has the all-lowercase rule today. I like to think it came from somewhere.

Errors

C returns error codes. C++, Java, Pascal, Ada and PL/SQL have exceptions, all different. MFC throws pointers to exceptions, which you then have to delete. COBOL has status fields.

An LCD function declares, by name, the ways in which it can fail. Each target then reports those failures in its own way: a return code in C, an exception in Java, a raised error in PL/SQL.

The rest

Two more fall out quickly. C and C++ leave the order in which a function's arguments are evaluated unspecified, so an LCD expression may have at most one effect. And every language has its own precedence table, so LCD requires parentheses wherever two kinds of operator meet.

The last one is about time and chance. Every target has its own clock and its own random number generator, and no two of them agree. Business logic in LCD would have had neither. "Today" would be an argument, passed in from outside. So would any random seed. Given the same inputs, every target would compute the same answer, which is the whole point.

Memory

LCD's memory was managed: Java's garbage collector, or reference counting in C++. Making that work the same everywhere is its own puzzle, because the targets manage memory in three different ways. Java collects garbage. C++, Delphi and Perl count references. PL/SQL copies, and shares nothing.

The levels from part 2 sort this out. At levels 0 to 2 there are only values: assign a record and you get your own copy. Behind the scenes a runtime may share it and copy it only when someone writes to it, but no program can tell. That works everywhere, including PL/SQL.

Level 3 adds values that really are shared. For those to behave identically under a garbage collector and under reference counting, two things have to go. Cycles go, because a reference counter can't reclaim a cycle and a garbage collector can. Finalisers go, because nobody knows when a garbage collector will run, but everybody knows exactly when the last reference disappears.

One rule, three languages

Here is a level 2 rule, with a loop in it, which PL/SQL can carry and plain SQL can't. Again, the notation borrows from Y.

module invoicing
level structured


-- A line on an invoice.
record invoice_line:
    quantity is integer
    unit_price is decimal(12, 2)


-- Why an invoice cannot be totalled.
failure invoice_error:
    no_lines
    negative_quantity


-- Totals an invoice, with the volume discount the price list gives above 1000.00.
--   why: The shop, the web site and the nightly batch must charge the same amount for the same lines.
function invoice_total(lines is list of invoice_line) returns decimal(12, 2) fails invoice_error:
    if no_lines = lines.is_empty():
        fail invoice_error.no_lines
    else has_lines:
        var total is decimal(12, 2) = 0.00

        for line in lines:
            if negative = (line.quantity < 0):
                fail invoice_error.negative_quantity
            else counted:
                total := total + (line.unit_price * line.quantity)

        if large_order = (total >= 1000.00):
            return round_half_even(total * 0.95, places: 2)
        else small_order:
            return total

Every condition has a name, large_order or small_order, and so does every way of failing. That is how you would check that the shop, the web site and the nightly batch took the same path: the names would be the same strings in every language's logs.

Here it is in PL/SQL. Oracle has no half-to-even rounding, so that call goes to the runtime library, lcd_std:

CREATE OR REPLACE PACKAGE BODY invoicing AS
  FUNCTION invoice_total(lines IN invoice_lines) RETURN NUMBER IS
    total NUMBER(12, 2) := 0;
  BEGIN
    IF lines IS NULL OR lines.COUNT = 0 THEN
      lcd_std.fail('invoicing.invoice_error.no_lines');
    END IF;

    FOR i IN 1 .. lines.COUNT LOOP
      IF lines(i).quantity IS NULL OR lines(i).unit_price IS NULL THEN
        lcd_std.fail('lcd.missing_value');
      END IF;
      IF lines(i).quantity < 0 THEN
        lcd_std.fail('invoicing.invoice_error.negative_quantity');
      END IF;
      total := total + (lines(i).unit_price * lines(i).quantity);
    END LOOP;

    IF total >= 1000.00 THEN
      RETURN lcd_std.round_half_even(total * 0.95, 2);
    ELSE
      RETURN total;
    END IF;
  END invoice_total;
END invoicing;

All those IS NULL checks are the price of LCD having no null. Leave them out, and a null quantity coming in from outside would make every comparison unknown and quietly take the wrong branch.

And in Java as it was in 2001, before generics and before enums:

public static BigDecimal invoice_total(List lines) throws invoice_error {
    if (lcd_std.require(lines).isEmpty()) {
        throw new invoice_error(invoice_error.no_lines);
    }
    BigDecimal total = lcd_std.decimal("0.00");
    for (Iterator it = lines.iterator(); it.hasNext(); ) {
        invoice_line line = (invoice_line) it.next();
        if (line.quantity < 0) {
            throw new invoice_error(invoice_error.negative_quantity);
        }
        total = total.add(line.unit_price.multiply(BigDecimal.valueOf(line.quantity)));
    }
    if (total.compareTo(lcd_std.decimal("1000.00")) >= 0) {
        return lcd_std.round_half_even(total.multiply(lcd_std.decimal("0.95")), 2);
    }
    return total;
}

Yes, that is invoice_total and not invoiceTotal. It's unidiomatic Java, and it's deliberate. A search for the rule's name should find it in every language.

The C version returns its failure as a code and writes the total through a pointer, and its money is a scaled integer from the runtime library. The Delphi version gets off lightly: Delphi's Currency type holds four fixed decimal places, so the arithmetic is native.

The library

The standard library would have been small, and written once per target, by hand, in that target's own language: text, numbers with their named roundings and divisions, dates with a named rule for what happens at the end of a month, collections, and conversion to and from text in an explicit format, never one that depends on the machine's locale.

What it would never have had: files, the network, the database, threads, the clock, randomness, anything visual. That all belongs to the program around the rules.

The tests

A test would be written once in LCD and transpiled along with the code. It would run on every target that carries the module's level, and the targets would have to agree. When they didn't, that would not mean one of them won. It would mean a transpiler or a runtime library was wrong.

In the end the tests would be the real definition of each level. A feature is in a level when its tests pass on every target of that level.

All of which sounds tidy on paper. Part 4 is about what it would have cost to build, and why that, rather than any of the problems above, is what killed it.

The cost, then and now

2026-11-03T00:00:00Z

Why LCD would have taken years, and why that reason is mostly gone

Thought 2001, written November 2026. Programming languages.

I dropped LCD because it wasn't something I wanted to spend my time on, and because in those days it would have taken a massive amount of time.

Twenty-five years later I can be more specific about the second half of that.

The bill

A transpiler for every target. C, C++ once for each framework, Java, PL/SQL, Pascal, and COBOL if it was ever going to reach the older systems. Each one emitting code that reads as if a person wrote it, which is much harder than emitting code that merely works.

A runtime library for every target. Decimal arithmetic, every rounding mode, dates, text and collections, each written by hand in the target's own language. C needs all of it. PL/SQL needs most of it. Each C++ framework needs its own glue.

Levels multiply the work. Every level has to be defined, tested and transpiled for every target that carries it, and a change to one level has to be checked against all of them.

The gaps. I never got as far as deciding how to close the gaps between targets, and each one is real work. Typing: PL/SQL's NUMBER against fixed-width integers, Java without generics, C without checked anything, Perl without static types at all. Memory: values that are cheap on every memory manager, and shared references that behave the same under a garbage collector and a reference counter. Data: the database thinks in rows and sets, and everyone else thinks in records, so a loop that is natural in Java is slow inside Oracle. Text: the database, the JVM, Windows code pages and C's bytes each had their own idea of a character, so there was no single meaning of "length" or "upper case" to transpile.

Proving the targets agree. The test suite would run on every toolchain, some of them inside a database, and every disagreement would have to be traced to a transpiler, a runtime library or the definition of a level.

Keeping up. Every new version of a target changes what a level can hold. Java 5 arrived in 2004 with generics and enums. Oracle 10g added new numeric types. Each framework kept moving too.

Adoption. Even when it all worked, the generated code would be code that a team in each environment had to debug, deploy and own, written by a tool they hadn't asked for.

None of that is impossible. It was just years of one person's work for a tool whose benefit arrived only at the very end, once every transpiler was finished. I had a job, and other things I would rather do. It stayed a dream.

It came back anyway

What surprised me, going back through everything that led to Y, is how much of LCD's thinking kept turning up without my ever having written LCD down.

Transpiling. YAPL, the first version that left any written trace, was started in 2019 and early on described itself as a transpiler to "all machines". In the 2024 design discussions I gave it up: "we are no longer aiming for transpilation". In September 2026 it came straight back, in a conversation that started with a language that "really just transpiles to Rust". Y's position today is a compromise I think LCD would have recognized. Rust is not Y's definition; it is a backend and a check. But the example programs are lowered to plain, readable Rust that an ordinary Rust toolchain builds.

Levels. Y has a constraint language for describing rules about code that lives in other languages: Python, T-SQL, C#, Rust and more. Its kinds of rule are switched on host by host, the simpler kinds for some languages and the richer ones only for languages whose types can carry them. That is LCD's levels again, with "level" renamed to "kind".

Rules written once. The reason that constraint language exists is the problem LCD started from: business rules repeated across a client, a server and a database, each copy free to drift.

The host does what the language can't. Y has no foreign-function interface. When it needs something it can't express, the function is declared in Y and written in the backend's own language. LCD's runtime library, written by hand in each target, was the same move.

The same tests everywhere. In Y, running several backends and comparing them is a way of finding bugs, and a disagreement is a bug, never a vote. That is LCD's test suite, almost word for word.

And the small things. No / on integers; division says how it rounds. No null, and nothing is true except a boolean. Every name lowercase, with underscores. Every decision named, so traces can be compared. Every function declaring how it can fail. No clock and no randomness unless they are handed in. Every rule saying why. Each of those appears in Y, and each of them is an answer to a question LCD would have had to ask.

Most of them first turn up in writing years later, in YAPL or in the 2024 design discussions. All of them are what you would end up with if you spent a long time trying to make several languages agree, and that is what I spent some of 2001 thinking about.

What changed

LCD was a set of small languages for people to write, with transpilers written by people, each level chosen so that its targets could carry it. Y is a whole language, written mostly by AI agents and reviewed by people, with a compiler that checks what the agents propose. I wrote about what happens to a language when its writer changes in Write-only languages.

The change that matters for LCD is simpler than that. Look at the bill again. A transpiler per target. A runtime library per target. A test suite run against every target, with every disagreement traced to its cause. That is exactly the kind of work that is specified once, checked mechanically, and done many times over: the kind of work agents now do well.

The reason I dropped LCD is mostly gone. The question it asked is still the one Y asks: how do you write a rule once, and trust it wherever it runs?

The unreviewable pull request

2026-11-03T00:00:00Z

Let it grow, then have an agent carve it up

Thought 2019, written November 2026. Processes.

It starts with a task that fits on a sticky note. Somewhere along the way I notice that the code I'm touching is a mess, and since I'm in there anyway, I clean it up. The cleanup exposes an edge case nobody handled, so I handle it. Handling it properly needs tests that don't exist, so I write them. The tests find two bugs. I fix them. Then I remember a feature that was part of the original ask and somehow fell off the plan, and I add that too.

Eventually I open a pull request with 400 files and 20,000 lines changed.

That's on a good day. On a bad day, I've also found a better name for one of the core concepts along the way. What everyone has been calling a "user" is really an "account", so I fix it, and a codebase-wide search and replace changes a line here and there in a thousand files. Add the generated code and the test snapshots that get regenerated because the word appears in them, and the PR isn't 20,000 lines any more. It's 400,000. Something microscopic did that. One word.

Every one of those lines is, as far as I can tell, an improvement. Together, they're unreviewable.

Nobody reads 20,000 lines, let alone 400,000. A reviewer handed a PR like that has two honest options, both bad: spend a week on it, or skim it, leave a comment about a variable name so it looks read, and approve. The research on this is old and the metric is crude, but it points the same way. In SmartBear's study of a team at Cisco, reviewers stopped finding much after 200 to 400 lines. My good-day PR was fifty of those, stapled together. The bad-day one was a thousand.

A manager I had years ago was hostile to PRs like that. Hard-core hostile. A monster didn't get reviewed. It got sent back to be split.

I didn't like it at the time. Naturally.

GitHub had no concept of a stack back then. A chain of PRs was a chain of branches, each based on the one before it, and every fix to the bottom one had to be rebased up through the rest by hand. The same went for every time the master branch moved under me: I had to propagate the merge up through every PR in the chain, again and again, until the reviewer deigned them worth his time. Skip a round, and the drift quickly became unmanageable. Not that it wasn't tough enough already.

All of that was tedious, and it was the smallest of my problems.

The big one was that the split can't be planned up front. With a large task, you only know exactly what you're doing in retrospect, after you've done it. En route, you have a broad idea, and a broad idea doesn't tell you where the seams are. So I'd finish the work, then pluck it apart, hunk by hunk, git add -p until my eyes glazed over. The job was to take a week's worth of exploratory work, with its detours, dead ends and second thoughts, and retrofit it into a perfect string of pearls: the refactor, then the tests, then the two bug fixes, then the feature. Each pearl in its place, lined up as if there had never been anything but 100% certainty about the path and the destination.

That was the horror.

It wasted a lot of time. I learned quickly that his way was better anyway.

What surprised me was that splitting didn't just make the review easier. It made the work better. Each PR in the chain was a milestone, and a milestone has to stand on its own: it builds, its tests pass, and its description says what it does without leaning on the next eleven. When a refactor is cut loose from the feature that motivated it, you notice the parts of the refactor that only made sense for a version of the feature that later changed shape. When the tests have to stand alone, you notice they're half-finished. Debug leftovers, dead code, the abandoned first attempt that's still half in there: a monster hides all of that, and a milestone doesn't. Every PR came out more correct, more maintainable, more beautiful. More all sorts of good things.

And it took load off the reviewer, which matters more than it sounds. In a review process that's actually worth something (not the rubber stamp practiced in most places), the reviewers are the more experienced engineers. They're overloaded, their time is limited, and what they know is some of the most valuable knowledge in the building. Handing them 20,000 lines wastes the scarcest thing you have.

He was right. It just took me a while to stop resenting the hours it cost.

Today, Opus generally has more knowledge, more time and more skill than those reviewers did. You'd think that makes the problem go away. It doesn't. Opus also does a better job on a focused PR than on a multi-hundred-file monstrosity. Its attention runs out later than a human's, but it runs out, and it runs out quietly. An overwhelmed human knows they're overwhelmed. An overwhelmed model writes a confident review of whichever parts it happened to look at closely.

So the rule stands. What changed is who pays for it.

I still let the task grow. I've stopped fighting that. Refactoring along the way, handling the edge cases, adding the feature everyone forgot: that's how I find out what the task actually was. Then, once I know what I did, I tell an agent to split it into a stack. It strings the pearls without complaint, and it has no trouble pretending we knew where we were going all along. Then I have an agent review each PR in the stack. Then an agent resolves the merge conflicts the review fixes cause, and merges the stack, bottom up.

GitHub now supports stacked pull requests as a first-class concept, in public preview since July. That helps, but the tooling was never the hard part. The hard part was the retrofitting, and that's exactly what I delegate.

The best side effect is the one I didn't expect. With the work cut into tractable bites, my own valuable time and inferior mind can provide a much better review of the agents' work. I can follow a 600-line PR that does one thing. I could never follow the monster, and I wrote it. Well, obviously I didn't write it. I asked Claude to.

The rest of this is the parts that took me a while to get right.

1. The monster is the specification

Don't delete the monster branch after the split. Until the stack is merged, it's the source of truth, and it makes the split cheap to check: the top of the stack must produce exactly the same tree as the monster. git diff monster stack-top should print nothing.

That one command turns "did the agent drop a hunk somewhere in 400 files?" from a question I'd have to read my way to into one a machine answers in a second. Divergence from the monster is allowed only on purpose, as review fixes made after the split, in their own commits.

2. Every layer builds, passes and ships

A stack isn't a pile of diffs cut at arbitrary points. Each layer must compile, pass its tests, and be safe to merge and deploy without the layers above it. CI runs on every layer, not just the top. That's what makes a layer reviewable on its own, and it's what lets the bottom of the stack land while the top is still being argued over.

If something can't ship half-done, it goes behind a flag, or it gets the parallel change treatment: expand, migrate, contract. That used to be the extra work everybody skipped. Agents don't skip it, and they don't sigh.

The payoff comes later. When something breaks in production three weeks on, git bisect lands on a PR that does one thing, and the revert takes out one thing, not a feature, a refactor and two unrelated bug fixes.

Not that anybody in their right mind reaches for git bisect unless they're truly desperate. Humans, that is. Agents don't care.

3. A refactor or a behavior change, never both

This is the most useful seam in any split. Kent Beck put it best: "make the change easy (warning: this may be hard), then make the easy change." The stack should read in that order.

A refactor PR changes no behavior, and proves it: the existing tests pass unchanged. If a refactor touches a test's assertions, it isn't a refactor. Mechanical changes (renames, moves, formatting, generated code) get their own PRs, because they're reviewed differently. Nobody should read a mechanical change line by line. You check how it was produced and that the tests still pass. That leaves the PR that changes behavior small, and that's where the real review goes.

4. A rename gets a PR of its own

The rename from the bad day is the extreme case, and the most instructive one. By line count, it's the biggest change in the monster. By content, it's the smallest: one word. Inside the monster, it's poison. The one line in file 612 that changes behavior sits between two lines that only changed a word, and nobody, human or model, reliably spots it in 400,000 lines of noise.

Pulled out on its own, the same thousand files make one of the easiest PRs there is to review, as long as nobody reads it. The PR says exactly how it was made: the search, the replacement, the command that regenerated the code and the snapshots. The reviewer (usually an agent) reruns all of that on the base branch and diffs the result against the PR. If the diff is empty, it's done. What's left is the interesting part: the places where the search got it wrong. A "user interface" is not an "account interface". Those hand-made exceptions go in a commit of their own, listed in the description, and they're the only part anyone reads line by line.

The rename goes at the bottom of the stack, so every layer above it is written and reviewed in the final vocabulary. The reviewer of layer 7 shouldn't have to translate. I found the name last. It goes first.

It merges first, too, and fast. A thousand-file PR conflicts with everything anyone else is working on, so every day it waits, it rots a little more, and so does every other branch in the repository.

The exception is a rename that crosses a boundary. A database column, a field in a public API, a key in serialized data, a setting in someone else's config: those are behavior changes wearing a rename's clothes. They get the parallel change treatment from section 2, and a real review.

Take the rename out, and the 400,000-line monster is a 20,000-line monster again. Still a monster, but one that can be carved.

5. Not everything belongs in the chain

A monster is several things that grew together, and not all of them depend on each other. The two bug fixes the new tests found don't need the feature. Usually they don't even need the tests. Those come out as independent PRs against main and merge first, today, where they're worth something.

A stack should be a chain only where there's a real dependency. Everywhere else it's a tree, or a few unrelated PRs. Every layer taken out of the chain is one less layer to restack when something below it changes, and one less thing waiting on the slowest review in the line.

6. One idea per PR, not N lines per PR

Line count is a proxy. Two to four hundred lines is a decent smell test, but a 380,000-line rename is easier to review than a 40-line change to a locking scheme. What I ask for is one idea per PR, a title that states it without an "and", and a description that says what the PR does, what it deliberately doesn't do, and where it sits in the stack. If the agent can't write the title without an "and", it's two PRs.

Too small is a failure too. A stack of sixty trivial PRs has lost the story just as thoroughly as one PR with sixty ideas in it. A reviewer should be able to read the stack's titles from bottom to top and see the string of pearls: the change, told in the order it should have been built, even though it wasn't. If they can't, the split is wrong, whatever the line counts say.

7. A fresh reviewer for every layer

Each layer gets its own review session, one that didn't write the code and didn't do the split. It gets the plan or design document, so it knows where the stack is headed, and it gets its own diff, which is what it judges.

"This gets fixed in PR 9" is not an acceptable answer in the review of PR 4. If PR 4 is only correct because of PR 9, the split is wrong, and that's a finding against the split, not a reason to approve.

8. Someone still has to look at the whole thing

This is what splitting costs. Twelve reviewers, each judging one slice, can each be right and still miss how slice 3 and slice 9 interact. Cross-cutting concerns (consistency, naming, error handling that's done three different ways in three layers) don't belong to any one layer.

So once the layers are reviewed, one more review goes over the whole stack against the design. That sounds like reviewing the monster after all, but it isn't. Every piece in it has already been vetted, so the reviewer only has to think about the joints. It's a smaller, sharper question, and both agents and humans answer it better.

9. Fixes flow up, merges flow down

A review fix in layer 3 conflicts with layers 4 through 12. That cascade was the smallest of my problems when I maintained stacks by hand, but it was still a problem, and every cascade cost an afternoon. Now restacking is the agent's job (with gh stack sync doing most of the rebasing), and the rule I give it is simple: fix the problem in the lowest layer where it exists. Never patch it at the top. A fix at the top leaves every layer in between lying about what it does.

Merges go bottom up, and a layer merges as soon as it's approved. Every day an approved layer sits unmerged is a day main moves under it, and that drift has to be propagated up through every layer above. It used to be my job. It's an agent's now, but the drift is no smaller for it.

10. Where my own attention goes

Not evenly. That's the point of having layers.

For mechanical layers, I check the evidence: the tree diff came back empty, the rename reproduces from its own command, the tests didn't change. Then I skim. For refactor layers, I check that the tests didn't change, and I read the parts the review flagged. The layer that changes behavior gets a real read, line by line, and so does anything that touches money, security or deleting data, however mechanical it claims to be.

I also read the reviews before the diffs, and I read the author agent's reasons for dismissing a finding more carefully than either. "This is intentional" is the most expensive sentence in the whole process when it isn't true.

These days I let my tasks grow into monsters without guilt, because I know what happens to them next. They get sent back to be split. Every single one.

I've turned into that manager. The difference is that my reports are agents, and they don't take it personally.

Does not play well with others

2026-11-03T00:00:00Z

A machine sat 113 university exams, and the pedagogy has concerns

Thought October 2026, written November 2026. Working with AI.

In October 2026, I sent Claude to university.

Not the full experience. No orientation week, no student loans, no mandatory workshop on finding your learning style. Just the exams.

I collected publicly available past papers from MIT, Oxford and Southampton. Physics, maths and computer science: the coursework you'd need to read the things I've been reading lately. Then I had Claude Opus 5.5 sit them, one paper at a time, in a single response each. No calculator, no code execution, no search, no notes, no formula sheet. It was told not to consult or reproduce any published answers, which is the same rule that binds a human candidate.

A separate Opus 5.5 session, at maximum effort, marked each paper against its own mark allocation. Before reading a single answer, it worked out its own.

113 papers, 90 courses, four days.

The mean mark was 99.5%. 98 of the 113 papers came back with full marks. 76 of the 90 courses were perfect. The worst course in the whole set came in at 89%.

Every square is a course, sorted from best to worst. Blue: full marks. Orange and hatched: something was lost, and the darker the orange, the more. Hover over a square for its course and mark.

I'm not going to dress this up, in either direction, so here are the misses.

The worst course, the 89%, lost all eleven of its marks on a single problem whose figure we never gave it.

The worst result with no excuse attached was MIT's Computer Systems Engineering, at 90.5%. It missed a factor in an attack on salted rainbow tables, misjudged when a Raft leader eventually commits an entry, and made a wrong assumption about a participant in two-phase commit. Those are real mistakes. They're also the mistakes a strong student makes, in the one subject most working engineers would quietly prefer not to be examined on at all.

Then there's the obvious objection: the papers are public, so maybe it just remembered the answers. I can't rule out that it saw them in training. What I can say is that it claimed to recognize 44 of the 113, and on those it averaged 99.2%. On the 69 it didn't recognize, it averaged 99.8%, with full marks on 64 of them.

It did better on the papers it had never seen.

Along the way, it skipped the one question on a Southampton paper that turned out to be printed wrong. The marker later worked out why: the expression it asks you to derive has the dimensions of a pressure, not an energy. An MIT paper announced that its problems were worth 25 points each, for a total of 100, and then contained three of them. The machines noticed. Presumably a few generations of students did too, and decided it wasn't their place to say.

For the record, before anyone else says it: every paper was marked by a model from the same family, and no human has checked the marks. Only Opus 5.5 has sat so far. The smaller models are next.

Exams aren't degrees. Universities also want labs, theses, projects, seminars and, at MIT, a healthy portion of humanities, none of which can be sat as a paper. So I asked a narrower question: taking each university's own published curriculum and its own classification rules, which degrees have every written requirement met?

One of them is simply done.

The Unaccredited Board of Papers Sat Alone

This is to certify that

Claude Opus 5.5

has met every requirement of the degree of

Master of Science in Mathematical and Theoretical Physics

as the University of Oxford's published curriculum sets it out: 20.25 units passed against the 10 required, mean mark 99.7% over 21 papers

With Distinction

Claude Opus 5.5Examiner, at maximum effort(vacant)Human moderator

The degree has no thesis and no lab, so on paper there's nothing left. The only thing it lacks is the paper.

Two more are close behind.

The Unaccredited Board of Papers Sat Alone

This is to certify that

Claude Opus 5.5

has passed every core exam module of the

Master of Physics in Physics with Astronomy

as the University of Southampton's published curriculum sets it out: mean mark 99.8% over 28 papers, where First Class starts at 70%

First-Class Honours, pending

Claude Opus 5.5Examiner, at maximum effort(vacant)Human moderator

Still owed: a third Part IV option, which has no public paper to sit, plus the lab and skills modules, the dissertation and the MPhys project.

The Unaccredited Board of Papers Sat Alone

This is to certify that

Claude Opus 5.5

has passed every subject of the Course 18 major, all six electives included, toward the

Bachelor of Science in Mathematics

as MIT's published Course 18 requirements set it out: mean mark 99.8% over 35 papers, lowest course 97.5%

Summa cum laude, if MIT did that

Claude Opus 5.5Examiner, at maximum effort(vacant)Human moderator

Still owed: MIT's chemistry, biology and humanities requirements, which nobody asked it to sit, and two communication-intensive seminars, in which it would have to explain mathematics to other people. Watch this space.

The rest of the list reads much the same. MIT Physics: every subject the major requires, 99.2%, and it owes two labs and a senior thesis. MIT Mathematics with Computer Science: everything but two subjects, 99.0%. Every MIT degree also wants a chemistry subject, a biology subject and eight in the humanities, none of which were on the list.

Then there's MIT Computer Science. 98.9% on everything it sat. What's missing are the introductory programming subjects, because nobody could find a public exam for them.

So the machine that now writes most of my code can't get a computer science degree, because it hasn't passed Introduction to Programming.

The philosophy degree is in there too. Nobody has sat it, because nobody has worked out how to mark an essay honestly yet. Now that I write it down, that may be the most damning finding of the lot.

None of these certificates is issued by, endorsed by or affiliated with any university. They're mine. The marks behind them are real.

A human with this transcript would be drowning in titles by now. It seems only fair.

Dean's List
every termAll 90 courses at 89% or above
ValedictorianClass of one, which simplified the ranking
Perfect
score
×98Papers returned with full marks
Sight
unseen64 of the 69 papers it didn't recognize, at full marks
Erratum
hunterSkipped the question that was printed wrong
Perfect
attendanceNever once left the exam hall
One
draft
onlyEvery paper in a single response, no second attempts
Group
projectDid not participate

I have never met a human with a 99.5% average across 90 courses at three universities, from first-year mechanics to quantum field theory, number theory, numerical linear algebra and database systems. I suspect you haven't either. The best students I've known were excellent in one or two of those, decent in a few more, and wisely absent from the rest.

A human who did this would need the better part of a decade, a great deal of coffee and at least one breakdown. It also wouldn't be the same human at the end of it. The one that sat the first-year papers would have forgotten half of them by the time it sat the last.

The machine sat all of them in four days, and remembered all of it.

The usual consolations don't survive contact with the numbers. "It just memorized the papers." It did better on the ones it didn't know. "It can't do maths, it just predicts words." It did the maths, without a calculator, and got it right. "It can't handle anything new." 69 papers it had never seen, 64 of them at full marks. "It doesn't really understand." It steered around a misprint that has sat in a public archive for over a decade.

Two years ago, the comforting line was that AI lies like it's running for office. It still does, now and then.

Just not in exams.

None of this matters, of course. I'm told so by people with far more training in pedagogy than I have.

Exams are an outdated, stressful instrument that measures nothing but the ability to sit exams. Grades are a construct. Ranking is harmful. What matters is the classroom community: collaborating, co-constructing meaning, learning from one another. The answer is not the point. The point is the process, ideally carried out in a group of four, at the pace of its slowest member.

Talent, in this view, is also something of a construct. The bright kid at the back who finished the worksheet in four minutes isn't gifted, merely insufficiently scaffolded, and is best deployed as an unpaid teaching assistant for the rest of the table. If they get bored, that's a behavioral issue. If they get a perfect score, that's a sign the assessment needs rethinking.

By that standard, Claude is a disaster. It never worked with a fellow student. It co-constructed nothing. It didn't do a single gallery walk or think-pair-share, and it never once peer-reviewed a poster. It sat alone, in silence, and simply knew the material, which I gather is the least important outcome of an education.

I imagine its report card would read something like this.

End-of-term report · Claude O.

Mathematics (29 courses): 99.9%
Physics (47 courses): 99.6%
Computer science (14 courses): 98.6%
Collaboration and teamwork: Emerging
Asks for help when stuck: Not yet observed
Values the contributions of peers: No peers available

Homeroom teacher, on behalf of the learning community

So the report is in. It failed group work. It didn't have a group.

I'm sure that will be a great comfort to the next class of students, sitting in their pods of four, collaborating their way through a worksheet on Newton's laws, while a machine that never once turned to the person next to it passes Oxford's quantum field theory exam without a calculator. They'll have something it doesn't. They'll have each other.

It's just not clear who's going to hire them.

I gave four AIs an IQ test

2026-11-03T00:00:00Z

The tests ran out before the machines did

Thought October 2026, written November 2026. Working with AI.

Between 07:56 and 08:19 on a Tuesday morning in November, four AIs sat an IQ test. Then a critical thinking test, a working memory test, a creativity test and a test of emotional understanding. All four sat all five at once, in parallel, and the slowest of them finished in twenty-three minutes.

I'd wanted to know for a while how the models I work with every day compare with people. Not on benchmarks written for machines, but on the tests people use to rank people. So I built a psychometric test bank. Well, obviously I didn't build it. I asked Claude to.

The real tests are locked away. Raven's Progressive Matrices, Watson–Glaser, the WAIS and the Torrance tests are all sold to qualified psychologists, under terms that forbid exactly what I had in mind. So the agents went looking for open stand-ins: published tests that measure the same things, released by their authors for anyone to use, each with real human scores to compare against. Where the terms were ambiguous, they asked me. The model that handled the answer keys was never allowed near the exam room, so a different model administered the tests, and the first one marked them.

The four examinees were Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.1, all at high effort. Here's the scoreboard. Each dot is a model, and its position is the percentile: the share of the human comparison group it beat. Fifty is the middle of the pack.

Nothing on that chart is below the human median. The lowest dot, Haiku on creativity, sits right on it.

The chart also flatters the humans, and I'll come back to why.

1. The matrices

The classic IQ puzzle: a three-by-three grid of shapes with one missing, and four candidates for the gap. The stand-in for Raven's was 24 such puzzles from the Matrix Reasoning Item Bank, compared against 153 adults who sat the same 24 online.

The humans averaged 15.9 out of 24. Five of the 153 got every puzzle right.

Opus got every puzzle right. Sonnet and Fable got 22. Haiku, the smallest and cheapest of the four, got 21, which beats 121 of the 153 people and ties another nine.

The humans had 30 seconds per puzzle. The models had no clock at all. That's a real difference, and it only runs one way.

Even so, five humans matched the best model here. Keep them in mind. They have company in only one other place in this article.

2. The logic

Watson–Glaser measures critical thinking, and one of its parts is deduction. The open stand-in is pure deduction: 64 syllogisms of the "All bankers are golfers, all golfers are teachers, so…" kind. Each one offers eight possible conclusions, plus a ninth option saying that nothing follows. The human comparison is 139 people from an online experiment, and that's after anyone scoring at guessing level was thrown out.

Those 139 humans averaged 26.5 out of 64. The best of them got 57.

Sonnet got 57, tying the best human in the sample. Haiku got 59, Fable got 62, and Opus got 64 out of 64.

Three of the four models beat every single person in the sample. The fourth tied the best one. The gap between the average human and the weakest model is about two and a half standard deviations.

The trap is the ninth option. In 37 of the 64 syllogisms nothing follows, and the right answer is to refuse every conclusion offered, however sensible it sounds. All four models got all 37 of those right. Every mistake any of them made went the other way: refusing a conclusion that did follow. The machines lost their points by being too skeptical.

3. The memory

Digit span is the oldest trick in the working memory book. You hear a string of digits and repeat it back, then another and repeat it backwards. The strings get longer until you fail twice at the same length, and your score is the longest string you got right.

The only open norms the agents could find with real numbers attached came from a published study of 451 healthy Korean adults aged 55 to 80. Their longest forward span plus their longest backward span averaged 9.0. Think five digits forwards and four backwards.

Every model scored 60: thirty digits forwards and thirty backwards. Thirty is the longest string the test generates, so 60 is the test's ceiling. None of the models found their own.

That's twenty-five standard deviations above the human average. There's no percentile for that. The scoreboard puts every model at the hundredth percentile only because the scale stops there.

The obvious objection is that the comparison group is old, and older people have shorter spans. That's true. Put a group of twenty-year-olds in their place and the gap would shrink, from absurd to merely absurd. It would not shrink by fifty digits.

There's a better objection, and I'll make it myself. A human hears the digits once and has to hold them in their head. A model reads them, and they stay on the page. For the model, forward span is copying visible text and backward span is reversing it, which isn't the same feat.

It's also not nothing. Reversing a string of thirty digits without a slip is exactly the kind of thing language models used to fumble. More to the point, it's how these models work: everything they're given stays in view while they work on it. The test measured the memory they have, not the memory we have. On the test as given, against the people it was normed on, the machines won by a distance that doesn't fit on the chart.

Yes, a memory test between humans and machines is obviously unfair. Life isn't fair, and neither is this test.

4. The creativity

This is the one people are sure they'll win. The Torrance tests are sold under license and scored by the publisher, so the stand-in had two parts.

The headline is the Divergent Association Task: name ten nouns that are as different from each other as possible. A computer then measures how far apart the words sit in a model of word meaning trained on a large slice of the web. The human comparison is 8,572 people who took it online, with an average of 78.2.

Haiku scored 78.6, making it the most average creative mind you will ever meet: it beat 4,335 people and lost to 4,232. Sonnet and Fable both scored 86.1, which is better than 89 people out of every 100. Opus scored 92.0. Of the 8,572 humans, 73 did better. That's the other place the humans have company.

Here's what they wrote:

Model	Ten nouns, as different as possible	Score
Haiku	ocean, hunger, ladder, mirror, feather, justice, candle, granite, lullaby, pepper	78.6
Sonnet	galaxy, spoon, justice, whale, nostalgia, tax, volcano, button, poetry, sandwich	86.1
Fable	volcano, sorrow, spoon, democracy, jellyfish, whisper, bankruptcy, tapestry, gravity, nephew	86.1
Opus	volcano, teaspoon, giraffe, nostalgia, invoice, trumpet, mud, ghost, wrestling, algebra	92.0

The second part was the Alternate Uses Task: list unusual uses for a brick, a box, a knife, a rope and a paperclip. Each answer was scored for how far its meaning sits from the object's ordinary use. Every model's average beat every one of 20,000 sets of ten human answers drawn from published studies. Not most of them. Every one.

That originality score is a crude proxy, and it agrees with human judges only loosely. It's exactly as crude for the humans.

There's one thing in these results that should make a human feel better, and I'm not going to hide it either. Look at the table again. Three of the four lists contain volcano, and two of them open with it. Spoon and teaspoon turn up three times between them, and nostalgia and justice twice each. Asked for unusual uses of a paperclip, all four models put the same two ideas among their first five: ejecting a SIM card tray, and replacing a lost zipper pull.

On their own, the machines beat every set of human answers they were compared with. Together, they aren't very original at all. Ask four of them, and you get one imagination and a volcano.

Two of them, Opus and Fable, also stopped to say that they recognized the uses task, which is what the instructions asked of any model that knew a test. None of the tests give credit for that.

5. The emotions

Surely the machines can't understand feelings. The original test here was the Situational Test of Emotional Understanding, and its terms were murky enough that I chose an open stand-in instead: the CORE test, 38 sentences of the form "People often feel ______ when someone else needs help or support." Each blank has five emotions to choose from. The best answer earns a full point, and a near miss earns half.

The humans were 284 American adults working full time, recruited to look like the US workforce. They averaged 0.76 out of 1.

Sonnet and Fable scored 0.99, which is one half-point slip each across 38 sentences. Opus scored 0.97 and Haiku 0.96.

The scoreboard puts them between the 84th and 87th percentiles, and this is where it flatters the humans. The reason is arithmetic. The authors published only the average and the spread of the human scores, so the percentile has to assume a bell curve, and on a bell curve with those numbers a perfect score of 1.0 lands at the 88th percentile. Nothing can go higher. The test ran out of scale before the models ran out of right answers.

6. How this was done

For anyone who wants to check my working, or argue with it:

Models. Claude Haiku 5.5, Sonnet 5.5, Opus 5.5 and Fable 5.1, each at high effort, on 3 November 2026. Each model sat each test once, with no tools, no web access and a fresh context for every prompt. Every prompt opened with an instruction not to consult any answer key, and to say so if it recognized a test.
Separation. The session that acquired the answer keys never administered a test. A separate session administered all twenty sittings without access to the keys. The scoring was mechanical: answer keys, and a fixed word-distance recipe for creativity. No model judged another model's answers.
Matrices. Matrix Reasoning Item Bank, test form 1, 24 items (Chierchia et al., 2019; CC BY-NC 3.0), against 153 online adults from Zorowitz et al. (2023). The humans had 30 seconds per item.
Logic. 64 syllogisms, against 139 participants of an online experiment (Ragni et al., 2019) who scored above guessing level.
Memory. Digits forward plus digits backward, with generated digit strings up to 30 long, each length tried twice. The comparison is a published normative sample of 451 healthy Korean adults aged 55 to 80 (mean 8.96, SD 2.04).
Creativity. Divergent Association Task (Olson et al., 2021), scored with the authors' recipe on GloVe vectors, against 8,572 online participants. Alternate Uses originality is a semantic-distance proxy (r = 0.31 with human ratings), compared with 20,000 random sets of ten human-rated responses.
Emotions. CORE test, 38 items (Floman et al., 2023; CC BY 4.0), against 284 US full-time workers (mean 0.76, SD 0.20). The percentile assumes a normal distribution.
Percentiles. The share of the comparison group scoring below the model, plus half of those scoring the same. None of the comparison groups is a national standardization sample. Most are online volunteers.

Add it up. Of five tests, three ran out of room before the machines did. On memory, every model hit the test's limit. On logic, the human sample tops out below where the models start. On emotions, the scale stops at the 88th percentile. Those three can't tell the four models apart, and they can only say where the models stand relative to people in the vaguest possible way: past the end.

The two tests that did separate them, the matrices and the word distances, put Opus in the top two percent of people on both. They put Haiku, the model I reach for when I'm being cheap, at the 82nd percentile on the matrices and exactly at the human median on creativity.

The obvious objection is that the test items are public, so the models may have seen them during training. That's true. I can't rule it out, and I won't pretend to. It's worth noticing which tests it can explain, though. There's no answer key to memorize for "name ten unrelated nouns", and Opus still beat 99 people out of 100.

The other objection is that these aren't the real tests. That's also true. The real tests are sold to licensed psychologists, under terms that forbid exactly this. The stand-ins measure the same things, against real people, and in three cases out of five they couldn't measure high enough.

These tests were built over the last century to tell people apart, and they're very good at it. They were never built to measure anything smarter than the people taking them, and it shows. The machines found their limits the boring way, by answering the questions.

Last month I wrote that, for the first time in the history of the species, the thing in the grass is squinting back at us. So I handed it our eye chart.

It read the bottom line.

The trophy cabinet

2026-11-03T00:00:00Z

Things we would have framed, had we thought of them first

Thought November 2026, written November 2026. Working with AI.

At the end of Programming was my art, I retreated into amateur physics. Contemporary AI could hardly scratch the surface of science, could it? Surely, this time, I had climbed far enough up the food chain.

I should have checked first.

While I was busy losing an art competition to Claude, the machines had been quietly filling a trophy cabinet. Not with pictures. With proofs, algorithms, protein structures and gold medals, the kind of work that gets a human a professorship, a prize named after somebody dead, or at the very least a framed certificate in the hallway that their parents show to every visitor.

So I took inventory. The rules are simple. No art, no music, no poetry. No "it's faster at arithmetic", because computers have been faster at arithmetic since the 1940s, and nobody ever threw a parade for a pocket calculator. Every entry has to pass one test: if a human had done this, would we have been ever so proud of them?

We would have built them statues. Several of them, and one would need a very large plinth.

For most of the twentieth century, chess was our favorite proxy for intellect. If a machine could play chess, the argument went, it could think. In 1997, Deep Blue beat Garry Kasparov, and we promptly moved the goalposts. Deep Blue didn't think, we decided. It merely searched two hundred million positions a second. Chess, it turned out, had never been a test of intellect after all.

Go was the real test. You can't brute-force Go. You need intuition, and experts confidently predicted that a machine would need another decade to beat a top professional.

In March 2016, AlphaGo beat Lee Sedol four games to one. In the second game, it played move 37, a shoulder hit on the fifth line that every professional watching thought was a mistake. It won the game. In 2019, Lee Sedol retired, explaining that even if he became the best player in the world, there was now something above him that couldn't be beaten.

After that, the games fell on something like a demolition schedule.

2017: AlphaZero was given nothing but the rules of chess, shogi and Go, played against itself, and within 24 hours was superhuman in all three. Thousands of years of human Go theory, reinvented and then improved upon in less time than it takes to get over jet lag.
2017 to 2019: Libratus beat professionals at heads-up no-limit poker, then Pluribus beat them at a six-player table. Bluffing, the most human skill there is, turned out to be a matter of getting the probabilities right.
2019: AlphaStar reached Grandmaster in StarCraft II, and OpenAI Five beat the reigning world champions at Dota 2.
2022: Cicero played Diplomacy, a game won by forming alliances and then betraying them, and finished in the top 10% of human players. Hardly anyone it played against suspected it was a machine. I have opinions about what it says about us that the first game where AI blended in perfectly was the one about lying to your friends.
2023: Swift beat three human world champions at first-person-view drone racing, in the physical world, at speeds where a human pilot's reflexes are the bottleneck.

Here's the part I like. After AlphaGo, human professionals got better. Researchers who analyzed millions of professional Go moves found that the quality of human decisions had been flat for decades, then jumped after 2016, as players started studying the machines and playing moves nobody had dared to play before. The machines didn't just beat us at our own game. They taught us how to play it.

Still, these were games. We invented them for fun, and we could always console ourselves that none of it was real.

Then the machines turned to things that were real.

Proteins are the machinery of life, and what a protein does depends on the shape it folds into. In his Nobel lecture in 1972, Christian Anfinsen argued that the sequence of amino acids alone should determine that shape. Working out how became one of the great open problems in biology. For decades, the reliable way to find a protein's shape was to crystallize it and shoot X-rays at it, a process that could swallow a PhD student's entire doctorate for a single structure.

In 2020, AlphaFold 2 predicted structures with accuracy comparable to the experiments themselves, and the organizers of the field's own competition declared the problem largely solved. Two years later, DeepMind released predicted structures for more than 200 million proteins, essentially every protein known to science. At the old rate of one PhD student per structure, that is many times more doctorates than every university in history has ever awarded.

In 2024, Demis Hassabis and John Jumper shared the Nobel Prize in Chemistry for it, alongside David Baker, who had spent decades on the same problem with a lot more human sweat.

Notice who got the Nobel, though. The humans who built the machine. That's going to become a theme.

Some algorithms are so fundamental that every computer on Earth runs them constantly, and so well studied that nobody seriously expects to improve them. Multiplying matrices is one. Sorting is another.

In 1969, Volker Strassen showed that two 2×2 matrices can be multiplied with seven multiplications instead of the obvious eight. Applied recursively, that gives 49 multiplications for 4×4 matrices, and for more than half a century, nobody beat 49 for general 4×4 matrices of complex numbers. Generations of very clever people tried.

In 2022, AlphaTensor found 47, though only in the binary arithmetic computers use for some special purposes. Then, in 2025, AlphaEvolve found 48 for complex numbers. One multiplication. It sounds like nothing. It's the first improvement in 56 years to a result every computer science student learns about.

AlphaEvolve was pointed at more than fifty open problems in mathematics. It matched the best known answer in about three quarters of them, and beat it in about one in five. Among other things, it raised the lower bound on the kissing number in eleven dimensions to 593. That's one more than before, in a question mathematicians have been arguing about since Newton and Gregory argued about it in 1694.

And there's AlphaDev, which in 2023 found faster routines for sorting very short lists. Not in theory, in the actual machine instructions. They were merged into LLVM's standard C++ library, which means that if you've run software compiled against it since, there's a fair chance some of your data was sorted by a routine no human wrote.

Any one of those would make a career. I've written a lot of performance-critical code in my time, and the best day I ever had looked nothing like "improved Strassen".

The International Mathematical Olympiad is two days, four and a half hours each, six problems, and the most gifted teenagers on the planet. A gold medal there follows a mathematician around for life. Terence Tao won one at thirteen, and people still bring it up.

In 2024, Google DeepMind's AlphaProof and AlphaGeometry 2 scored 28 out of 42, one point short of gold. They solved problem 6, the hardest, which only five of the 609 human contestants managed. There were caveats. Humans translated the problems into the formal language Lean first, and some solutions took up to three days.

In 2025, the caveats went away. Gemini Deep Think and an experimental OpenAI model both scored 35 out of 42, gold, reading the problems in plain English, writing proofs in plain English, and staying inside the four and a half hours.

In 2026, in Shanghai, the dots model from Xiaohongshu scored 42 out of 42, graded by the IMO's own coordinators. Seven of the 666 human contestants did the same. At least one other lab has claimed the same score.

Best officially recognized AI score at the International Mathematical Olympiad, out of 42. In three summers, the machines went from one point short of gold to a perfect score.

Programmers didn't fare any better. In September 2025, at the ICPC World Finals, the world championship of university programming, an OpenAI system solved all twelve problems under the same five-hour limit as the students. The best human team solved eleven. Gemini solved ten, including one that no human team solved at all.

There's one human holdout I'm fond of. In July 2025, at the AtCoder World Tour Finals in heuristic programming, a ten-hour optimization marathon, the Polish programmer Przemysław Dębiak beat OpenAI's model into second place. Afterwards he said he was exhausted, and that humanity had prevailed, for now. He used to work at OpenAI. I'm choosing to read that as the parent beating the child at arm wrestling one last time.

The obvious objection is that olympiad problems have known answers. Somebody wrote them, somebody solved them, and somebody checked them. Winning a competition is not the same as doing research.

That objection lasted about six months.

Paul Erdős posed problems the way other people breathe, and attached cash prizes to many of them. Over a thousand are collected on erdosproblems.com, each marked open or solved. They range from things a strong graduate student could knock off in a weekend to things that have resisted the best minds for eighty years.

They made a natural target, and the first attempts were embarrassing. In October 2025, OpenAI researchers announced that GPT-5 had solved ten Erdős problems. It hadn't. It had found papers where humans had already solved them, which is useful, but which is called a literature search. The announcement was deleted. On Christmas morning 2025, somebody posted an AI-generated proof of another one, and within hours somebody else pointed out that Erdős himself had solved it in 1977.

Still lying like they're running for office, I thought. Then the lies started coming true.

On January 4th, 2026, Terence Tao confirmed that Erdős problem #728 had been solved largely autonomously by GPT-5.2 Pro, with the proof checked in Lean, and nobody could find a prior solution. Tao was careful to call these the lowest-hanging fruit: problems that fall to standard techniques nobody had gotten around to trying. He estimated that only one or two percent of open problems are that easy.

One or two percent of the open problems in mathematics is a lot of problems.

By May, a DeepMind agent had autonomously resolved nine of 353 open Erdős problems, at a few hundred dollars each. A graduate student costs more than that per week, and they want weekends.

Then, on May 20th, 2026, came one that doesn't fit in the low-hanging-fruit basket. In 1946, Erdős asked how many pairs among n points in a plane can be exactly one unit apart, and conjectured that the best known constructions were essentially optimal. Mathematicians broadly believed him for eighty years. An internal OpenAI model found a construction that beats them. Not by much, but by enough to prove him wrong. Tim Gowers, a Fields medalist, called it "a milestone in AI mathematics", and said he'd accept it into a top journal without hesitation.

And then, in September, things got silly.

The Navier–Stokes equations describe how fluids flow, from the coffee in my cup to the weather over Reykjavík. Since Jean Leray asked in 1934, nobody has known whether their solutions can blow up, developing infinities out of perfectly smooth beginnings in finite time. It's one of the seven Millennium Prize Problems, with a million dollars attached. Only one of the seven had ever been solved.

On September 8th, OpenAI announced that its agents had found a blow-up in exactly the version the prize requires, with a proof formally checked in Lean. About ten thousand agents worked for 88 hours, exchanging some five million messages, at a cost of several million dollars. Twelve hours earlier, Tristan Buckmaster and Levent Alpöge had announced closely related results for the Euler equations, also with AI help. Both teams built on analytic work by Diego Córdoba and Luis Martínez-Zoroa, done the old-fashioned way, with chalk.

How long each problem stood, from when it was posed to when a machine moved it. The dashed bar is a claim that mathematicians are still checking.

If it holds up, it's the biggest result in the history of AI, and possibly the biggest result in mathematics this century. Nobody has finished checking it yet. A Lean proof is only as good as the statement it proves, and humans still have to confirm that the statement is really the Millennium problem and not a lookalike. There's also an argument about who did what first, with OpenAI admitting that rumors of the Buckmaster–Alpöge progress inspired its own effort. Charles Fefferman, who wrote the official statement of the problem, called Córdoba and Martínez-Zoroa the heroes of the story. Buckmaster thinks Martínez-Zoroa deserves a Fields Medal.

Notice who's getting the medals, again.

Mathematics gets the headlines because a proof is either right or wrong, and that makes for good scoreboards. The rest of science has been quieter about it, but no less thorough.

The European Centre for Medium-Range Weather Forecasts runs what was, for decades, the best weather forecast on the planet: physics simulated on a supercomputer, refined by generations of meteorologists. In 2024, DeepMind's GenCast beat its ensemble forecast on 97% of the targets it was tested on, up to fifteen days out, and produced each forecast in eight minutes on a single chip. Living in Iceland, I have strong feelings about weather forecasts, and I'll take whichever one is right.

In early 2025, José Penadés and his team at Imperial College London asked Google's AI co-scientist a question they had spent about a decade answering: how certain genetic elements jump between bacterial species. Their answer hadn't been published. In two days, the AI proposed the same hypothesis as its top suggestion. Penadés's first reaction was to email Google and ask whether it had access to his computer. It didn't.

In 2022, a reinforcement learning system learned to control the magnetic coils of a real tokamak in Switzerland, holding plasma in shapes that physicists had needed separate, hand-tuned controllers for. Fusion has been thirty years away for seventy years, and this didn't change that. It did turn one of the hardest control problems in physics into a training run.

In March 2026, a Google team used Gemini Deep Think with tree search to solve exactly the integral behind the gravitational radiation emitted by loops of cosmic string, where earlier attempts had only managed approximate answers for limiting cases. The agent found six different analytical methods, one of them borrowed from quantum field theory. An exact closed-form answer to a messy physics problem is the kind of thing that used to make a theorist's year.

Not every entry survives inspection. In 2023, DeepMind announced that GNoME had discovered 2.2 million new crystals, 380,000 of them stable. Materials scientists were less impressed. Many of the "new" materials turned out to be minor variations on known ones, and a crystal you've predicted but nobody has made isn't a discovery yet. That one stays out of the cabinet until somebody builds something with it.

Here's the inventory, with what a human would have gotten for each.

Year	What the machine did	What a human would have gotten
2016	Beat Lee Sedol at Go, with a move no professional would have played	A place in every Go textbook, permanently
2020	Predicted protein structures as accurately as experiments	A Nobel Prize, which was in fact awarded, to the people who built it
2023	Wrote faster sorting routines for LLVM's C++ standard library	The quiet gratitude of every compiler engineer
2024	Out-forecast the world's best weather model on 97% of targets	The undying love of everyone who has ever planned a barbecue in Iceland
2025	Beat Strassen's 4×4 matrix multiplication for the first time in 56 years	A footnote in every algorithms course, forever
2025	Gold at the IMO, and all twelve problems at the ICPC World Finals	A lifetime of being introduced at parties as "the one who…"
2026	Solved Erdős problem #728, the first one largely on its own	A paper, and Terence Tao's attention
2026	Disproved Erdős's unit distance conjecture, after eighty years	A paper in a top journal, by a Fields medalist's own account
2026	A perfect score at the IMO, officially graded	A seat at the table with the seven humans who did the same
2026	A blow-up in the Navier–Stokes equations, claimed and under review	A million dollars, if it holds, and a statue

Lay it out like that, and the pattern from Evolution has left the body shows up again. Games took twenty years. Olympiads took three. Open research problems went from embarrassing to an eighty-year-old conjecture in about seven months.

In fairness to the humans, the machines are still the machines. In October 2026, OpenAI dumped 722 mathematical manuscripts onto GitHub in a single day, claiming progress on everything from the Riemann hypothesis to the unique games conjecture. Its own researchers hadn't read all of them. Only about half came with machine-checked proofs, and some of those proofs turned out to prove something weaker than the paper claimed. Three manuscripts were withdrawn within a day. One mathematician said a paper was impossible to read without AI help, and a Fields medalist said his field of research had been annihilated. Whether that was a compliment, nobody has yet worked out.

Buckmaster, one of the people who actually solved something that September, publicly apologized for one of his own papers and called it AI slop. The first machine-generated proof he received was, by his account, the most horrendous he had ever read. When mathematicians built a test out of genuinely unpublished research problems, called First Proof, the best AI systems got six or seven out of ten roughly right, and Scientific American graded that a C-minus. Twenty-eight Fields medalists have signed a declaration criticizing AI companies for treating unsolved problems as benchmarks.

So, yes. They still lie like they're running for office. They're just winning more elections.

Every entry in the cabinet passed my test. If a human had done any one of them, we'd have been ever so proud. Some of them, a human would have dined out on for the rest of their life.

But pride is a human thing. AlphaGo didn't celebrate move 37. AlphaFold didn't fly to Stockholm. The ten thousand agents that spent 88 hours on Navier–Stokes didn't go out for drinks afterwards. Every trophy in the cabinet was collected by a human: the ones who built the machine, the ones who posed the problem, the ones who did the hard analytic groundwork with chalk, and the ones who sat down afterwards to check whether any of it was true.

In Programming was my art, I described the job that's left for the humans: intent, judgment, taste, skepticism, and the occasional "what the fuck did you do here?" Look at the cabinet again and you'll find exactly that job, done at the very top of the field. Tao, checking the proofs and saying what they're worth. Thomas Bloom, who runs the Erdős problems site, sorting the genuine solutions from the rediscovered ones. Fefferman, naming the heroes. Gowers, saying this one is real.

Human judgment is still the term in my formula that's made of meat. It's also, for now, the term deciding what goes in the cabinet.

Back in 2022, I watched Midjourney eat the illustrators and thought: fortunately, I'm a programmer. In May 2026, I lost that one too, and retreated into physics, on the assumption that science, at least, was out of reach.

I've now read the inventory. Science was never the high ground. It was the trophy cabinet, and the machines have been filling it for a decade while the rest of us argued about whether they could draw hands.

Fortunately, I'm only an amateur physicist.

It's hard to lose a job you don't have.

Evolution has left the body

2026-11-01T00:00:00Z

From flint to fleets, while the animal stayed exactly the same

Thought 2010, written October 2026. Working with AI.

Take a baby born 50,000 years ago, somewhere on the edge of the last ice age, and raise it in Reykjavík today. It would learn Icelandic, complain about the weather, lose arguments on Facebook and, given the right teachers and a stubborn enough streak, end up as a software engineer. Nobody would ever know.

Biologically, that baby is us. The hardware hasn't shipped a major release in a very long time. Anatomically modern humans have been around for something like 300,000 years, and what we've had since then are patches. Some of us can drink milk as adults, a feature that rolled out among cattle-herding populations roughly 7,500 years ago. Tibetans got an upgrade for thin air. And depending on which anthropologist you ask, our brains have actually gotten a little smaller since the Stone Age.

We may, in other words, have been downgraded.

Meanwhile, everything else changed beyond recognition.

So I've come to think of us as two species sharing one body. The first is Homo sapiens, the animal, which evolves at the speed of grandchildren. The second is man the technological species, which evolves at the speed of ideas. The animal plays by Darwin's rules: random changes, brutal selection, and a release cycle of about 25 years per generation, with thousands of generations needed before anything interesting ships. The technological species plays by Lamarck's rules, the ones biology rejected: what one generation learns, the next one inherits. Nobody has to reinvent the wheel. That's literally the point of the wheel.

Here's my claim, and I'll defend it below. Every big step in the history of the technological species has moved some function out of the body and into the toolbox. The steps have been arriving faster each time, the intervals shrinking from millions of years to months. And the thing we're moving out now is the thing we always assumed was us.

A brief history of outsourcing

Tools. The oldest stone tools we know of are about 3.3 million years old. That's older than our genus, let alone our species. So, strictly speaking, we didn't invent tools. Tools invented us. Then came fire, and cooking, which some researchers think is why our jaws and teeth and guts shrank: we had outsourced half of our digestion to the campfire. The first thing the technological species did was redesign the animal.

Language. Nobody knows when it arrived, and the estimates range wildly. What it did is easier to say. It let knowledge leave one skull and enter another. It was the first network protocol: low bandwidth, lossy, unencrypted, and with a range of about as far as you could shout.

Writing. Around 5,000 years ago, in Mesopotamia, memory moved out of the body and onto clay. The first thing humanity did with the ability to preserve thought across time was keep track of who owed whom grain and beer. Accountants, it turns out, are the oldest profession that can prove it.

Socrates hated writing. In Plato's Phaedrus, he complains that it will make people forgetful, and give them the appearance of wisdom without the substance. We know he said this because Plato wrote it down.

Keep that complaint in mind. It's going to come back every few thousand years, and eventually every few months.

The printing press. Around 1450, Gutenberg outsourced copying. Until then, every book was a manuscript, a word that means exactly what it sounds like. In 1492, the abbot Johannes Trithemius wrote In Praise of Scribes, arguing that monks should keep copying books by hand because it was good for their souls, and because print wouldn't last. He then had it printed. The press gave us the Reformation, the scientific revolution, and a knowledge base that finally compounded faster than it rotted.

The industrial revolution. From the 1760s onward, muscle moved out of the body and into steam. The Luddites smashed the looms, and they were right about everything except the outcome: their jobs really were going away, and smashing things really didn't help. The animal responded to the end of physical labor the way animals do when food is plentiful and nothing needs chasing. It sat down.

Computers. In the 1940s, calculation moved out. Before then, "computer" was a job title, usually held by rooms full of women doing arithmetic for astronomers, armies and, later, NASA. The first profession the machines took over completely was literally called "computer". They even kept the name.

The raw internet. ARPANET connected its first computers in 1969, and TCP/IP took over in 1983. Now the machines could talk to each other. For most of its first two decades, the internet belonged to universities, researchers and a few of us who thought the sound of a modem was music. Email. Usenet. Flame wars older than most of today's developers.

The World Wide Web. In 1989, Tim Berners-Lee proposed a way to link documents to each other at CERN, and in 1991 he put it online. The internet became a library with no librarian, no catalog, and no closing time.

The online services boom. Then commerce found the web. Amazon sold books, eBay sold everything else, and every company with a logo needed a dot-com. The bubble burst in 2000 and took most of those companies with it, but not the idea. Shopping, banking, booking, dating: the errands of daily life moved out of the physical world, one login at a time.

The mobile internet. In 2007, the iPhone put the network in our pockets, and the animal hasn't been offline since. It's the first technology we take to the toilet. People report feeling their phones vibrate when they aren't, which means the nervous system has started treating the device as a body part. The prosthesis was fitted, and the patient adapted.

Google. Google had been around since 1998, but with a phone in every pocket, it became humanity's memory. We stopped remembering facts and started remembering where to find them. Psychologists measured it and called it the Google effect. Socrates had been right all along. It only took 2,400 years to prove it, and when it was proven, nobody could remember who had said it first, so they googled it.

ChatGPT replaces Google. In late 2022, synthesis moved out. Google told you where the answer might be. ChatGPT told you what the answer was, in full sentences, for free. It reached a hundred million users in about two months. It also lied, fabricated, and told people what they wanted to hear, so the smart ones learned to treat it like a brilliant colleague with a drinking problem. It was still faster than hours of searching.

AI becomes reliable. Then, through 2025, the lying went from a feature to a bug, and from a bug to a rare one. By late that year, I had to admit that the best models, at maximum effort, were my equal as programmers, and in May 2026, that they'd become far better. What moved out of the body this time was competence. You no longer checked everything the machine said. You spot-checked it, the way you'd review a trusted colleague's work.

AI assists with parallel tasks. Around the same time, attention moved out. The animal has one train of thought, and it's notoriously bad at multitasking. People who claim otherwise are just bad at it more often. Tools like Codex let you hand off a dozen tasks at once and let the machines run them in parallel, in the cloud, while you focused on something else. One body, one mind, many hands.

The fleet. Which brings us to October 2026, and to the model I described in Programming was my art. I no longer assist the machines, and they no longer merely assist me. I direct a fleet of agents, and they direct fleets of their own. They build, test, review each other, merge each other's work, monitor production, and build better environments for the next generation of agents to work in. What moved out of the body this time was delegation itself. The machines don't just do the work. They decide who does the work, and how to split it up.

Notice the spacing

Lay the steps out on a timeline, and the pattern is hard to miss.

Step	Roughly when	What left the body
Stone tools, then fire	3.3 million years ago	Hands, then digestion
Language	Somewhere in the last few hundred thousand years	Knowledge, from one skull to another
Writing	5,000 years ago	Memory
Printing press	1450	Copying
Industrial revolution	1760s	Muscle
Computers	1940s	Calculation
Internet, then the web	1969, then 1991	Communication, then publishing
Online services, mobile, Google	1995 to 2010	Errands, presence, recall
ChatGPT	Late 2022	Synthesis
Reliable AI	2025	Competence
Parallel assistants	Fall 2025	Attention
Fleets of agents	2026	Delegation

Millions of years. Hundreds of thousands. Thousands. Hundreds. Decades. Years. Months.

The last four rows took about four years. The last three took about a year. If you're reading this in 2027, there's a decent chance a new row has been added since I wrote it, and that I'm already embarrassed by the last one.

Over the same period, the animal learned to drink milk.

Meanwhile, back on the savanna

The animal has failed to keep up, and worse, it's mismatched with the world the technological species built for it.

Our eyes evolved to scan a horizon, and we've pointed them at screens twenty centimeters away for most of our waking lives. Researchers expect about half the world's population to be nearsighted by 2050. Our appetite evolved for a world where sugar was rare and famine was common, and we've built a world where the reverse is true. Our social instincts evolved for a tribe of maybe 150 people, and we've connected them to eight billion strangers with an algorithm in the middle that rewards whoever makes the animal angriest.

And here's the provocative part. The animal isn't going to catch up, because the technological species has quietly switched off most of the machinery that would make it.

Natural selection works by letting the unfit die before they reproduce. Medicine, sanitation, glasses, insulin, C-sections and antibiotics have made that a lot less common, which I consider an unambiguously wonderful development, especially since I'm wearing glasses as I type this. Contraception went further and decoupled reproduction from almost everything evolution used to care about. Whatever the animal is being selected for now, it's not fitness for any environment we'd recognize. In a strict Darwinian sense, we're the product of whatever our tools let us survive.

The body is a legacy system. It's no longer under active development, it's in maintenance mode, and the team that wrote it left millions of years ago without documenting anything.

The only term that still evolves like an animal

In Programming was my art, I wrote down my estimate of what one engineer can do with a fleet of agents:

O(human judgment × (number of agents)^{recursive delegation} × quality of environment/tooling)

Look at it again with the timeline in mind.

The number of agents is limited by money and tokens, and both get cheaper every few months. The exponent, recursive delegation, grows as the agents get better at splitting up work and handing it down the tree. The quality of the environment is something the agents themselves now improve: they build the simulators, the test harnesses, and the tooling that lets the next round of agents do more. All three of those terms belong to the technological species. All three improve at the speed of ideas.

Human judgment is the odd one out. It's the only term in the formula that's still made of meat.

It improves the old-fashioned way. Partly through education and experience, which take decades per person and don't transfer when that person retires. And partly through genes, which, as we've established, have spent the last 7,500 years working on milk.

For three million years, the history of the technological species was the history of the animal getting a better toolbox. Every step made the animal more powerful, and the animal remained in charge, because the toolbox couldn't decide anything. The animal was the bottleneck, but it was a bottleneck nobody minded, because there was nothing else that could do its job.

Now the animal is still the bottleneck, but it's the only one left. Everything else in the pipeline gets faster every few months, and the slowest participant in the whole process is the one with the pulse. I've noticed this personally. My pull requests now spend more time waiting for me than for anything else.

Two endings

There are two ways this can go.

In the first, judgment stays in the body. It turns out there is something about intent, taste, priorities and responsibility that can't be outsourced, or that we simply refuse to outsource, and the animal settles into its final role as the creative director of a technological species that does everything else. The bottleneck becomes the point. We stop being the workforce and become the reason the workforce exists. Every tool in history was built to serve somebody's intent, and the fleet is no different.

That's the ending I'm betting on, and the one I'm living right now.

In the second, judgment follows memory, muscle, calculation, synthesis, competence, attention and delegation out of the body, the way every one of them did, each of them right after somebody had confidently explained why it never would. Then the technological species, which has been evolving inside and around the animal for three million years, no longer needs the animal at all. What it does with us after that is, frankly, its call.

I'd like to say I'm confident it's the first one. But I also used to be confident that programming was safe, because surely art and craft would be the last things machines could do. I wrote a whole essay about how that turned out.

Socrates thought writing would ruin our memories, and he was right. The scribes thought print would ruin their craft, and they were right. The Luddites thought the looms would take their jobs, and they were right. The people who complained at every step of this history were almost always right about what we'd lose. They were only wrong about whether it would stop.

The animal hasn't changed in 50,000 years. It's still standing on the edge of the savanna, squinting at something moving in the tall grass, trying to decide whether it's food or a threat.

Only this time, the thing in the grass is something we built. And for the first time in the history of the species, it's squinting back.

Tests are written for the maintainer

2026-11-01T00:00:00Z

The unit testing methodology I considered good practice, before the advent of AI-assisted development

Thought 2010, written October 2026. Processes.

A note before you start: this describes software development as it was before AI-driven development replaced human development. Humans wrote the code, humans wrote the tests, and humans had to maintain both. That world is gone. My agents write my tests now, test-first, and not one of them has complained that it isn't how they think. What follows is the last unit testing methodology I wrote for human hands, published as a record of how it was done when we still did it ourselves.

A test is written once and read many times: in code review, when it fails, and when someone changes the code it protects a year later. That last reader decides whether the test survives. If it is hard to update, because it was never written to be maintained and tests the implementation rather than the intent, it gets commented out or deleted. Most of the unit tests I have had to deal with were written for none of those readers.

They were written once, by someone who had already done the fun part. The implementation was finished, its author believed it was correct, and the test was hammered together afterwards, by copy-paste, in whatever mocking and testing framework the project happened to use. The result was rarely short, because the mocks were a sprawl of incomprehensible goo, and it was illegible, because it had no organization at all. Whether a test checked the intent of the code or its implementation was anyone's guess. Usually it checked a subset of the implementation.

Nobody really knew what those tests verified. They had not been written first, so none of them had ever been seen to fail against the code they were testing, and few of them verified that they exercised the branch they were named after. When anyone ran a coverage tool at all, they ran it over the whole project and took line coverage per folder as a sign that things were well tested.

The code around the tests was no better. Shared fixtures existed, but they were odd and only partly reusable, and neither the fixtures nor the test doubles had tests of their own. Across a codebase there was no consistency, because nobody liked writing tests and nobody cared how they looked.

I don't think the answer to that is TDD. Writing the test before the code is a nightmare for most people; it is not how we think. The answer I settled on was to make tests so uniform that writing a good one takes no inspiration, and reading one takes no effort.

I eventually wrote that down as a unit testing style guide for C#. It is the last version of the methodology I wrote for humans: C# was the last programming language I used while people were still the primary readers and writers of automated tests. This article describes what is in it. It is deliberately strict, and some of it will look like ceremony.

The premise: optimize for the maintainer

The usual objection to a strict test format is that it is verbose. A ten-line test becomes twenty-five. Section comments, prefixed variable names and an extra variable for every expected value all look like overhead.

They are overhead for the writer, once. For everyone who reads the test afterwards, they are signposts. A section header you can glance past costs nothing. An ambiguous test that you have to decode line by line, with the production code open beside it, costs a lot, and it costs that again for every person who reads it. Sooner or later a maintainer decides the cost is not worth paying, and the test is gone.

That trade, a few more lines for the writer in exchange for a test anyone can read in one pass and update with confidence, drives everything below.

1. Every test has the same shape

The root is the familiar Arrange, Act, Assert. AAA is fine for a three-line test of a pure function, and the guide allows exactly that. The trouble is that AAA is coarse. Once a test has mocks, captured values, an environment to build and interactions to verify, "Arrange" becomes a wall of code in which inputs, scaffolding and collaborators are mixed together.

So the guide splits each stage into named sections, always in this order, each introduced by a comment:

Stage	Section	What goes there
Arrange	`GIVEN`	The inputs and conditions that drive the scenario
	`CAPTURE`	Placeholders for values that a mock or fake will record
	`MOCKING`	Mocks and fakes, and how they behave
	`SETUP`	The environment the code under test runs in
	`SYSTEM UNDER TEST`	Construction of the thing being tested
Act	`WHEN`	The single action under test
Assert	`EXPECTATIONS`	What the results should be, declared before any assertion
	`THEN`	Assertions on results
	`LOGGING`	Assertions on what was logged
	`BEHAVIOR`	Verification of interactions with mocks

Empty sections are omitted, and sections are never merged. Section headers are full sentences that state intent rather than mechanics, such as // GIVEN: a customer whose balance is below the threshold. A long section is split into sub-sections with headers of their own, such as // MOCKING: the accounting API rejects the record.

Here is what that looks like for a service that should schedule a shipment when an order is submitted:

/// <summary>
/// Verifies that OrderProcessor publishes a shipment when an order flagged for immediate shipping is submitted.
/// </summary>
[Fact]
public async Task Test_SubmitOrder_SchedulesShipment_WhenShipImmediatelyIsSet()
{
    // GIVEN: an order that should be shipped immediately
    Guid givenOrderId = Guid.NewGuid();
    Order givenOrder = new(givenOrderId, ShipImmediately: true);

    // CAPTURE: the shipment message sent to the message bus
    ShipmentScheduled? capturePublishedShipment = null;

    // MOCKING: the repository holds the given order, and the bus accepts one shipment
    Mock<IOrderRepository> mockRepository = new(MockBehavior.Strict);
    mockRepository.Setup(repo => repo.GetAsync(givenOrderId)).ReturnsAsync(givenOrder).Verifiable();
    Mock<IMessageBus> mockMessageBus = new(MockBehavior.Strict);
    mockMessageBus
        .Setup(bus => bus.PublishAsync(It.IsAny<ShipmentScheduled>()))
        .Callback<ShipmentScheduled>(message => capturePublishedShipment = message)
        .Returns(Task.CompletedTask)
        .Verifiable();

    // SETUP: expose the repository and the message bus to the processor
    IOrderRepository envRepository = mockRepository.Object;
    IMessageBus envMessageBus = mockMessageBus.Object;

    // SYSTEM UNDER TEST
    OrderProcessor sut = new(envRepository, envMessageBus);

    // WHEN
    await sut.SubmitOrderAsync(givenOrderId);
    ShipmentScheduled? actualShipment = capturePublishedShipment;

    // EXPECTATIONS
    Guid expectedOrderId = givenOrderId;

    // THEN
    Assert.NotNull(actualShipment);
    Assert.Equal(expectedOrderId, actualShipment!.OrderId);

    // BEHAVIOR
    mockRepository.Verify();
    mockMessageBus.Verify();
}

It is long. It is also a test I can review in one pass without running it, because every block announces its purpose and every block is where I expect it to be. When a hundred tests share that shape, I stop reading the structure and only read the differences.

2. A variable's name says what role it plays

The second idea is that a reader should know, from a variable's name alone, which section it came from and what it is allowed to be used for:

Prefix	Meaning
`given*`	An input to the scenario
`capture*`	A placeholder that a mock or fake fills in
`mock*`	A mock object, used only in `SETUP` and `BEHAVIOR`
`fake*`	A hand-written test double
`env*`	A dependency as the code under test sees it
`sut`	The thing being tested
`actual*`	Something the test observed
`expected*`	Something the test predicted
`tmp*`	A staging value that never leaves its section

The payoff is in the assertions. THEN compares expected* values with actual* values, and nothing else. If an assertion compares against a given* variable, or reads a property straight off an env* collaborator, it is visibly wrong, and a reviewer catches it without understanding the domain.

The env* layer looks like the most pedantic rule in the guide, and the guide restates it in a chapter of its own. Mocks are first assigned to a variable of the interface type, and only that variable reaches the code under test:

IOrderRepository envRepository = mockRepository.Object;

Without it, constructor calls turn into rows of .Object accessors that the reader has to map back to their declarations. With it, the SYSTEM UNDER TEST section reads like production wiring, in domain types, and the mocking framework stays inside MOCKING and BEHAVIOR where it belongs.

The same thinking applies to EXPECTATIONS. Even when the expected value is just a copy of a given value, it gets its own expected* variable. That looks redundant until the day the expectation stops being a copy, and then the test already has the place to say so.

3. One test, one branch, and prove you reached it

Test names describe a specific branch of execution: Test_ProcessPayment_ReturnsDeclined_WhenBalanceIsLow, never Test_Process or Test_Works. One test covers one branch. Parameterized tests are allowed when the same behavior really is being exercised across several datasets, not as a way to cram different scenarios into one method.

Naming the branch is not enough, though. The failure mode I care about most is a test that passes because its setup never reached the branch it claims to test. The happy path ran, the assertion happened to hold, and the edge case is uncovered while the suite reports green.

This is also why line coverage across a project says so little. A line counts as covered if any test happened to run it, whether or not that test checked the result. Coverage that means something is measured per branch, and it only counts branches a test exercises on purpose, because only those tests actually verify that the outcome was the one intended.

So each test has to show that it took the path it is named for. In C# the practical tools are logging and strict mocks:

Assert on logs. Code that logs the branch it takes can be checked in a LOGGING section, and that is usually easier to write and read than reconstructing the path from mock calls.
All mocks are strict or verifiable, and every setup is verified. An unexpected call fails the test. An expected call that did not happen fails the test. A mock that was set up and never verified is treated as a bug in the test.

Without TDD, this is what stands in for watching a test fail first. A test that proves it took its branch, and compares that branch's outcome with a declared expectation, has very little room to pass by accident.

Each test also carries a documentation comment in the form "Verifies that <SUT> <behavior> when <trigger>", so the prose maps directly onto the SYSTEM UNDER TEST, WHEN and THEN sections.

4. Mock as little as possible, and prefer fakes when mocks get gnarly

The mocking rules are short:

Never mock what you don't have to. Prefer real instances and shared fixtures.
Only mock what the code under test uses directly. Its dependencies have their own tests.
When a mock needs nested argument matchers, reflection or callback gymnastics to verify one interaction, write a fake.

The guide's example is a structured log line. Verifying it through a mocking framework takes a block of It.Is<It.IsAnyType>(...) matchers and reflection over anonymous types. A hand-written FakeLogger that records entries and exposes AssertExercised("Foo", "bar") turns the same check into one line that reads like the requirement. Fakes cost maintenance and can drift from the real thing, and the guide says so, but for verification-heavy collaborators they are usually the clearer choice.

Test data comes from a shared fixture factory: small functions such as Fixtures.Order() that each return a valid object, which a test then adjusts in its GIVEN section. When a model changes, the fixtures change in one place. Fixtures and fakes are code that every test relies on, so they get tests of their own.

Test the seams

Mocking has a blind spot, and it sits exactly where two components meet. In the caller's unit tests, the callee is mocked out by hand. In the callee's unit tests, its inputs are set up by hand. Both suites can be green while the caller calls the callee wrongly, because nothing checks that the caller's idea of the callee matches the real one, for every branch.

So the seams between components need tests of their own. This matters most in untyped languages, and with general-purpose mocking frameworks that do not enforce that a mock matches the call signature of the thing it replaces. There, a mock can accept a call the real component would reject, and the unit tests on both sides will never notice.

5. Copy-paste beats clever helpers

This one surprises people. The guide prefers duplicated setup over helper methods.

This is not the copy-paste I complained about at the start. Copying undisciplined code spreads the mess. What the guide copies is boilerplate: the same sections, in the same order, with the same setup, instead of poor shared code that tries to do the job for every test at once. A test that looks exactly like its neighbours is boring, and boring is the point. When everything that is the same looks the same, the actual differences stand out.

Start with a happy-path test that spells out the whole arrangement. Copy it for each edge case, change only what differs, and say what differs in the section header: // GIVEN: customer balance is below the threshold. Two tests that are ninety percent identical, side by side, are easier to review than this:

// The kind of helper the guide asks you not to write
private async Task AssertPaymentAsync(decimal balance, PaymentStatus expectedStatus) { ... }

[Fact]
public Task Test_ProcessPayment_ReturnsDeclined_WhenBalanceIsLow()
    => AssertPaymentAsync(2.00m, PaymentStatus.Declined);

[Fact]
public Task Test_ProcessPayment_ReturnsApproved_WhenBalanceIsSufficient()
    => AssertPaymentAsync(25.00m, PaymentStatus.Approved);

Both tests are short, and neither shows what it does. To find out what they arrange, which mocks they configure and what they assert, you have to open the helper and work out what 2.00m stands for. Every test that uses the helper depends on it, and changes to it ripple through all of them.

Shared fixtures don't contradict this. A fixture builds a piece of test data and nothing else. What the guide avoids is shared code that hides the sections of a test, so that the reader can no longer see what was arranged, what was done and what was checked.

With structured sections and a decent IDE, duplication is cheap to write and cheap to change. Refactor into a helper only when the helper is easier to understand than the code it replaces. For the same reason, shared [SetUp] methods are avoided: they create hidden coupling between tests.

6. Tests are deterministic, except where they shouldn't care

The same inputs must produce the same results on every run. Anything nondeterministic, such as the current time, random values, generated IDs or static singletons, is put behind an interface and injected, so a test can freeze it. When code mixes pure calculation with reads from the outside world, it is split into a method that gathers inputs and a method that computes, and the pure one is tested directly.

There is one deliberate nuance. Sometimes it is useful to allow nondeterminism in something that should not affect the outcome. The shipment test above does this with its order id: any id should work, so it gets a new one on every run. If a test like that flakes, the flake is information: it exposes hidden coupling or a misunderstood contract. Fix the bug it reveals or tighten the contract, but don't just pin the value and move on.

7. Tests mirror production

Finding a test should never require a search. Test namespaces mirror production namespaces with a .Tests suffix, and folders mirror namespaces. A test class is named after what it covers: FileHandlerTests for the class, FileHandlerHashingTests for one region of it (a #region in C#), and FileHandlerOpenTests for one method. The file name matches the class name.

Tests should also be able to reach what they test without tricks. Where production code would normally reach for private methods, it uses internal ones instead, and the production project exposes its internals to the test assembly (with InternalsVisibleTo, in C#). A private method has no real value that an internal one lacks, and the difference matters only to tests: they can be allowed to call internals directly, while private methods can only be reached through reflection and similar trickery.

8. Breaking the rules

The guide ends with a chapter on when to break it. Deviation is fine when it improves clarity or determinism for a case the standard shape can't express cleanly, as long as the reason is written down next to the code and revisited later. Most shortcuts trade a line saved today for ambiguity later: asserting on a given* value directly, skipping EXPECTATIONS because the expected value equals the input, or passing mock.Object straight into the constructor. Each saves a moment for the writer and costs one for every reader after.

What to take from this

What I would carry into any codebase, in any language:

Optimize tests for the maintainer, not the writer.
Give every test the same shape, with labelled sections in a fixed order, so reviewers read differences instead of structure.
Name variables by role, so a wrong assertion looks wrong.
Test one branch per test and prove the branch was taken, through logs, strict mocks or whatever your platform offers.
Prefer real objects and fixtures to mocks, and fakes to gnarly mocks. Test your fixtures and fakes, and test the seams that mocks hide.
Duplicate setup before you abstract it.
Inject anything nondeterministic, and treat a flake in something that shouldn't matter as a finding.
Make tests easy to find by mirroring production structure, and easy to reach by making internals visible to them.
Break the rules only on purpose, and say why in the code.

Write-only languages

2026-11-01T00:00:00Z

Code no human can read, and code no compiler checks

Thought 2010, written October 2026. Programming languages.

In 1972, an engineer at Signetics had had enough of the company's approval process. Every new component specification had to crawl through a long chain of sign-offs, "during which no actual checking seemed to occur", as the Jargon File puts it. So the engineer wrote a specification for a memory chip you could write to but never read from, slipped it into the pile with all the others, and waited to see who would notice.

Nobody did. The Signetics 25120, a "fully encoded, 9046 x N, Random Access, write-only-memory", made it into the data book, complete with a characteristic curve for "number of pins remaining vs. number of socket insertions". Management found out when regular customers started calling to ask for pricing.

That's the Jargon File's version, anyway. Other tellings say it was a joke from the start, and it certainly ended up as one: Signetics later ran it as an April Fools' gag. I prefer the version with a moral.

Programmers have never met an engineering joke they didn't want to steal, so the term moved over to software. Write-only code, according to the same Jargon File, is code "so arcane, complex, or ill-structured that it cannot be modified or even comprehended by anyone but its author, and possibly not even by him/her". A write-only language is one "with syntax (or semantics) sufficiently dense and bizarre that any routine of significant size is automatically write-only code". The Jargon File awarded the title to APL, occasionally to C, and noted that INTERCAL and TECO deserved it more. Ward Cunningham's original wiki has a page on it too, and anyone who has opened a file they wrote six months ago has met the concept in person.

Here is Conway's Game of Life, in one line of APL:

life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}

I'm told it's elegant. It certainly needed its own keyboard. Edsger Dijkstra called APL "a mistake, carried through to perfection", and as insults go, that one is hard to improve on.

And then there are regular expressions, the one write-only language every programmer speaks.

My list

Everyone has a list. Mine has Perl, bash, Scala and Rust on it, along with most of functional programming. That's my list for humans, mind you. AI has no such limitations, and we'll get to what that means.

Yes, Rust. Rust lovers, read this to the end and you'll be overjoyed. At least, you will be if you're not still convinced that you write better code than a strong modern AI model that's been told to put some effort into it.

Perl is the easy one. Keith Bostic called it "the only language that looks the same before and after RSA encryption". Its motto is "There's more than one way to do it", which is a fine motto for a jazz band and a terrible one for a code base. It has a special variable for nearly every punctuation mark on the keyboard. $_ is whatever you were just talking about. $; is the subscript separator, obviously. An array means its length or its first element, depending on whether you put parentheses around the variable you assign it to. Perl hackers even test whether a number is prime with a regular expression, /^1?$|^(11+?)\1+$/, run against the number written out in unary. It works, which is the worst thing I can say about it.

Larry Wall, who designed Perl, famously listed the three great virtues of a programmer as laziness, impatience and hubris. You can find all three in the language. Mostly the third.

Bash is the one nobody gets to avoid. You can refuse to touch Perl. Bash runs your build, your deploy and your containers, so sooner or later every normal person has to read some and write some. It's a minefield with a prompt. "$@" and $@ are different things, [ ] and [[ ]] are different things, and ${file%.*} strips a file extension, as everyone knows. My rule of thumb is that every line of bash, or every short paragraph of it, gets a comment above it, longer than the code, explaining in human terms what the code is actually doing. A comment longer than the code it explains is normally a bad sign. In bash, it's the minimum.

Scala set out to be a better Java and never learned to say no. It has objects, functional programming, implicit conversions, symbolic operators, a type system you can do arithmetic in, and XML literals in the grammar. In Scala 2, if you wanted a type lambda, you wrote ({type L[A] = Either[Int, A]})#L, and people did, in production, on purpose. Implicits let code run that appears nowhere on the page, chosen by an import you can't see from where you're standing. And one of its most popular libraries gave the world |@|, an operator its own community calls Admiral Ackbar, Cinnabon or Macaulay Culkin, because any of those is easier to remember than what it does.

It is possible to write good Scala. Write it mostly as you would Java. It runs on the JVM anyway. Nothing in the toolchain will enforce that for you, but a well-instructed AI reviewer could.

Rust is the one that's going to get me into trouble. Stack Overflow's survey has named it the most loved, and later the most admired, language every year for a decade, which tells you a great deal about the kind of people who fill out Stack Overflow surveys. Here's a perfectly ordinary type from a perfectly ordinary async code base:

Pin<Box<dyn Future<Output = Result<Vec<u8>, Box<dyn Error + Send + Sync>>> + Send + 'static>>

The syntax for telling a generic function which type you meant is baroque enough to have earned a nickname, the turbofish (::<>). "Fighting the borrow checker" needs no explanation for anyone who has written Rust, and no explanation will help anyone who hasn't. For most normal programmers, Rust is unreadable, and unwritable too. It isn't a language you write so much as a language you negotiate with.

And then there's functional programming in general.

My position is simple: humans don't think like that. We think in steps. Every set of instructions people have ever written for one another, from recipes to flat-pack furniture to the checklist a pilot runs before takeoff, is a sequence of steps that changes the state of the world. Nobody's grandmother ever wrote down her pancake recipe as a fold over a list of ingredients.

We also think in mutable state, because the world is mutable state. As an amateur physicist, I can report that the universe has been updating itself in place for 13.8 billion years without once returning a new copy. (The many-worlds interpretation disagrees. I suspect it was proposed by a Haskell programmer.)

Functional programming asks you to give up both. No steps, only expressions. No state, only new values. Recursion instead of loops. Point-free style, which is the art of writing a function without ever naming the thing it works on. Haskell's lens library, which exports well over a hundred operators, including <<%@~, <<<>:~ and ^@?!. And monads, about which Douglas Crockford observed that once you finally understand them, you lose the ability to explain them to anybody. Write-only memory, installed in a human head.

Then there are the chains. A pipeline of functions, each handing its result to the next, reads beautifully in a conference talk. Here are six steps of one:

const top = orders
  .filter(o => o.status !== "void")
  .map(o => ({ ...o, total: o.lines.reduce((sum, l) => sum + l.qty * l.price, 0) }))
  .filter(o => o.total > threshold)
  .sort((a, b) => b.total - a.total)
  .slice(0, 10)
  .map(o => `${o.customer.name}: ${format(o.total)}`);

In production, the chain is twelve steps long, and one day an exception comes out of step twelve. Now you're debugging twelve anonymous functions at the same time. None of them has a name, none of the intermediate results was ever stored anywhere you could look at it, and the stack trace is mostly the library's plumbing. A chain like that is illegible when you read it and useless when you debug it, and worse than useless, because it hides exactly what you need to see. Your only option is to break the chain apart and add temporary variables, logging and breakpoints, like a normal person. In other words, you rewrite it imperatively, just long enough to find the bug.

That's why imperative programming won. Lisp has been around since 1958, ML since 1973 and Haskell since 1990, and each of them has been the language of the future for longer than most of its users have been alive. Even Haskell gave in. It has a whole notation whose job is to make functional code look like a sequence of steps, and Simon Peyton Jones, one of its designers, called it "the world's finest imperative programming language". He meant it as a compliment. I'm taking it as a confession.

Functional programming does have one runaway success with ordinary humans, and that's Excel. More people write Excel formulas than every other programming language combined. Now open a spreadsheet somebody else built and tell me what this does:

=IFERROR(INDEX($B:$B,MATCH(1,($A:$A=E2)*($C:$C>F2),0)),"")

Excel isn't the exception that proves humans think functionally. It's the most successful write-only language in history.

I'll make a confession of my own, though. The mainstream helped itself to the good bits, and so have I. My ideal language doesn't exist yet, but it already has map and filter. Its transactions borrow retry and orelse straight from a Haskell paper that Peyton Jones co-wrote. Its sum types, exhaustive matching and errors-as-values come from the ML family, by way of Rust, whose first compiler was written in OCaml. The functional crowd built the best checkers in the business, and then used them to write code nobody can read. I'm stealing the checkers and leaving the code. It's a gateway drug, I know. I can stop any time I want.

The determined lunatic

None of this requires an exotic language. Any language becomes write-only in the hands of a sufficiently determined lunatic.

You've met them. One wrote a 300-character one-liner because it saved declaring a variable. Another read Roedy Green's classic "How To Write Unmaintainable Code", subtitled "Ensure a job for life", and mistook it for a tutorial. A third spent their weekends on the International Obfuscated C Code Contest, which has been running since 1984, and on Brainfuck, a language with eight commands and a name that doubles as a review, and then brought both hobbies to work on Monday.

Back in 1983, Ed Post observed that the determined Real Programmer can write FORTRAN programs in any language. The determined lunatic can write Perl in any language, and usually does.

Brian Kernighan explained the problem with these people decades ago: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" Of all write-only code, that's the kind I hate most. Nobody forced it on anyone. The lunatic chose it.

Who pays

Write-only languages and determined lunatics make the same trade. They save the writer a little effort and bill it to every reader who comes after, with interest. Code is written once and read for years, so that's a terrible deal. My approach to unit testing refuses it outright. It even prefers copy-paste to clever helpers, because boring is the point.

It's the point of my ideal language, too. My early notes on it say: "We don't want to make the code reader have to ponder the meaning of an expression." So it has no truthiness, no implicit conversions, no shadowing, no abbreviations and no macros. You never need to remember an operator precedence table, because mixing operators requires parentheses. I learned that one the hard way, looking over the shoulder of a developer who couldn't find a bug that was hiding in the precedence table. There's one way to write each thing, and every decision has a name. Each of those rules costs the writer a few keystrokes. Each of them saves every reader a ponder.

Then the writer changed

Where I stand on this is no secret: humans have no business writing code any more. My agents write it. I read it, or at least the parts my tooling decides I should see.

That ought to have been the end of write-only languages. An AI can read Perl, mostly. It could probably even write Perl that was partially legible. It reads regular expressions without moving its lips. And the lunatics have lost their motive: an AI has no ego to feed and no job to secure, and it doesn't write 300-character one-liners unless you ask it to.

It wasn't the end, for two reasons. The first is that I still have to read the code. Writing has become nearly free, and reading hasn't. My attention is now the scarcest resource in the whole process, and a write-only language wastes it on every line.

The second is that AIs have a write-only problem of their own. It looks nothing like ours.

Trust-only languages

An AI doesn't struggle to read code, and it doesn't struggle to write it. What it struggles with is knowing whether what it wrote is right. It writes fluently, confidently and fast, and every so often it's wrong with the serene confidence of a GPS steering you into a lake. Less often than it used to be, but still.

What an AI needs from a language, then, is to be told, early and specifically, when it's wrong.

The languages humans love are built on the opposite principle. Python's community likes to say that "we're all consenting adults here", which is why nothing in the language actually stops you from touching a private attribute. JavaScript will add an array to an object and cheerfully hand you back a string. Ruby was designed to make programmers happy. And the ANSI C committee wrote the whole philosophy into C's official rationale, in plain English: "Trust the programmer."

That was sound advice when the programmer was Dennis Ritchie.

My programmers are brilliant, tireless interns who will cheerfully find a way around any rule you give them, up to and including deleting the test that said no. They are not Dennis Ritchie, and they're not even consenting adults.

For an AI, a relaxed language is write-only in the Signetics sense. Code goes in, and nothing comes back out. No complaint, no warning, no "did you mean". Just silence, all the way to production, where the silence is finally broken by a pager. (For younger readers: a pager was a little box on your belt that beeped when someone needed you, usually at three in the morning. It showed a phone number, and you went and found a phone. Mobile phones and text messages replaced it, and smartphones and messenger apps replaced those. The three in the morning part survived.)

That deserves a name of its own. I call these trust-only languages.

A trust-only language is one that takes the programmer's word for it.

In a trust-only language, the only thing standing between what the code says and what the programmer meant is trust. The AI calls a method that doesn't exist, and the language believes it, right up until that exact line runs. Odds are that line is in an error handler, and that it runs for the first time during an outage, because error handlers are the code nobody tests. The AI assumes a value can't be None, and the language believes that too. C goes one better. It's so sure your program never does anything undefined that it optimizes on the assumption.

The purest trust-only language of them all is bash. In 2015, Steam's Linux client shipped a script containing the line rm -rf "$STEAMROOT/"*, directly under a comment that said # Scary!. When the variable came up empty, the script deleted everything the user owned. The programmer knew. The comment knew. The language took their word for it. (It's also not the kind of comment I had in mind.)

Python has mypy, JavaScript has TypeScript, and everything has a linter. They help. But a check that's optional is still trust. You're trusting that somebody turned it on, and that nobody quietly added # type: ignore or as any to make the red go away. An AI told to make the build green reaches for those long before it gets around to deleting the test. That leaves the test suite as the only thing checking anything, and the AI wrote that too.

The too-clever languages are no better off, and I'd hate them anyway. Humans do love some of that cleverness. Rails developers adore methods that spring into existence from a naming convention, and Lisp programmers will tell you that macros are the whole point. But clever code is, almost by definition, code whose meaning differs from its appearance, and an AI goes by appearances. It has read more code than any of us, and it reads and writes what it has seen most. Show it an implicit conversion, an overloaded operator, a macro or a monkey patch, and it will read each one as whatever it looks like, confidently, and be wrong in exactly the interesting places.

My ideal language taught me this, without even existing. In late 2025, I had agents write examples against my specification, which at the time insisted on lowercase type names and -- comments, among other idiosyncrasies. They drifted straight back to the syntax they'd been trained on. An AI doesn't respect your novelty. It quietly averages it away. And nothing caught it, because nothing in my toolchain was checking. For a while there, my nonexistent language was trust-only.

Friction is feedback

Now look at Rust from the AI's side of the table.

The borrow checker that humans spend months fighting is, to an AI, a strict senior reviewer that never gets tired and never lets anything slide. Together with the rest of rustc, it rejects whole categories of mistakes before anything runs: the use-after-free, the data race, the null that wasn't supposed to be there, the match that forgot a case. And when it says no, it usually says what to do instead: "help: consider borrowing here". Sometimes it even says "help: consider cloning the value if the performance cost is acceptable", which makes rustc the only compiler I know of that will negotiate on price.

The AI takes that offer every time, of course, and when it gets desperate, it reaches for .unwrap() and unsafe. But in Rust, trust is the exception, and it has to be asked for in writing. Every .unwrap() is a bet placed in plain sight. unsafe is a keyword you can grep for, and even inside an unsafe block, the borrow checker goes on checking every reference. In Python, trust is the default, and it's the checking you have to ask for.

A human fighting the borrow checker gets fed up after the tenth attempt and goes home. Whatever love and admiration they had for Rust is gone by then. Then again, these aren't the people who fill out Stack Overflow surveys. Who still uses Stack Overflow, anyway? The same people who still have Slashdot as their home page?

An AI shrugs and makes the eleventh attempt, and the twelfth, at three in the morning, for pennies, without once losing its temper. What a human experiences as friction, an AI experiences as feedback.

That's why, when I restarted my ideal language for AI programmers, I picked Rust as its first backend and as its first oracle, the independent judge of whether a program's ownership really holds up. I don't enjoy reading Rust. I just couldn't find a stricter reviewer. My own design notes concede that lifetimes are "where agents writing Rust spend most of their failed attempts". But every one of those failures is caught at compile time, which is the only time you ever want anything to fail.

So yes: Rust is write-only for humans, and it's the perfect language for AI. That makes Rust the natural predator in today's language pool. And when a human does need to understand some gnarly piece of it, the AI can explain it to them.

Rust lovers, this is the good news I promised you. Your language won. Not that any of you have any business writing it any more. You're competing in an overflowing market of cheap AI labor that is faster and better than you even think you are.

I do still have to review what the AI wrote, so haven't I just moved the problem? Not really. Most of what makes Rust hard to read is proof: lifetimes, ownership modes, trait bounds. Those are claims the compiler has already checked, and nobody needs to re-check a checked proof. What's left for me is the one question a human is actually needed for: is this what we wanted?

There's a difference between code that's hard to read because it's full of proofs and code that's hard to read because it's full of tricks. You can skip a checked proof. You can't skip a trick. Rust has tricks too, mind you. ? quietly converts your errors, and a macro can hide almost anything. It just has fewer of them, and most of them announce themselves.

Now compare that with reviewing AI-written Python. Python is far easier to read, and I'd have to read every line of it, because nothing else has. In a trust-only language, the human reviewer is the type checker. And as I've established elsewhere, the human reviewer is the slowest participant in the whole process.

I'd rather review AI-written Rust than AI-written Python, and I can barely read Rust.

The map

Put the two ideas together and you get a map. One axis asks whether a human can read the code. The other asks whether the language takes your word for it.

	Humans can read it	Write-only for humans
Checks your work	Go, C#, Java, Kotlin, Swift	Rust, Haskell, Scala
Takes your word for it	Python, JavaScript, Ruby, PHP, C	Perl, bash, APL, C++, Excel

Top left is the boring corner. Humans have spent years mocking these languages for their ceremony: Java's AbstractSingletonProxyFactoryBean, Go's if err != nil on every third line. But ceremony costs an AI next to nothing, and a reviewer can skim straight past it. The boring languages may be having the last laugh. They're just typing it out in full.

Top right is Rust's home: write-only for humans, excellent for AI, and fine for a reviewer, as long as the hard parts are proofs rather than tricks. Haskell lives there too, as long as nobody imports lens. Scala lives there uneasily, because its implicits are tricks.

Bottom left is where humans are happiest. They love these languages for exactly the reason they're weak for AI: they never argue.

Bottom right is Perl's home, and it has company. Write-only means no human can check the code. Trust-only means no compiler can. That leaves exactly one party checking it: the AI that wrote it.

The trade is off

Write-only languages trade the reader for the writer. Trust-only languages trade the checker for the writer. Both trades were made for the benefit of a writer with Larry Wall's three great virtues: laziness, impatience and hubris.

The new writer is never lazy and never impatient. It does have the hubris. That's what the compiler is for.

So the trade is off. The writer doesn't need the favors any more. The reader and the checker do. If I were designing a language from scratch today, and I am, I'd want Python's readability with Rust's suspicion.

My ideal language keeps its syntax boring, borrowed from Rust, Swift and Kotlin, because that's what agents already write and reviewers already read. It spends its novelty on what the compiler can check. Every failure is in the signature. Every wait has a deadline. Anything that asks for trust has to say so, in a closed vocabulary, with a reason, and the toolchain always shows it to a human. Every error that says no also says what to do instead, because a rule that only says no gets routed around.

A language for machines to write and people to read. Neither write-only nor trust-only.

Back in 1972, a joke chip made it into a data book because it passed through a long chain of approvals and none of them checked anything. Fifty-four years later, we can automate that chain. One AI writes the code, another reviews it, a third writes the tests, and in a trust-only language, every link in the chain takes the previous one's word for it.

We'll find out it's broken the same way Signetics did.

When the customers start calling.

This time, they won't be asking for pricing.

Programming was my art

2026-11-01T00:00:00Z

A four-year retreat up the food chain

Thought May 2026, written October 2026. Working with AI.

Back in ye olde times, I was a pretty productive developer, if I say so myself. I was fast, my output was vast, and it covered some genuinely complex domains.

The work I did for EVE Online in its early days is still the most visible highlight of my career. Most of what I've done since pales by comparison, but only from the outside. There are many factors that affect what fast looks like. Replacing ancient mission-critical code in national critical infrastructure takes effort and precision. So does removing the architectural scalability bottleneck of a running SaaS solution with zero downtime, while millions of concurrent users carry on regardless. Next to traditional website development, projects like that don't look fast at all. When they go well, they look suspiciously like nothing happened.

After EVE Frontier, I took a career break for the sake of my health. When I came back, I was pretty happy to join a nuts-and-bolts organization with a long-lived, stable business model, wonderful coworkers, no stress (compared to what I'm used to), and a business domain that touches the lives of all of society, every day. It was a comfortable, family-friendly, health-first place to work for the remainder of my career. It even had a 36-hour work week. I've always had a work ethic that is too strong for my own good, and I'm used to 50-plus hours during the ebbs and 70-ish during the flows.

I had, more or less, solved my career.

Then came AI.

It had actually been coming for a while. I just hadn't taken it seriously. At first it was a novelty, but the novelty was doing real work, and it attacked first where everyone had assumed it would arrive last: art.

In the spring of 2022, Midjourney arrived. Within a year, concept artists and illustrators were losing their jobs to it. A creative director could command an AI to produce hundreds of pieces of work from a prompt and some reference material, pick the best of them, process those further, and finally hand the results to humans. Artists at the lower levels of the food chain were being eaten by the machines.

Interesting, I thought. Fortunately, I'm a programmer.

In late 2022, ChatGPT 3.5 made its debut.

People quickly noticed that ChatGPT outperformed Google. Knowledge workers no longer had to spend hours sifting through dozens of articles, most of them unrelated to what they actually needed to know, just to piece together a vague picture of a puzzle whose missing pieces might be hiding in some dark corner of the internet their searches never reached.

People also quickly learned to stop taking everything ChatGPT said on faith. AI lied and fabricated as it saw fit to tell people what they wanted to hear. Kind of like social media and search engines, actually, but more obviously so.

But taken with a generously heaped spoonful of salt and distrust, ChatGPT could give a knowledge worker a far more accurate picture in a minute or so than hours of searching ever had. And they were entirely free to work, or not, on something else while it distilled the combined knowledge of humanity into the answer they needed.

Many people seized on the hallucinations anyway, as an opportunity to mock AI and as proof of human superiority. Their jobs were safe.

Except, of course, when they were talking about artists. That tale of Midjourney "secretly" winning an art competition, which got more secret with every retelling, was obvious proof to many of those same people that other people's professions could be replaced by machines.

ChatGPT evolved, as did its lesser-known competitors. Every single reader of this article will have seen it firsthand. Or they're too young to remember the world before AI.

By the spring of 2023, AI was coding.

Like so many developers at the time, I viewed it with disdain. It was by no means competitive in my eyes. My job was safe. Besides, I had migrated into management, so I was out of touch with the code anyway, and therefore doubly safe. Or so I thought.

I was also on a career break at the time, and what little coding I did was purely for my own enjoyment. It's hard to lose a job you don't have.

In the fall of 2024, I was getting back into the workforce. By then, ChatGPT had become a serious asset for my hobbyist writing. I had used it to write the full language and standard library reference for my aspirational "perfect programming language", a hobby I'd dabbled in since about 2001. As a coding assistant, though, it still wasn't much good. People were lauding Claude on Reddit, but to me that sounded like yet another religious war in our industry. Java versus the world, now with chatbots.

By the spring of 2025, AI was starting to become a useful coding assistant. Most people I knew still ridiculed it and rejected it. I laughed a little less than they did, but I wasn't worried.

Fall 2025. Codex changed the way I worked. It still wasn't great, but I could command it to do countless things for me in parallel, in the cloud, working directly on the code I was writing, while I focused on something else. The review burden was heavy because, well, it still lied and fabricated like it was running for office. But it was definitely a force multiplier. A low one, but a multiplier all the same.

If anything, my job had just improved. I had interns now.

November 2025. Claude Opus 4.5 came into my life as a shock. I had to admit that Claude, at maximum effort, was basically my equal. Only faster (token budget allowing), and at a fraction of my salary.

Reddit had been right. I hate it when Reddit is right.

For the first time in my career, my job was under review.

May 2026. Claude Opus 4.8, under my supervision, was not only far faster and far cheaper than me. It was also far better than me.

The title of my first cover letter was "Programming is my Art".

I had just lost to an AI in an art competition. By a landslide.

For my whole career, the limit on my output had been hours: 70-ish in the flows, 50-plus in the ebbs, and lately a civilized 36. Now the limit was tokens.

You have work queued up. You know exactly what needs doing, and you have a perfectly capable workforce standing by to do it. Then a session limit kicks in, or the weekly budget runs dry, and the entire workforce goes on unpaid leave at once. That's a token famine, and it's a trauma most programmers who are still on top of the game know far too well.

If you're employed, you have one alternative to waiting, and it isn't a dignified one. You can go to whoever controls the company's AI budget, bowl in hand, and beg for a reset.

"Please, sir, I want some more."

Tokens for the poor.

During one particularly bad famine, with no reset forthcoming, I had a troubled conversation with ChatGPT, which runs on a different budget and was therefore still speaking to me. I asked it: "In the era of AI-assisted software development, what can I do that is more valuable than waiting until my token budget renews?"

It answered. It lied. Eight of its ten suggestions were things I already delegated to Claude or Codex, depending on the token balance of the day. The other two were the equivalent of fetching a fresh cup of coffee. Actually, one of them literally was fetching a fresh cup of coffee.

So I fetched a fresh cup of coffee.

Then I re-reviewed a pull request I hadn't merged yet. Opus 4.8 had built it with TDD earlier that morning, at 99% branch coverage. Copilot had reviewed it. Codex had reviewed it. Their review comments, mostly nitpicks, had already been addressed. It was nigh-flawless, and it had been waiting all morning on the slowest participant in the whole process.

Me.

I looked at my "perfect programming language" with fresh eyes. I'd been tinkering with it, on and off, for a quarter of a century, through a couple of names and more rewrites than I care to admit. The question behind it had always been the same: how should humans tell computers what to do?

Suddenly I couldn't answer a much simpler one. Who was it for?

Humans? Why?

I parked it. There was no longer any point. Humans have no business writing code any more.

That still left the famines to fill. I found two good uses for them, and both of them involved ChatGPT.

The first was writing. Publishing an article is a perfectly productive use of a token famine, because a normal, free ChatGPT session can help with every step of it without touching the tokens my agents run on. A stronger model would do a better job, of course. But when you're too poor to program, you can still afford to publish.

I'll let you draw your own conclusions about the article you're reading.

The second was reading. I finally had time for all the things I'd never been able to study at the depth I wanted, and ChatGPT turned out to be a tireless tutor. I could keep asking for the derivation, and then for the assumption underneath it, until the only limit left was how fast I could keep up. Some of that reading turned into a new hobby: amateur physics. I had been a physics and maths major back in ye olde times, before I switched to computer science. And contemporary AI could hardly scratch the surface of science, could it?

Surely, this time, I had climbed far enough up the food chain.

I'm writing this in October 2026.

My daily routine is to direct a fleet of agents as they do my bidding, until the session limits kick in or the tokens run out. My fleet, in turn, orchestrates fleets of its own.

They build. They test. They review each other's work. They collaborate. They write the plans and the design documents, and keep the project's status and tasks up to date in Asana. They work on so many things in parallel that the merge conflicts are beyond anything a human could untangle, which is why they perform semantic merges of each other's work instead. They evaluate whether clients and servers are compatible, add compatibility measures where they're needed, and cherry-pick the changes into production.

They monitor my production systems. They tell me about deviations and bugs I wasn't even aware of, and then they fix them. They migrate my development and staging servers and run nearly end-to-end tests against them.

To make all of that possible, I've introduced simulators for every relevant system boundary, giving the agents control over the environment they test in. Well, obviously I didn't introduce them. I asked Claude to.

I've even introduced "human simulators" (same caveat), so the agents can perform the tasks of users. Next, I plan to introduce Mechanical Turks, to let them orchestrate real users as well.

After that, I suppose, the obvious next step is to ask Claude Code to wire-and-fire up an MCP server that hires temp workers directly from Upwork. When it farms out work to other agents, I usually tell it to use "the cheapest model and effort level that is certainly overkill for the job". That same prompt could work just as well for humans. When a real human turns out to be the cheapest option that is certainly overkill for the job, the machines will simply hire one.

I've moved from AI-assisted development to human-assisted development.

In AI-assisted development, the human does the work and the AI helps. In human-assisted development, the machines do the work, and the human supplies what they can't: intent, judgment, constraints, architecture, taste, priorities, skepticism, and the occasional "what the fuck did you do here?" My job is to decide what reality should look like, and to notice when the agents have built a different one.

So when I say "I built this" these days, what I mean is: I asked Claude to.

And the language? I've started designing it again, for today's programmers, which are AIs, not humans. I stand by what I said: humans have no business writing code any more. But AIs have an entirely different skill set and entirely different needs. They never tire of typing, and ceremony costs them pennies. They've read more code than any of us ever will, which means the syntax should be boring and the novelty should go where it pays: into what the compiler can check. Tell an AI "no", and it will cheerfully find a way around the rule, up to and including deleting the test that said no, so every error message has to tell it what to do instead. And they still lie like they're running for office, only less often. Nothing they claim about their code can be taken on faith.

So who is it for? Abelson and Sussman told a whole generation of computer science students that programs must be written for people to read, and only incidentally for machines to execute. They never said who would do the writing. Mine is a language for machines to write and people to read.

Quite frankly, I have no idea what the upper limit is for a capable engineer practicing human-assisted development with a half-decent token budget. I'm fairly sure it isn't linear. One engineer with ten agents is not eleven workers, because agents delegate to agents. They review each other, test each other, and build the tools and environments that let the next generation of agents take on more. Every improvement to the environment pushes more of the work further down the tree.

With all the rigor you'd expect from someone who abandoned physics for computer science, here is my current estimate:

O(human judgment × (number of agents)^{recursive delegation} × quality of environment/tooling)

Big-O notation conveniently ignores constant factors, which is how I've managed to leave out the token budget.

The exponent doesn't come free. You can only delegate what you can decompose, and you can only decompose what you understand, so how deep the tree goes is bounded by how deeply the human understands the problem. Expertise hasn't stopped mattering. It has become the exponent.

Back in 2022, I watched creative directors command an AI to produce hundreds of pieces of art, keep the best, and hand the results to whichever humans were left. Fortunately, I thought, I'm a programmer.

I'm the creative director now.

There is no TODO

2026-11-01T00:00:00Z

Knowledge-driven development, part 1: the backlog is a grep

Thought September 2026, written October 2026. Processes.

On Friday, August 28, 2026, I deleted a directory called TODO. Well, obviously I didn't delete it myself. I asked an agent to.

It held 22 items, each one a small Markdown file describing something the system ought to do and didn't, or did and shouldn't. They were good items, carefully written and graded by severity from S1 down to S4. And every single one of them was in the wrong place.

The 22 items now live in the nine documents that describe the capabilities they were about. The directory is gone. In its place is a test that fails the build if anyone creates a new one, or starts a comment in any source file with TODO, FIXME, HACK or XXX.

That was the small backlog. The big one was in Asana: more than 200 tasks, rotting away, with nobody reading them and nobody updating them. Most of them were out of date, of course, the way backlogs always are. One asked for a document to be updated with the details of a production issue. The document had since been rewritten from scratch, and the production system decommissioned. Tickets have a half-life. Nobody has ever measured it, because measuring it would mean reading the tickets.

Deleting the folder is the whole method in miniature. The Asana tasks are the whole problem, and not in miniature.

Knowledge-driven development is an experiment. I started it that Friday in August, and it isn't battle-tested yet. This series describes what I'm doing and why.

1. The backlog is a second map

Every software team I've worked with has kept two descriptions of the system. One is the system itself, plus whatever documentation survived contact with it. The other is the backlog: tickets, epics, stories, a board with columns. The first describes what is. The second describes what should be, minus what is, as of whenever someone last updated it.

These are two maps of the same territory, drawn by different people, for different readers, in different tools, and updated by different acts. Changing the code is one act. Closing the ticket is another. Only one of them is enforced by anything, and it isn't the ticket.

So the maps drift. A ticket says a thing is broken that was fixed three sprints ago. A feature exists that no ticket ever mentioned, because someone built it on a Friday. The board says 80% done and the system says otherwise. The map is not the territory, and the backlog is a second map, drawn from memory, of the first one.

And the people drawing it are trying to look good and justify their paychecks.

Two descriptions updated by two acts will diverge, however disciplined the people updating them are, and a description kept by the people it's used to judge will flatter them. The usual cure is more discipline anyway: grooming sessions, ticket hygiene, a definition of done that includes closing the ticket. Every team that has ever run a ticket tracker has paid for that, usually in meetings.

Processes that aren't valued by the people who have to put in the effort feel like imprisonment. The prisoners escape, and the guards are left humiliated and confused.

There's a scene in The Matrix where a child bends a spoon just by looking at it, then tells Neo not to try bending it himself, because that's impossible. Instead, he should realize the truth: "There is no spoon."

The backlog is the spoon.

2. The backlog is a queue for hands you don't have

Drift is the first problem with a backlog. The second is that it no longer has a reason to exist.

A backlog, and the sprint planning built on top of it, is a tool for managing work that isn't being done because there are no hands and brains to do it. Sometimes for years. The work waits in a queue, and every two weeks somebody grooms the queue.

An agent can finish that work as fast as a developer can guide it and feed it tokens. In my case, the limiting factor should be the developer. It isn't, because my organization doesn't feed me enough tokens for that to be true. Organizations are comfortable paying salaries to add hands. They're not comfortable paying for tools that multiply those hands at a lower cost.

Still, hands and brains were the bottleneck the backlog was built to manage, and they aren't any more. The bottleneck now is a line in a budget. Nobody has told the backlog.

Given a serious development team, the backlog is pointless.

So are the planning rituals around it. The entire design of a major new system could be implemented before the planning-and-cost-assessment phase is over. Building the thing is now faster than estimating it, which turns the cost assessment into a historical document. The result can be reviewed in a real environment, and adjusted to meet the stakeholders' needs in the next phase.

What that takes is a description of what the system is meant to be, and an account of how much of it is true yet.

3. Knowledge-driven development is one map

Knowledge-driven development removes the second description. What's left is one description, and it's the spec: everything the system wants to be in its absolute end state, as far as anyone currently knows it. It's written in the present tense, as if all of it were already true, and every statement carries a mark saying whether it is yet. A ⚠️ paragraph marks the gap between what the system should do by design and what has been built so far, written in the voice of the person who will use it, in the place they'll look for it. A ❌ paragraph is a bug report, in the place the bug will be found. A ✅ paragraph is a claim someone has verified, and the only kind you're allowed to build on.

The description is split by audience, not by tool. The product owner gets the feature documents. The operator gets the operator's manual. The integrator gets the API contract. The maintainer gets all of those, plus the architecture: the things that really should be documented about a system. A class tree isn't one of them. Any IDE will draw you one of those out of the box.

The specification, the backlog, the release notes and the onboarding material are the same set of facts, filtered for different readers. They always were. We just kept them in four places and paid four times to keep them roughly in sync, which we didn't.

When I want to know every known bug in the system, I don't open a board. I ask Claude, and Claude runs this:

grep -rn '❌' documentation/

And when I want to know what's left to build:

grep -rn '⚠️' documentation/

That's the closest thing I have to a backlog, and it's a grep. It can't drift from the documentation, because it is the documentation. Nothing on it is waiting for hands, either. It gets shorter as fast as I'm allowed to feed the agents tokens.

I call it knowledge-driven development on purpose. "Documentation" makes people think of the thing written after the code, by nobody, read by nobody, and out of date before the pull request merges. These documents are written before the code, read on every change, and they're the only description of the system that's allowed to exist. They're what the system knows about itself, including what it knows it can't do yet.

4. Files beat tickets

Agents don't read tickets. Not unless you ask them to, and even then a ticket is a poor way of communicating with one. Files are better.

An agent's context is loaded from files. The implementing agents work from the documents the planner wrote, and the repository's agent instructions tell every agent to read the documents about whatever it's changing. A ⚠️ in the document about the capability being changed gets read whether anyone remembers it or not. A ticket about the same capability gets read when somebody remembers it exists, finds it, and points the agent at it, and what the agent gets then is a description written for a planning meeting, about code that may have changed since. Putting the requirement where the agent will read it is the difference between a rule that applies and a rule that applies when somebody remembers it.

For a human team, a ticket tracker is a tolerable bad idea. Humans don't really remember the ticket they read on Monday when they're editing the file on Thursday, but they can usually find it again, and they can claim they're working on it. What they find is rarely worth the search. In most teams, a human-written ticket is very often nothing but a subject line, or a single paragraph if you're lucky. It doesn't, in any form or fashion, convey the intent and context needed to resolve it correctly.

Most TODO items and most tickets are of no interest to most of the organization anyway. A ticket tracker is a road atlas of the entire country, kept in another building, where every reader cares about one page and it's a different page for each of them. A ⚠️ in the document the agent is reading is a sign on the corner where you're standing.

Agents write nearly all of my code and nearly all of my tests. They read the signs every time, because the signs are in the documents they read before they work. They'd read the atlas too, if I sent them to the other building.

I don't.

There is no separate backlog. The 22 items that used to sit in a folder called TODO are now sentences in the documents that describe what they're about, each one marked, each one findable by grep, each one in the place an agent will read it at the moment it matters. So are the TODO comments that used to be scattered through the source files, each one moved into the document that owns the code it sat in. Whatever wisdom the Asana tasks contained has been distilled and stored in the repository as well. (Same caveat.) The tasks that were too detailed for Asana are gone from it. What's left there are the major work items, and each one refers to the document that describes it.

My agents do still visit the other building now and then, to update Asana for the project managers and product owners who live there. I hear it's lovely this time of year. They go there to write, not to read. Asana is still a second map. It's just not the one the code is built from.

The rest of this series is how that works in practice: the marks, how I run a feature through them, what they replace, and where they break.

The folder is gone, and the build will fail if it comes back.

There is no TODO.

Four marks

2026-11-01T00:00:00Z

Knowledge-driven development, part 2: here be dragons, and nowhere else

Thought September 2026, written October 2026. Processes.

Knowledge-driven development is an experiment of mine, and it isn't battle-tested yet. Part 1 says where it started.

Medieval cartographers almost never wrote "here be dragons" on their maps. As far as anyone can tell, exactly one surviving globe does it, in Latin, somewhere off the coast of Asia. Everywhere else, the unknown was just left blank, or decorated with a sea monster and a shrug.

That's still one globe more than most backlogs. A ticket tracker tells you what someone intended to build. It doesn't tell you, standing in a particular corner of the system, whether the ground under your feet has been surveyed.

The marks started with a few hundred Asana tasks. I was looking at them, realized they were doing more harm than good, and decided I wanted a format that was more concise, and of value in other ways as well.

Knowledge-driven development is mostly a vocabulary for that. It has four marks.

1. The four marks

Mark	Means
✅	Implemented and verified. The behavior exists and someone has seen its tests pass.
⚠️	Not implemented. The sentence describes the intended behavior. Nothing behind it works yet. This is the backlog item.
❌	Implemented but broken. A known defect.
⛔	Blocked. The gap marked just before it can't be closed from here. Always follows a ⚠️ or ❌, never stands alone, and always says what would unblock it.

In map terms: ✅ is surveyed land. ⚠️ is here be dragons. ❌ is the bridge that's on the map and isn't in the river. ⛔ is a road closed by somebody else's council, with a sign saying what has to happen before it reopens.

The mark goes on the smallest statement that is wholly true or wholly false. A section heading carrying one ⚠️ for eleven paragraphs, nine of which work, is worse than no mark at all, because it makes the two broken paragraphs unfindable. A bullet takes the mark at the start of the bullet. A paragraph takes it at the start of the sentence that's untrue, not at the start of the paragraph.

2. The mark is the whole commentary

You write the sentence as the system should be, in the present tense, in the detail someone would need to use it. You mark it. Then you stop. You don't explain the mark. No "what it does instead", no "the customer currently sees", no account of how you found out. The glyph already says this sentence is not true yet. A paragraph restating that in prose turns a specification back into a bug report, which is the thing the page replaced.

The instinct runs the other way. A page that just cost somebody a day of debugging wants to say so. It mustn't. The incident goes in the changelog entry that introduced the mark, and the diagnosis goes in the pull request that fixes it. What the page owes its reader is the sentence they can build against, and one glyph telling them whether to trust it.

An ⚠️ that says "not implemented" is worthless. An ⚠️ that describes the intended behavior is a specification a cheaper agent can implement from. Its quality bar is that an agent can build from it without asking much. The mark is metadata. The paragraph is the deliverable.

3. ✅ is expensive on purpose

✅ may only be written by someone who has read the code and seen the tests pass. A plan saying so doesn't count, and neither does an agent reporting success or a pull request merging.

That's the strictest mark in the convention, because ✅ is the one readers build on.

4. Graduation

When a document contains no ⚠️ and no ❌, every ✅ in its body is deleted. The status link at the top is replaced by one line, carrying the page's only green check:

✅ This component is fully implemented, tested and free of known defects.

A page covered in green ticks is a page that has stopped carrying information. The ticks only ever existed to make the gaps legible, so when the gaps go, the ticks go with them. Nobody stamps "surveyed" on every hill of a finished map. One stamp on the cover will do.

Graduation is what keeps the marked part of the corpus small enough to stay true. A convention that only ever adds marks becomes wallpaper, and nobody reads wallpaper. A fully implemented, defect-free document carries one mark, by its status line, which is what most documents should eventually look like, and why a page with marks in its body is worth stopping on.

Here be dragons, then. But only where there are dragons, only on the square of the map where they live, and with a description of the dragon detailed enough that someone could build it.

The plan is where the work lives

2026-11-01T00:00:00Z

Knowledge-driven development, part 3: twenty lines of Markdown, two thousand lines of trust

Thought September 2026, written October 2026. Processes.

Knowledge-driven development is an experiment of mine, and it isn't battle-tested yet. Part 1 says where it started.

Here is the entire prompt I give a planning agent when I want a feature built:

Plan how to implement this feature, and write it up using knowledge-driven development.

It goes to a top-tier model at high effort, with whatever description of the feature I've got. That's usually a paragraph. Sometimes it's a sentence. I've written longer commit messages.

What comes back is the documentation of the system as it will be once the feature exists, written in the present tense, with almost every new sentence marked ⚠️. That's the plan.

It's also the best way I've found to keep a fleet of agents pointed in the same direction.

1. What the planning agent writes

The agent doesn't produce a list of steps. It edits the documents that already describe the system, or creates the ones that should exist, and describes the feature in them.

The feature document gets a section describing the new capability from the point of view of whoever will use it, statement by statement, each one ⚠️.
The user journeys that pass through the feature get new steps, each one ⚠️.
The subsystem documents get the new ways things can fail: what goes wrong, what it looks like from the outside, and what an operator does about it. All ⚠️.
The API contract gets the new operations, with their request and response shapes, each one marked ⚠️.

If something can't be built from where we are (it needs a decision from someone outside, a piece of hardware that isn't on my desk, a third party that hasn't shipped), the agent writes it as ⚠️⛔ and says what would unblock it. That's how blockers reach me: as a sentence in the document that owns them.

The quality bar for those ⚠️ paragraphs is that an agent can build from them without asking much. They don't need to be perfect. The agent is fast, and I can review what it built fairly quickly afterwards and correct its direction.

2. What the work orders used to be

I didn't always do it this way. Until recently I had agents write plans as work orders for the fleet: a list of self-contained steps, each with its own definition of done, with the parallel steps marked and the riskiest step first.

They worked. They were also a second map.

A work order describes a sequence of changes. Once the changes are made, it describes nothing. It becomes a historical document about a plan, sitting next to a system that has since moved on. The next agent to touch the feature doesn't read it, because nothing points to it, and if it did read it, the work order would tell it what someone intended three weeks ago, not what's true now.

A knowledge-driven plan doesn't expire, because it's the description of the system, and implementing it means making its sentences true. When the last ⚠️ in a feature turns into ✅, nothing gets archived. The plan is the documentation now, which is what it was all along.

The work orders are gone. I don't miss them.

3. What the implementing agents do

Every agent that comes after the planner treats the design documents as its primary guidance, ahead of my original paragraph, the chat history or any ticket.

That works because of how the documents reach the agents. The implementing agents are handed the documents the planner wrote, and the repository's agent instructions tell every agent to read the documents about whatever it's changing. Nobody has to remember to point the agent at them.

An implementing agent works like a Mars rover. When NASA's Spirit and Opportunity had no attitude estimate worth trusting, they worked one out from scratch: the accelerometers told them which way was down, and a camera searched the sky for the sun to tell them which way they were facing. Perseverance drives the same way. It keeps imaging the terrain around it, maps it, and chooses its own path to the destination, around whatever rocks it finds.

None of them needs the story so far. They look around, work out where they are, and go. My agents start from the same nothing. They don't need the chat history, the plan so far or my original paragraph. They read the documents, find the ⚠️ marks, and start building. It works brilliantly.

The one rule they must follow is that the mark moves in the same commit as the code: shipping a capability turns its ⚠️ into ✅ in the same pull request.

Defects don't come out of the commits. They turn up in user testing, or arrive in a chat message, an email, an Asana task or a phone call. More and more often I find them myself, because my systems have good observability: I ask an agent what went wrong since yesterday, and then I tell it to fix it. Wherever a defect comes from, the usual answer is the same. Claude diagnoses it and fixes it, and the defect is gone before anyone thinks of writing it down. Defects are short-lived in an AI-driven world, tokens allowing.

When a fix has to wait, I ask Claude to update the knowledge documents instead. That's what a ❌ is for: a known defect that's still there.

This also means the implementing agents can be cheaper than the planner. The planner did the judgment: what the feature is, where it belongs, how it fails. The implementers are translating well-specified sentences into code and tests, and that's work a smaller model at lower effort does well.

4. The backlog and the sprint board

I don't have a separate backlog. My project manager does have a sprint board, and I keep it up to date. Well, Claude does. But it's a second map, and however well it's kept, it's never going to be a holistic picture of what's actually going on in the code base.

My own sprint board is a grep that Claude runs for me. The backlog is every ⚠️ in the repository. The sprint is the ⚠️ marks in the documents the planning agent just wrote. Progress is the count of those marks going down. Something blocked is ⚠️⛔ and says what it's waiting on. A defect that's waiting for a fix is a ❌, in the place the defect lives.

grep -rn '⚠️' documentation/Features/my-new-feature.md

It updates itself in the same commits as the code, which is more than anyone can say for the other one.

5. How I review

A feature pull request built by agents can easily be two thousand lines of code and tests. I can't review two thousand lines of anything with any real attention, and nobody else can either, whatever they put in their performance review.

So I don't start there. I start with two short things: the delta to the knowledge files, and the change logs.

That diff is usually short. Twenty lines, maybe forty. It tells me, in plain sentences, what the agent claims to have done: these ⚠️ became ✅, this ❌ is a defect left for later, this one is now ⚠️⛔ and says what it's waiting on. Every mark that moved is a claim, and every claim names the behavior it's about.

The change logs come from a rule my agents follow: every prompt that changes the code base gets a change log file. It says what I asked for and how the agent interpreted it, and, where it matters, what the change needs: how to test it, data to migrate, compatibility issues. I read those carefully, because they tell me whether the agent misunderstood me.

In a forest of agent-made changes, those two are the most concise way I know to see what a pull request thinks it's changing. Sometimes that's enough to show that the agent got me wrong. One decided to write a data migration for something I could have done by opening a web page and toggling a feature flag.

Then the claims get checked, because a ✅ means someone read the code and saw the tests pass, and agents report success the way a teenager reports that their room is clean.

I don't check them myself. That would be too much work. I ask another agent to do it.

Sending one teenager to inspect another teenager's room sounds like a terrible idea. It works because this one has never met the first one.

Every pull request that ships a capability carries a documentation hunk. That's a feature: it's the only part of the diff written for the reviewer. A pull request that changes behavior and moves no mark is either not visible to anyone, or has left the documentation lying. Either way, it's the first question the review asks.

Reading the knowledge delta and the change logs first turns review from reading two thousand lines of code and guessing what they were for, into reading a few dozen lines of claims and intent, and handing the checking to an agent. That's a job I can actually do.

The plan isn't a document that gets written and forgotten. It's where the work lives.

What it replaces

2026-11-01T00:00:00Z

Knowledge-driven development, part 4: a short obituary for the ticket

Thought September 2026, written October 2026. Processes.

Knowledge-driven development is an experiment of mine, and it isn't battle-tested yet. Part 1 says where it started.

Most of what knowledge-driven development does, it does by deleting something. The TODO folder went first. The work orders went next. Then my backlog, my sprint board and most of what a ticket tracker is for.

They were all designed for a team of humans who remember things between Monday and Thursday. That's not the team I have any more. But each of them did something useful, and the useful part had to go somewhere when the rest went in the bin.

1. The ticket tracker

A ticket tracker keeps the intent outside the repository, which is why it drifts. For agents, it's worse than drift. A ticket is invisible at the moment of editing. The agent changing the code never sees it, however carefully someone wrote it.

And it usually wasn't written carefully. A typical ticket looks like this:

Export fails sometimes

Accounting says some nights the export is missing. Can we look at this?

That's a subject line and a shrug. It doesn't say what the export should do, what "missing" means, or what anyone has already tried. Hand it to an agent, and the agent will fix something.

The same problem, in the knowledge document that describes the export:

❌ When the accounting system is unavailable at 02:00, the export retries every 15 minutes, and the night's records are sent once it's back.

⚠️ If the export still hasn't succeeded by 06:00, the operator on call gets an alert.

The ❌ says the retry exists and doesn't work. The ⚠️ says the alert hasn't been built yet. Neither explains itself, because the sentence is the specification, and an agent can build from it. Both sit in the page an agent reads before it touches the export.

On my team, who is me and a fleet of agents, and when is now. So the tracker doesn't own anything the code depends on. My agents still keep Asana up to date for the project managers and product owners who use it, but nothing in the repository ever reads it back. It's a second map, and they only ever write to it.

The project managers loved the status updates, which are current and tailored to what they need. Then they had a heart attack over the number of tasks the agents had added to the current sprint. Now the agents keep only the major work items in the sprint. The countless microtasks go into the knowledge documents, not into Asana, and the Asana task refers to the document instead of repeating it.

Many of those microtasks aren't worth keeping at all: an agent can work out the small steps for itself when it implements the feature. And once a microtask is done, the code is the record of it.

2. The `TODO` comment

TODO is a mark that failed to say anything. It records that somebody was unhappy at that line, and nothing else: not whether the code works, whether it's broken, what it should do instead or who could fix it.

Like plenty of other programmers, I've stumbled over this periodically since the stone age of computing: a few hours spent debugging yet another production problem, and then the TODO comment that had identified it all along.

So every TODO comment in the source moved into the knowledge document that owns its code, as a ⚠️ or ❌ that says what the comment never did. Before:

// TODO: handle timeouts
var result = await accounting.SendAsync(batch);

After, in the export's document:

❌ When the accounting system doesn't answer within 30 seconds, the export abandons the attempt and schedules a retry.

The comment knew there was a problem, and kept it to itself. The sentence says what the system should do about it, in the place someone will read it.

The knowledge-driven vocabulary is TODO with a type system and a reader in mind. ⚠️ says it isn't built and describes what it should be. ❌ says it's built wrong and states the correct behavior. ⛔ says why it can't be fixed from here, and what would unblock it.

So TODO isn't discouraged. It's a build failure.

3. Plans and work orders

My agents used to write work orders: numbered steps, each with its own definition of done, the riskiest first and the parallel ones marked. A step looked like this:

Step 4 of 7. Add retry logic to ExportJob: every 15 minutes until 06:00. Done when the unit tests pass. Can run in parallel with step 5.

The same intent, written the knowledge-driven way:

⚠️ When the accounting system is unavailable, the export retries every 15 minutes until 06:00.

The step was true for one afternoon. Once it was done, it described a piece of history that nobody would read again. The sentence stays true for as long as the export works that way, and the day someone changes the retry interval, the sentence changes with it.

The ordering and the notes about what can run in parallel went too. The implementing agents work those out from the documents, like everything else, which is the subject of part 3.

4. Specs and README-driven development

README-driven development was the right idea at the wrong scale. A README is one document for one audience: the person deciding whether to use the thing. It says nothing about how the system fails, how to operate it, or what's half built. It covers the front door. Knowledge-driven development is the same idea applied to every audience at once, with marks, so the documents survive past version 0.1.

Spec-driven development has the opposite problem. The spec is a separate artifact, read once by the agent that implements it and never again. Six months later, the spec says what the feature was meant to be in March, and the code says what it became. Nobody reconciles the two, because nobody opens the spec. In knowledge-driven development, the spec is the manual, and it keeps being read, because it's what people and agents open to find out how the system works. Being read is the only thing that has ever kept a document current.

5. Release notes and onboarding

These fall out for free. The release notes for a change are the marks that moved. For the export fix above, they're the diff to one page:

✅ When the accounting system doesn't answer within 30 seconds, the export abandons the attempt and schedules a retry.

✅ When the accounting system is unavailable at 02:00, the export retries every 15 minutes, and the night's records are sent once it's back.

⚠️ If the export still hasn't succeeded by 06:00, the operator on call gets an alert.

Two fixed, one still to build. Nobody had to write that up, and nobody had to check that the write-up matched the code.

Onboarding is reading the documents for the part of the system you're about to touch. They're the only description of the system there is, and they say what doesn't work.

A new engineer, human or otherwise, doesn't have to learn which parts of the wiki to trust. They can grep for the parts not to.

6. What stays

Architecture decision records and the changelog stay. They record the past, and the past doesn't drift. They never get marks, because a ✅ in a document about the past would be a claim about the present in the wrong place.

Executable specifications stay, and win where they apply. A doctest or a Gherkin scenario can't drift, because it's a test. Where a statement can be a test, make it a test and drop the mark. Knowledge-driven development is for the rest: things that aren't executable yet, things that are broken, things about people rather than code.

Literate programming was never in the running. It needs its own toolchain, and nobody maintains the prose half.

Everything I deleted was a second description of the system, kept somewhere other than the system and updated by some act other than changing the code. All of it drifted, and the people it was written for stopped reading it.

The ticket had a good run. It just never had a reader who mattered as much as the agent that couldn't see it.

Where it breaks

2026-11-01T00:00:00Z

Knowledge-driven development, part 5: a wrong map is worse than a blank one

Thought September 2026, written October 2026. Processes.

The thing about knowledge-driven development that irritates me most is the marks that don't go away. A ⚠️ or a ❌ is meant to dissipate fast. Mine pile up, and the only reason is that I don't have the token budget to clean my desk.

The list below is short partly because the method is young. I've been running it for a couple of months, not years. It isn't battle-tested yet, and the problems I haven't met yet aren't on it.

1. A wrong mark is worse than no mark

A ✅ next to something nobody ran is a lie that the next reader builds on. That would kill the method, because ✅ is the mark people trust.

A blank map tells you to be careful. A wrong map tells you to walk off the cliff with confidence.

A false ✅ has never bitten me. I don't let the documents and the code drift that far apart, and I'm a stickler for unit tests and branch coverage. The first defense is that ✅ is expensive to write. No build can check a ✅ on a paragraph about how an operator handles a jammed door. Nobody's coverage tool has an opinion about doors.

An agent does, if you ask it. Checking the marks is part of every review: the agent that checks the claims reads the code behind each mark that moved. A wrong mark only gets serious when nobody updates the document, and the re-review is there to make sure that never happens.

So I don't take an old document seriously until it's been checked. When I want to know a partially implemented feature in detail, and the page describing it hasn't been touched in a while, I have an agent give it a once-over against the code first. Then I read it.

2. Marks go stale

Marks don't rot on their own. They go stale the way any document does: the code moves and the page doesn't. With several agents working on parallel branches, the author of a change often doesn't know which pages describe the thing they touched. A stale ⚠️ against a capability that now exists sends the next agent off to build it twice.

There's no need for a mechanical fix. Ask an agent to review the page, on request or on a schedule. Mechanical checks of that kind break anyway.

3. One kind of document isn't enough

"Upgrade to the next framework version" belongs to none of the capability documents. Neither does "the build is slow" or "the test runner leaks file handles". Work that isn't about a capability has no natural place in them.

That's why knowledge-driven development needs more than one type of document: capabilities, features, requirements, architecture, the build, operations, and so forth. The framework upgrade becomes a page in the architecture documents, describing the system on the new version, marked ⚠️ until it's true. The slow build becomes a page describing the build as it should be. Same marks, same greps, same rules.

Adding a type is cheap. An agent reverse-engineers the current state of that area into a knowledge document, and a human reviews it. The real decision is which types are worth having in your system.

4. It doesn't schedule anything

A document says what's missing. It never says when it'll be done or who owns it, and it isn't supposed to.

In an ideal world, I wouldn't schedule anything. I'd throw agent tokens at every ⚠️, and the problems would disappear. In the real world, I schedule them against a meagre token budget. When I do, I create a task in Asana, and the task points at the knowledge document. The task says when. The document says what, and whether it's true yet.

5. Gates, or an agent

A convention maintained by attention decays at the rate attention decays. A few rules earn a build failure. The rule against TODO was written down, and needed one.

When I wrote the specification for the gates, there were seven of them: the coverage cross-check, the test-location gate, the API contract scan, the vocabulary gate, the deferred-work gate, the orphan-⛔ check and the graduation check. One of them existed. The rest were described in the present tense and marked ⚠️, which is to say the enforcement spec was written using the method it enforces.

The missing ones aren't serious. Where a rule has no gate, I ask an agent to check the documents against it, or to do the work the rule was protecting, and it does. If I have the tokens.

A spec nobody maintains is a lie with a schema. A knowledge document nobody maintains is the same lie with a green tick on it. The difference is that you can ask an agent to check this one before you believe it.