It's a local proxy (npx @sliday/tamp) that sits between your coding agent (Claude Code, Aider, Cursor, Cline, etc.) and the upstream API. It compresses tool result blocks — JSON minification, TOON columnar encoding for arrays, line-number prefix stripping, whitespace normalization, and optional LLMLingua-2 neural compression — achieving ~52.6% fewer input tokens with zero behavior change.
Fair point on COBOL—I oversimplified. Programming languages exist for precision and execution, not because machines can't parse English. That framing was sloppy.
But I push back on "the entire premise is wrong."
The interesting part isn't "AI can execute pseudocode"—nobody debates that. The point is the artifact: the .md output matters, not the runtime. A codebase where every function is readable English changes who can participate in a pull request, audit logic, or catch wrong assumptions. "Multiply by 9/5" vs "multiply by 1.8" is an editorial conversation, not a code review.
It's a proof of concept to show the artifact is executable, not a production proposal. It's slow (today), expensive, and non-deterministic - I said so in the post. The question is whether the intermediate representation (English) has value beyond performance? I believe that the loop is shortened here: there're no in-between element intent→weird non-human language→result, it becomes intent→result. No NEED to create synthetic procedures, explaining how the code works in plain language should give us the output.
An old person enters a bank, asks to open an account, speaks plainly in his native language, the teller clicks buttons, and the account is created. From the subjective perspective, there's no in-between interface: the old person had a though, than it got realized.