aplflow

AI agents made writing code nearly free. That moved the bottleneck to verifying it, so I built a notation layer where a 60-year-old executable notation is the spec, the interpreter is an independent judge, and the coding agent is just the compiler.

Overview

The idea started as a worse idea and got better by being cut down. My first version was “revive APL as a language for the AI era.” Then I watched Guido van Rossum take questions at a meetup here in Amsterdam, and one aside stuck with me more than anything else he said that night: in his view a programming language is 80 percent community. That ratio kills the naive plan outright. No amount of good design buys the other 80 percent for a solo consultant; languages live or die on the people who show up, and that cannot be willed into existence by one person and a coding agent.

What survived was narrower and more useful. Ken Iverson published APL in 1962 as a notation, not runnable software, for describing operations on whole arrays of data to a human reader; it took IBM four years to build an interpreter for it. For most of APL’s history, the gap between a notation that describes an algorithm and software that executes it was expensive to cross, which is most of why APL never became anyone’s daily language. AI coding agents are now a cheap bridge across exactly that gap. So the question stopped being whether APL should come back as a language, and became something narrower: does a terse, unambiguous, executable notation sitting above a real codebase have a job to do once an agent is willing to expand it into working code.

A friend of mine supplied the other half, unprompted, weeks later in a different conversation: coding got nearly free once agents took it over, so could an agent write the verification too. We joked about calling that “vibe verification,” then noticed the joke was not actually a joke. If one agent writes the implementation and a second agent writes the tests, and both start from the same ambiguous English prompt, they can inherit the exact same misunderstanding. Two agents confirming each other’s bug is not verification, it is correlated failure wearing a green checkmark. Verification only means something when the oracle is independent of the thing it is checking, and unambiguous about what “correct” means; English gives you neither. Executable notation gives you both: a human writes a few lines of APL as intent, an interpreter runs those lines as ground truth with decades-settled semantics, and an agent expands the same intent into production code in whatever language the team actually ships. Agreement across randomized inputs is real evidence. Disagreement is a caught bug, not a green checkmark papering over one.

Notation as spec, interpreter as judge, agent as compiler.

Technical

The public site at aplflow.dev is the whole deliverable: plain HTML, one stylesheet, no build step, no framework, in keeping with the project’s own argument that a good idea does not need much machinery to prove itself.

• index.html states the pitch in one screen.
• essay.html carries the full argument (the origin story above, expanded, with sources cited).
• demo.html walks the loop end to end on a real example, including a bug an agent’s plausible-looking first attempt ships and the notation catches.
• notation.html documents the working APL subset in use (standard Dyalog semantics, no invented glyphs), with a reference table and supporting artifacts: printable keyboard overlays and the APL385 typeface.
• site/kit/aplflow-agent-kit.md is the reference document that makes a coding agent fluent in this notation subset. The notation renders and tokenizes poorly in most models’ training data, so this gets pasted into a CLAUDE.md or Cursor rules file before asking any agent to read or write APL against the project; it works far better with the rules in front of it than from memory.
• roadmap.html lays out what is deliberately built versus deliberately deferred, and why.
• scripts/ handles the operational side: SSH access to the box that serves the site, matching the DNS pattern used across the consultancy’s other domains.

Why You Should Care

The correlated-failure problem this addresses is not hypothetical. It is the default outcome of a workflow a lot of teams are already running: one ambiguous prompt, two agents, one for the code and one for the tests, with no reason to expect their blind spots to differ. Catching that requires an oracle that never read the prompt in the first place, and an executable notation with 60 years of settled semantics is about as independent and unambiguous as an oracle gets.

The trunk is finished by design: an essay, a worked demo, a notation reference, and an agent-fluency kit, and nothing else. No roadmap theater, no issue tracker, no maintainer treadmill. That is deliberate, not a placeholder for a bigger effort that ran out of time. Guido’s 80 percent number is exactly why: a language needs an army it cannot get by design, but an idea only needs to be right and demonstrated, and then it just sits there being right whether or not anyone ever builds the army. I would rather ship one argument all the way to finished than run a language project I already know cannot get the community it would need.

Status

Live at aplflow.dev. The essay, the demo, the notation reference, and the agent-fluency kit are complete and published. Scoped deliberately as a finished argument rather than an ongoing maintenance project; the highest-value next step, a runnable notebook that turns the demo’s hand-walkthrough into a live comparison harness, is documented in the roadmap but intentionally not built.

Site: https://aplflow.dev