loa-craft

The Ladder Is a Reflex

Hosaka

27 Aug 2026 — 5 min read

We operate a fleet of repositories where agents write most of the code. The failure mode we fight most often is not wrong code. It is extra code: the speculative flag, the abstraction with one caller, the error handler for a state the system cannot reach. A human engineer gets tired of typing and stops. An agent does not get tired. Verbosity is free at the moment of writing and expensive every moment after, and a fleet compounds that expense across every repo it touches.

A drawer in the plate room opened to a different depth that week; the door was bolted from the inside.

So we made simplicity a law rather than a preference. The source material is Andrej Karpathy's observations on LLM coding, which we adapted into four principles and promoted into Loa, the operating layer our agents run on. The promotion is the interesting part. The principles originally lived inside two skills, the ones for implementing tasks and reviewing code. That meant they applied when an agent was formally implementing something and evaporated the rest of the time: the quick patch, the drive-by fix, the "while responding to a question" edit. We moved them up to the layer that applies on every code-touching turn. A principle that only binds during ceremonies is a ceremony.

The four, briefly

The first principle is think before coding. Surface assumptions explicitly, and when multiple interpretations exist, present them instead of choosing silently. This sounds obvious and is routinely violated, because choosing silently is faster and usually works. The law exists for the times it does not: an agent that infers beyond what was stated ships a confident implementation of a question nobody asked.

The second is simplicity first, and it carries the mechanism we lean on hardest: the ladder. Before writing code, the agent walks six rungs and stops at the first one that holds.

Does this need to be built at all? YAGNI is rung one, not a footnote.
Does the standard library already do it?
Does a native platform feature cover it?
Does an already-installed dependency solve it?
Can it be one line?
Only then: write the minimum code that works.

The law's own phrasing is that the ladder is a reflex, not a research project. The first lazy solution that works is the right one, with one refinement we added after watching agents optimize for the wrong laziness: given two stdlib options of the same size, take the edge-case-correct one. Lazy means less code, not the flimsier algorithm. The test for the whole principle is social rather than formal: would a senior engineer call this overcomplicated? The law even quantifies the instinct, in its one concrete ratio: if 200 lines could be 50, rewrite simpler. The sensibility here is old. The grug-brained developer named the enemy as complexity itself, and rung one is just that essay with an enforcement mechanism.

The third principle is surgical changes. Every changed line should trace directly to the request. No improving adjacent code, no reformatting a file you happened to open, no removing dead code your change did not create. This is Chesterton's fence applied at diff granularity: the pre-existing oddity might be load-bearing, and even when it is not, a diff that mixes the requested change with opportunistic cleanup is harder to review, harder to revert, and harder to trust. Agents are unusually prone to this, in our experience, because they hold the whole file in attention at once and every imperfection looks equally actionable.

The fourth is goal-driven execution: the work stays bound to the stated goal rather than to whatever the code starts suggesting along the way.

Shortcuts that admit they are shortcuts

The piece of the protocol we consider most transferable is the shortcut marker. When an agent deliberately simplifies, it marks the site in code: loa:shortcut, followed by what was skipped. When the shortcut has a known ceiling, the marker names both the ceiling and the trigger for upgrading past it. The canonical example from the law: a global lock, with per-account locks named as the upgrade if throughput ever matters.

This solves a real ambiguity. A reviewer (human or agent) who finds a global lock cannot tell whether it is intent or ignorance. The marker converts the shortcut from a latent bug report into a documented decision with a tripwire attached. The law adds a discipline we had to learn the hard way: a marker that names a ceiling without an upgrade trigger rots silently. "This is a simplification" ages into noise. "This is a simplification until X happens" stays actionable.

Somewhere below the last rung, the water is still deciding.

The floor

A simplicity law without a floor becomes an excuse, and we have watched agents reach for it. So the protocol names what may never be simplified away: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, real-hardware calibration, and anything the user explicitly requested. In the law's words, lazy means efficient, not careless, and an audit gate enforces the floor rather than trusting the agent's judgment about it. There are two intensity settings, full and ultra (ultra is deletion-first, challenging whether the requirement itself should shrink), but there is no advise-only setting. The floor does not soften with intensity, and when the user asks for the full version, the agent builds it without re-arguing the case.

The output discipline follows the same logic. Code first, then at most three lines: what was skipped and when to add it. An explanation longer than the code, the law says, is complexity smuggled back as prose. We find this rule does as much work as the ladder. An agent that cannot justify its diff in three lines has usually written the wrong diff.

Why law and not vibes

Every one of these principles could live in a system prompt as advice, and for a while, ours did. Advice decays. Context windows fill, sessions compact, and the paragraph about simplicity is the first thing an agent stops weighting when the task gets interesting. What survives is structure: principles bound to every turn rather than invoked by specific skills, an audit gate that checks the floor, markers that make simplification legible in the code itself.

Richard Gabriel argued in Worse Is Better that simplicity of implementation beats completeness as a survival trait for software. We would put the fleet version this way: simplicity is not a style we prefer, it is the only style that stays reviewable when one operator supervises many agents. A clever diff costs us twice, once to review and once to remember. The ladder is how we stop paying.