Ongoing · Medium Priority
Machine-First Languages
A research thesis, sourced and stress-tested from primary talks and experiments, arguing that once code-writing is free, we should design programming languages for machines to write correctly — not for humans to write comfortably.
The problem
Every programming language in use today was designed around a constraint that’s quietly dissolving: that a human has to be the one typing the code. That constraint is why languages tolerate ambiguity, ship escape hatches like `any` and `unknown`, and let footguns like TypeScript’s string-coercing sort slip through — those are all compromises made to keep human authors productive, not because they’re the safest possible design. Once an agent is doing most of the writing, the tradeoff that justified those compromises stops applying, but almost nobody has gone back and re-derived language design from scratch with that premise removed.
At company scale this isn’t an academic question. Teams adopting agentic coding are pouring agent output through languages and type systems built to protect human patience, and inheriting all of the silent-failure surface that comes with them — except now nobody is reading every line to catch it. The mismatch between “language designed for human ergonomics” and “code that’s mostly agent-authored” becomes a real source of production bugs, not just an inefficiency.
The approach
This isn’t a piece of software — it’s a working research file: a project folder with a manifest, a running set of dated ideas, and a references log tying each idea back to its source (talks by Benoit Schillings at Google DeepMind, a WorkOS Demo Night talk from Boundary/BAML, an AI Engineer talk on “fighting slop with slop,” and Zero, a real agent-first language experiment). Each idea entry is written as a self-contained claim with its source citation and a link back to the original talk or page, so the thesis stays falsifiable and traceable rather than becoming a vague opinion.
The thesis itself has concrete texture, not just a slogan. It covers: why productivity-vs-correctness tradeoffs (TypeScript’s `any`/`unknown` escape hatches) made sense for humans and stop making sense for agents; the counterintuitive finding that maximally-readable code is often also the most agent-legible code, because legibility reduces ambiguity for both readers; BAML’s approach of inferring error types transitively through the compiler so an agent can’t silently swallow an exception class; and Zero’s more radical move — making a compiler-owned semantic graph (with stable node IDs, typed edges, and per-write hash verification borrowed from optimistic concurrency control) the actual source of truth, with human-readable `.0` files generated as a projection rather than the input. That last idea — invert what’s primary and what’s derived — is the one with the most legs: it generalizes past programming languages to any place a human-readable text file (configs, prompts, specs) is also the thing an agent edits.
What I learned
The clearest thing that came out of tracking these sources side by side is that “optimize for the agent” doesn’t mean “optimize away human readability” — in several of these talks it means the opposite. Readability and machine-parseability turn out to be the same axis more often than intuition suggests: structure that helps a human review code (explicit types, unambiguous naming, no clever control flow) is exactly the structure that shrinks the space an agent has to reason over. The genuinely radical move isn’t “make it less readable,” it’s “make the readable version a derived artifact instead of the source of truth” — that’s a much sharper and more defensible claim than the raw thesis title suggests, and I wouldn’t have landed on it without pulling apart four independent sources instead of trusting the first framing.
Where this could go
The next step on my list is to move this from a synthesized reading list to something I can actually test — a small toy language or IR with the Zero-style graph-as-source-of-truth property, tried against a real agent coding loop, to see whether the round-trip savings the thesis predicts actually materialize versus text-diff-and-reparse.
The bigger opportunity is organizational, not just linguistic. Any company standardizing on agentic coding is implicitly choosing a representation layer for agent-machine communication, and most are choosing it by default (whatever language the team already writes) rather than by design. The optimistic-concurrency-control pattern from Zero — hash-guarded writes to a shared program state — is directly reusable as a pattern for any internal tool where agents and humans edit the same structured artifact concurrently: config stores, infra-as-code, even shared documents. Teams building internal agent platforms should be asking the same question this research thread asks about languages: is the thing our agents edit optimized for an agent’s failure modes, or just inherited from what humans happened to build first.
Takeaway
This is early-stage research, not a shipped tool — but the underlying bet (representation design should follow from who’s actually doing the writing) is one I expect to keep testing against real systems, not just talks.
Text summarized and optimized using Anthropic’s models and reviewed by a human.