2026-08-12
Programming is about altitude. Machine code gave way to assembly, assembly to C, C to Python, and now (so the current version goes) to prompting and context. The leverage work that used to go into hand-tuned macros, lint rules, end-to-end test suites didn't disappear, it just moved to a different substrate.1 The framing goes further: this is simply the next rung on the same ladder that took us from assembly to C.2 On the surface, the two notions are congruent. It has the shape of every abstraction story that came before it, hide more of the machine, work with more of your own intent, repeat.
To me, that's not the right story, or at least not for the reason everyone reaches for. "Higher-level" was never about an objective height to begin with. What counts as simple, familiar, or abstract is relative to the conceptual interests of the person doing the abstracting—meaning the ladder was always somebody's ladder built out of what they already found legible.3 Context engineering isn't a new rung because there's no ladder to add a rung to. It's a schema change, the same leverage work described above, aimed at a different object, legible to a different kind of reader. Schema, not simplification, is what the rest of this is actually about.
This isn't only a theoretical correction since it holds up historically. Compilers and program synthesizers have always shared a goal, generating software from a description of its behavior, but the difference between them was never altitude—it was who supplies the how. A compiler still expects a human to have written a procedure, however abstractly, and just makes the lower-level procedure invisible. A synthesizer starts from a specification of what and searches for a procedure that satisfies it, no human hand required. That's not a smaller step up the same ladder, it's a different axis, and it isn't new. Alan Turing's Intelligent Machinery, written in 1948, already describes searching for a program that fits a specification. Cordell Green formalized program synthesis as a theorem-proving task twenty years later, in 1969; Zohar Manna and Richard Waldinger spent the following two decades building it out into deductive synthesis. The dream of getting behavior without writing the procedure by hand is closer to eighty years old than five.
What's actually new is which mechanism finally made that dream work at scale. Deductive synthesis bet on logic and theorem-proving, and largely stayed slow and narrow, precise only on problems small enough to formally specify. LLMs are making the same bet with a completely different instrument, pattern-matching learned from an enormous corpus instead of proof search, and that instrument generalizes where the old one didn't. So when the leverage work moves, or a new rung gets named, what actually happened is a seventy-year-old axis, sitting orthogonal to the abstraction ladder the whole time, finally got the technique it needed. Nobody moved up. Something else came online.
If the level didn't change, the obvious objection is that the object automated away is exactly the part that used to demand rigor, so lowering it should lower the bar. That objection doesn't hold up well against the practitioners with the least reason to wave it away: one, a decade of production experience in a corner of the industry where correctness is genuinely non-negotiable;4 another, someone who has spent the past several years doing nothing but running and writing about these workflows in public, in detail, daily.5 Neither is arguing that coding is solved. LLMs are much better at augmenting engineers than they are at replacing them, and what gets automated is the mechanical part, not the judgment.6
One prescription for writing code in an AI-assisted codebase is smaller files, strong encapsulation, high cohesion, clear naming, real test coverage—the same virtues that were always good practice, not a relaxed version of them. Writing code that LLMs will understand is not that different from writing code that humans will understand. That's the schema argument stated from inside the practitioner's chair: legibility used to have one reader, and now it has two. A codebase that satisfies both isn't a lower bar than one that satisfied a single human reviewer, it's a stricter one. The failure mode everyone points to, bloated, unreviewable code shipped by someone who never read the diff, isn't evidence the bar dropped. It's what happens when nobody bothered to write for either reader at all. Poor-quality output from an agent isn't an inherent property of the tool, either, it's a choice the engineer made.5
That distinction between good and bad design needs a mechanism, not just an assertion, and this is where a specific framing becomes useful for crystallization.3 It names a Gulf of Envisioning (i.e., the gap between what a user wants and their ability to formulate a prompt that will get it) and proposes closing it with feedforward: previews of a response's anticipated length, the kinds of representations it will include, even a brief look at the model's inner dialogue before it commits to an answer. That's not a metaphor for what a skill file or a CLAUDE.md is doing, it's a literal description of it. Context engineering isn't a vague persistent-knowledge layer; it's feedforward design aimed at a gulf HCI has been naming since long before language models existed.
The paper goes a step further. It describes the system abstracting a goal-model from the user's prompt, then choosing whether to generate a response that aligns with that model or one that deliberately diverges from it, presenting both so the user can reflect on and refine their own goals. That's the schema argument with the metaphor stripped out: the abstraction isn't the model working one level up from code, it's the model constructing a schema of intent and a design decision about whether to confirm or challenge it. It's also why the failure mode, bloat, unreviewable diffs, the burnout that comes from vibe-coding without care, isn't a tax on working at this layer. The paper's own framing is that deliberately designed abstraction is what ends up "augmenting and preserving their cognition and control over the interface." Skip the design and you get exactly what the critics describe. Do it and you get the same thing practitioners keep independently describing from opposite ends of the industry: the same rigor, relocated.
Take the schema framing seriously and the interesting question changes. "How high up are we now" was never the right question, since there was no ladder to measure altitude against, only a series of schemas built for whoever did the building. The question worth asking is whose schema this one is, and who it was built legible for. Feedforward, goal-model transparency, the two-reader craftsmanship described above, these are all answers to that question, not evidence of a rung climbed. Get the schema wrong and you get exactly the failure mode critics reach for: bloated diffs, engineers who can't explain their own code, atrophy dressed up as productivity. Get it right and the same rigor that used to live in a linter or a type system now lives in a skill file instead.
None of this is settled, and it shouldn't read as settled. Turing's version of the idea sat shelved as a schoolboy essay for twenty years before the field caught up to it; the vocabulary for this moment is probably still that far out from being written. What's worth holding onto in the meantime isn't a conclusion, it's the distinction: abstraction was never a height, and mistaking it for one is how a real argument about design gets flattened into a referendum on whether coding is dead. It isn't. It just found a new schema to be precise in.
std::mdspan and the executors work behind std::execution. Now working on Claude Code at Anthropic. ↩