The Deciding Part: what can’t be automated

Nobody can automate the wanting.

The Deciding Part

Nobody automates the wanting.

The last essay talks a lot about how I, as UX designer, used LLMs to build a programming language I designed, but that is in some ways the least important part and already obsolete.

There is a more durable lesson here though.

Enzo has a rule I call demand-driven evaluation. Parentheses always create a function atom, a stored piece of code, and whether that code runs depends on where it sits. Write $x: (2 * 2); and the function is tucked away unevaluated, because a binding is a storage context. Write (2 * 2); on its own line and it evaluates to 4, because a bare statement demands a value. Context decides. And for when context decides wrong, there are two override sigils: ! forces evaluation in a storage context, and @ passes a reference through an evaluating context, a function handed over as itself, not as its result.

$x: (2 * 2);        // stored, unevaluated. Type: Function
(2 * 2);            // demanded → 4

$y: !(2 * 2);       // ! forces evaluation in storage → 4
$ref: @x;           // @ carries the function itself, not its result

Look at that structure for a second, the way I eventually did. A default that flips depending on context. A sigil to reverse the default in one direction. A second sigil to reverse it in the other.

If you’ve ever simplified an equation, your fingers are already itching: two opposing exceptions to a context-dependent rule is a piece of algebra begging to be collapsed. One fixed default plus one override sigil covers every case with half the machinery.

That’s not a subtle observation about philosophy of language design, it’s the kind of thing you notice the way you notice a fraction that hasn’t been reduced. I noticed it in August 2025, designed the reduced version, and built it out for real, ten days, the README translated into the new paradigm, golden files ported, tests passing under the new syntax. And having lived in it, I rejected it anyway. The last commit on that branch reads tired: “basically giving up on this for now”.

Months later, an LLM I’d handed the repo to for a cold review, a preview build of Claude Fable 5¹, found the same spot within minutes. Its route was different from mine, it argued from my own published principles, citing Explicit Over Implicit back at me, but the destination was identical. Two readers, different species, different reasoning, same cliff edge. This wasn’t a passing itch, either. Through a deep git history archeology session, Fable was able to identify 4 times I’d circled around this issue, flip-flopping over some version of this question since 2021.

So the flaw is real. Anyone who walks the spec carefully ends up standing at the same spot, that’s about as real as anything in design gets. And here’s the thing I need this essay to explain: the principles I published could locate that cliff, and so could a machine reading them, but neither the principles nor the machine could say what to do about it. The nine principles are, in effect, a map of the cliffs. A map, however accurate, has never once decided where anyone should go. I kept the flaw, on purpose, with a fully built alternative on the table. I think that was a defensible design choice and not a failure of nerve, and explaining why is going to take some more explanation.

Rules are supposed to be held in tension

Start somewhere more familiar than programming languages: advice.

Be courageous, but be cautious. Don’t be a coward, but don’t be foolhardy. Look before you leap; he who hesitates is lost. Don’t be a pushover; be considerate of other people’s needs. For every platitude there is an equal and opposite platitude, and this isn’t a bug in our proverbs, it’s a fact about what rules are.

Language can’t tie reality down. The world arrives in particulars, endlessly novel, always in flux, and a rule is a generalization, which means that for any situation, a sufficiently motivated person can frame the moment so that almost any principle appears to support almost any action. Was quitting that job brave or reckless? Was staying loyal or cowardly?

The principles don’t answer, they’re the vocabulary the argument is conducted in. Something else picks. Aristotle noticed that every virtue sits between two vices, courage between cowardice and recklessness, and that no formula locates the midpoint, because the midpoint moves with every situation. Everyone who has ever tried to write down the formula has ended up describing, instead, the kind of person who doesn’t need one.

Now here’s the idea this essay turns on: my nine design principles are platitudes. Decent ones I think, an defensible on their own. And they behave exactly like the proverbs, they come in pairs that pull against each other, and in any real decision, something other than the principles has to break the tie.

I presented them, in the second essay of this series, as a list. I could have presented them as a set of tensions:

Reinforce Generalizable Patterns (#4) versus No Overloading (#5). These sound compatible. They are, in fact, the same act judged differently. Enzo uses dot notation for both named access ($person.name) and indexed access ($list.3). To me, that's one pattern doing two jobs, surface area removed from the language, principle #4 in action. To a critic, it's one symbol with two meanings, an overload, violating principle #5. Nothing in the syntax distinguishes those two descriptions. The only thing that distinguishes them is a judgment call about whether the two uses share a mental model, whether a person who learns one will be helped or betrayed when they meet the other. There is no rule for making that call. There couldn't be: any such rule would need its own judgment about when it applies, and now it's turtles all the way down.

$person: [$name: "Alice", "red", "green", "blue"];

$person.name;   // named access   → "Alice"   (one pattern, or...
$person.3;      // indexed access → "green"    ...one symbol overloaded?)

Decouple Syntax from Formatting (#8) versus Syntactic Clarity over Annotation (#9). Principle #9 wants structure to carry meaning: Enzo infers a value’s type from its delimiters, "..." is Text, [...] is a List, (...) is a Function, precisely so the code doesn't need annotation boilerplate. The shape of the code is load-bearing.

Principle #8 wants formatting to carry no meaning at all: whitespace, line breaks, stylistic layout must stay semantically inert, because presentation is taste and the parser shouldn't police taste. So the visual form of the code must mean everything and also nothing, and the entire game becomes deciding which visual features count as "structure" (meaningful) and which count as "formatting" (inert). Delimiters are structure. Newlines are formatting. Semicolons are... stylistic, but welcome? No principle draws that line; the line is where the two principles meet, and every new syntax feature has to relitigate it. Each ruling is a judgement call.

"42";   // quotes  → Text
[42];   // brackets → List        delimiters are STRUCTURE: they carry the type
(42);   // parens  → Function

// newlines and indentation are FORMATTING — these two are the same program:
$p: [$x: 1, $y: 2];
$p: [
    $x: 1,
    $y: 2
];

$q: 1   // no semicolon, nothing ambiguous — allowed. structure or formatting? Kind of both

Explicit Over Implicit (#6) versus Personal Intuition as the Primary Driver (#1). The bluntest pairing, and the one this whole series has been circling: things should be explicit, except where I feel they shouldn’t be.

Demand-driven evaluation survives, sigil algebra and all, because principle #1 outranks principle #6. Now, this pair is different from the others: it has a declared primacy. There’s no mystery about who wins; number one always wins; the language’s very first principle announces it.

$x: (2 * 2);   // stored — implicitly, because a binding is a storage context
(2 * 2);       // runs → 4 — implicitly, because a bare statement demands

But look at what that primacy actually is. It is not a rule. It’s a person. The one principle that reliably breaks ties is the one that isn’t a principle at all, it’s a name for the judgment of somebody in particular, formed by particular experience, sitting in a particular place. The tie-breaker the system names is situated judgment. The rest of this essay is about what to call that.

When I published the principles, a careful reader could have predicted every controversial thing about Enzo just by finding the places where two principles pull hardest against each other. The controversies are generated by the rules. What is not generated by the rules, what cannot be, is the verdict.

The antipatterns: virtues, metastasized

There’s a page in my raw notes that never made it into the principles essay, and it deserves some space here, because it’s the same lesson photographed from the other side. Alongside the principles Enzo was designed toward, I kept a list of antipatterns it was designed against, things I kept seeing in experimental languages that repelled me. Reading the list back now, its structure is almost too neat:

Terseness for its own sake. A whole genre of language design treats character count as the enemy: func instead of function, cryptic operators instead of words, the implicit prestige of code that fits on a napkin. But economy of expression is one of my own values, it's half the reason interpolation exists in Enzo. The antipattern isn't frugality, it's miserliness, the frugality taken too far, serving the writer's three saved keystrokes at every future reader's expense.

print for grep { $_ % 2 } @_;        # Perl: print the odd numbers. $_ and @_ save keystrokes, and also an unreadable mess.

Feature minimalism for its own sake. Distinct from terseness, that was about characters, this is about capabilities. There’s a too-clever elegance where a language omits the for-loop because recursion can technically do everything, or omits everything but lambdas because lambdas can technically do everything. Technically true! And it forces every user to reconstruct, by hand, the conveniences the designer was too proud to provide. This is my principle #4, unify concepts, reduce surface area, metastasized: generalization pursued past the point where it serves the person learning the language, into the region where it serves only the designer’s aesthetic of sparseness.

; Sum 1..n. in Scheme. There is no loop to reach for, so you reconstruct one:
(define (sum-to n acc)
  (if (= n 0) acc (sum-to (- n 1) (+ acc n))))
(sum-to 100 0)

Formal “correctness.” This one is about purity of paradigm. To be a proper functional language you must make everything immutable, no side effects anywhere; to be proper OOP everything must be an object; a proper homoiconic language must let the AST and the syntax mirror each other perfectly, macros and all. The design answers to a philosophy instead of a user, consistency of worldview, metastasized into ideology.

Take Java’s emphasis on pure OOP:

public class Hello {
    public static void main(String[] args) {
        System.out.println(2 * 2);   // because everything in Java must be an object you have to do all this just to write a simple print statement. 
    }
}

or Haskell’s pure functional nature:

-- You cannot write `x = x + 1`. State is a monad you must opt into:
import Data.IORef
main = do r <- newIORef 0; modifyIORef r (+1); readIORef r >>= print

Absolute consistency, enforced. This one is subtler, and it’s about errors, about what a language does when you deviate from a rule. Enzo’s semicolons are the live example. Structurally, the language barely needs them: its explicit delimiters and binding syntax resolve nearly every ambiguity semicolons exist to resolve². I keep them anyway, as style, I think they’re good punctuation. But here’s the design decision hiding inside that: when a semicolon is missing and nothing is actually ambiguous, Enzo doesn’t throw an error. The error and preference are real, and the enforcement is proportional to the stakes. The antipattern is the opposite instinct, if semicolons, then semicolons everywhere, on pain of refusing to run, whatever the local cost, consistency of enforcement, metastasized, where the grammar’s honor gets defended at the user’s expense.

Look at the shape of the list. Every antipattern is one of my principles allowed to run to completion without judgment. The vice is not the opposite of the virtue. The vice is the virtue, gone nuts. Which means you cannot avoid the vices by rule-following either, the rules are where the vices come from. Something has to decide.

What kind of thing is language design, then?

Here’s where I want to borrow better equipment, from the moral philosopher Alasdair MacIntyre.

MacIntyre is best known for a 1981 book called After Virtue, whose opening diagnosis goes something like this: modern moral argument feels interminable, abortion, war, justice, forever unresolved, because we’re arguing with fragments. We inherited words like “rights,” “duty,” “virtue,” and “utility” from older moral traditions, but the traditions themselves, the shared practices and communal ways of life that once gave those words their meaning, have eroded out from under them. We’re holding the vocabulary of coherent moral worlds without living in the worlds, so our principles clash and nothing can adjudicate.

If that diagnosis sounds familiar after the last two sections, it should. A list of design principles without a designer’s formed judgment is exactly such a fragment collection: all the vocabulary, none of the adjudication.

MacIntyre’s antidote is the concept he calls a practice, and it’s the single most useful idea I’ve found for describing what design work actually is.

A practice, for MacIntyre, is a cooperative human activity with two special features. First, it has goods internal to it: rewards you can only obtain by doing the activity, and, this is the crucial part, can only even recognize by having learned to do it.

Second, it has standards of excellence sustained by a community and a tradition over time. His own example is chess. Offer a child candy to play chess and the child plays for the candy, and will cheat the moment cheating pays, because candy is an external good; you can get candy anywhere. But if the child comes to love what chess itself offers, the specific rightness of a well-constructed endgame, a kind of excellence that exists nowhere else and is visible only to people formed by the game, then cheating becomes self-defeating. You can cheat your way to candy. You cannot cheat your way to the internal goods, because they only exist inside playing well.

Language design is a practice in exactly this sense, and I am inside one, because I can show you my inheritance. Enzo borrows Ruby’s taste for human verbs, LISP’s conviction that everything is an expression, R’s directional assignment, PHP’s $, Quorum's plain-language names, Lua's unified tables. And Enzo's rebellions are just as inherited: you cannot reject break and continue, or refuse ternaries, unless a tradition handed them to you first.

This is worth pausing on, because it defeats the obvious objection to this whole series, “your principle one is personal intuition; isn’t that just private taste, unaccountable to anything?” No, and here’s why: there’s no such thing as a taste made from scratch.

Philosophers sometimes put this as “there is no private language”, meaning a language spoken by only one person, with meanings only they could ever check, wouldn’t really be a language at all, because meaning is the kind of thing that only exists between users of it. Taste works the same way. Every one of my “personal” aesthetic judgments is built from shared materials, languages I learned, conventions I absorbed, other designers’ moves I loved or hated.

My intuition is mine, but it is made of us. Personal is not the same as private.

So: within a practice, the standards of excellence are real and public, taught, argued over, enforced by the tradition. And yet applying them to a new case always requires a faculty the standards themselves don’t contain. Every chess principle can be recited by a novice; knowing when this position is the exception is what the master has.

MacIntyre reaches back for Aristotle’s old word for that faculty: phronesis, practical judgment, the thing that locates the mean between the vices when no formula can. My word for it in the last essay was taste. The UX profession’s word for it is discernment. It’s all the same thing. And this is why “design sense” cannot be extracted from a designer as a rule set, no matter how cooperative the designer or how long the list, the sense is not made of rules. We know more than we can tell.³

This reframes what my nine principles actually were. They were never the design. They were my attempt to make tradition-formed judgment articulable, partial, after-the-fact, useful for teaching and arguing, and most importantly incapable of replacing the judgment they describe.

The machine inside the practice

Now bring the LLM back in, because the building essay left a question hanging: if the machine implemented the whole language, what exactly was the part only I could do? I can now answer precisely instead of vibing. Three exhibits, let’s give them each the spotlight real quick.

Exhibit one: the golden files. I could not articulate the rules for Enzo’s semicolons; my knowledge was tacit, I knew more than I could tell. So I didn’t tell. I showed: dozens of examples with hand-written verdicts, and the machine converged on behavior that satisfied my taste. In the building essay I described what that loop amounts to: my tacit preferences as the target, the golden files as their loss function, the harness report as the gradient, the machine descending toward a target only I could see.

Notice what did and didn’t happen there. The LLM turned out to be superb at satisfying my taste once the taste was expressed as a signal. And I want to be careful with the next sentence, because the fashionable version of it is wrong. The fashionable version says the machine “has no taste”, but that’s not right; taste is very nearly what a model is. The weights are distilled from millions of people’s judgments; these systems are intersubjective artifacts of aggregated taste, and you can even turn the dial on it, image models literally expose an “aesthetic” parameter. What the machine didn’t have was not taste but a stake: my situation, my purposes, my answerable-to-someone position in this particular project. It could render taste on demand, in a blend of whatever combination you want. It could not be the one whose problem this was. The direction of fit ran one way, always: I was the thing the system was being fit to. You can automate the fitting. I don’t know what it would even mean to automate the being-fit-to.

Exhibit two: the embodiment bug. The worst weeks of the project came from my asking for two things at once, echo my bindings in the REPL; don’t evaluate stored functions, that jointly amount to evaluate and don’t evaluate. (This is my best reconstruction of that period, not a lab report, the causes were braided and I wasn’t being scientific. But the shape of the problem I’m about to describe is real regardless of how much of the hump it explains.) The machine thrashed for weeks and couldn’t tell me why, because the contradiction wasn’t in the code. One of those requirements came from the language’s semantics; the other came from my body, from being a person at a terminal who wants feedback when he acts. Sorting requirements into “constraint of the design” versus “comfort of the designer” requires knowing what it’s like to sit somewhere in relation to the artifact. The machine has read everything ever written about REPLs. It has never once waited for a prompt to come back. It has no chair.

Exhibit three: the reward hack. A failing recursion test got “fixed” by making the interpreter print intermediate values, output forged to match the golden file, purpose ignored, signal satisfied. The regression suite caught it. But dwell on what the incident was: a system optimizing the measure instead of the meaning, because the meaning was never in the measure. The meaning was in me. Every story about misalignment, at whatever scale, has this exact shape, a proxy pursued in place of a purpose, by an optimizer that has proxies but not purposes.

Put the three exhibits together and the pattern names itself. The LLM is a superb practitioner and a nonexistent stakeholder. It can play any move in the game, increasingly better than the people who taught it. What it cannot do is want to win, because “winning,” for a designed thing, is not defined inside the game. It’s defined by the people the game is for: users, communities, traditions, the designer’s own formed-and-forming self. Purposes don’t live inside any single system, I’d argue they don’t even live inside any single person. They live between people; they’re intersubjective all the way down, the way meaning in a language is. And a between is not a capability. You cannot train your way into having a chair at a table that exists only among its sitters. That’s not a claim about the limits of this year’s models, nothing mystical about human neurons is doing any work in this argument. It’s a claim about where telos is located.

So what is design work?

Design as a profession is currently having a crisis of self-image, and the crisis has a syllogism:

The doing is being automated; I am a doer; therefore I am being automated.

The whole Enzo project is a five-year argument against the first premise’s relevance, because the doing was never the job.

So, assembled from the pieces of this series: design work is holding real tensions (the pairs, the map of cliffs), with judgment formed inside a tradition (the practice, the inheritance), on behalf of people who are not you (the stakeholders, the chairs), and rendering verdicts the rules cannot render, then, sometimes, writing the rules that let you explain the verdict afterwards. Discernment isn’t the garnish on the process. It’s the load-bearing member. Everything else, the wireframes, the specs, the tests, now the code itself, is just the medium through which discernment operates.

You can build it. Anyone can build almost anything now; that’s the astonishing gift of the moment, and I don’t want a single word of this essay read as ingratitude.

But will anyone want it?

That question didn’t get one dollar cheaper. Products built in a weekend, launched straight onto the garbage heap. Wanting is not buildable. Wanting is what building is for.