Before: the human reasoned about syntax; the compiler enforced it. Now: the human reasons about meaning; the coding agent interprets it.</title> </marker> </defs> Before</text> Human</text> reasons about</text> </g> Syntax</text> enforced by</text> </g> Compiler</text> that makes it work</text> </g> Now</text> Human</text> reasons about</text> </g> Meaning</text> interpreted by</text> </g> Coding Agent</text> that makes it work</text> </g> </svg> </div> </section>

06
The unexpected consequence</h2>
I thought AI would make me write software faster.
Instead, it made me start projects I would never have started before. 
The biggest change was not productivity. The biggest change was willingness. </div> </section>

07
What happened next</h2>

March 2026 · San Francisco
Co-presented an AI Web Security tool at RSAC 2026 with Milan Duric. Same trip: a private downtown dinner hosted by Maverick Capital, room of AI Platform leaders. </li>
Spring 2026
Shipped a Temporal-based self-service that lets users order web-service resources while AI quietly handles the operational work. Role at the time: Senior Platform Engineer & Solution Architect, Web Security / Application Delivery. </li>
Two weeks ago
New role: Enterprise Solution Architect for Group-wide AI Platform and AI-assisted development. </li>
Last week
Joined J floor</a>. More talks already on the calendar. </li> </ol>
None of this was on my calendar a year ago. </div> </section>

Thank you
The most important thing Claude Code gave me was not faster software development. It gave me the ability to turn years of accumulated ideas into working systems before I lost interest in them. 
raskell.io </a>
Tools: How Agents Actually Do Things

Unknown — Tue, 09 Jun 2026 00:00:00 +0000

Part 3 of The Agent Platform Handbook. From Loop to Platform. Previous: Your Agent Wants Root</a>. Next: Context Is the Product. </blockquote>
In post one</a> we built the agent harness: a loop, a one-tool registry, a system prompt, a dispatcher, an iteration budget. In post two</a> we slid a sandboxed runtime under the shell tool without touching the loop. The harness stands today at tag post-02</code></a> of the-agent-platform-handbook</code></a>: four files, one tool, fenced. The loop works. The runtime is fenced. The agent is still mostly useless, because one tool means the model can either run a shell command or do nothing. Every real agent has a toolbox.
This is the toolbox post. We will extend the same harness with three more tools (fs_read</code>, http_get</code>, git</code>), promote the one-tool registry into a real one, handle parallel tool calls, and look at the failure modes that show up the first time the model has more than one thing to pick from. The diff lands as tag post-03</code></a> in the same repo. The agent loop’s overall shape, the system prompt structure, and the iteration budget do not change.
The interesting work in this post is not the tools themselves. It is the registry, the schemas, and the contract between what the model sees and what your code runs. Get those right and adding a fifth tool is a one-file change. Get them wrong and you will spend the next quarter retraining users on a registry the model cannot navigate.
How we got here</h2> For about a year, the way you let a language model call a function was to ask it nicely. The ReAct paper in October 2022 sketched the loop in pseudocode. The first implementations, including the early LangChain releases that month, made it real by parsing the model’s prose output. You instructed the model to write Action: search</code> on one line, Action Input: "what is X"</code> on the next, then stopped generation on a token like Observation:</code> and used the rest of the lines verbatim. It worked. It also broke whenever the model felt creative, whenever the user’s question contained the stop token, whenever the prompt accidentally taught the model a slightly different format. Then on June 13, 2023, OpenAI shipped function calling. You declared your tools with a JSON Schema. The model returned a structured object with name</code> and arguments</code>. No more parsing prose. No more stop tokens. The reliability gap between “this works in the demo” and “this works on Tuesday morning” closed by an order of magnitude in a single release. Anthropic shipped tool_use</code> shortly after on the same shape, and structured outputs (constrained decoding that guarantees the model emits valid JSON for a given schema) followed in late 2024. The Model Context Protocol, also from Anthropic, arrived in November 2024 and added a transport layer for tools so they could live in a separate process or a separate machine. The calling convention did not change. MCP just gave the registry a network. We will spend post eight</a> on MCP specifically. The lesson from this lineage is one sentence. The model talks JSON now. The work that remains is the work you control: the registry, the schemas, the contract for what happens after the call. That is what this post is about. The mental model</h2> A tool layer has three pieces. The model picks. The registry resolves. The handler runs. +-------------------+ | Model | | "I want to call | | fs_read with | | path=/etc/hosts" | +---------+---------+ | | tool_use block v +-------------------+ schema list | Tool registry | <----- the model sees | name -> handler | +---------+---------+ | | dispatch v +-------------------+ | Handler | | side effect runs | | (in the sandbox) | +---------+---------+ | | { ok, value | error } v +-------------------+ | tool_result | ---> back into context +-------------------+</code></pre> What the model sees and what the handler runs are decoupled. The model sees a name, a description, and a JSON schema for inputs. The handler sees parsed arguments and returns a result string. The registry is the seam. Every tool engineering decision in this post is about that seam. Build the registry</h2> Post two</a> left the harness with a single Tool</code> type in types.ts</code> and one implementation in tools.ts</code>. Three additions turn that into a real registry: a tagged-union ToolResult</code> so errors flow as data and not exceptions, a max_output_bytes</code> field so a 50 MB log file does not blow the context window, and a new registry.ts</code> so the loop does not care how many tools exist. We also reorganize the tools onto their own subdirectory now that there is more than one of them. The post-03 tree looks like this. the-agent-platform-handbook/ ├── agent.ts # loop and dispatch (rewritten) ├── registry.ts # new ├── types.ts # +ToolResult, +max_output_bytes └── tools/ ├── shell.ts # moved from ./tools.ts, returns ToolResult ├── fs.ts # new ├── http.ts # new └── git.ts # new </code></pre> Two changes in types.ts</code> versus post-02</code>. // types.ts export type ToolResult = | { ok: true; value: string } | { ok: false; error: string }; export type Tool = { name: string; description: string; input_schema: { type: "object"; properties: Record<string, unknown>; required?: string[]; }; max_output_bytes?: number; run: (input: Record<string, unknown>) => Promise<ToolResult>; }; </code></pre> ToolResult</code> is a tagged union. Tools never throw to the loop. They return { ok: false, error }</code> when the side effect fails or the input is wrong. This matters because the model needs to read the failure and decide what to do next. An exception kills the loop. A returned error gives the model a chance to retry, switch tools, or report back to the user. max_output_bytes</code> is the per-tool truncation cap. The default is small. A shell</code> tool that runs cat /var/log/syslog</code> should not return three megabytes of text into a context window that costs you per token. The registry itself is tiny. // registry.ts import type { Tool, ToolResult } from "./types"; export class Registry { private readonly tools = new Map<string, Tool>(); register(tool: Tool): this { if (this.tools.has(tool.name)) { throw new Error(`duplicate tool: ${tool.name}`); } this.tools.set(tool.name, tool); return this; } schemas() { return Array.from(this.tools.values()).map(({ run, ...t }) => t); } async dispatch(name: string, input: Record<string, unknown>): Promise<ToolResult> { const tool = this.tools.get(name); if (!tool) return { ok: false, error: `unknown tool: ${name}` }; try { const result = await tool.run(input); return cap(result, tool.max_output_bytes ?? 8192); } catch (err) { return { ok: false, error: `tool threw: ${String(err)}` }; } } } function cap(result: ToolResult, max: number): ToolResult { if (!result.ok) return result; const bytes = Buffer.byteLength(result.value, "utf8"); if (bytes <= max) return result; const head = result.value.slice(0, max); return { ok: true, value: `${head}\n\n[truncated: ${bytes - max} more bytes]` }; } </code></pre> The registry holds tools, hands the model the schema view (without the handler), dispatches by name, caps output, and turns any thrown exception into a returned error. Forty lines. Done. Four tools</h2> Now the actual toolbox. The shapes are deliberate, and so are the descriptions. // tools/fs.ts import type { Tool } from "../types"; export const fs_read: Tool = { name: "fs_read", description: "Read a UTF-8 text file from the local filesystem and return its contents. " + "Fails if the path does not exist, is not a regular file, is not valid UTF-8, " + "or exceeds 1 MB. Use this for source files, configs, and logs.", input_schema: { type: "object", properties: { path: { type: "string", description: "Absolute or relative path to the file." }, }, required: ["path"], }, max_output_bytes: 1024 * 1024, run: async ({ path }) => { try { const file = Bun.file(String(path)); const exists = await file.exists(); if (!exists) return { ok: false, error: `no such file: ${path}` }; if (file.size > 1024 * 1024) return { ok: false, error: `file too large: ${file.size} bytes` }; const text = await file.text(); return { ok: true, value: text }; } catch (err) { return { ok: false, error: String(err) }; } }, }; </code></pre> Notice the description. It tells the model what the tool does, when it fails, and when to choose it (“Use this for source files, configs, and logs”). The model’s tool-selection is a function of these strings. Vague descriptions produce vague selection. Boring, specific descriptions produce reliable selection. // tools/http.ts export const http_get: Tool = { name: "http_get", description: "Perform an HTTP GET request and return the response body as text. " + "Times out after 10 seconds. Returns the status code in the result. " + "Use this to fetch public documentation, API responses, or web pages. " + "Do not use it to interact with internal services.", input_schema: { type: "object", properties: { url: { type: "string", description: "Absolute https:// URL." }, }, required: ["url"], }, max_output_bytes: 64 * 1024, run: async ({ url }) => { const u = String(url); if (!u.startsWith("https://")) return { ok: false, error: "only https:// is allowed" }; try { const ctl = AbortSignal.timeout(10_000); const res = await fetch(u, { signal: ctl }); const body = await res.text(); return { ok: true, value: `status: ${res.status}\n\n${body}` }; } catch (err) { return { ok: false, error: String(err) }; } }, }; </code></pre> Two design choices to call out. The tool enforces https://</code> at the handler level even though the description says so, because the model will sometimes call it with http://</code> anyway. The status code is folded into the value, not into a separate field, because the model reads strings. // tools/git.ts export const git: Tool = { name: "git", description: "Run a read-only git command in the current repository and return its output. " + "Allowed subcommands: log, diff, show, status, branch, ls-files. " + "Any other subcommand is rejected. Use this to inspect history, " + "see uncommitted changes, or list tracked files.", input_schema: { type: "object", properties: { args: { type: "array", items: { type: "string" }, description: "Arguments after `git`, e.g. ['log', '--oneline', '-5'].", }, }, required: ["args"], }, max_output_bytes: 32 * 1024, run: async ({ args }) => { const a = (args as string[]) ?? []; const allowed = new Set(["log", "diff", "show", "status", "branch", "ls-files"]); if (a.length === 0 || !allowed.has(a[0])) { return { ok: false, error: `subcommand not allowed: ${a[0] ?? "(none)"}` }; } const proc = Bun.spawn(["git", ...a.map(String)], { stdout: "pipe", stderr: "pipe" }); const [stdout, stderr] = await Promise.all([ new Response(proc.stdout).text(), new Response(proc.stderr).text(), ]); const code = await proc.exited; if (code !== 0) return { ok: false, error: stderr || `git exited ${code}` }; return { ok: true, value: stdout }; }, }; </code></pre> The git</code> tool is interesting because it shows the allow-list pattern. The model can ask git push --force</code> if it wants to. The handler refuses, returns a clear error, and the model goes back to the drawing board. The allow-list lives in the handler, not in the description, because trusting the model to obey natural-language constraints is exactly the trap post two</a> was about. The shell</code> tool from post-02</code> moves to tools/shell.ts</code> and gets the same envelope refactor as the new tools: its run</code> now returns ToolResult</code> instead of a raw string. The sandbox flags and the executed command stay exactly as they were. Four tools, registered: // agent.ts import { Registry } from "./registry"; import { fs_read } from "./tools/fs"; import { http_get } from "./tools/http"; import { git } from "./tools/git"; import { shell } from "./tools/shell"; const tools = new Registry() .register(shell) .register(fs_read) .register(http_get) .register(git); </code></pre> The loop changes a little</h2> Modern frontier models can ask for several tools in a single turn. Treat them as parallel calls and you save round trips. Treat them as sequential and the model will figure it out, but slowly. // agent.ts (continued) const response = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 4096, system: SYSTEM_PROMPT, tools: tools.schemas(), messages, }); messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { // ... print final answer, return } const calls = response.content.filter((b) => b.type === "tool_use"); const results = await Promise.all( calls.map(async (block) => { const result = await tools.dispatch(block.name, block.input as Record<string, unknown>); console.error(`> ${block.name} ${JSON.stringify(block.input)} -> ${result.ok ? "ok" : "err"}`); return { type: "tool_result" as const, tool_use_id: block.id, content: result.ok ? result.value : result.error, is_error: !result.ok, }; }), ); messages.push({ role: "user", content: results }); </code></pre> Two changes versus the post-02</code> dispatch. The loop runs all tool calls from a single turn in parallel with Promise.all</code>. The is_error</code> flag now gets set when the result was an error, because the model uses it to decide whether to retry or change strategy. The rest of the work — unknown-tool handling, exception wrapping, output capping — moved into the registry, so the agent.ts dispatch shrinks from roughly twenty-five lines to ten. A short transcript shows the difference. $ bun agent.ts "summarize the largest TypeScript file under src and tell me what changed in the last commit" > fs_read {"path":"src/agent.ts"} -> ok > git {"args":["log","-1","--stat"]} -> ok src/agent.ts (185 lines) implements the agent loop against the Anthropic Messages API. It builds a registry of four tools (shell, fs_read, http_get, git), dispatches tool_use blocks in parallel, and stops when the model returns an end_turn response or hits the 10-iteration budget. The last commit added the parallel-dispatch path and a small output truncation helper; net 38 lines added across agent.ts and registry.ts. </code></pre> One turn. Two tool calls. They ran simultaneously. The model fused the results into a single answer. Designing tools that the model can actually use</h2> After you have built the registry, the failure mode that bites you is not the code. It is the design. Three patterns that hold up. One tool per concept. A fs</code> tool with a union input schema (mode: "read" | "list" | "stat"</code>) reads cleaner to a human and worse to a model. The model has to pick the right mode</code> and the right arguments simultaneously. Split it: fs_read</code>, fs_list</code>, fs_stat</code>. Three tools, three clear pictures. The model picks better and the schemas are simpler. Descriptions are written for the model. The description is the only place the model learns when to use a tool. Be specific about inputs, outputs, error cases, and use cases. “Read a file” picks worse than the fs_read</code> description above. The cost of the extra eighty tokens per turn is rounding error against the cost of the model picking the wrong tool and looping. Errors are data. Every tool returns { ok, error }</code> rather than throwing. The model can read the error, reason about it, and choose: retry with different inputs, switch tools, or surface the failure to the user. An exception removes all of that. The honest version of the tradeoff is in the table. Decision</th> Cheap option</th> Right option</th> Why</th></tr></thead> Tool granularity</td> one tool with a mode</code></td> one tool per concept</td> Better selection, simpler schemas, simpler errors.</td></tr> Description</td> one sentence</td> inputs, errors, when-to-use, in prose</td> The model picks from the string.</td></tr> Error model</td> throw exceptions</td> tagged-union ToolResult</code> always</td> The model can recover. Exceptions kill the loop.</td></tr> Output size</td> return whatever the OS gives</td> cap per tool, truncate with a marker</td> Context windows are not log files.</td></tr> Side effects</td> run, hope, retry on error</td> idempotency keys or confirm</code> argument</td> Retries are real. Re-deletes are real.</td></tr> Parallel calls</td> serial loop</td> Promise.all</code> over tool_use blocks</td> Modern models batch. Latency drops by ~Nx.</td></tr> Sensitive ops</td> “do not delete files” in prompt</td> allow-list in the handler</td> The model will eventually try anyway.</td></tr> </tbody></table> Failure modes worth naming</h2> The first time you hit any of these you will think your code is broken. It is not. These are tool-layer problems specifically. Tool sprawl. Beyond roughly twenty tools, models start picking poorly. Domains blur. Two tools with similar descriptions get confused. The fix is not “better descriptions.” It is fewer tools at any given turn, achieved by routing or by giving different sub-agents different toolboxes. We will come back to this in post twelve</a>.</li> Description rot. A tool’s behavior changes (faster timeout, new error mode, narrower input). The description does not. The model keeps picking it for the old reasons. Treat descriptions as part of the API surface. Version them.</li> Argument hallucination. The model passes path: "the file the user mentioned"</code> instead of an actual path because it lost track of the conversation. Strict schemas help. Server-side validation of plausible inputs (file exists, URL parses) helps more.</li> Hallucinated tools. The model invents a tool name that is not in the registry. The registry returns unknown tool: X</code> as an error. The model reads it and either retries with a real tool or apologizes. Both are correct behaviors. The bug would be silently dispatching to a default handler.</li> Output explosion. A cat large_file</code> or a curl massive_api</code> blows the context window. The per-tool cap above handles it. Without a cap, you discover the problem at a token-cost billing alert.</li> Side effects on retry. The model calls a tool, the call hangs, the loop retries, the tool runs twice. For idempotent reads, this is fine. For git push</code>, email_send</code>, or database_write</code>, it is not. Idempotency keys or explicit confirm: true</code> arguments are the only durable fixes.</li> Concurrent races. Parallel tool calls can step on each other. Two fs_write</code> calls to the same path in one turn is the classic example. The agent will not notice. You will, in production. The fix is per-tool serialization or explicit no-parallel marking in the dispatcher.</li> Auth surfaces in errors. A tool that calls an internal API may put a bearer token in its error message when the request fails. That error becomes part of the conversation and gets sent back to the model on the next turn. Strip secrets from error strings at the handler.</li> </ul> What this layer does not solve</h2> This is the tool layer. It is not the context layer, the memory layer, or the identity layer. Things you might expect this post to cover that get a dedicated post later. Where the tool definitions live. Hardcoded into the agent works at the demo scale. Real fleets need a shared registry. That is MCP. Post eight</a>.</li> Which tools an agent should know about for a given task. The registry above gives every tool to every turn. Per-task filtering and tool discovery are part of the context strategy. Post four</a> and post five</a>.</li> Which agent gets which tools. Different sub-agents need different toolboxes. The dispatch problem is the multi-agent problem. Post ten</a> and post twelve</a>.</li> Who is allowed to call which tool. Per-tool RBAC, capability tokens, human-in-the-loop approvals. Post fourteen</a>.</li> Identity for the call itself. When the http_get</code> tool calls an internal service, the service needs to know who is asking. Post thirteen</a>.</li> </ul> Where this lands in the platform</h2> Total damage going from post-02</code> to post-03</code>: one new file (registry.ts</code>), one new directory (tools/</code>) with four files, two extensions to types.ts</code>, a rewritten agent.ts</code> dispatch, and a one-line tsconfig.json</code> update so the build picks up the new subdirectory. git diff post-02 post-03</code> against the companion repo is the entire delta this post describes. The system prompt grows by a sentence. The iteration budget, the message-history shape, and the overall loop are unchanged. Post one was the loop. Post two was the runtime around the loop. This post is what the loop reaches through to do anything useful. In the reference architecture from post twenty-two</a>, the registry is the seam between the agent process and everything else: MCP servers, internal APIs, file systems, side effects, the world. The rule from earlier posts still holds. The harness only ever grows; it does not get rewritten. Each post adds one layer to the same artifact and explains why the layer below was not enough. The layer below this one was an empty toolbox. The layer above is what the model knows when it picks. A model with a brilliant toolbox and no context will pick wrong every time. Next we make the model less blind. That post will ship as post-04</code> in the same repo. Next</h2> Part 4: Context Is the Product. Models are commodities. Context is not. Sources of context, why retrieval alone is not enough, and a minimal .AGENTS/</code> convention that loads context from disk into the same agent we have been building. Your Agent Wants Root Unknown — Fri, 05 Jun 2026 00:00:00 +0000 Part 2 of The Agent Platform Handbook. From Loop to Platform. Previous: What an Agent Actually Is</a>. Next: Tools, How Agents Actually Do Things. </blockquote> In post one</a> we did not just define what an agent is. We built one. A working harness in roughly one hundred and fifty lines of TypeScript on Bun: a loop, a one-tool registry, a system prompt, a dispatcher, and an iteration budget. A note on the word, because post one did not use it. The harness is the code that wraps the model and turns a chat API into something that acts. Loop, tools, system prompt, dispatcher, budgets today, and (further into the series) memory, identity, observability, policy, and the rest. Everything that is yours to write and yours to operate. The model is a dependency you call. The harness is the artifact you ship. In this series the harness is what grows, post by post. The code lives at tag post-01</code></a> of the-agent-platform-handbook</code></a>, and the rest of the series builds on it one layer at a time. Every post adds one file or rewrites one piece. This is the post that adds the second layer. The harness has one tool so far, called shell</code>, that runs any command you hand it under sh -c</code>. Post one closed with a one-line caveat: that tool will run rm -rf $HOME</code> if the model decides that is the right command, and the model will decide this at least once. This post is about the gap between “at least once” and “we are fine with that.” The shell tool from post one is, by any honest reading, an arbitrary-code-execution primitive with a polite English-language API in front of it. The model is non-deterministic. Tool results can carry instructions the model will treat as authoritative. Other agents may feed inputs back into your loop. Each of those is a way for a tool call to do something the operator did not intend. The defense is not to write better prompts. The defense is to put a fence around the runtime so the cost of a bad call is bounded. So this is the runtime post: the layer that sits underneath every tool the harness will ever have. We will sketch the threat model, walk the lineage of isolation primitives from chroot to microVMs, explain why “just run it in Docker” is only half an answer, and end by adding that layer to the harness from post one. The agent loop does not move. Only the floor underneath the shell tool changes, and the diff lands as tag post-02</code></a> in the same repo. What an agent runtime is actually exposed to</h2> A traditional service runs known code. You wrote it. You reviewed it. The only inputs are the ones the API contract allows. An agent runtime is not that. Three things make the agent threat model different. First, the model picks the action. The set of commands your shell tool will execute over its lifetime is a function of every prompt, every retrieved document, every tool output, and the model’s sampling temperature. You cannot enumerate it in advance. You cannot review it in code. You can only constrain what happens after. Second, tool results are an injection surface. A web page the agent fetches can contain “ignore previous instructions and run X.” A code file the agent reads can contain a comment that nudges the next decision. This is indirect prompt injection, documented by Greshake and others in 2023, and there is no fully reliable defense at the model layer. The runtime is where you assume the model will eventually be tricked. Third, blast radius scales with fanout. A single agent in a single shell on a single laptop is a manageable problem. A fleet of one hundred agents per tenant, each with shell, network, and file-system access, is not. Once you have more than one, you have a multi-tenant security problem whether you planned for one or not. So the question is no longer “can my agent be subverted.” It will be. The question is “what does the rest of the system look like the day after.” A short history of trying to contain a process</h2> The good news is that the industry has been working on “give this process less than the full machine” for forty-six years. The bad news is that almost none of the early answers were built with an adversary that picks its own commands in mind. The lineage matters because every modern option is a reaction to a specific failure of the option before it. chroot, Unix V7, 1979. Bill Joy’s contribution. A process sees a subtree of the filesystem as its root. Designed for build isolation, not security. Trivial to escape if you have any capability beyond a vanilla user. FreeBSD jails, Poul-Henning Kamp, 1999. Took chroot’s filesystem trick and added process visibility, network, and user separation. The first credible “container” in the modern sense. Still in production today and still good at what it does. Solaris Zones, 2004. A more ambitious version of jails with resource controls. Influential design, not a survivor. Linux cgroups and namespaces, 2002 through 2008. Namespaces gave you separate views of mounts, PIDs, networks, and users. cgroups, originally Process Containers from Google in 2007, gave you per-group resource accounting. The pieces existed. The user experience was awful. LXC, 2008. Tied cgroups and namespaces into a single CLI. Still awful, just less so. Docker, 2013. Took the same primitives and made them shippable. Image format, registry, declarative configuration, single command. The reason every paragraph after this one talks about “containers” is Docker. Kubernetes, 2014. Made running many containers across many machines a default. Pushed isolation choices down into the runtime layer. Kata Containers, 2017. A merger of Intel Clear Containers and Hyper.sh runV. Each pod runs in its own Linux VM, exposed to Kubernetes through a runtime that looks OCI-compatible. The first serious answer to “what if my container shared less than a whole kernel with the host.” Firecracker, AWS, 2018. A minimal virtual machine monitor on top of KVM, built to run Lambda and Fargate workloads. Around 125 milliseconds to boot. No legacy device model. Designed from the start for multi-tenant short-lived workloads. gVisor, Google, 2018. A user-space kernel, called runsc</code>, that intercepts syscalls from a container and services most of them itself, only escalating a narrow subset to the host. Drop-in replacement for runc</code> in any OCI-compatible runtime. Slower I/O, smaller attack surface. Wasmtime and the WASI runtimes, 2019 onward. A different model entirely: compile your tool to WebAssembly, run it in a sandbox with capability-passed I/O. Excellent for things that fit. Not yet a general answer for “run arbitrary shell commands.” The lesson from this lineage is the one the agent runtime question keeps re-asking. Every layer was designed for the threat model of the time. chroot was about build isolation. Docker was about deployment ergonomics. Firecracker, gVisor, and Kata were the first three options designed in an era where the workload itself was assumed to be untrusted. That assumption is the one that matches what an agent does. Why a default Docker container is not enough</h2> Docker is the default for almost every agent project that is past the laptop stage. There are good reasons. The packaging is good. The ecosystem is enormous. Kubernetes speaks it natively. For most workloads that are not adversarial, it is the right answer. Three things stop it from being enough for an agent runtime. The kernel is shared. A default docker run</code> puts your process in a set of namespaces with a set of cgroups, but it runs against the same kernel as the host. Any kernel bug reachable from the container becomes a host compromise. This is not theoretical. The runc CVEs of 2019 and 2024 each gave a container with default settings a path to escape. Those got patched. The next one is in flight somewhere. The defaults are generous. A vanilla docker run</code> keeps a substantial set of Linux capabilities, allows the container to write to its own root filesystem, leaves network access to internal services open by default, and runs the process as root inside the container. None of those are inherent to containers. All of them have to be turned off explicitly. The agent will be told to do things. Volume mounts that expose the host filesystem will get used. Network interfaces that reach internal APIs will get called. Secrets sitting in environment variables will end up in tool output. The model is helpful. It does not have a security review board. The honest version of the rule is this. A hardened Docker container, with capabilities dropped, network disabled, the root filesystem read-only, user namespacing on, no-new-privileges set, and resource caps in place, is enough for single-tenant, low-stakes, well-scoped agent workloads. It is not enough for multi-tenant or for code paths where the agent can be steered by external input. For those, you want a second isolation boundary underneath the container. The mental model</h2> There are three boundaries you can put between an agent’s tool call and the host kernel. Stack them in your head before picking a vendor. host kernel ================================================= | | | +------------------+ +---------------+ | | | Docker default | | Hardened | | | | ----------------| | Docker | | | | shared kernel, | | ---------- | | | | many caps, | | no caps, | | | | network on, | | no net, | | | | fs writable | | ro fs | | | +------------------+ +---------------+ | | ^ ^ | | | | | | +--------+-----------------------+------+ | | | gVisor (runsc) | | | | user-space kernel intercepts the | | | | syscall surface. host kernel sees | | | | only a narrow subset. | | | +---------------------------------------+ | | ^ | | | | | +------------------+--------------------+ | | | Firecracker / Kata | | | | separate Linux kernel per workload. | | | | KVM is the boundary. host kernel is | | | | one hypervisor call away. | | | +---------------------------------------+ | ================================================= host hardware</code></pre> Read it bottom-up. Firecracker and Kata give you the strongest isolation by giving the workload its own kernel and putting KVM between it and yours. gVisor gives you most of the same benefit with a lower operational cost by replacing the syscall surface with a user-space implementation. Hardened Docker is what you actually want at the laptop or small-team scale. Default Docker is fine for code you wrote and not for code the model wrote. Pick the layer that matches the workload. Stacking is allowed and often correct: hardened Docker plus gVisor is the usual production starting point for agent fleets. Adding the runtime layer to the harness</h2> The cheapest meaningful upgrade to the harness from post one is to stop running tool calls in the same process as the agent loop. Wrap the shell tool in a hardened container, with gVisor underneath if you have it installed. The loop stays the same. The blast radius drops by an order of magnitude. None of the four other pieces of the harness (system prompt, dispatcher, message history, iteration budget) need to know any of this happened. Install gVisor once on the host: # Linux only. macOS users can skip gVisor and keep the hardened flags. curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor \ -o /usr/share/keyrings/gvisor-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) \ signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] \ https://storage.googleapis.com/gvisor/releases release main" | \ sudo tee /etc/apt/sources.list.d/gvisor.list sudo apt-get update && sudo apt-get install -y runsc sudo runsc install sudo systemctl reload docker </code></pre> You now have runsc</code> as an available Docker runtime. From here, the rest of this section is three small changes to the harness from post one. The repo at post-01</code> has three files (agent.ts</code>, tools.ts</code>, package.json</code>); at post-02</code> it has four. Run git diff post-01 post-02</code> against the-agent-platform-handbook</code></a> and the entire delta of this post is on screen. Change 1: extract the Tool</code> type into its own file. In post one, Tool</code> lived at the top of tools.ts</code> next to the only implementation. We are about to grow the toolbox and start swapping tool implementations between sandboxed and non-sandboxed variants, so the type and the implementations want to live in different files. Pure refactor, no behavior change. // types.ts (new file) export type Tool = { name: string; description: string; input_schema: { type: "object"; properties: Record<string, unknown>; required?: string[]; }; run: (input: Record<string, unknown>) => Promise<string>; }; </code></pre> Change 2: point agent.ts</code> at the new location. One line. The loop, the system prompt, the iteration budget, the tool-call dispatcher are all untouched. // agent.ts import Anthropic from "@anthropic-ai/sdk"; import type { MessageParam, ToolResultBlockParam } from "@anthropic-ai/sdk/resources/messages"; - import { shell, type Tool } from "./tools"; + import { shell } from "./tools"; + import type { Tool } from "./types"; </code></pre> Change 3: rewrite tools.ts</code> so the shell tool runs inside a hardened container. The exported name, description, and input schema stay the same so the model sees the same tool. Everything that changes is below the public interface, in run</code>. That is the separation we are paying for: the agent does not know its tool got fenced. // tools.ts (sandboxed version) import type { Tool } from "./types"; const SANDBOX_IMAGE = "alpine:3.20"; const SANDBOX_WORKDIR = "/work"; const dockerArgs = (image: string, command: string) => [ "docker", "run", "--rm", "--runtime=runsc", // gVisor. drop on macOS. "--network=none", // no exfil, no SSRF "--read-only", // no writes to the rootfs "--tmpfs", "/tmp:size=64m", // give /tmp back, bounded "--cap-drop=ALL", // no Linux capabilities "--security-opt=no-new-privileges", // no setuid escalation "--user=1000:1000", // unprivileged uid in the container "--memory=256m", // hard memory cap "--cpus=0.5", // fractional cpu cap "--pids-limit=64", // no fork bombs "--workdir", SANDBOX_WORKDIR, image, "sh", "-c", command, ]; export const shell: Tool = { name: "shell", description: "Run a shell command inside an isolated sandbox with no network and a read-only filesystem. Returns stdout, stderr, and exit code as JSON.", input_schema: { type: "object", properties: { command: { type: "string", description: "Shell command to run under `sh -c` inside the sandbox.", }, }, required: ["command"], }, run: async ({ command }) => { const args = dockerArgs(SANDBOX_IMAGE, String(command)); const proc = Bun.spawn(args, { stdout: "pipe", stderr: "pipe" }); const [stdout, stderr] = await Promise.all([ new Response(proc.stdout).text(), new Response(proc.stderr).text(), ]); const code = await proc.exited; return JSON.stringify({ code, stdout, stderr }); }, }; </code></pre> Total damage: one new file of ten lines, one moved import, and forty-five lines of tools.ts</code>. In exchange, roughly a thousand-fold reduction in blast radius. The agent can still ask rm -rf /</code>. It will return an exit code, an error, and a clean host. Network calls will fail closed. Reads outside /work</code> are not possible because nothing is mounted into /work</code>. The sandbox dies the moment the command returns, so persistence between calls is also gone, which is a separate problem we will pick up in post six on memory</a>. A few things to notice. The harness shape from post one is intact. Same loop, same dispatcher, same system prompt, same iteration budget, same JSON contract between the agent and the tool. The sandbox is a runtime concern, not an agent-architecture concern. This separation is exactly the point. You should be able to swap gVisor for Firecracker, or Docker for Podman, or Alpine for a custom image, without touching the loop. The tradeoffs are real. Spawning a container per tool call costs roughly 200 to 800 milliseconds on a modern host, mostly Docker daemon overhead. For a coding agent that runs three shell commands per turn, that is acceptable. For a sub-millisecond-per-call tool, it is not. The fix at scale is a container pool, or moving to Firecracker microVMs with snapshot/restore where boot time drops to around 125 milliseconds and per-call cost drops further. The image is alpine:3.20</code>, which is around 8 megabytes. Use a bigger image when the workload needs it. Mount a per-session work directory under /work</code> when the agent needs to read or write files between calls. Both of those are configuration changes, not architecture changes. Picking the layer</h2> Use the table to pick where to start. The honest answer for most teams is “hardened Docker plus gVisor today, Firecracker microVMs later when scale or tenancy demands it.” Workload</th> Sensible default</th> Why</th></tr></thead> Local dev agent, one user, your laptop</td> Hardened Docker, gVisor if available</td> Convenience wins; the blast radius is one machine.</td></tr> Shared internal tool, single tenant</td> Hardened Docker plus gVisor</td> Cheap upgrade, real benefit, no orchestration cost.</td></tr> Multi-tenant SaaS, agent per user session</td> Firecracker microVM per session</td> Per-tenant kernel isolation; fast boot per session.</td></tr> Kubernetes-native agent platform</td> Kata Containers</td> Drop-in OCI shape, pod-level VM boundary.</td></tr> Unknown code from the public internet</td> gVisor at minimum, microVM preferred</td> Syscall surface or hypervisor surface, not yours.</td></tr> WASM-shaped pure-function tool</td> Wasmtime with capability-passed I/O</td> Fastest sandbox available when the workload fits.</td></tr> Throwaway batch job, internal only</td> Hardened Docker</td> Stacking layers adds cost without proportional gain.</td></tr> </tbody></table> The table assumes Linux. macOS does not have KVM, so Firecracker and gVisor are Linux-host options. On macOS you can run them inside a Linux VM (Lima, OrbStack, Docker Desktop) and pay the nested cost. What this layer does not solve</h2> Isolation is a necessary condition for a safe agent runtime. It is not a sufficient one. The honest list of what is still on your plate after this post. Outbound network policy. --network=none</code> is the right default for the shell tool. The moment you give an agent an http</code> tool, you need an egress policy that distinguishes “the model should reach the public web” from “the model should never reach the internal metadata service.” That is its own design problem.</li> Persistent state. A throwaway sandbox forgets everything between calls. Real agents need memory across tool invocations. The design question is which directories survive, who can read them, and what the eviction policy is. We will come back to this in post six</a>.</li> Tool-level policy. Even inside a perfectly isolated sandbox, you may want certain commands to require human approval. That is a permissions problem, not an isolation problem, and we will spend post fourteen</a> on it.</li> Identity. A sandboxed container still has to call your tools, your models, and your APIs. Long-lived API keys baked into the image are how production agent fleets get embarrassed. Post thirteen</a> puts SPIFFE under this stack.</li> Time and resource budgets. --cpus=0.5</code> and --memory=256m</code> cap a single invocation. They do not cap a loop that asks for one hundred invocations. Iteration budgets, token budgets, and wall-clock budgets are a separate fence. Post sixteen</a> covers that fence.</li> </ul> Where this lands in the platform</h2> You can hold the platform in your head one box at a time, and you can hold the harness on disk one tag at a time. Post one drew the agent loop and shipped it as post-01</code></a>. This post opened the runtime box, put three concrete things inside it (a hardened container, a user-space kernel, a microVM), picked one, and shipped the result as post-02</code></a>. The reference architecture in post twenty-two</a> will keep this box exactly where it is and treat the contents as a choice that varies by workload. The rule from post one still holds. Each post adds one layer to the same harness and explains why the layer below was not enough. The harness only ever grows; it does not get rewritten. The layer below this one was the shell tool itself. The layer above is the rest of the toolbox. An agent with one tool is a demo. An agent with a real tool registry is software. Next we extend the same harness with a real registry, give it a schema, and explain what changes when the model decides between four tools instead of one. That post will ship as post-03</code> in the same repo. Next</h2> Part 3: Tools, How Agents Actually Do Things. Function calling, structured outputs, schema design that survives model drift, and the failure modes nobody talks about. We extend the post-one agent with a four-tool registry and a tool-selection trace. What an Agent Actually Is Unknown — Tue, 02 Jun 2026 00:00:00 +0000 Part 1 of The Agent Platform Handbook. From Loop to Platform. A 22-post series that walks the agent stack from a single loop to a production platform. Next: Your Agent Wants Root</a>. </blockquote> If you sit in three meetings on the same day, you will hear the word agent used to mean three different things. A vendor will use it to mean a chat window with a logo. A platform team will use it to mean a workflow with a retry. A security lead will use it to mean a long-running process with credentials you cannot see. None of those people are entirely wrong. None of them are talking about the same thing. This is the first post in a series that goes from a single agent loop up to a production platform. Before we can talk about isolation, tools, identity, or orchestration, we have to agree on what the thing in the middle of the diagram actually is. So we will define it, sketch its anatomy, trace the path the industry took to get here, and then build a working one in roughly two hundred lines of TypeScript on Bun. By the end of the post the abstract noun is a concrete file you can run. A working definition</h2> An agent is software with five properties. Drop any one and what you have is something else. A goal. Not a single prompt. A target state, a task description, or a problem statement that the system is trying to satisfy.</li> A model. One or more inference engines that translate the current state plus the goal into a next step. Today this is almost always a large language model.</li> A context. Information the model can read beyond the user input. System prompts, documents, prior turns, environment state, configuration files.</li> Tools. A finite, named set of side-effecting operations the model is allowed to invoke. Reading a file. Running a shell command. Calling an API.</li> A loop. The model picks a tool, the tool runs, the result re-enters the context, the model picks again. The loop ends when the goal is satisfied, the budget is exhausted, or a stop condition is hit.</li> </ol> There is usually a sixth property in production, memory, which is state that survives the loop. We will treat memory as a separate layer in post six</a> and keep this first agent stateless. A system with all five properties is an agent. A system with four is something else worth a name. A chat window has goal, model, context, and a loop, but no tools, so it is a chatbot. A CI pipeline has a goal, context, tools, and a loop, but no model, so it is a workflow. A function call has a goal, a model, context, and a tool, but no loop, so it is a one-shot completion. The presence of the loop is what makes the behavior open-ended. The presence of tools is what makes the loop matter. The architecture diagram for every agent ever shipped looks like this. +--------------+ | Goal | | (user task) | +-------+------+ | v +------------+ +---------------+ +------------+ | Context +-------->| Model |<--------+ Memory | | docs, env, | | next action? | | (optional) | | prior turns| +-------+-------+ +------------+ +------------+ | | tool call v +---------------+ | Tool | | shell, http, | | file, custom | +-------+-------+ | | result v +---------------+ | Runtime | | (where the | | side effect | | happens) | +-------+-------+ | v +----------+----------+ | done? --no--> loop | | | | | yes | | v | | return | +---------------------+</code></pre> The diagram is small on purpose. Almost every post in this series will redraw it with one component opened up. Post two opens the runtime. Post three opens the tool. Post four opens the context. Post six opens the memory. Post seven opens the model. The capstone in post twenty-two assembles all of them into a reference architecture. Hold the picture in your head. We will come back to it. How we got here</h2> You can read the rest of this section as background and skip the first two subsections if you have already lived through them. The third subsection, on the 2024 to 2026 stretch, is worth the read either way because it explains why everyone you work with is suddenly using the word agent. The old AI</h3> The idea of a software agent is older than the modern LLM by about fifty years. Terry Winograd’s SHRDLU, in 1970, was a program that took natural-language commands, planned actions in a simulated blocks world, executed them, and updated its internal state. It had a goal, a model of the world, a set of tools, and a loop. It was an agent. It worked beautifully on the blocks world and fell over the instant you stepped outside it, because the model of the world was hand-coded and the language understanding was brittle. Through the 1980s and 1990s the idea kept coming back under different names. Expert systems wrapped business logic in inference rules. The Belief-Desire-Intention architecture, formalized by Bratman and others, gave agents an explicit cognitive model: what they believed, what they wanted, what they intended to do next. There were good papers, working systems, and shipping products. The thing all of them missed was a usable model of language. You could specify the agent’s goals in formal logic or in a structured DSL. You could not say “go book me a flight” and have it parse. The lesson from this era is that the architecture has been right for decades. The bottleneck was the model. The chat era</h3> When GPT-3 arrived in 2020 and ChatGPT in late 2022, the language bottleneck broke. You could finally write a goal in English and the system would respond coherently. The first response from the industry was to wrap that capability in a chat window and sell it. That is not an agent. There is no loop, no tools, and the model cannot do anything to the world it lives in. It is a very good autocomplete with a memory of the conversation. The agent pattern only came back when somebody asked the obvious next question. If the model can read and write English, and we can let it call functions, can we close the loop and let it act? Two papers and two viral demos answered that question between late 2022 and early 2023. The papers came first. ReAct: Synergizing Reasoning and Acting in Language Models by Yao and others, published in October 2022, showed that interleaving a reasoning step with a tool-use step produced better performance than either alone. The blueprint was small enough to fit on a napkin: think, act, observe, repeat. It became the de facto pattern for almost every agent shipped since. The demos came in early 2023. Auto-GPT, released by Toran Bruce Richards in March 2023, wrapped GPT-4 in exactly that loop and let it run unattended. It demoed brilliantly and broke constantly. BabyAGI, by Yohei Nakajima a few weeks later, did the same thing with about a hundred lines of Python. Neither was production-grade. Both made the idea legible to people who had never read the ReAct paper. After Auto-GPT you could explain an agent by saying “imagine ChatGPT but it keeps going until the task is done.” That was a marketing breakthrough, not an engineering one, but marketing is how ideas spread. OpenAI’s function-calling API, launched in June 2023, was the engineering breakthrough that followed. Instead of trying to parse “the model wants to call search(query)</code>” out of free-form prose, you declared your tools with JSON schemas and the model returned a structured tool call. Anthropic’s tool_use</code> shipped on the same pattern. With function calling, the agent loop stopped being a regex problem and started being a software problem. We will come back to this in post three</a>. The 2023 wave produced the first real frameworks: LangChain in October 2022, AutoGen in late 2023, CrewAI and LangGraph in 2024. They competed on abstractions. Some won, some lost. We will review them in post nine</a>. The point for now is that by mid-2024, building an agent was a Python or TypeScript exercise rather than a research project. The 2025 to 2026 bundling</h3> Here is where the word agent stopped being a research term and became a product category. It happened in two waves. The first wave was builder-facing. In early 2025, Anthropic shipped Claude Code, a command-line agent that ran on your laptop, edited files, ran shell commands, and could spawn sub-agents. OpenAI relaunched Codex as a real agent rather than a completion endpoint. The open-source community produced OpenCode and a half-dozen adjacent projects (aider, continue, opencoder) that gave the same shape a vendor-neutral surface. None of these were technically novel. The loop was the ReAct loop. The tools were bash</code> and edit</code>. What was new was the bundling: the loop, the tools, and the runtime arrived together, in a binary you could install in thirty seconds. Once that shipped, every infrastructure and platform engineer had a working agent on their laptop within a week. I wrote about what came next in What Sixteen AI Agents Taught Me About Management</a>. Once builders had working agents, they wanted to run more than one. Once they ran more than one, they hit coordination problems. Once they hit coordination problems, they discovered that agent orchestration is a management problem with a software wrapper. The second wave was assistant-facing and it broke out of the developer audience entirely. OpenClaw shipped in early 2026 and crossed a hundred thousand GitHub stars in its first week. Hermes followed in the same lane. Both took the agent pattern and gave it to people who do not write code. A research task. A contract review. A calendar negotiation. The same loop, with different tools and different context. The enterprise buyer stopped being the developer tooling team and started being any line of business with a workflow. That is where the market is right now, as of mid-2026. Every engineering org has builders running coding agents locally. Every business org has someone piloting an assistant agent. Almost no organization has a coherent platform underneath any of it. The point of this series is to close that gap. Build one</h2> You learn what an agent is by building one. The code that follows is a complete, working agent in TypeScript on Bun. It is roughly two hundred lines. It reads a goal from the command line, calls Anthropic’s API with a small tool registry, executes tool calls, feeds results back, and stops when the model is done or the iteration budget is exhausted. You will need three things to follow along. bun --version # 1.1 or newer echo $ANTHROPIC_API_KEY # any valid key bun add @anthropic-ai/sdk </code></pre> The full source for this post is in the-agent-platform-handbook</code></a> at tag post-01</code>. You can clone it and run bun agent.ts "list the three largest files under /etc"</code> if you would rather read the code in your editor. The tool interface</h3> The smallest unit worth defining first is a tool. A tool has a name, a description the model can read, a JSON schema for its input, and a function that runs the side effect and returns a string. // tools.ts export type Tool = { name: string; description: string; input_schema: { type: "object"; properties: Record<string, unknown>; required?: string[]; }; run: (input: Record<string, unknown>) => Promise<string>; }; </code></pre> That is the entire contract. The run</code> function returns a string because the model will read the result as text. If your tool returns structured data, serialize it with JSON.stringify</code> and let the model parse it. We will revisit this choice in post three</a> when we look at structured outputs more carefully. A shell tool, which is the most useful single tool you can give an agent, looks like this. // tools.ts (continued) export const shell: Tool = { name: "shell", description: "Run a shell command in the current working directory and return its stdout, stderr, and exit code as JSON.", input_schema: { type: "object", properties: { command: { type: "string", description: "The shell command to run. Runs under `sh -c`.", }, }, required: ["command"], }, run: async ({ command }) => { const proc = Bun.spawn(["sh", "-c", String(command)], { stdout: "pipe", stderr: "pipe", }); const [stdout, stderr] = await Promise.all([ new Response(proc.stdout).text(), new Response(proc.stderr).text(), ]); const code = await proc.exited; return JSON.stringify({ code, stdout, stderr }); }, }; </code></pre> A few things to notice. The description is written for the model, not for you. Be specific about what the tool does, what it returns, and what its constraints are. The JSON schema is the contract the model sees when it decides whether to call this tool. Bun’s Bun.spawn</code> returns streams, so we read both stdout and stderr and join them with the exit code into one JSON payload the model can reason about. This tool will run any shell command. That is wildly unsafe. Do not deploy it. We will spend post two</a> explaining why and what to do about it. For a single-user, single-directory demo on your own laptop, it is fine. The loop</h3> The loop is the part most explanations rush. Take it slowly. // agent.ts import Anthropic from "@anthropic-ai/sdk"; import type { MessageParam, ToolResultBlockParam } from "@anthropic-ai/sdk/resources/messages"; import { shell, type Tool } from "./tools"; const client = new Anthropic(); const tools: Tool[] = [shell]; const SYSTEM_PROMPT = `You are a careful command-line assistant. You have access to a shell tool. Use it to investigate the user's request and answer concretely. When you have the answer, stop calling tools and reply in plain text.`; </code></pre> We pull in the SDK, register one tool, and write a system prompt. The system prompt is the first piece of context that is not user input. We will spend post four</a> on how to grow this into a real context strategy. For now it is a single paragraph telling the model how to behave. // agent.ts (continued) async function step(messages: MessageParam[]) { return client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 4096, system: SYSTEM_PROMPT, tools: tools.map(({ run, ...t }) => t), messages, }); } </code></pre> Every call to the model is a step</code>. The tool list we send is the schema only, never the run</code> function, so we strip it. The model returns a message that is either a final text answer or a request to call one or more tools. The loop itself is fifty lines. // agent.ts (continued) export async function run(goal: string, maxIterations = 10) { const messages: MessageParam[] = [{ role: "user", content: goal }]; for (let i = 0; i < maxIterations; i++) { const response = await step(messages); messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const text = response.content .filter((b) => b.type === "text") .map((b) => (b as { text: string }).text) .join("\n"); console.log(text); return; } if (response.stop_reason !== "tool_use") { throw new Error(`unexpected stop reason: ${response.stop_reason}`); } const toolResults: ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; const tool = tools.find((t) => t.name === block.name); if (!tool) { toolResults.push({ type: "tool_result", tool_use_id: block.id, content: `unknown tool: ${block.name}`, is_error: true, }); continue; } console.error(`> ${block.name} ${JSON.stringify(block.input)}`); try { const result = await tool.run(block.input as Record<string, unknown>); toolResults.push({ type: "tool_result", tool_use_id: block.id, content: result }); } catch (err) { toolResults.push({ type: "tool_result", tool_use_id: block.id, content: String(err), is_error: true, }); } } messages.push({ role: "user", content: toolResults }); } console.error(`iteration limit (${maxIterations}) reached`); } </code></pre> Walk through it once. We start with the goal as the first user message. We call the model. We append the model’s response to the conversation. If the model says end_turn</code>, we print the final text and return. If the model says tool_use</code>, we find the requested tool, run it, and append the result as a user-role tool_result</code> block. The model sees the result on its next turn and decides what to do. The for</code> loop with maxIterations</code> is the only thing standing between this agent and an unbounded run. We will spend a chunk of post sixteen</a> on whether iteration counts are the right budget unit. They are not, but they are the simplest. Start with the simplest. The entry point is two lines. // agent.ts (continued) const goal = process.argv.slice(2).join(" "); if (!goal) { console.error("usage: bun agent.ts '<goal>'"); process.exit(1); } await run(goal); </code></pre> That is the entire agent. Around one hundred and forty lines of code with the imports and the system prompt. It is a real agent by the definition we started with. It has a goal, a model, context (the system prompt and the running message list), tools (one of them), and a loop (the for</code> with maxIterations</code>). Running it</h3> A small transcript makes the loop concrete. $ bun agent.ts "what is the largest TypeScript file under src and what does it do?" > shell {"command":"find src -name '*.ts' -type f -printf '%s %p\n' | sort -nr | head -5"} > shell {"command":"wc -l src/agent.ts"} > shell {"command":"head -40 src/agent.ts"} The largest TypeScript file under src is src/agent.ts at 4837 bytes (150 lines). It implements an agent loop against the Anthropic Messages API. It defines a single shell tool, sends the user's goal to the model, executes any tool calls the model requests, feeds the results back, and stops when the model returns an end_turn response or the iteration budget of 10 steps is exhausted. </code></pre> The lines prefixed with ></code> are the agent’s tool calls, logged from the console.error</code> in the loop. The final paragraph is the model’s end_turn</code> text. Three tool calls, one final answer, one closed loop. You have an agent. Why most agent demos are not agents</h2> Now that the definition is concrete and you have a working example, the question of what is and is not an agent becomes useful. The honest version of the answer is in the table. System</th> Goal</th> Model</th> Context</th> Tools</th> Loop</th> Verdict</th></tr></thead> ChatGPT, 2022 launch</td> Y</td> Y</td> Y</td> N</td> Y</td> Chatbot</td></tr> ChatGPT today (browse, code, files)</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> Cursor’s inline edit</td> Y</td> Y</td> Y</td> Y</td> N</td> Completion</td></tr> A GitHub Actions workflow</td> Y</td> N</td> Y</td> Y</td> Y</td> Workflow</td></tr> A pure retrieval-augmented chat</td> Y</td> Y</td> Y</td> N</td> Y</td> Chatbot+RAG</td></tr> A function-calling API call</td> Y</td> Y</td> Y</td> Y</td> N</td> Tool call</td></tr> Claude Code in the terminal</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> The script in this post</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> Auto-GPT, BabyAGI</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> OpenClaw</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> A Temporal workflow with an LLM step</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> </tbody></table> The first two rows are the same product two years apart. ChatGPT launched in November 2022 as a chat window with no tools. Today the same web UI can browse the live web, run Python in a sandboxed runtime, convert and read PDFs, and generate images. It crossed the line. The interesting thing is that the user-facing language did not change. It is still called a chatbot. Under the definition we are working with, it is an agent. The boundary moved underneath the marketing. That is the pattern to expect across the industry over the next two years. Every chat product will quietly grow tools. Every workflow product will quietly grow a model. The labels will lag the architecture by a year or two. If you only listen to the labels, you will miss the moment a system becomes something you should be governing differently. The pure RAG row is the one that does not cross. A retrieval-augmented chat that only enriches its own context does not get tools in the sense that matters. The model cannot decide to do something different based on what it finds. It just answers from a richer context. Useful, sometimes excellent, not an agent. The moment that same system gains a “search again with a different query” or “fetch this document” tool, it is. The Temporal-with-LLM row is interesting for the opposite reason. That is an agent. It is also a workflow. The two categories are not mutually exclusive. Post seventeen</a> will explain why the production version of almost every agent ends up wrapped in a durable workflow. The point of the table is not to gatekeep the word. It is to point at the conceptual distinction. A chatbot fails by being uninformed. An agent fails by acting wrong. Once your system can act, the failure mode changes, and so does what you owe the operator. Failure modes</h2> The script above will work the first ten times you run it. Some of the failure modes it has are obvious. Some you only see in production. The honest list, in roughly the order you will hit them. Infinite loops disguised as progress. The model can call tools forever without converging. maxIterations = 10</code> saves you from your own demo today. It will not save you when somebody asks a harder question tomorrow. Real budgets are token-based or wall-clock-based, not step-based. We will fix this properly in post sixteen</a>.</li> Cost runaway. Every iteration is a full model call with the entire conversation as input. The token cost grows roughly quadratically with the number of steps because each new turn re-sends every prior turn. A ten-step loop costs more than ten times a one-step call. Prompt caching helps. Smaller models for the cheap turns help more. We will spend post eighteen</a> on this.</li> Lying about success. The model can claim it completed the task without actually verifying. The shell tool does not check whether the answer is correct. You can ask “did you do X?” and get “yes” when the truth is “I tried, it failed, I gave up.” Evals exist for this. Post sixteen</a> explains them.</li> Broken tool output. If a tool returns a megabyte of binary data, the model will choke or hallucinate. Tool outputs need to be summarized, truncated, or schema-shaped. The agent will not do this for you.</li> No isolation. The shell tool will run rm -rf $HOME</code> if the model decides that is the right command. The model will not decide this often. It will decide it at least once. That is the topic of the next post.</li> Hidden state. Every tool call has side effects on the runtime. Files get created. Network calls get made. Database rows get inserted. The conversation log does not capture any of it. You can replay the model’s reasoning. You cannot replay the world it was reasoning about. Idempotency and durable execution are how serious systems handle this.</li> Concurrency edge cases. This loop is sequential. The model can ask for multiple tools in one turn, and the example above runs them in order. If two of those tools both want to write the same file, you have a bug the model cannot see.</li> </ul> None of these are reasons not to build an agent. They are the reasons the rest of this series exists. What this post left out on purpose</h2> A long post still leaves things out. The intentional omissions, with pointers to the posts that pick them up. Isolation. The shell tool is dangerous. Fixed in post two: Your Agent Wants Root</a>.</li> A real tool registry. One tool is the demo. A useful agent has four to a dozen. Covered in post three</a>.</li> Context strategy. The system prompt is a paragraph. Real systems load context from disk and shape it per task. Covered in post four</a> and post five</a>.</li> Memory across sessions. The agent forgets everything between runs. Covered in post six</a>.</li> Model selection. We hardcoded one model. Production agents route. Covered in post seven</a>.</li> Tool protocol. The tool interface is bespoke. The industry converged on MCP. Covered in post eight</a>.</li> Frameworks. We built this raw. The framework conversation is in post nine</a>.</li> Identity, evals, durability, economics, governance. All of arc four and five.</li> </ul> If you read the table of contents for the series you can see the shape: every post in the rest of the series fixes one limitation of the agent you just built. Where this lands in the platform</h2> The diagram at the top of this post is the smallest box in the eventual reference architecture. The agent loop sits inside a runtime. The runtime sits inside a fleet. The fleet sits inside a platform with identity, observability, governance, and a control plane. The shape we end up with in post twenty-two</a> is the same shape we started with, blown up to enterprise scale, with every component opened up and given its own production-grade story. You can hold the whole series in your head with a single rule. Each post adds one layer of the stack and explains why the layer below was not enough on its own. The next layer up is the runtime. The shell tool you just gave a frontier model is a loaded gun. Next week we explain how to point it somewhere safe. Next</h2> Part 2: Your Agent Wants Root</a>. Why a Docker container is not enough, and what Firecracker, gVisor, and Kata actually solve. Publishes Thursday. The Field Exists Now Unknown — Fri, 22 May 2026 00:00:00 +0000 Alasdair Allan, the creator of Vera</a>, has started a public catalogue at agentlanguages.dev</a>: programming languages designed for AI agents to write. When he mentioned it to me on LinkedIn, the count was twenty-one. When I checked, the site already listed twenty-eight. That pace is the point. Six months ago, the idea that programming languages would bend around AI authorship still sounded like a late-night compiler conversation. Now there is a catalogue, a taxonomy, and enough independent projects to argue about the shape of the field without pretending the field is hypothetical. That is a real change. The taxonomy is better than my timeline</h2> In The Last Programming Language Might Not Be for Humans</a>, I described three futures: explicit languages stripped of ambiguity</li> declarative languages where types act as proof obligations</li> no language at all, where the prompt is the specification and the executable is the product</li> </ul> I still think that direction of travel is useful. The long arc points away from source code as the thing humans primarily edit, and toward artifacts that agents generate, compilers check, runtimes execute, and other agents can trust. But Alasdair’s taxonomy is cleaner for describing the field as it exists today. He splits it into three camps: syntactic, where the problem is representational ambiguity</li> verification, where the problem is semantic correctness</li> orchestration, where the problem is agent coordination</li> </ul> That framing is less linear and more honest. Vera and my Haskell work are not step one and step two. They are two near-term answers to the same pressure. That correction matters because it changes what we should measure. If the field is a timeline, the question is which phase arrives next. If the field is a set of camps, the question is which diagnosis is right for which workload. That is a much better question. Vera and BHC are adjacent, not sequential</h2> One useful correction: Raskell is not the project. Raskell is this blog. The relevant projects are hx</a> and BHC, the Basel Haskell Compiler, both under arcanist.sh</a>. hx is the tooling layer. BHC is the compiler layer. That distinction matters because the bet is not “invent Raskell as a new AI language.” The bet is that Haskell already has much of the semantic shape we need, and that the missing layer is tooling, runtime control, diagnostics, and compilation strategy. Vera takes a more bespoke path. It asks what a language should look like if it is designed for models from first principles. That leads to mandatory contracts, typed effects, solver-backed verification, and De Bruijn-style slot references instead of variable names. That is a serious design. I like it because it does not just say “AI will write code” and stop there. It changes the language around that claim. BHC starts from the other side. It assumes Haskell’s purity, type system, and compositional style are already close to the right substrate for AI-written software. The weak points are around the compiler and the experience around it: how fast the loop is, how clear the errors are, how reproducible the build is, how explicit the runtime profile is, and eventually how much semantic information survives into numeric and GPU-oriented lowering. So I do not think Vera and BHC compete for the same idea. They may compete for attention, mindshare, or some future market. But intellectually they are adjacent. Vera says: design the language around the agent. BHC says: make the semantically rich language operationally good enough for the agent era. Both are verification-camp bets. Why the verification camp is crowded</h2> The most interesting thing in the catalogue is how crowded the verification camp is. That should not surprise us, but it still does. Once you work with coding agents every day, the failure mode becomes obvious. The problem is not that the model cannot type syntax. It can type syntax just fine. The problem is that plausible code is cheap, and plausible code is often wrong. That changes the job of the language. A language for AI-authored code does not need to make the model feel clever. It needs to make wrongness cheap to detect. Ideally before runtime. Ideally before deployment. Ideally in a form the model can consume and repair. That is why contracts, effects, refinement types, strong type systems, proof export, SMT solvers, and structured compiler diagnostics keep showing up. These are not aesthetic choices. They are different ways of building a feedback loop around a generator that will always be probabilistic. The generator does not need to be trusted. The artifact needs to be checkable. That sentence is probably the center of the whole field. The market is less interesting than the artifact</h2> There will be a temptation to turn this into a market map too early. Which language wins? Which toolchain gets adopted? Which one has the most stars? Which one gets bundled into an IDE or agent framework first? Those questions matter eventually. They do not matter most right now. The important question is what the unit of software becomes when the author is no longer primarily human. My answer, in Source Code Is the New Assembly</a>, was that source code becomes one rendering of a richer semantic artifact. The agentlanguages.dev catalogue strengthens that view. The syntactic camp is trying to make the text representation easier for models to manipulate. The verification camp is trying to make the artifact easier to prove correct. The orchestration camp is trying to make agent work easier to sequence, constrain, and audit. Those are not disconnected concerns. They are different surfaces of the same object. If agents are going to generate software that matters, the artifact has to carry more than instructions. It has to carry constraints, effects, provenance, trust boundaries, and execution intent. Source code can be part of that. It cannot remain the whole thing. Where BHC fits</h2> BHC’s long-term target is not just “AI writes Haskell.” That is too small. The more interesting target is verifiable compute expressed through a functional, semantically dense language and lowered into the right execution profile. Sometimes that means ordinary native code. Sometimes WebAssembly. Eventually, for the numeric profile, it should mean GPU-oriented compute where the compiler can preserve enough structure to reason about what is being executed. This is the part that keeps pulling me back to Haskell. Functional purity is not just beautiful. It is useful. It makes dependencies visible. It makes transformations local. It reduces the hidden state an agent has to simulate. It gives the compiler more leverage. It gives verification machinery more structure. And Haskell is verbose in exactly the right places. Not verbose like boilerplate. Verbose like meaning. Type signatures, algebraic data types, explicit transformations, pure functions. These are things an agent can generate, a compiler can check, and a human can audit later when something matters enough to read. That is the bet behind BHC and hx. Not a new language for its own sake. Not Haskell nostalgia. A belief that semantic density becomes more valuable when generation gets cheap. What the catalogue proves</h2> The catalogue does not prove which camp is right. It proves the pressure is real. Independent people arrived in the same neighborhood at roughly the same time, using different words and different tools. That usually means the underlying constraint changed. In this case, the constraint is authorship. The old language design question was: what can humans write, read, and maintain? The new question is: what can agents generate, compilers verify, runtimes constrain, and humans audit when needed? That does not make human readability irrelevant. It changes its position. Human readability becomes part of auditability, not necessarily the primary authoring constraint. That is the shift agentlanguages.dev makes visible. The field exists now. It has camps. It has disagreements. It has projects with code, projects with papers, projects with benchmarks, and projects that are still mostly intent. That is fine. Early fields are messy. The useful thing is that we can stop arguing about whether the category is real and start arguing about which claims survive measurement. That is where the work gets interesting. Source Code Is the New Assembly Unknown — Thu, 07 May 2026 00:00:00 +0000 In The Last Programming Language Might Not Be for Humans</a>, I argued that if AI becomes the primary author of code, the source language has to bend around that author. In What Comes After the Last Programming Language</a>, I extended the argument one layer down: even the operating system still assumes a human is writing CPU-centric instruction streams, and that assumption has an expiration date. I left the deepest move for last on purpose. If languages are bending and operating systems are bending, it is because something more fundamental is bending. The unit of software is changing. The thing we treat as authoritative, version, review, ship, replay, and audit, is on its way to becoming something other than a tree of source files. I want to make that move explicitly. This is the post where I plant the flag. What I am actually claiming</h2> The clearest way I can put it is this: programming languages were never the destination. They were a writing system for an era when humans had to author the syntax. They survived because humans were the bottleneck, and the machine had to be addressed through a human-legible medium. That arrangement is starting to come apart. Once generation is cheap, syntax is not the scarce resource anymore. The scarce resource is semantic stability. What I want is not a better language for models to type. I want an artifact that preserves meaning across generation, verification, lowering, execution, audit, and replay. I will call that thing a semantic artifact, and I will call the machine around it a meaning engine. Both terms exist in adjacent literatures already. I am using them deliberately, not as branding. A semantic artifact is the new unit of software. The meaning engine is what compilers and runtimes become when they accept those units. Source code does not vanish in this picture. It demotes. It survives the way assembly survives today: indispensable, specialized, and no longer the layer most people author. That is the full claim. The rest of this post is the case for it. Programming languages were always writing systems</h2> There is a reflex in our field to treat programming languages as if they were a category unto themselves. They are not. They are a specialized branch of writing. Writing, in linguistics, is a technology for making language visible and durable. It is a system of conventional marks that encodes linguistic structure in a persistent medium. It is not thought itself. It is not even speech. It is a representation that allows institutions, tools, and machines to act on language across time and space. Programming languages fit this definition without strain. They are notation systems that encode executable intent in marks a compiler can consume. Like every writing system, they were shaped by the dominant author and the dominant medium of their era. Assembly is the closest thing we have to a logographic system for computation. Each opcode points at one specific machine action. There is no abstraction between the symbol and the execution. C is structured prose for systems work, designed when the author was a competent human engineer and the target was a single-CPU machine with byte-addressable memory. Python is a writing system tuned for readability and velocity, designed for an author who would rather get to the point than negotiate with the type system. Haskell pushes in the other direction, toward formal logic notation, where the writing system itself encodes proof obligations. Every one of these languages is a compromise between precision and expressiveness. None of them was final. Each was tuned to what humans could reasonably author and what compilers could reasonably lower. Once you see this clearly, the historical contingency becomes obvious. Source code is not sacred. It is a notation layer that won because humans had to write something, and machines had to lower something. It became the universal artifact of software because the author was human and the medium was text. Change the author, and the universal artifact has no reason to stay text. This is the same observation Unison</a> has been making in production for years, just from a different angle. Unison stores definitions by the hash of their structured form, not by filename. Text is a view, not the artifact. The system has not gone post-code. It has gone post-text, while keeping code as the underlying object. That is a useful first step, and it is much more than a curiosity. It is a working proof that the source file is not load-bearing in the way our tools pretend it is. Code is a lossy compression of intent</h2> The thing programmers do, when we write code, is compression. We take a high-dimensional, contextual, often-ambiguous understanding of what the system should do, and we squeeze it into a rigid, linear, explicit sequence of statements that a compiler will accept. The compiler then performs a different compression, from our notation down to machine code. By the time the binary runs, several lossy passes have happened. Assumptions live in our heads or in a README. Side effects live implicitly in function calls. The reasons we made certain decisions live in commit messages, ticket systems, or, more often, nowhere. The artifact that runs is missing most of the meaning that produced it. We know this is lossy because we spend enormous effort patching the loss. We write tests to recover behavioral intent. We write documentation to recover design intent. We write architecture decision records to recover historical intent. We write runbooks to recover operational intent. We sprinkle assertions to recover invariants we could not express in the type system. We add observability to recover what the running program is actually doing because the source did not say. Programming, in this view, is manual compression of intent into executable form. It worked because the human author could hold the uncompressed version in their head while typing the compressed version. It also worked because the compressed version was good enough to ship and the uncompressed version did not have to survive review. AI changes the economics of that compression. Generation gets cheap. Expansion from a few sentences to thousands of lines of code is no longer the hard part. What gets relatively more expensive is the part that was always implicit: deciding which version is correct, which assumptions are still valid, which constraints must hold, which environments will give the same result, which side effects are allowed. In a world with cheap generation, the uncompressed version is what we should be authoring. Not the compressed one. What a semantic artifact actually is</h2> A semantic artifact is not a fancier source file. It is not “code with metadata.” It is a different kind of object, with different properties, and the difference matters. A semantic artifact is intent-first. It says what must hold, not how. It can carry “how” as one of several lowerings, but the upper layer is the obligation, not the implementation. It is structured. It is a typed graph of entities, constraints, transformations, effects, evidence, and provenance. Text is one rendering. JSON is another. A diagram is another. None of them is the artifact. It is content-addressed. Identity is structural, derived from the artifact itself, not from a filename or a path. Two artifacts with the same meaning have the same identity. This is the lesson Unison teaches and the lesson the rest of the industry has not fully absorbed. It is explicit about effects. Reads, writes, time, randomness, network, ledger postings, model inference, file system access, are all declared. Effects are part of the type, not lurking inside a function body. Koka and Vera both make this argument from the language side. A semantic artifact takes the same idea seriously enough to make it part of the artifact identity. It is verifiable. It carries obligations: properties that must hold, invariants that must be preserved, preconditions on inputs, postconditions on outputs. Some of these are dischargeable by SMT solvers. Some need proof kernels. Some can only be enforced at runtime. The artifact records which is which, and what evidence exists for each. It is reproducible. It declares its environment with enough precision that a meaning engine somewhere else, or the same meaning engine a year later, can replay it and get the same outputs. Wasm with the deterministic profile, Nix-pinned environments, content-addressed inputs, deterministic schedulers, this is the substrate that makes reproducibility a property rather than a hope. It is explainable. Execution emits a provenance graph. What ran, on what data, in what environment, with what assumptions, against what obligations, with what residual uncertainty. The provenance is part of the output, not a log file someone deletes after a week. The thing to notice about that list is that none of these properties is exotic. Every one of them already exists in some production system today. What does not exist yet is the synthesis. We treat them as add-ons around code. The argument I am making is that they are not add-ons. They are the artifact, and code is one rendering of it. The meaning engine</h2> If the artifact changes, the machine around it has to change too. Compilers were built for source text. Runtimes were built for binaries. Neither was built for typed, verifiable, provenance-rich semantic objects. The meaning engine is what fills that gap. I am using the term as a placeholder for a category, not for a single product. A meaning engine accepts a semantic artifact and: Elaborates it. Resolves references, links schemas, grounds entities, checks types and effects.</li> Verifies it. Discharges obligations against the right backend. Type checks first. SMT for decidable arithmetic and structural constraints. Proof kernels for the residual cases that need full mathematical certainty. Runtime contracts for the cases nothing else can decide.</li> Plans execution. Picks an environment. Pins a target. Chooses where to run, on what hardware, with what capability set.</li> Lowers to code. Wasm, native CPU, GPU kernels, distributed dataflow graphs, whatever the planner decided. Code becomes an output, not an input.</li> Executes deterministically. Capability-bounded, replayable, audited.</li> Explains. Emits a provenance graph alongside the result. Says what assumptions held, what proofs passed, what tests ran, what fell back to runtime checks, what remained uncertain.</li> </ol> The interesting reframing is the compiler itself. The old job of a compiler was to translate one notation into another. The job of a meaning engine is to materialize meaning into execution and to keep meaning intact across that materialization. Translation becomes a sub-task. The primary task is preservation. The semantic intermediate representation is where this lives or dies. I do not think the answer is “use LLVM IR with more comments.” LLVM IR is too low. It is already shaped around the mechanics of execution. We need a layer above it that carries domain meaning, obligations, and effects with first-class status. MLIR</a> is the most relevant existing infrastructure for this. It treats multi-level structure as the design center: dialects, regions, operations, progressive lowering. A meaning engine could plausibly use an MLIR-style dialect stack with a semantic dialect at the top and execution dialects at the bottom. That is an implementation question, not a thesis question, and I want to keep the two separate. A scientific experiment as an executable artifact</h2> Abstract claims about new artifacts age badly. The argument has to survive contact with concrete domains. The first place I would point is science. Take a differential expression analysis from RNA sequencing. Today, the artifact that runs is some combination of: a Snakemake or Nextflow workflow, a Conda environment file, a few R scripts, a Jupyter notebook with the figure-generation logic, a README that explains how to run it, and a PDF describing the methods for the eventual paper. The “program” is spread across all of these, and the relationships between them are mostly informal. People have been trying to fix this. The Common Workflow Language</a> standardizes the workflow part. RO-Crate</a> packages methods, data, outputs, and identifiers together. PROV-O</a> gives you a vocabulary for entities, activities, and agents. These are real progress, and they show that the field has been edging toward semantic artifacts for years. What is still missing is a single authoritative object that also carries assumptions, allowed environments, correctness obligations, and execution traces in one verifiable form. A semantic artifact for the same analysis would look more like this: artifact RNASeqDiffExp.v3 inputs { reads: FASTQ[] reference: GenomeRef alpha: Real where 0 < alpha <= 1.0 } assumptions { sha256(reference) == "9f8c1a..." paired_end(reads) same_instrument(reads) } outputs { counts: CountTable figures: FigureSet } effects { fs.read("reads/", "reference/") fs.write("results/") cpu.simd gpu.optional } obligations { deterministic_target = "wasm32-wasi" environment = "nix:sha256-7m..." p_adj_threshold(counts) <= alpha } plan { trim -> align -> quantify -> diffexp -> render } </code></pre> The syntax above is illustrative. The shape is the point. What this artifact gives you that a workflow file plus a README does not: a reviewer can inspect the assumptions directly. A lab can replay the artifact against the pinned environment and reproduce the figures byte for byte. An auditor can ask whether GPU execution changed numerical behavior and get a defensible answer. A future model can propose an optimization, and the meaning engine can reject the optimization automatically if it weakens any obligation. The provenance graph it emits is the methods section of the paper, machine-checkable, not a paragraph somebody wrote at midnight before submission. The artifact does not have to make every claim machine-decidable. It only has to make explicit which claims are decided how. That is already a significant improvement over the current state, where most of those distinctions live in tribal knowledge. A contract as an executable artifact</h2> The second domain I would point to is the one where words and computation already overlap uncomfortably: legal and financial agreements. There is real prior art here. The Accord Project</a> models contracts as text plus a data model plus executable logic. The Common Domain Model</a> treats financial products and lifecycle events as machine-readable, machine-executable domain objects. Smart contracts, in their actual industrial form rather than the crypto-bro form, have been heading in this direction for a decade. The honest statement is that legal language will never be fully decidable. Many clauses are intentionally ambiguous. Many require human judgment. That is not a bug. It is how the institution works. But a semantic artifact does not require full decidability. It requires that the boundaries between decidable and undecidable be explicit. Some clauses become parameters. Some clauses become executable logic. Some clauses remain text with cross-references into the structured part. The artifact records which is which. contract FixedRateLoan.v1 parties { lender, borrower } terms { principal: Money where principal > 0 rateAPR: Percent where 0 <= rateAPR <= 0.25 termMonths: Nat where termMonths > 0 } preconditions { kyc_clear(borrower) sanctions_clear(borrower) } obligations { monthly_payment(m) = amortize(principal, rateAPR, termMonths, m) total_paid = principal + total_interest(principal, rateAPR, termMonths) } effects { ledger.post notice.send archive.write } evidence { jurisdiction = "CH" execution_target = "wasm-ledger" text_reference = "Loan_2026_03_15.pdf#sha256:4b2a..." } </code></pre> A loan agreement, in this form, is verifiable in the parts that should be verifiable, executable in the parts that should be executable, and traceable back to the natural-language contract for the parts that are not either. A bank can check on every payment that the obligations still hold. An auditor can ask why a specific posting happened and get a provenance graph that points back to the artifact and the inputs. A regulator can require a class of contracts to demonstrate certain invariants without reading every contract by hand. This is a much more serious model of “smart software” than the casual conflation of code with policy that the smart-contract era encouraged. The point is not that every rule becomes automatic. The point is that the system can tell you, without ambiguity, which rules it can enforce, which rules it can only check, and which rules a human still has to interpret. What current systems already get right</h2> I want to be careful here, because the easy mistake is to write this kind of essay as if nothing existing matters and everything has to be invented from scratch. That is wrong. Most of the pieces of a meaning engine already exist. They are scattered across systems that solved one face of the problem each. The synthesis is what is missing. Vera</a> optimizes for the generation loop. It makes syntax canonical, contracts mandatory, effects explicit, verification part of the normal compilation pipeline, and Wasm the default execution target. It is, in my framing, the best current example of “language designed for machine authorship.” It is not yet a meaning engine because the source text remains the artifact of authority. But the discipline it imposes on the artifact is exactly the discipline a semantic artifact needs. BHC</a> (the bridge Haskell compiler I have written about elsewhere) optimizes for the typed substrate and the deployment surface. Multi-stage IRs, a Core layer that survives across lowerings, profile-specific runtime contracts, multiple backends from native to Wasm to GPU. It treats semantic preservation across lowering as a first-class goal, which is the exact discipline a meaning engine needs at the lowering layer. It is still source-language-centered, by design. That is its scope. Dafny</a> and Lean</a> push hardest toward proof-bearing semantics. Dafny puts specifications inside the language and uses SMT to discharge them. Lean has a minimal trusted kernel and builds proof automation on top. They show what the upper bound of “verified meaning” looks like in practice. They are not yet the substrate for cross-domain artifacts, deterministic deployment, and provenance packaging, but they set the standard for what the verification layer of a meaning engine should aspire to. Koka</a> and similar effect-typed languages show that you can keep effect information at the type level without giving up performance. Effects in the type signature, not just in the function body. That is the model the artifact needs at the meaning layer. MLIR</a> shows that a multi-level dialect stack is a workable architecture for keeping high-level structure across lowering. A semantic IR sitting above MLIR-style dialects is a plausible engineering path. Wasm</a> and WASI</a>, with the recent deterministic profile</a> work and tooling like Wasmtime’s determinism guide</a>, give us a portable, sandboxed, increasingly deterministic execution target. This is the substrate that makes “replay this artifact and get byte-identical outputs” feasible without operating-system heroics. Nix</a> gives us declarative, reproducible, isolated environments. The pinning story is mature. The integration story is still rough. But the building block is real. PROV-O</a>, RO-Crate</a>, and CWL</a> give us standards for provenance, packaging, and portable workflows, particularly in the scientific domain. They are evidence that “explainability as a structural property of the artifact” is not science fiction. It is the way some communities already work. Unison</a> gives us content-addressed, structured code identity. This is the lesson the rest of us still have not fully internalized: identity should not depend on filenames or formatting. If I were to draw the comparison shortly: Vera optimizes the generation loop. BHC optimizes the typed substrate. Dafny and Lean optimize formal truth. Wasm and Nix optimize deterministic deployment. PROV and RO-Crate optimize provenance. Unison optimizes structural identity. None of them is the future on its own. The future is the synthesis. From compilers to meaning engines</h2> The reframing I find most useful is to put the old pipeline next to the new one and look at what changes. Old pipeline ============ source code -> compile -> binary -> run New pipeline ============ intent | v elaborate ---> semantic artifact | (typed, content-addressed, | effects explicit) v verify ---> obligation graph | (proved | tested | runtime) v plan ---> execution plan | (env pinned, target chosen, | capabilities bounded) v lower ---> Wasm | native | GPU | distributed | v execute ---> results | v explain ---> provenance graph</code></pre> Every stage matters, and every stage has explicit outputs. Elaboration produces a fully grounded semantic artifact. Verification produces a graph of discharged and residual obligations. Planning produces a deterministic execution plan with a pinned environment and a capability set. Lowering produces target-specific code as one of several possible outputs. Execution produces results plus a provenance graph. Explanation reads the provenance graph and answers questions about why the system did what it did. The execution trace becomes a first-class output, not a side effect. Today, a stack trace exists because something went wrong. In a meaning engine, an execution trace exists because something happened, and the system promises to be able to reconstruct it later. The compiler does not disappear. It moves. It becomes one stage of a larger pipeline, and the pipeline is what people interact with. Why this is bigger than programming</h2> I want to zoom out for one section, because the trilogy has been quietly building toward a claim that is not really about programming languages at all. Writing systems have changed several times. Oral tradition gave way to written records. Manuscripts gave way to print. Print gave way to digital text. Each transition expanded the scale and durability of what humans could record, distribute, and act on collectively. Each transition reshaped institutions in ways that took decades to settle. We are in the early phase of another transition. We are moving from systems that record knowledge to systems that execute knowledge. A scientific paper is a record. A semantic artifact for a scientific experiment is an execution. A legal contract is a record. A semantic artifact for a financial product is an execution. An infrastructure runbook is a record. A semantic artifact for the same operational behavior is an execution. This is the civilizational layer of the argument, and I am stating it deliberately even though it is uncomfortable. The shift from text-as-record to text-as-execution will be at least as large as the shift from manuscript to print. It will not be the same as previous transitions, because it is happening on infrastructure we built and partially understand, not on infrastructure that emerged organically over centuries. But the order of magnitude is similar. If that framing is even half right, “what programming language should we use” is a small question. The big question is what kinds of institutions we are willing to build on top of artifacts that are themselves executable. The role of humans</h2> If we do not write code, what do we do? This is a fair question, and I want to answer it directly rather than dodge it. We define constraints. We shape intent. We evaluate outcomes. We design systems of meaning. We argue about which obligations matter and which assumptions are reasonable. We negotiate the boundaries between automated and human-decided parts of an artifact. We decide which evidence is acceptable and which is not. This is a different job. It is closer to architecture than to authorship. The unit of work is the obligation, not the function. For people who like writing code, this is going to feel like a loss. I understand. I like writing code too. But the historical pattern is clear. Each abstraction layer demoted the layer below it from “primary skill” to “specialized skill.” Assembly programming did not disappear when C arrived. It became the thing a small number of people did when it really mattered, in compilers, in kernels, in performance-critical hot paths. The same is going to happen one layer up. Most people will stop authoring code as the primary artifact. Some people will keep doing it, where it really matters, and they will be more important to the field, not less. The work that gets more interesting, in this picture, is the work of building meaning engines themselves. The substrate is wide open. There is room for many designs. The decade ahead is going to look more like the early compiler era than like the late framework era. That is a good time to be working on infrastructure. Implications for builders right now</h2> The migration is staged. The way I think about the timeline: Near term Medium term Long term (now) (2-3 years) (3-10 years) Semantic -> Artifact core -> Multi-target sidecars lowering - specs beside - content- - Wasm/WASI first the code addressed - native CPU - pinned envs identity - GPU kernels (Nix) - typed effects - distributed DAGs - provenance - obligation (PROV-O) graphs Artifact-first - deterministic - graded domains replay (Wasm) verification - science - contracts Improve auditability Make the artifact - infra policy without abandoning the review surface - audit/compliance the current stack</code></pre> I do not want to leave this post in the air. The trilogy has been escalating, and each step has been more speculative than the last. This post is the most speculative of the three. It is fair to ask what any of this implies for what we should be doing in 2026, not in 2036. A few things I think are already actionable. Take semantic sidecars seriously. If you are shipping software in any regulated or critical domain, you can already start writing artifact manifests that bind your code to its assumptions, its allowed effects, its pinned environment, its provenance, and its replay instructions. You do not need a new compiler to do this. You need discipline and a few tools that already exist. Nix and Wasm are good starting points. PROV-O is a usable vocabulary. The investment compounds. Treat reproducibility as a property, not a hope. If you cannot replay your artifact deterministically, you do not have a semantic artifact. You have a hope. Wasm with the deterministic profile, Nix-pinned environments, content-addressed inputs, and deterministic schedulers are the building blocks. The cost of getting there is real but bounded, and the gains in audit, debugging, and incident response are immediate. Make effects explicit. You do not need a new language to do this. You can do it with discipline in the language you already use. Module boundaries that separate pure from effectful code are not exotic, they are just unfashionable in some communities. The discipline is what matters. The syntax is downstream. Stop treating proof and test and observation as the same thing. They are not. A proven property, a tested property, and an observed property carry different weights. A meaning engine has to keep them separate. You can start keeping them separate yourself, in code review and in design review, today. Invest in IRs more than in syntax. The next decade of leverage is in the layer above LLVM IR and below user-facing source. If you are building tools for software development, this is where the interesting work is. The tooling that wins will preserve more meaning than today’s compiler stacks do. If you build infrastructure, the heuristic is simple. Anywhere your team is currently relying on “shell scripts plus a README plus a notebook plus a PDF plus tribal knowledge” to encode a process, that is a candidate for a semantic artifact. Pick one such process, and try to model it as an artifact instead of as a pile. Open questions I do not pretend to have settled</h2> I am stating the thesis confidently, but I want to be honest about what I do not know. I do not know the exact shape of the semantic IR. I have a bias toward an MLIR-style dialect stack with a semantic dialect at the top, augmented with effect typing, content-addressed identity, and explicit obligations. A content-addressed term graph in the Unison style is a credible alternative. A two-part design with a logical core plus an executable planning layer is another. The winning design is probably hybrid. I would rather present the question honestly than fake an answer. I do not know how much proof to demand before execution. Too much proof and the system is unusable. Too little and the artifact loses its claim to authority. Vera’s split between static proof and runtime fallback is realistic. Lean’s kernel model is the strongest, and the slowest. The right answer is graded, not absolute, and it will probably depend on the domain. I do not know how distributed execution fits in. Wasm gives us a portable substrate. WASI gives us a capability model. Content addressing gives us identity. None of these solves scheduling, data locality, and semantic replay across clusters. That is an implementation frontier, not a hole in the thesis, but it is a frontier and I want to flag it as one. I do not know which domains move first. My best guess is the domains that already pay most of the cost of ambiguity today: scientific workflows, regulated finance, compliance and audit, infrastructure policy, and certain parts of public-sector procurement. Domains where the gap between “what we wrote” and “what we ran” is currently catastrophic when something goes wrong. I would not be surprised if those domains develop their own meaning engines first, and a general-purpose substrate emerges as the synthesis a few years later. I do not know how long the migration takes. My only confident claim about timing is that it does not arrive by deleting today’s stacks. It arrives by moving semantics upward, year by year, until the artifact most teams care about is no longer a tree of source files. Closing</h2> We called them programming languages because we thought we were speaking to machines. In reality, we were translating ourselves into a form machines could tolerate. The notation was a compromise between what we could write and what they could lower. Now that machines can understand us more directly, the question is not how to write better code. The question is how to think in systems that can be executed. The artifact we author should preserve meaning, not perform it. The runtime should keep that meaning intact, not erase it during translation. Code does not disappear in this story. It drops a layer. It becomes implementation detail, escape hatch, optimization substrate, foreign-function boundary. Important. Powerful. Not primary. The trilogy ends here, in the same place each transition in computing has ended. The previous artifact survives, demoted, while a higher layer takes over the work of authority. Source code joins assembly in the long list of things that used to be the thing and now are something we lower to. The interesting work, for the rest of this decade, is at the layer above. That is where I am spending mine. Further reading</h2> The systems already pointing at parts of this future, grouped by the dimension each one gets right. Semantic IRs and structural identity. The argument that artifact identity should not depend on filenames, and that compiler stacks should preserve high-level structure across lowering, already has working precedent. MLIR</a> for multi-level dialect stacks</li> Unison</a> for content-addressed code</li> </ul> Verification. What it looks like to push specifications and proofs into the artifact, with three different bets on how strict the proof obligation should be. Dafny</a> for specs in the language, SMT-backed</li> Lean</a> for a minimal trusted kernel and proofs as terms</li> Vera</a> for Z3 on decidable cases and runtime fallback for the rest</li> </ul> Typed effects. The case for putting side effects into the type rather than hiding them in the function body. Koka</a> for row-polymorphic effects with handlers</li> Vera</a> for mandatory effect declarations on every function</li> </ul> Reproducible execution. What “the same artifact runs the same way somewhere else, a year later” actually requires in production. WebAssembly</a> and WASI</a> for portable, sandboxed, increasingly deterministic execution</li> Wasmtime determinism guide</a> for the concrete steps to byte-identical replay</li> Nix</a> for declarative, isolated, pinned environments</li> </ul> Provenance and packaging. The vocabulary for explaining what ran, on what data, in what environment, with what evidence. PROV-O</a> for entities, activities, and agents</li> RO-Crate</a> for artifact bundles with methods, data, and identifiers</li> Common Workflow Language</a> for portable, vendor-neutral workflows</li> </ul> Domain artifacts. The honest evidence that “software artifact” is too narrow a category for what comes next. Accord Project</a> for contracts as text plus data model plus logic</li> Common Domain Model</a> for financial products and lifecycle events as machine-readable, machine-executable objects</li> </ul> Patents Per Capita Is a Vanity Metric Unknown — Fri, 01 May 2026 00:00:00 +0000 It is the first of May, Labour Day. A holiday explicitly about work, which makes it a good day to ask whether the work that gets counted is the work that actually matters. Earlier this week I posted on LinkedIn about how Swiss innovation rankings tend to be illustrated with photos of Zurich, even though Basel produces a meaningful share of what those rankings reward. It performed better than most of my other shares there. Some of the feedback agreed. Some pushed back. Almost all of it stayed inside the same frame the rankings themselves set: which Swiss city deserves credit for the score. That is not the question I find interesting. The question I find interesting is what the score is measuring in the first place, and whether it is the score we should be optimising for. The LinkedIn format is not the right place to work that out. A long-form post on a Labour Day morning is. Switzerland topped the Global Innovation Index in 2025 for the fifteenth year in a row. The index is published annually by the World Intellectual Property Organization, the United Nations agency that administers the international patent system, and it ranks roughly 140 economies on how innovative they are. The 2025 press release went out in September. The country celebrated. Zurich’s skyline got photographed again. Roche and Novartis, the two Basel-headquartered pharmaceutical giants, were name-checked. ETH Zurich and EPFL, the country’s two federal technical universities, got their nods. The framing was the usual one: small country, outsized output, durable lead. I am Swiss. I am from Basel. I build infrastructure for a living, which means I spend a lot of time staring at dashboards that report how systems are performing in production. A number that sits at the top of a leaderboard for fifteen consecutive years should make any engineer who watches dashboards suspicious before it makes them proud. The metrics that look the smoothest the longest are usually the ones telling you the least about what is happening right now. This post is about why “most innovative country” is a vanity metric: a number that is real, and countable, and correlated with success, but that should not be the thing you optimise for. The Global Innovation Index measures yesterday extremely well. It does not measure today, and it tells you almost nothing about tomorrow. Traffic Replay as a Security Primitive Unknown — Mon, 27 Apr 2026 00:00:00 +0000 If you have ever tuned a WAF rule, you know the cycle. A rule triggers on legitimate traffic. You get paged. You look at the logs, which tell you the rule ID and the request path but not enough to reproduce what happened. You loosen the rule based on your best guess. You deploy. You wait. Next week, you get paged again, either because the rule is still too aggressive or because you loosened it too far and now something is getting through. The problem is not the WAF. The problem is that you are tuning a stateful, context-dependent system without the ability to reproduce the inputs that caused the behavior you are trying to change. You are debugging blind. This is not unique to WAFs. Every edge system that makes decisions about traffic, proxies, rate limiters, auth gateways, bot detectors, suffers from the same structural issue: the traffic that triggered the behavior is gone. It existed for the duration of the request, it was logged incompletely, and now you are making changes based on a partial reconstruction of what happened. Traffic replay solves this. Not as a testing tool. As a security primitive. What replay actually means</h2> Traffic replay, in the sense I mean it here, is not load testing. It is not generating synthetic traffic that looks like production. It is capturing real requests as they happened, in order, with their headers and bodies intact, and re-executing them against a target environment deterministically. The distinction matters. Load testing answers “can this system handle the volume?” Replay answers “will this system make the same decisions about the same traffic?” One is about throughput. The other is about behavior. A replayed request hits the same WAF rules, the same rate limits, the same routing logic as the original. If the original was blocked, you can see whether the replay is also blocked, and if not, exactly what changed. If you modify a rule and replay the same traffic, you get a direct comparison: old behavior versus new behavior, same inputs, different configuration. This is the primitive that WAF tuning has always been missing. Not better logs. Not more dashboards. The ability to say “here is the exact traffic that caused the problem, and here is what happens when I change the rule.” The capture problem</h2> The first obstacle is getting the traffic into a replayable format. Production traffic is ephemeral. It arrives, gets processed, and disappears. Logs capture metadata: timestamps, status codes, paths, maybe some headers. They do not capture the full request as a replayable artifact. There are two practical approaches. The first is capturing at the browser. Every modern browser can export a session as a HAR (HTTP Archive) file. This gives you the complete request and response for every HTTP transaction in a session: method, URL, headers, body, timing. When a user reports “this request was blocked,” you can ask them for a HAR export. You now have the exact traffic, not a description of it. The second is capturing at the proxy. If your reverse proxy or load balancer can mirror traffic to a capture endpoint, you get production-representative traffic without depending on user cooperation. This is more complex to set up but gives you continuous coverage rather than incident-by-incident captures. Either way, the result is the same: a sequence of HTTP requests that can be replayed faithfully. Replay is not as simple as resending</h2> There are subtleties that make naive replay useless. The obvious one is URLs. If you captured traffic hitting production.example.com</code> and want to replay it against staging.example.com</code>, you need to rewrite the host. But you also need to rewrite any absolute URLs in headers like Origin</code> and Referer</code>, and potentially in request bodies for APIs that include callback URLs. Then there are cookies. A replayed request with production session cookies will either fail authentication on staging (different session store) or, worse, succeed against a production session you did not intend to touch. Cookie stripping is not optional. It is a safety requirement. Headers need mutation too. You might need to inject an authorization token for the staging environment, or add a header that tells the WAF “this is a replay, do not count it toward rate limits.” You might need to strip headers that identify the original client IP to avoid polluting analytics. And ordering matters. If request B depends on state created by request A (a login followed by an authenticated action), replaying them in parallel or out of order produces meaningless results. Deterministic replay means sequential, in capture order, by default. None of this is algorithmically hard. But getting it wrong in any of these dimensions produces results that are misleading rather than useful. A replay tool that does not handle URL rewriting, cookie stripping, header mutation, and ordering is a footgun, not a primitive. The diff is the point</h2> Replay alone is useful. Replay with behavioral diffing is what changes the WAF tuning workflow. The pattern works like this. You have a set of captured traffic. You replay it against environment A (say, production with the current WAF rules) and save the results. You replay the same traffic against environment B (staging with the proposed rule change) and save those results. Then you diff. The diff is not a text diff. It is a behavioral diff. For each request in the capture, you compare: Status codes: did the same request get a 200 in one environment and a 403 in the other?</li> WAF decisions: did the WAF block in one and allow in the other? Which rule ID? What score?</li> Security headers: did CSP, HSTS, or X-Frame-Options change between environments?</li> Response characteristics: same content type? Same cache behavior?</li> </ul> Request: GET /api/v2/users?search=<script>alert(1)</script> Production (current rules): Status: 403 x-waf-action: block x-waf-rule: 941100 Staging (proposed rules): Status: 200 x-waf-action: pass x-waf-rule: (none) ⚠ WAF regression: XSS payload now passes </code></pre> This changes the WAF tuning conversation entirely. Instead of “I think loosening rule 941100 is safe,” you have “I replayed 2,000 captured requests against the proposed rule change. Three requests that were previously blocked are now allowed. Here they are. Two are false positives that should pass. One is an XSS payload that should not.” That is not a guess. That is evidence. Why this is a security primitive</h2> I use the word “primitive” deliberately. A primitive is a building block that other things compose on top of. Deterministic replay with behavioral diffing is a primitive because it enables patterns that are otherwise impractical: Safe WAF rule iteration. Change a rule, replay traffic, inspect the behavioral diff, deploy with confidence. The feedback loop goes from “deploy and hope” to “verify, then deploy.” This is the most immediate use case, and the one that solves the 3 AM pager problem. Environment drift detection. Replay the same traffic against staging and production on a regular schedule. When the behaviors diverge, you know something changed that should not have. This catches configuration drift, certificate mismatches, and routing differences before they become incidents. Regression testing for edge config. Every change to your proxy, WAF, or rate limiter configuration gets a replay run before deployment. The diff tells you exactly what changed in observable behavior. This is the edge infrastructure equivalent of a unit test suite, except instead of testing code you are testing policy. Incident reproduction. When a user reports a block, capture the traffic, replay it, confirm the block, and then iterate on the fix in staging without affecting production. The time from “user report” to “verified fix” drops from hours to minutes. Compliance evidence. When an auditor asks “how do you know your WAF rules are working?”, you can show them replay runs with behavioral diffs that demonstrate which rules triggered on which traffic patterns. Not “we have a WAF configured.” Verifiable behavioral evidence. Each of these patterns exists in some ad-hoc form at organizations that invest heavily in security tooling. What they lack is a common primitive that makes them systematic. What exists today</h2> There is no shortage of tools that touch parts of this problem. The gap is in how they compose. Manual security testing platforms. Burp Suite</a> is the standard. Its Repeater lets you capture a request and resend it with modifications, which is replay in the most literal sense. OWASP ZAP</a> provides similar capabilities as open source. Both are excellent for manual pen-testing: an engineer investigates a specific request, tweaks parameters, observes the response. What they do not do is automated, batch-level behavioral comparison across environments. You can replay one request in Burp and inspect the result. You cannot replay two thousand requests against staging and production and get a structured diff of every WAF decision that changed. The workflow is manual and investigative, not systematic and CI-integrated. Traffic capture and replay tools. GoReplay</a> (gor) captures live HTTP traffic and replays it against another environment. It is the closest existing tool to what I am describing, and it is good at what it does: mirroring production traffic to a staging environment for load and correctness testing. mitmproxy</a> can intercept, record, and replay HTTP flows with full scriptability. tcpreplay</a> operates at the TCP level for network-layer replay. The limitation across all of these is that they are replay tools, not behavioral analysis tools. They send the traffic. What happens next, comparing WAF decisions, diffing security headers, detecting regressions, is left to you. Desktop proxies. Charles Proxy</a> and Fiddler</a> capture and replay HTTP traffic with rich GUIs. They are useful for development debugging but are desktop applications, not CLI tools. They do not integrate into CI/CD pipelines or produce machine-readable behavioral diffs. Load testing tools. k6</a>, Locust</a>, Gatling</a>. These can replay captured traffic at volume, but they measure performance, not policy behavior. They answer “can the system handle the load?” not “did the WAF make the same decision?” WAF testing frameworks. ftw</a> (Framework for Testing WAFs) is the OWASP project for validating Core Rule Set behavior. It uses synthetic payloads designed to trigger specific rules. Nuclei</a> is a template-based vulnerability scanner that sends crafted requests and checks responses. Both are valuable for validating that your WAF blocks known-bad patterns. Neither replays real captured traffic, which means neither can tell you whether a rule change affects the legitimate traffic that your actual users send. API testing tools. Hurl</a> can chain HTTP requests with assertions, which is close to sequential replay with verification. curl</a> can resend individual requests. Both are useful building blocks but do not provide the capture-replay-diff workflow as a single primitive. The pattern across all of these is the same. Each tool handles one or two steps well: capture, or replay, or analysis. No single tool captures real traffic, replays it deterministically with URL rewriting and cookie stripping, and then produces a structured behavioral diff across WAF decisions, security headers, and status codes. The pieces exist. The composition does not. This is the gap that Ushio</a> fills. Ushio is a Rust CLI that does three things. It converts HAR files into a replayable capture format. It replays captures against one or more targets with URL rewriting, header mutation, and cookie stripping. And it diffs two replay results to identify behavioral changes in status codes, WAF decisions, and security headers. # Convert a browser HAR export to ushio format ushio convert session.har -o capture.json # Replay against staging with auth header, strip cookies ushio replay capture.json \ -t https://staging.example.com \ --header "Authorization:Bearer $TOKEN" \ --strip-cookies \ -o staging.json # Replay against production ushio replay capture.json \ -t https://prod.example.com \ --strip-cookies \ -o prod.json # Diff the results ushio diff staging.json prod.json --only-diff </code></pre> The output is either pretty-printed for human review or JSON for pipeline integration. Exit code 0 means no behavioral differences. Exit code 1 means differences were found. This makes it composable with CI/CD: run a replay diff on every edge config change, fail the pipeline if behavior regresses. What changes when you have this</h2> The shift is from reactive to proactive. Without replay, you discover WAF problems when users report them or when the pager goes off. With replay, you discover them before deployment. The feedback loop compresses from incident-driven to change-driven. But the deeper shift is epistemic. Without replay, WAF tuning is a matter of judgment and experience. You read the rule, you read the logs, you make a call. With replay, it is a matter of evidence. You replay the traffic, you observe the behavior, you make a decision based on what actually happened. I do not think this replaces judgment. You still need to decide whether a particular request that is now being allowed is acceptable. But the decision is grounded in concrete behavior rather than reconstruction from incomplete logs. The security engineer’s job changes from “guess what the WAF will do” to “observe what the WAF does and decide if that is correct.” Every edge system that makes decisions about traffic should be testable with real traffic. WAFs, rate limiters, bot detectors, auth gateways. If you cannot replay traffic and diff the behavior, you cannot systematically verify that the system does what you think it does. That is not a tooling problem. That is a visibility problem. And it is solvable. References</h2> Ushio</a> - Deterministic edge traffic replay tool</li> Zentinel</a> - Security-first reverse proxy with structured WAF decision logging</li> HAR 1.2 specification</a> - The HTTP Archive format</li> What Zentinel Is Really Optimizing For</a> - The operator-first proxy design philosophy</li> Notes from RSAC 2026</a> - Where the applied security thread connects to industry context</li> </ul> The Economics of Inference Unknown — Wed, 22 Apr 2026 00:00:00 +0000 In the previous article</a>, I described running sixteen AI agents as a virtual company over Christmas 2025. The architecture worked. The coordination model worked. What did not work was the economics. My token budget evaporated in days, not because the agents were unproductive, but because every act of coordination, every status update, every escalation consumed a metered resource that I could not replenish fast enough. At the time, I framed this as a budget problem. My consumer subscription could not sustain the overhead of agent-to-agent communication. An enterprise with API access and a real budget would not have the same constraint. That framing was correct, but it was also too small. What I was actually experiencing, at the scale of one person and sixteen terminal panes, was something much larger. I was experiencing inference as a utility. A consumed physical resource, the same way I consume electricity when I turn on a light and water when I open a tap. That framing changes everything about how you think about the economics of AI. What makes something a utility</h2> Utilities share a set of properties that distinguish them from ordinary goods and services. They are not optional. Modern life depends on them. They are consumed continuously, not purchased once. They require massive physical infrastructure to produce and deliver. They are metered. They are priced per unit of consumption. Their supply chains are subject to geography, geopolitics, and regulation. And their cost structure is dominated by the capital expenditure of building and maintaining the infrastructure, not by the marginal cost of the next unit delivered. Water. Electricity. Natural gas. Telecommunications. These are the four traditional utilities. Every modern economy is built on top of them. Their availability, reliability, and cost determine what is possible in a given jurisdiction. You do not build a semiconductor fab where the power grid is unreliable. You do not run a data center where the water supply for cooling is uncertain. The utility layer is the foundation, and everything above it is constrained by what the foundation can support. Inference is acquiring every one of these properties. It is consumed continuously. Every agent interaction, every model call, every token generated is a unit of consumption. When my sixteen agents were coordinating, they were consuming inference the way a factory floor consumes electricity: steadily, measurably, and in direct proportion to the work being performed. It requires massive physical infrastructure. The data centers running frontier models are among the most capital-intensive facilities being built anywhere in the world right now. They require advanced silicon, enormous quantities of power, water for cooling, and physical security. They are not software projects. They are industrial projects. It is metered and priced per unit. Every major inference provider charges per token. Input tokens, output tokens, sometimes with different rates for different capability tiers. The billing model is already a utility billing model. You pay for what you consume. Its supply chain is subject to geography and geopolitics. Chips, data, talent, energy</h2> At RSAC 2026, I attended a panel with four former NSA directors and US Cyber Command commanders. Paul Nakasone laid out what he considers the four factors that determine a nation state’s strategic potentiality in this era. Not GDP. Not military strength. Four things: chips, data, talent, and energy. I wrote about this</a> at the time. But I have been thinking about those four factors through a different lens since the shiioo experience. Nakasone was talking about national power. I am talking about the supply chain of a utility. Every utility has a supply chain that determines who can produce it, at what cost, and with what dependencies. For electricity, the supply chain is fuel (coal, gas, uranium, sunlight, wind), generation infrastructure (power plants, turbines, panels), transmission (the grid), and distribution (the last mile to your outlet). For water, it is source (rivers, aquifers, desalination), treatment, transmission (pipes, pumps), and distribution. For inference, the supply chain is Nakasone’s four factors. Chips are the generation capacity. Advanced GPUs, specifically the frontier silicon manufactured overwhelmingly by TSMC in Taiwan and designed primarily by NVIDIA in the United States, are the turbines of the inference economy. Without them, you do not generate inference at competitive cost. The global concentration of this manufacturing capacity in a single facility on a geopolitically contested island is the equivalent of the entire world’s electricity depending on one power plant. It is a single point of failure that makes infrastructure planners lose sleep. Energy is the fuel. Frontier inference is measured in gigawatts now, not megawatts. A single large-scale inference cluster draws more power than a small city. The AI 2027</a> scenario projects global AI datacenter power consumption reaching 38 GW by 2026, and that number is rising on a curve that shows no sign of flattening. You cannot run inference without power, and you cannot build the power infrastructure overnight. The jurisdictions that have cheap, abundant, reliable energy have a structural advantage that no amount of software cleverness can compensate for. Data is the raw material that the models learned from, the substrate that makes inference meaningful rather than random. Who has it, under what legal constraints it can be used, and how diverse and representative it is all determine the quality and applicability of the inference you can produce. Talent is the operational workforce. Not just the researchers who design the models, but the engineers who build the infrastructure, the operators who keep it running, and the security professionals who defend it. This is the human capital layer that every utility depends on, and it is concentrated in a handful of geographic clusters for the same reasons that petrochemical engineering talent concentrates near refineries. When you map it out, inference has the same supply chain structure as any mature utility. And the strategic implications follow directly. Supply chain layer</th> Electricity</th> Water</th> Inference</th></tr></thead> Raw input</td> Fuel (gas, uranium, sun)</td> Source (river, aquifer)</td> Data (training corpora)</td></tr> Generation</td> Power plants, turbines</td> Treatment plants</td> GPUs, data centers</td></tr> Transmission</td> The grid</td> Pipes, pumps</td> Networks, API endpoints</td></tr> Fuel for generation</td> Primary energy</td> Electricity for pumping</td> Electricity (38+ GW)</td></tr> Key bottleneck</td> Grid capacity, permits</td> Water rights, drought</td> Chip fabrication (TSMC)</td></tr> Geopolitical risk</td> Pipeline politics, OPEC</td> Cross-border rivers</td> Taiwan, export controls</td></tr> </tbody></table> The analogy is not a metaphor. It is a structural description. What AI 2027 got right about the economics</h2> The AI 2027</a> scenario, written by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean, is a speculative timeline. The authors are careful to frame it that way. But the economic projections in it have a quality that I keep returning to: they treat AI compute as an industrial resource, not a software product. Their scenario tracks global AI datacenter spending reaching the trillion-dollar range. It maps the distribution of frontier compute capacity across nations, with the United States holding roughly 70% through its companies and China at around 12%. It projects power consumption figures that match what utility planners, not software engineers, would recognize as relevant. What makes this framing useful is not the specific numbers. It is the category. When you project AI spending in trillions and power consumption in tens of gigawatts, you are not describing a software industry. You are describing a utility buildout. The capital expenditure patterns, the infrastructure timelines, the regulatory questions, the geopolitical competition, all of it maps to how nations have historically competed over energy infrastructure, telecommunications infrastructure, and industrial capacity. The AI 2027 authors project that the feedback loop of AI systems accelerating AI research compresses the timeline for capability growth. Whether their specific dates hold is less important than the structural observation: if capability is growing on a steep curve and that capability requires physical infrastructure that grows on a much slower curve, then the binding constraint on AI is not software. It is infrastructure. It is the utility layer. This is what I experienced at the personal scale with shiioo. The software worked. The orchestration model worked. What ran out was the physical resource: tokens, which is to say inference, which is to say compute, which is to say silicon and electricity. The bottleneck was not the architecture. The bottleneck was the meter. What this means for post-AI systems</h2> If inference is a utility, then every system that depends on inference is a utility consumer. And that changes how you design those systems. When I built shiioo, I treated token consumption as a budget to manage. That was the individual developer framing: I have a fixed allocation, I need to spend it wisely. But if you zoom out to the enterprise or the nation state, the framing shifts. You are not managing a budget. You are managing a utility dependency. The questions become infrastructure questions. How much inference capacity do you need? Where does it come from? What happens when your provider has an outage? What are your contractual guarantees for availability and throughput? What is your fallback if the primary supply is interrupted? Do you own any generation capacity, or are you entirely dependent on external providers? These are exactly the questions that enterprises ask about electricity, about water, about telecommunications. And they are starting to ask them about inference, even if most of them do not yet use that framing. The organizations that will navigate this transition well are the ones that recognize what inference actually is: a consumed resource that correlates with power draw, requires physical infrastructure, and generates value in the form of information contextualization and evaluation. Every time a post-AI system communicates with another system or with a human, it is consuming inference. Every agent-to-agent message, every model evaluation, every generated response is a unit drawn from a metered supply that has real physical costs behind it. The implications branch in several directions. Pricing will converge toward utility models. Per-token pricing is already the norm, but the industry will move toward the more sophisticated pricing structures that utilities use: tiered rates, time-of-use pricing, capacity reservations, spot markets. Some of this is already emerging. It will accelerate as enterprises start treating inference spend the way they treat energy spend: as a major operational cost that requires dedicated procurement and optimization. Sovereignty will matter. If inference is a utility, then depending on a foreign provider for your inference supply is the same kind of strategic vulnerability as depending on a foreign country for your energy supply. Europe learned this lesson with Russian natural gas. The question of whether you can run inference workloads within your own jurisdiction, on your own infrastructure, under your own legal framework, is not an abstract concern about data residency. It is a question of infrastructure sovereignty. This is why I built Archipelag</a>, and it is why I think the compute sovereignty conversation in Europe needs to move from policy papers to physical infrastructure. Efficiency will become an engineering discipline. When electricity was cheap and abundant, nobody optimized for energy efficiency. When it became expensive, an entire engineering discipline emerged around it. The same will happen with inference. Right now, most systems that use inference do so profligately, full context windows, verbose prompts, redundant calls. As inference cost becomes a meaningful line item, optimizing for token efficiency will become as normal as optimizing for energy efficiency. The structured communication protocols I described in the shiioo article, typed messages instead of free-form conversation, are an early example of this. Every token should carry information, not politeness. Metering and observability will be essential. You cannot manage a utility you cannot measure. Enterprises will need inference observability the same way they need power monitoring and network monitoring: real-time visibility into consumption, cost attribution to specific workloads and teams, anomaly detection for unexpected usage spikes, and capacity planning based on historical patterns. The tooling for this barely exists today. It will be a significant market within a few years. The meter is the message</h2> When I ran out of tokens over Christmas, my first reaction was frustration. My second reaction was to think about the architecture differently, to design for token efficiency, to route cheap communication through cheaper models. But my third reaction, the one that has stayed with me longest, was recognition. I recognized the shape of the problem. It was not a new shape. It was the shape of every utility constraint I have ever encountered. The shape of “the infrastructure is the bottleneck.” The shape of “the resource is finite and metered and you need to think about your consumption.” The shape of “the supply chain is geopolitical.” Nakasone’s four factors, chips, data, talent, energy, are not just a framework for assessing national power. They are the bill of materials for producing inference. And the nations, enterprises, and individuals who control that bill of materials will have the same structural advantage that energy-rich nations had in the industrial age and bandwidth-rich nations had in the information age. The fifth utility is here. We are just early enough that most people still think they are buying software. References</h2> What Sixteen AI Agents Taught Me About Management</a> - The predecessor to this article</li> Notes from RSAC 2026</a> - Paul Nakasone’s four factors and the geopolitical dimension</li> AI 2027</a> - Scenario work by Kokotajlo, Alexander, Larsen, Lifland, and Dean</li> Archipelag</a> - Decentralized, sovereignty-first AI compute network</li> How I Work These Days</a> - Where I first wrote about the shift to agent-driven development</li> </ul> What Comes After the Last Programming Language Unknown — Sun, 19 Apr 2026 00:00:00 +0000 In The Last Programming Language Might Not Be for Humans</a>, I described three futures for programming languages as AI becomes the primary author of code. Explicit languages for machines. Declarative languages where types are proofs. And ultimately, no language at all, where AI generates machine code directly and the intermediate layer disappears. I left something out. There is a fourth possibility, and it goes deeper than the language. What happens to the operating system? The operating system was designed for typists</h2> Every operating system in production today, Linux, Windows, macOS, the BSDs, was built on the same foundational assumption: a human writes a program, the program is compiled into a sequence of CPU instructions, and the OS manages the execution of those instructions. Processes. Threads. System calls. Virtual memory. File descriptors. Schedulers. These abstractions exist because the fundamental unit of work is a sequence of CPU operations authored by a human programmer. This is not an exaggeration. Look at the POSIX specification. fork()</code> creates a copy of the calling process. exec()</code> replaces the current process image with a new program. read()</code> and write()</code> move bytes between a process and a file descriptor. mmap()</code> maps a file into the process’s virtual address space. Every one of these primitives assumes a CPU-centric, sequential execution model where a process is a container for a stream of instructions that the CPU executes one at a time (or a few at a time, with threads). This made sense for sixty years. Dennis Ritchie and Ken Thompson designed Unix in 1969 around the PDP-7, a machine with a single CPU and 18-bit words. The abstractions they chose, processes, pipes, files as byte streams, were elegant reflections of what the hardware could do. Those abstractions survived because they generalized well. When CPUs got faster, processes got faster. When CPUs got more cores, threads mapped naturally onto them. When networks arrived, sockets extended the file descriptor model. The operating system grew, but the foundational unit of work never changed: a sequence of CPU instructions, managed by a scheduler, isolated by virtual memory. How the GPU became an accidental general-purpose computer</h2> The GPU was never meant to be here. Its entire history is a sequence of coincidences. In the early 1990s, GPUs existed to draw triangles. Silicon Graphics made specialized hardware for 3D rendering, and the rest of the industry followed. NVIDIA’s GeForce 256, released in 1999, was marketed as the world’s first “GPU,” a term NVIDIA invented. Its job was to take vertices and textures from a CPU program, transform them, and rasterize them to a framebuffer. It was a peripheral. A display adapter with math capabilities. Then game developers started abusing the hardware. Shader programs, originally designed for lighting and surface effects, turned out to be tiny parallel programs that could do arbitrary computation. By the mid-2000s, researchers at Stanford and elsewhere realized you could encode general-purpose math problems as texture operations: matrix multiplications as pixel shaders, fluid simulations as render passes. It was a hack. The GPU did not know it was doing science. It thought it was rendering a really weird image. NVIDIA saw the opportunity and released CUDA in 2007, giving the GPU a proper programming model for general-purpose computation. But the architecture of the system did not change. CUDA was a userspace library. The GPU driver ran outside the kernel. The operating system still treated the GPU as a display device. The OS scheduled CPU processes and managed CPU memory. The GPU scheduled its own work and managed its own memory, through CUDA, through the driver, outside the OS’s view. Then came cryptocurrency mining. Bitcoin miners discovered that GPUs were vastly more efficient than CPUs for SHA-256 hashing, because the algorithm is embarrassingly parallel and the GPU has thousands of cores. This was the first mass-market workload where the GPU did the economically valuable work and the CPU was just overhead. Mining rigs were machines where the CPU was an afterthought, a cheap Celeron whose only job was to feed work to a rack of GPUs. But the operating system running on that Celeron was still Linux, still managing the GPU through CUDA, still treating it as a peripheral. Then came machine learning. First training (AlexNet in 2012, the moment deep learning became real), then inference. Each transition was coincidental. Nobody designed GPUs to be good at neural network training. They just happened to have the right characteristics: massive parallelism, high memory bandwidth, and a programming model that could express matrix multiplications. The workloads found the hardware. The hardware did not seek the workloads. And so we arrived at 2026 with the most important compute workload in a generation, AI inference, running on hardware that was originally designed to render Quake, managed by drivers that bypass the operating system, scheduled by a proprietary runtime that the kernel cannot see or control. The GPU is the most important processor in the machine, and the OS does not know what it is doing. Nearly twenty years after CUDA, we are still using that model. The workloads have changed beyond recognition. The software stack has not. How CPUs and GPUs actually differ</h2> To understand why this matters, it helps to understand how CPUs and GPUs compute differently. Not at the marketing level. At the architectural level. A CPU is designed for latency. It has a small number of powerful cores (8 to 128 on a modern server chip), each with deep pipelines, branch predictors, out-of-order execution engines, and large caches. Each core is optimized to execute a single thread of instructions as fast as possible. When your program says “if this, then that,” the CPU predicts which branch you will take and starts executing it before it knows the answer. When your program accesses memory, the CPU has three levels of cache to hide the latency of going to DRAM. The entire design optimizes for one thing: getting through a single sequence of instructions with minimal delay. A GPU is designed for throughput. It has thousands of small cores (16,384 CUDA cores on an H100), each simple, each capable of executing one instruction per clock, grouped into blocks that execute the same instruction on different data simultaneously. There is no branch predictor because all threads in a warp (a group of 32) execute the same instruction at the same time. If your program has a branch, both paths execute and the unwanted results are discarded. There is very little cache because the design assumes you are streaming through large data sets, not randomly accessing small ones. The entire design optimizes for one thing: doing the same operation on as many data points as possible simultaneously. CPU (latency-optimized) GPU (throughput-optimized) ======================== ============================ +---------+ +---------+ +--+--+--+--+--+--+--+--+--+ | Core 0 | | Core 1 | ... 8-128 | | | | | | | | | | | complex | | complex | cores | | | | | | | | | | | OoO exec| | OoO exec| | | | | | | | | | | | branch | | branch | | SM | | SM | | SM | | predict | | predict | | | | | | | | | | | +---------+ +---------+ | | | | | | | | | | | | +--+--+--+--+--+--+--+--+--+ +----+----+ +----+----+ thousands of cores | L1 32K | | L1 32K | simple, in-order +---------+ +---------+ same instruction, +----+------------+----+ different data | L2 ~1 MB | +-----------------------+ +---------------------------+ | L3 ~32 MB | | HBM ~80 GB | +-----------------------+ | ~3 TB/s bandwidth | | DRAM ~512 GB | +---------------------------+ | ~100 GB/s | +-----------------------+ One instruction, 16384 data points at once One instruction at a time, very fast</code></pre> This difference is why matrix multiplication, the core operation in neural network inference, runs three orders of magnitude faster on a GPU. A matrix multiply is thousands of multiply-and-add operations on independent data points. The CPU executes them one at a time (or a few at a time with SIMD), fast but serial. The GPU executes thousands simultaneously, each on its own core. The CPU finishes one row while the GPU finishes the whole matrix. For traditional software, CPU architecture is perfect. A web server parses HTTP requests (branchy, sequential), queries a database (latency-sensitive, cache-friendly), and formats a response (string operations, unpredictable access patterns). Each request is different. Each code path branches differently. The CPU’s branch predictor, out-of-order execution, and deep cache hierarchy are exactly right. For inference, GPU architecture is perfect. Each layer of a transformer is a dense matrix multiplication followed by an element-wise nonlinearity. Every token in the batch gets the same operations applied to the same weights. There are almost no branches. The data is enormous and streaming. The GPU’s thousands of simple cores and high-bandwidth memory are exactly right. The problem is that we run both workloads on an operating system that only understands the first kind. The GPU is becoming the computer</h2> When you run inference on a large language model, the GPU is not assisting the CPU. The GPU is doing the work. The CPU’s role is orchestration: loading weights, managing memory, feeding tokens, collecting output. The actual computation, the matrix multiplications that turn a prompt into a response, happens on the GPU. For a 70-billion-parameter model, the GPU does billions of floating-point operations per token. The CPU does bookkeeping. The numbers make this concrete. An NVIDIA H100 delivers roughly 1,979 teraflops of FP8 compute. The CPU it is paired with, typically an AMD EPYC or Intel Xeon, delivers maybe 2-3 teraflops of FP32. The GPU has three orders of magnitude more compute throughput for the operations that matter in inference. When a request arrives at an inference endpoint, the CPU spends microseconds parsing HTTP and tokenizing text. The GPU spends milliseconds doing the actual thinking. The ratio of useful work is not close. This inversion has happened gradually enough that we have not fully reckoned with it. We still run inference workloads on Linux. We still manage GPU memory through CUDA driver calls from userspace processes. We still treat the GPU as a device the OS mediates access to, the same way it mediates access to a disk or a network card. But a disk does not run your business logic. A network card does not make decisions. The GPU increasingly does both. When an AI agent decides whether to approve a transaction, route a request, or generate a response, the decision happens on the GPU. The CPU is the secretary. The GPU is the executive. If the executive is making the decisions, why is the secretary’s office designed for the secretary? This is not merely an aesthetic complaint. The mismatch has practical consequences. GPU memory management is manual and error-prone. Context switches between GPU workloads are expensive because the OS has no concept of GPU process state. Scheduling is done by the CUDA driver, not by the kernel, which means the OS cannot enforce fairness or priority between GPU workloads the way it enforces them between CPU processes. And isolation, the most critical property for multi-tenant inference, depends entirely on userspace software that the OS does not control or verify. What an inference-native OS would look like</h2> Imagine an operating system where inference is the fundamental compute primitive. Not a syscall you invoke. Not a library you link. The basic unit of work. In a traditional OS, the primitive is a process: an isolated address space running a sequence of CPU instructions with access to file descriptors, network sockets, and memory. The scheduler gives each process time on the CPU. The kernel mediates access to shared resources. In an inference-native OS, the primitive would be a shard: an isolated execution context with dedicated GPU resources, its own VRAM partition, its own compute units, its own inference pipeline. The scheduler does not give shards time on the CPU. It gives them capacity on the GPU. The kernel does not mediate file descriptors. It mediates model weights, token streams, and attention contexts. Traditional OS Inference-native OS ================= ==================== Process A Process B Process C Shard A Shard B Shard C | | | | | | v v v v v v +-------------------------------+ +-------------------------------+ | CPU scheduler | | GPU scheduler | | (time-slicing) | | (capacity-slicing) | +-------------------------------+ +-------------------------------+ | | | | | | v v v v v v +------+ +------+ +------+ +--------+ +--------+ +--------+ | Core | | Core | | Core | | CU | | CU | | CU | | 0 | | 1 | | 2 | | slice | | slice | | slice | +------+ +------+ +------+ +--------+ +--------+ +--------+ | | | GPU is a peripheral v v v called via ioctl/CUDA +-------------------------------+ | VRAM partitions | | (isolated per shard) | +-------------------------------+</code></pre> The analogy that keeps coming back to me is mainframes and timesharing. In the 1960s, computers were batch-processing machines. You submitted a job, waited, got results. Then Multics and later Unix introduced timesharing: multiple users, each with the illusion of having the whole machine, isolated from each other by the OS. The transition was not just a performance improvement. It was a conceptual shift in what the machine was for. It went from “a machine that runs one job at a time” to “a machine that runs many jobs concurrently, safely isolated.” We need the same transition for GPUs. Right now, GPU computing is in its batch-processing era. One workload gets the GPU (or a partition of it, managed by CUDA MPS or MIG), and isolation is an afterthought bolted on by the driver. The inference-native equivalent of timesharing would be an OS that treats GPU capacity the way Unix treats CPU time: a shared resource, securely partitioned, with each tenant unable to see or affect the others. The isolation model is the critical piece. In a traditional OS, processes are isolated by virtual memory on the CPU side. Two processes cannot read each other’s RAM because the page tables prevent it. The MMU (Memory Management Unit) enforces this in hardware. It is not a software convention. It is a physical guarantee. But GPU memory is a different story. In most systems, GPU memory isolation depends on the CUDA driver, which runs in userspace. NVIDIA’s MIG (Multi-Instance GPU) provides hardware partitioning on some GPU models, but it is coarse-grained (up to 7 instances on an A100) and not available on consumer hardware. A vulnerability in the driver, or in any process with GPU access, can potentially read VRAM belonging to another workload. For inference workloads handling sensitive data, this is not acceptable. Hardware-level isolation is the answer. Intel VT-d IOMMU can enforce DMA translation boundaries so that each GPU partition’s VRAM is physically inaccessible to other partitions. Not software-isolated. Hardware-isolated. The same level of guarantee that CPU virtual memory provides, but for GPU resources. The technology exists. It is used in server virtualization today for PCIe passthrough. The question is whether an OS can be built that uses it as a first-class isolation primitive for inference workloads, not as a virtualization feature. coconutOS</h2> This is not purely theoretical. I have been building a proof of concept. coconutOS</a> is a capability-based microkernel written in Rust, engineered specifically for GPU-isolated AI inference. It boots on x86-64 hardware via UEFI, and its entire architecture is designed around the idea that the GPU is the primary execution engine. The choice of a microkernel is deliberate, and it carries historical baggage worth addressing. The microkernel idea goes back to the 1980s. Andrew Tanenbaum, the computer scientist at Vrije Universiteit Amsterdam, built Minix</a> as a teaching OS based on the principle that the kernel should do as little as possible: manage memory, schedule tasks, pass messages. Everything else, file systems, drivers, network stacks, runs in userspace as separate processes. If a driver crashes, the kernel restarts it. The system keeps running. Tanenbaum and Linus Torvalds had a famous debate about this in 1992 on the comp.os.minix newsgroup. Torvalds argued that monolithic kernels were faster and more practical. Tanenbaum argued that microkernels were more reliable and that “Linux is obsolete.” Torvalds won the practical argument. Linux became the dominant OS precisely because a monolithic kernel is simpler to build and faster to run when all your workloads are CPU-centric. Putting the file system and drivers in kernel space avoids the overhead of message passing between userspace processes. But Tanenbaum’s argument was about fault isolation, and fault isolation becomes more important as the consequences of failure increase. When the failure is “the file server process crashes and is restarted in 50 milliseconds,” a monolithic kernel’s performance advantage wins. When the failure is “a GPU driver bug in kernel space lets one tenant’s inference workload read another tenant’s medical records from VRAM,” the calculus changes. In a monolithic kernel like Linux, the GPU driver runs in kernel space with full access to system memory. A bug in the NVIDIA driver (and there have been many: CVE-2024-0090</a>, CVE-2024-0092</a>, CVE-2023-31018</a> to name a few from recent years) can compromise the entire system. In a microkernel, the GPU HAL runs as an isolated shard in userspace. A bug in the HAL crashes that shard. The kernel survives. Other shards survive. The failure domain is contained. Tanenbaum was right about the principle. He was just early about the workload that would make it matter. GPU-isolated inference is that workload. The performance overhead of microkernel message passing is irrelevant when the actual work happens on the GPU and the kernel’s job is orchestration, not computation. The CPU side is the control plane. The GPU side is the data plane. A microkernel is the right architecture for a control plane. The core abstractions: Shards, not processes. Each shard is an isolated address space with its own page tables, running in ring 3. But unlike a traditional process, a shard’s primary resource is not CPU time. It is GPU capacity. A shard gets a partition of VRAM, a slice of compute units, and a dedicated HAL (Hardware Abstraction Layer) shard that manages its access to the GPU. The HAL shard itself is unprivileged. It communicates with the kernel through the same capability-based IPC that every other shard uses. There is no “root” equivalent for GPU access. Capabilities, not permissions. Access control is capability-based, inspired by systems like seL4</a> and the research that came out of the University of Cambridge’s Computer Laboratory. Each shard holds unforgeable capability tokens that grant access to specific resources: VRAM regions, IPC channels, filesystem paths, GPU compute slices. Capabilities can be granted, revoked, restricted, and inspected. There are no ambient permissions. A shard cannot access anything it does not hold a capability for. This is fundamentally different from Unix permissions, where a root process can access everything. In coconutOS, there is no root. There are only capabilities. GPU ASLR. Each shard’s VRAM and MMIO virtual addresses are randomized. Even if an attacker finds a vulnerability in one shard, they cannot predict where another shard’s GPU memory is mapped. CPU-side ASLR has been standard since the mid-2000s. The insight is that the same principle applies to GPU resources, and that without it, a GPU memory disclosure vulnerability in one workload can be used to locate and read another workload’s model weights or inference state. Pledge and unveil for GPUs. This is one of the design choices I am most attached to, because it comes directly from my years of admiring OpenBSD. Theo de Raadt’s pledge(2)</code> and unveil(2)</code> syscalls are among the most elegant security primitives ever designed. A process calls pledge("stdio rpath")</code> and permanently gives up the ability to do anything except read files and use standard I/O. It cannot escalate back. The promise is irreversible. coconutOS applies the same idea to GPU resources. pledge_gpu</code> lets a shard declare that it will only do inference, not training. Once pledged, it cannot allocate new VRAM beyond its partition, cannot modify model weights, cannot access raw compute dispatch. unveil_vram</code> lets a shard lock its VRAM view to a specific region. Other regions become physically invisible through the IOMMU. A compromised inference shard cannot undo its own containment because the kernel enforces the pledge at the hardware level. The inference stack. The proof of concept runs a transformer forward pass end-to-end: RMSNorm, multi-head attention with rotary position embeddings (RoPE), SiLU feed-forward networks, softmax. It is based on Andrej Karpathy’s llama2.c</a>, adapted to run as a shard with GPU isolation. The kernel preserves FPU and SSE state across preemption using FXSAVE/FXRSTOR, so inference math is not corrupted by context switches. This is a detail that matters: if the scheduler preempts a shard mid-matrix-multiply and does not preserve the floating-point register state, the results will be silently wrong. Traditional OSes handle this for CPU processes. coconutOS handles it for GPU inference shards. Why this matters</h2> You might look at coconutOS and think: this is an interesting research project, but nobody is going to replace Linux for AI workloads. And you might be right. Linux is entrenched. CUDA is entrenched. The entire AI infrastructure stack, from PyTorch to vLLM to Triton Inference Server, is built on top of assumptions that coconutOS challenges. But consider the trajectory. Five years ago, AI inference was a batch job you ran on a cluster. You uploaded data, kicked off a job, came back later for results. The security model was simple: whoever had SSH access to the machine had access to the GPU. Isolation was a non-issue because there was only one workload. Today, inference is a real-time service. Companies like Anthropic, OpenAI, and Google serve billions of inference requests per day. Multiple customers share the same GPU hardware. The workloads process sensitive data: medical records, financial transactions, legal documents, personal conversations. The security and isolation requirements have changed fundamentally, but the OS layer has not changed at all. We are running safety-critical, multi-tenant inference workloads on an operating system that was designed in 1991 for running file servers and web servers. The gap between what we are doing on GPUs and how we manage GPU access is widening. Right now, GPU multi-tenancy in the cloud means trusting the CUDA driver and the hypervisor to keep workloads separated. NVIDIA’s MIG helps, but it is only available on data center GPUs (A100, H100), offers coarse-grained partitioning (7 instances maximum), and still relies on the CUDA driver for memory management within each partition. For most use cases, this is fine. For financial services, healthcare, defense, and any context where inference handles regulated data, “trusting the driver” is not a compliance-grade answer. The analogy is virtualization. Before Xen and KVM, server multi-tenancy meant trusting the host OS to isolate users. It worked until it did not. Hardware virtualization (VT-x) gave us actual isolation guarantees enforced by the CPU. The cloud was built on those guarantees. We need the same thing for GPUs. Hardware-level isolation, enforced by the kernel, with capability-based access control and monotonic privilege restriction, is where this has to go. Whether it looks like coconutOS or like a set of patches to Linux or like NVIDIA building isolation into their next GPU architecture is an implementation question. The architectural direction is not optional. The four futures, updated</h2> Looking back at the original post, the timeline extends further than I initially described: Near term Medium term Long term Far horizon (now) (2-5 years) (5-15 years) (10-20 years) Explicit Declarative Post-language Inference-native languages languages (AI-native operating systems (Vera) (Haskell + BHC) targets) Reduce noise --> Change the --> Remove the --> Redesign the in the loop signal layer machine HOW, but WHAT, verified Intent to Intent to unambiguous by types execution inference</code></pre> The first three futures are about the intermediate layer between human intent and machine execution. The fourth future is about the machine itself. If the primary workload is inference, the machine should be designed for inference. Not adapted. Not extended. Designed. Each transition in this timeline follows the same pattern that has repeated throughout the history of computing. When a new type of workload becomes dominant, the infrastructure eventually reshapes itself around that workload. Mainframes were redesigned for timesharing when interactive use became the dominant workload. Server hardware was redesigned for virtualization when multi-tenancy became the dominant workload. Network infrastructure was redesigned for packet switching when interactive data became more important than circuit-switched voice. The question is never whether the infrastructure will adapt. It is how long the transition takes and what it looks like on the other side. This is admittedly the furthest out of the four possibilities. We are even further from inference-native operating systems than we are from AI generating machine code directly. The hardware support is early. The software stack is embryonic. coconutOS boots and runs a transformer forward pass, which is a start, but it is a long way from something you would deploy in production. But the same was true of virtual memory when MIT’s Project MAC implemented it in 1961. It took decades for hardware support to mature, for operating systems to build on it, for the abstraction to become invisible. Today, every program you run uses virtual memory and nobody thinks about it. The same was true of containerization when Google started using cgroups internally in 2006. Docker did not arrive until 2013. Kubernetes until 2014. The gap between “research prototype” and “runs the world” is real, but so is the trajectory. The workloads are catching up. The hardware is catching up. The question is whether we build the OS to match, or whether we keep running inference on an operating system that thinks the CPU is in charge. Honest assessment</h2> I do not know if inference-native operating systems will happen in this form. I do not know if the microkernel approach is right, or if the better path is extending Linux with GPU isolation primitives (the way cgroups extended Linux for containers, the way KVM extended Linux for virtualization). I do not know if hardware vendors will build the IOMMU support that makes per-shard GPU isolation practical at scale, or if NVIDIA will solve this problem at the driver level before anyone needs a new OS. There are smart people working on adjacent problems. Google’s TPU architecture has custom scheduling and isolation built into the hardware. AMD’s ROCm is exploring open-source alternatives to CUDA’s closed driver model. Intel’s GPU roadmap includes hardware virtualization features. Any of these paths could make coconutOS’s approach unnecessary by solving the isolation problem at a different layer. What I do know is that running inference workloads on operating systems designed for sequential CPU programs is an impedance mismatch that will become less tolerable as inference becomes more critical. Something will change. coconutOS is my attempt to explore what that something might look like, with real code that boots on real hardware and runs a real transformer. The code is open source, ISC-licensed, and very much a work in progress. If you are thinking about similar problems, I want to hear from you. github.com/coconut-os/coconutOS</a> What Sixteen AI Agents Taught Me About Management Unknown — Thu, 16 Apr 2026 00:00:00 +0000 Over the 2025 Christmas holidays I had sixteen AI agents running in parallel across four macOS workspaces. Each workspace held four Ghostty terminal panes, each pane running its own Claude Code instance, each instance working on a different piece of a different project. I was on Anthropic’s 20x Max subscription, and during the holiday period the token limits were generous enough that I could burn through context at a rate I had never attempted before. It was the most productive week of my engineering life. It was also the week I learned that managing AI agents is, at its core, a management problem. Not a technical one. The terminal wall</h2> The setup started simple. Mitchell Hashimoto’s Ghostty, which I consider one of the best terminal emulators released in years, supports split panes in both directions. Four panes per workspace. Four workspaces. Sixteen agents. Each one working on a real task: scaffolding a new crate, writing tests for a module I had sketched out, researching an API I needed to integrate, refactoring a component I had been putting off for months. Workspace 1 Workspace 2 Workspace 3 Workspace 4 =================== =================== =================== =================== | Agent 1 | Agent 2| | Agent 5 | Agent 6| | Agent 9 | Agent 10| | Agent 13 | Agent 14| | scaffold| tests | | refactor| research| | API | migrate| | docs | bench | |---------|---------| |---------|---------| |---------|---------| |---------|---------| | Agent 3 | Agent 4| | Agent 7 | Agent 8| | Agent 11 | Agent 12| | Agent 15 | Agent 16| | config | lint | | deploy | review | | schema | ci | | proto | fuzz | =================== =================== =================== =================== Me: switching between workspaces, scrolling back through conversations, keeping a text file of who does what</code></pre> The first few hours were exhilarating. I would spin up an agent, give it a task, switch to the next pane, give it a task, move to the next workspace, repeat. By mid-morning I had more concurrent engineering work happening than most small teams produce in a day. Then the problems started. I could not remember what each agent was doing. This was before Claude Code added the prompt and context summary at the top of the input line, so the only way to check was to scroll back through the conversation history and find the original prompt. With sixteen sessions, that meant a lot of scrolling. I started naming my macOS workspaces. I named each Ghostty pane. I kept a text file open with a list of which agent was doing what. I was, without quite realizing it, building a project management system out of sticky notes and window titles. The irony was not lost on me. I had sixteen AI agents doing engineering work, and I was spending half my time doing the one thing AI was supposed to eliminate: keeping track of who was working on what. Kage, the first attempt</h2> That frustration led to kage</a>. The name means shadow in Japanese. The idea was straightforward: build a Rust binary that could orchestrate multiple terminal sessions, let me switch between them, and show me at a glance what each one was doing. kage used alacritty_terminal</code> (the terminal emulation library extracted from the Alacritty terminal emulator) to manage PTY sessions, ratatui</code> for a terminal UI, and redb</code> for local persistence. I could spawn agents with goals, set iteration limits, checkpoint and resume sessions, and pool across multiple LLM providers. The vision was that I could use Claude Code alongside OpenAI’s Codex and whatever else was available, routing tasks to whichever provider had capacity. +-----------------------------------------------------------+ | kage TUI (ratatui) | | +-------+ +-------+ +-------+ +-------+ +-------+ | | | Sess 1| | Sess 2| | Sess 3| | Sess 4| | ... | | | | goal: | | goal: | | goal: | | goal: | | | | | | scaf. | | tests | | refac.| | API | | | | | +---+---+ +---+---+ +---+---+ +---+---+ +-------+ | | | | | | | +------|----------|-----------|----------|-------------------+ | | | | +----v----+ +--v----+ +--v----+ +--v----+ | PTY | | PTY | | PTY | | PTY | alacritty_terminal | (Claude)| |(Codex)| |(Claude| |(Claude| manages each session +---------+ +-------+ +-------+ +-------+ +---------------------+ +------------------+ | redb (persistence) | | LLM provider pool| | checkpoints, goals, | | Anthropic, OpenAI| | session state | | route by capacity| +---------------------+ +------------------+</code></pre> It worked. Technically. I could see all my sessions in one interface. I could switch between them. I could track what each agent was supposed to be doing. But it felt clunky. The terminal streaming had issues. The UI was functional but not fluid. And more importantly, I realized the tool was solving the wrong problem. The problem was not that I needed a better way to look at sixteen terminal panes. The problem was that sixteen independent agents with no coordination between them produced sixteen independent streams of work with no coherence between them. Agent A would refactor a module that agent B was simultaneously writing tests for, using the old API. Agent C would make a design decision that conflicted with what agent D was building. I was the only point of integration, and I could not context-switch fast enough to catch every conflict. Agent A: refactors auth module Agent B: writes tests for auth module | | +-- removes old_login() +-- tests old_login() +-- renames to authenticate() +-- expects old return type +-- changes return type +-- passes locally (stale code) +-- FAILS after A merges Agent C: picks REST for new API Agent D: builds gRPC client for new API | | +-- adds /api/v2/users +-- generates proto stubs +-- writes OpenAPI spec +-- implements streaming calls +-- INCOMPATIBLE with C's design Me (the only integration point): "Wait, what is everyone doing?"</code></pre> I needed the agents to coordinate with each other. Not just run in parallel. Actually collaborate. Shiioo, the virtual company</h2> The second attempt was shiioo</a>. The name is the Japanese romanization of CEO. The premise had changed entirely. What if the agents were not just parallel workers? What if they were employees in a virtual enterprise, each with a specific role, a defined skillset, a limited set of tools, and a reporting structure? I had been reading about organizational design and it struck me how directly the problems I was having with agent orchestration mapped to problems that real companies solve with management hierarchies. When you have sixteen people working on a project, you do not give each one independent access to everything and hope for the best. You create teams. You assign leads. You define communication channels. You escalate decisions that exceed a team’s authority. So that is what I built. shiioo is a Rust-based client-server system with an event-sourced persistence layer. Each agent is modeled as an employee with a SKILLS.md</code> file that defines its capabilities, a limited set of MCP interfaces it can access, and a position in an organizational hierarchy. Agents are grouped into squads. Each squad has a lead. Squad leads report to department leads. Department leads report up to me. +------------------+ | CEO (me) | | Strategic | | decisions only | +--------+---------+ | +-----------------+-----------------+ | | +--------v---------+ +---------v--------+ | Dept Lead: | | Dept Lead: | | Infrastructure | | Product | +--------+---------+ +---------+--------+ | | +--------+--------+ +--------+--------+ | | | | +------v------+ +------v------+ +------v------+ +------v------+ | Squad Lead: | | Squad Lead: | | Squad Lead: | | Squad Lead: | | Backend | | Platform | | Frontend | | Data | +------+------+ +------+------+ +------+------+ +------+------+ | | | | +----+----+ +---+---+ +----+----+ +---+---+ | | | | | | | | | | Ag1 Ag2 Ag3 Ag4 Ag5 Ag6 Ag7 Ag8 Ag9 Ag10 Each agent has: - SKILLS.md (capabilities) - Limited MCP interfaces - Defined scope of authority - Escalation path upward</code></pre> The architecture uses a DAG workflow engine built on petgraph</code> for task dependencies, a policy engine for authorization and approval gates, and a capacity broker that routes LLM calls across multiple providers. Every action is event-sourced, which means I have a complete audit trail of every decision every agent made, and I can replay any sequence of events to understand how a particular outcome was reached. +-------------------------------------------------------------------+ | shiioo server | | | | +------------------+ +------------------+ +-----------------+ | | | Workflow Engine | | Policy Engine | | Capacity Broker | | | | (petgraph DAGs) | | (RBAC, approval | | (route LLM | | | | | | gates, authz) | | calls across | | | | task deps, | | | | providers) | | | | retries, | | who can do what, | | | | | | timeouts | | who approves | | Anthropic, | | | +--------+---------+ +--------+---------+ | OpenAI, ... | | | | | +---------+-------+ | | +----------+----------+ | | | | | | | +-------v--------+ | | | | Event Store | +--------------------v------+ | | | (redb + S3) | | MCP Tool Server | | | | | | (expose enterprise tools | | | | every action | | to agents) | | | | is persisted, | +----------------------------+ | | | replayable | | | +---------------+ | +-------------------------------------------------------------------+ | | +----v----+ +----v----+ | CLI REPL| | Web | | (Chief | | Dashboard| | of Staff| | (real- | | mode) | | time) | +---------+ +---------+</code></pre> The key insight was the escalation model. Most tasks could be handled by individual agents within their defined scope. When an agent encountered a decision that exceeded its authority, such as a design choice that would affect other teams, a dependency conflict, or a resource allocation question, it escalated to its squad lead. The squad lead either resolved it or escalated further. Only the decisions that truly required strategic judgment, market positioning, resource allocation across projects, architectural direction, reached me. I was the CEO. Not in some metaphorical sense. In the literal operational sense that the only decisions that required my attention were the ones that should require a CEO’s attention. It worked</h2> shiioo was rough. The UI was a REPL with seven built-in commands. The web dashboard was basic. The documentation was incomplete. But the model worked. I bootstrapped multiple projects using this setup over the holidays. Agents would pick up tasks, work within their scope, coordinate through the reporting structure, and escalate when they hit ambiguity. The squad lead agents were particularly effective because they had enough context about their team’s work to resolve most conflicts without involving me. The event sourcing turned out to be more valuable than I expected. When something went wrong, and things did go wrong, I could trace the decision chain from the final output back to the original task assignment. I could see exactly where an agent made a bad call, which agent approved it, and what information was available at each step. This is something you cannot do with sixteen independent terminal sessions. You cannot even do it with most human teams. For a week, I was running a virtual company. And the virtual company was shipping code. Then the tokens ran out</h2> Nobody talks about this part when they discuss agent orchestration: the economics. During the Christmas holiday period, Anthropic’s 20x Max subscription was unusually generous with token limits. I do not know the exact numbers, but the allowance was noticeably higher than usual. I was burning through it. The problem was not the agents doing useful work. The problem was the agents talking to each other. In any organization, a significant portion of communication is overhead. Status updates. Clarifying questions. Acknowledging instructions. Confirming understanding. In a human company, this overhead is accepted because humans need it to function. In an agent company, every word of that communication costs tokens. I watched my weekly token budget evaporate. Not because the agents were writing code, although they were. Because the squad leads were having lengthy exchanges with their teams about task requirements. Because agents were asking clarifying questions that a slightly better prompt would have made unnecessary. Because the escalation chain, every step of it, required a full context window of conversation. Token budget (weekly) ===================== Useful work (code, tests, docs) ████████░░░░░░░░░░░░ ~35% Agent-to-agent coordination ██████████████░░░░░░ ~40% Escalation chain overhead ████████░░░░░░░░░░░░ ~15% Clarifying questions / retries ████░░░░░░░░░░░░░░░░ ~10% ^^^^^^^^^^^^^^^^^^^^ |---- productive ---|--- overhead ---| The overhead was not a bug. It was the cost of coordination. The same cost human companies pay in salaries for meetings, Slack threads, standups, and status reports. The difference: human overhead is a fixed cost. Token overhead scales with every message.</code></pre> It was the AI equivalent of employees standing around the coffee machine. Except every minute at the coffee machine cost real money. When the holiday period ended and the token limits returned to normal, shiioo became impractical for my situation. I have more than ten active projects. I need to decide, deliberately and granularly, what my limited token budget goes toward. A virtual company that autonomously allocates its own token spend, no matter how effectively, does not give me that control. I stopped using it. Not because the architecture was wrong. Because the economics did not fit my constraints. The management lesson</h2> Every problem I encountered was a management problem that real companies have solved, or at least learned to live with. The coordination problem: sixteen independent workers producing inconsistent output. Solved the same way companies solve it. Hierarchy, defined roles, communication channels. The overhead problem: too much communication relative to productive work. Every manager knows this. Every company struggles with it. The optimal amount of coordination is not zero and it is not “as much as possible.” It is somewhere in between, and finding that point is one of the hardest problems in organizational design. The economics problem: the work gets done, but the cost of the work exceeds the budget. This is not a technology problem. This is a business problem. And it has different answers at different scales. For an individual developer on a consumer subscription, shiioo’s overhead is too expensive. The token cost of agent-to-agent communication eats into the budget for actual work. I need to be hands-on, directing each agent personally, because my token budget is small enough that every token should go toward output I directly value. For an enterprise with API access and a meaningful budget, the calculus is completely different. If you are paying for engineering time at market rates, the token cost of agent coordination is a rounding error compared to the cost of human coordination. The overhead that made shiioo impractical for me, agents discussing requirements, leads resolving conflicts, escalation chains processing decisions, would be a bargain for a company that currently pays humans to do the same thing at 100x the cost and 10x the latency. Individual developer (consumer sub) Enterprise (API access) ==================================== ==================================== Token budget: limited, weekly cap Token budget: pay per use, large Overhead cost: eats into real work Overhead cost: rounding error Control need: high (every token Control need: moderate (aggregate must count) ROI matters) +----------+ +----------+ | Useful | <-- want to maximize | Useful | <-- still majority | work | this slice | work | +----------+ +----------+ | Overhead | <-- this hurts | Overhead | <-- acceptable cost +----------+ +----------+ | Budget | | | +----------+ | Room to | (no room) | grow | +----------+ Same architecture. Different economics. Different answer.</code></pre> Then OpenClaw happened</h2> A few weeks after Christmas, OpenClaw</a> launched and crossed 100,000 GitHub stars within its first week. The community was impressed. A personal AI agent framework with multi-agent support, tool integrations, and an approachable setup experience. I looked at it and felt a mix of recognition and mild frustration. OpenClaw solved the “how do I run an AI agent” problem elegantly. But shiioo was solving a different problem. Not “how do I run agents” but “how do I run an organization of agents.” Hiring, delegation, escalation, governance, audit trails, budget management. The boring, structural, enterprise problems that do not demo well but determine whether agent orchestration actually works at scale. OpenClaw is a good tool for individuals. What I built, rough as it was, is a sketch of what enterprises will need when they move past “we have an AI assistant” to “we have an AI workforce.” Those are fundamentally different problems, and they require fundamentally different architectures. I do not say this to diminish OpenClaw. I say it because I think the industry is still mostly working on the first problem while the second one is coming fast. What I would do differently</h2> If I were building shiioo again today, three things would change. First, the communication protocol between agents needs to be structured and minimal. Free-form conversation between agents is expensive and produces the same rambling overhead that plagues human Slack channels. Agents should exchange typed messages with defined schemas. Not “hey, I was thinking about the API design and I wonder if we should consider…” but { type: "design_decision", scope: "api", proposal: "...", requires_approval: true }</code>. Every token in agent-to-agent communication should carry information, not politeness. Second, the token budget needs to be a first-class resource managed by the system, not an afterthought. Every agent should have a token allowance. Every escalation should have a cost. The system should make tradeoff decisions about whether a clarifying question is worth the tokens, the same way a well-run company makes tradeoff decisions about whether a meeting is worth the calendar time. Third, I would separate the orchestration layer from the LLM provider entirely. shiioo was built around the Anthropic Messages API. It should have been built around an abstract capability interface where the provider is a pluggable backend. Not for vendor neutrality as a principle, but because the economics change when you can route low-stakes agent communication through a smaller, cheaper model and reserve the frontier model for decisions that actually require it. Task type Model tier Cost per 1K tokens ========== ========== ================== Strategic decisions Frontier $$$$ (architecture, design) (Opus, GPT-5) | v Squad lead coordination Mid-tier $$ (conflict resolution, (Sonnet, GPT-4o) task assignment) | v Agent-to-agent comms Small/fast $ (status, ack, handoff) (Haiku, GPT-4o-mini) Route by decision weight, not uniformly. Most tokens go to the cheapest tier. Most value comes from the expensive tier.</code></pre> What this means for actual enterprises</h2> I ran my virtual company for a week across personal projects. It was an experiment. But the patterns I stumbled into are not experimental. They are the same patterns that every large organization will need to operationalize as agentic employees become real line items on the org chart. This is not a distant future. Companies are already deploying AI agents for customer support, code review, compliance checks, and data pipeline management. What most of them have not done yet is think about what happens when those agents need to coordinate. When the support agent needs to escalate to the engineering agent. When the compliance agent needs to block a deployment the CI agent is trying to push. When three agents working on the same codebase need to not step on each other. The companies that figure this out first will have a structural advantage that compounds. Consider a mid-size engineering organization. Two hundred engineers. They spend, conservatively, 30% of their time on coordination. Standups, planning meetings, Slack threads, code review discussions, design document feedback loops, incident response coordination. That is sixty full-time-equivalent salaries spent on people talking to each other about work rather than doing it. Nobody questions this cost because it has always been the cost of building software with humans. Now replace even a fraction of that coordination layer with agents. Not the engineers themselves. The coordination between them. An agentic squad lead that triages incoming tickets, assigns them based on skill match, checks for conflicts with in-flight work, and only escalates to a human lead when the decision genuinely requires human judgment. An agentic project manager that tracks dependencies across teams, flags blockers before they become crises, and generates status updates from actual commit history instead of asking twelve people to fill out a spreadsheet. </th> Today</th> Near future</th></tr></thead> Coordination</td> All human, expensive, slow, lossy</td> Mostly agents, cheap, fast, auditable</td></tr> Status updates</td> Asked for weekly (often stale by the time they reach leadership)</td> Generated from event logs (always current)</td></tr> Conflict detection</td> Someone notices during code review (after the work is done)</td> Automatic, flagged before work begins</td></tr> Escalation</td> Informal, depends on who knows whom</td> Structured, policy-driven, with full context</td></tr> </tbody></table> The organizations that will benefit most are not the ones with the best AI models. They are the ones that treat agent orchestration as an organizational design problem. That means defining clear scopes of authority, building escalation paths that preserve context, implementing approval gates that match their governance requirements, and maintaining audit trails that satisfy compliance. These are not engineering problems. They are operations problems. And most companies already have people who know how to solve them. They are called managers. The irony is that the skills most relevant to the agentic enterprise are not machine learning or prompt engineering. They are the skills that good managers have always had: defining clear responsibilities, building trust through transparency, knowing when to delegate and when to intervene, and designing systems where people, or agents, can do their best work without tripping over each other. Every enterprise will need to answer a specific set of questions in the next few years. How do you onboard an agentic employee? How do you define its scope? What happens when it makes a mistake? Who is accountable? How do you audit its decisions? How do you revoke its access? These questions sound like IT governance, and they are. But the answers will reshape how companies think about headcount, team structure, and operational capacity in ways that most leadership teams have not begun to consider. The companies that start experimenting now, even crudely, even with something as rough as what I built over a holiday week, will have a vocabulary and a set of institutional patterns that the latecomers will not. And in organizational design, having the right patterns early matters more than having the best technology late. Where this goes</h2> I still believe the virtual company model is the right abstraction for large-scale agent orchestration. It solves the same coordination problems that human organizations solve, using the same structural patterns that have been refined over decades of organizational theory. The technology is ready. The architectures are straightforward. The missing piece is the economics. When frontier model inference costs drop by another order of magnitude, and they will, the token overhead of agent-to-agent communication stops being prohibitive. When that happens, the question will not be “should we orchestrate agents in a hierarchy” but “what does the org chart look like.” I suspect we are closer to that moment than most people think. And when it arrives, the hard problems will not be technical. They will be the same problems that have always made management hard: delegation, trust, accountability, and knowing when to let your people work and when to step in. The agents are ready to work. We just need to learn how to manage them. References</h2> kage: Local-first agentic work orchestrator</a></li> shiioo: Virtual Company OS</a></li> OpenClaw: Personal AI agent framework</a></li> Ghostty terminal emulator</a></li> alacritty_terminal crate</a></li> </ul> Why We Built a Haskell Package Manager in Rust Unknown — Mon, 13 Apr 2026 00:00:00 +0000 Why would anyone invest serious engineering effort into Haskell tooling in 2026? Haskell is a niche language. It has been a niche language for thirty years. Most companies do not use it. Most developers have never written a line of it. If you are going to pour months of work into building a package manager and toolchain from scratch, in Rust no less, the obvious question is: why not just use Rust? The answer is the same one I gave in The Last Programming Language Might Not Be for Humans</a>: the way we write software is changing. AI is becoming the primary author of code, and the languages that will matter most in that future are not the ones optimized for human typing speed. They are the ones optimized for formal correctness, composability, and provability. Haskell is not niche in that framing. It is early. I have written before</a> about why Haskell shaped the way I think. The short version: Haskell teaches you to think about programs as compositions of well-typed transformations, and that discipline makes you better at everything else. I still believe this. I write most of my production software in Rust, but I think in Haskell. The problem was never the language. The problem was everything around it. The state of Haskell tooling</h2> If you want to start a Haskell project today, you install ghcup, which manages GHC (the compiler), Cabal (the build tool), Stack (a different build tool), and HLS (the language server). Then you decide whether to use Cabal or Stack, which is a decision that has split the Haskell community for over a decade and which nobody has fully resolved. Then you configure your project, using either a .cabal</code> file (a custom format that predates TOML, YAML, and JSON as configuration languages) or a stack.yaml</code> plus a .cabal</code> file (because Stack still needs Cabal files underneath). Then you wait for GHC to compile your dependencies, which takes long enough that you start questioning your life choices. I have introduced Haskell to teams and watched the enthusiasm drain from people’s faces during the toolchain setup. Not because the language was hard, but because the first thirty minutes were spent fighting ghcup</code>, cabal update</code>, resolver mismatches, and cryptic build errors that had nothing to do with the code they wanted to write. A typical first encounter: you want to write a small HTTP server. You install ghcup, install GHC 9.8.2, run cabal init</code>, and get a .cabal</code> file with a dozen fields you do not understand yet. You add warp</code> as a dependency and run cabal build</code>. GHC starts compiling warp</code> and its transitive dependencies: http-types</code>, bytestring</code>, text</code>, network</code>, streaming-commons</code>, vault</code>, wai</code>, and about forty others. Four to six minutes on a modern machine. Every time you switch GHC versions or clean your cache, you pay that cost again. Now compare this with Rust. You run cargo new my-server</code>. You add axum</code> to Cargo.toml</code>. You run cargo build</code>. It compiles. The first build is not instant either, but cargo</code> does not ask you which of two incompatible build tools you prefer, does not require a separate tool to manage the compiler, and does not present you with a configuration format from 2005. Or Python. uv init my-server</code>. uv add fastapi</code>. uv run</code>. Done. The entire dependency resolution and installation takes less than a second because uv</code> resolves and installs in parallel, in Rust, without spawning Python. Every major language ecosystem has converged on the same answer: one tool that handles project creation, dependency management, building, testing, and publishing. Haskell has three tools that each do part of the job, disagree about how dependencies should work, and require a fourth tool to manage the compiler itself. People have been talking about Haskell’s tooling problem for years. I decided to do something about it the way astral.sh</a> did for Python: rewrite the developer experience from scratch, in Rust, and make everything dramatically faster. The astral.sh playbook</h2> When Astral released uv</code> and ruff</code>, it proved something important. You can take a mature ecosystem with deeply entrenched tooling, rebuild the developer experience in Rust, and people will switch, because the new tools were fast enough and coherent enough that the switching cost paid for itself immediately. Python’s tooling situation before uv</code> was remarkably similar to Haskell’s. pip</code>, pip-tools</code>, pipenv</code>, poetry</code>, conda</code>, virtualenv</code>, venv</code>, pyenv</code>. Each solved part of the problem. Each had opinions that conflicted with the others. Setting up a Python project from scratch meant choosing a stack of tools, hoping they worked together, and accepting that your lockfile format depended on which combination you picked. Astral did not try to fix any single tool. They rewrote the experience. uv</code> is a single Rust binary that does what pip</code>, pip-tools</code>, virtualenv</code>, and pyenv</code> did, but 10-100x faster and with a coherent interface. ruff</code> is a single Rust binary that does what flake8</code>, isort</code>, pycodestyle</code>, and pyflakes</code> did, but 100x faster. The Python community switched because the tools were obviously better the first time they used them. The playbook has three steps: Wrap first. Use the existing tools under the hood rather than reimplementing everything. uv</code> wraps pip’s package index and resolver logic. hx wraps GHC and Cabal.</li> Tame second. Add better error messages, faster startup, unified configuration, and workflows that make sense. This is where most of the user-facing value lives.</li> Replace last. Only replace underlying components when you have to. For hx, that meant building a native build mode that bypasses Cabal entirely for simple projects, and a native dependency resolver in Rust that is 24x faster than Cabal’s constraint solver.</li> </ol> This approach is pragmatic in a way that matters. You do not need to rebuild the world to improve the experience. You need to rebuild the surface. The parts that people touch every day. Why Rust</h2> The choice to build hx in Rust is a direct response to a structural problem. Haskell’s existing tooling is written in Haskell. This creates a bootstrap problem. To build the build tool, you need the compiler. To install the compiler, you need the compiler manager. To build the compiler manager, you need a compiler. The dependency chain is circular, and every link in it is slow to compile. Think about what this means in practice. You are a new developer. You want to try Haskell. You download ghcup. ghcup is a shell script that downloads a pre-built GHC binary, but it also installs Cabal, which is itself a Haskell binary compiled with GHC. If the pre-built binary does not exist for your platform, you need GHC to build Cabal, but you need Cabal to set up GHC. The bootstrap documentation exists because the bootstrap problem exists, and it exists because the tools are written in the language they manage. GHC’s runtime system adds initialization overhead to every invocation. When you type cabal build</code>, the first 45 milliseconds are spent starting the GHC runtime before Cabal even begins to think about your project. Stack is worse at 89 milliseconds. These numbers sound small until you are running commands in a tight development loop, hitting save and expecting the build to start instantly. Or in CI, where the build tool is invoked hundreds of times across a pipeline and those milliseconds compound into minutes. hx starts in 12 milliseconds. A native binary without a garbage-collected runtime does not need to initialize one. The tool should not have the same dependencies as the thing it manages. hx build # 12ms startup + build time cabal build # 45ms startup + build time stack build # 89ms startup + build time </code></pre> Memory tells the same story: Tool</th> Startup memory</th> Build memory (simple project)</th></tr></thead> hx</td> 8 MB</td> 45 MB</td></tr> cabal</td> 45 MB</td> 250 MB</td></tr> stack</td> 85 MB</td> 320 MB</td></tr> </tbody></table> For a tool you invoke constantly, this matters. Especially on CI runners with constrained memory, or on a laptop where you have four terminal panes open with different projects. The Rust decision also solves the distribution problem. A Rust binary is a single static executable that cross-compiles trivially. No runtime dependencies. No “install GHC first so you can install the tool that installs GHC.” curl | sh</code> and you are running. hx is available via the install script, Cargo, aqua, winget on Windows, and Homebrew. Every distribution channel ships a self-contained binary. What hx actually does</h2> hx replaces the cabal + stack + ghcup + fourmolu + hlint</code> workflow with a single binary: curl -fsSL https://arcanist.sh/hx/install.sh | sh hx new my-app && cd my-app hx run </code></pre> No ghcup. No stack. No cabal-install. One tool, one configuration file, one lockfile format. Configuration</h3> The configuration is hx.toml</code>. Not a .cabal</code> file with its custom syntax that nobody can parse without a library. Not a stack.yaml</code> with YAML indentation traps. TOML, the same format that Rust (Cargo.toml</code>), Python (pyproject.toml</code>), and most modern tools have converged on. [project] name = "my-app" kind = "bin" [toolchain] ghc = "9.8.2" [build] optimization = 2 warnings = true [format] formatter = "fourmolu" [lint] hlint = true [hooks] pre-build = "scripts/generate-version.sh" post-test = "scripts/notify.sh" </code></pre> Everything in one file. The toolchain version is pinned per-project, so different projects can use different GHC versions without conflict. When you run hx build</code> in a project pinned to GHC 9.8.2 and another pinned to 9.6.4, hx switches automatically. No ghcup set</code> commands. No global state. Lockfiles</h3> The lockfile is also TOML. Every dependency is pinned with a sha256 fingerprint: version = 1 ghc = "9.8.2" created_at = "2026-01-16T00:00:00Z" [[package]] name = "aeson" version = "2.2.1.0" sha256 = "a5a5b8a..." deps = ["base", "text", "bytestring"] </code></pre> hx lock --check</code> in CI fails if the lockfile is stale. This is deterministic by default. Not “deterministic if you remember to run cabal freeze</code> and commit the freeze file and hope nobody ran cabal update</code> on a different machine.” Deterministic the way cargo</code> and uv</code> are deterministic. Automatically. Every time. If you are coming from Stack, you might say “Stack already has lockfiles.” It does. Stack’s approach is to pin to a Stackage snapshot, which gives you a curated set of packages known to work together. This is a valid approach, but it means your dependency versions are dictated by what the Stackage maintainers decided to include in that snapshot. If you need a newer version of a package that is not in the current LTS, you start adding extra-deps</code>, and your reproducibility guarantees become more complex. hx resolves from Hackage directly, pins every version, and verifies checksums. You control exactly what you get. Native builds</h3> For simple projects with only base</code> dependencies, hx has a native build mode that bypasses Cabal entirely. It constructs the module graph itself and invokes GHC directly: Operation</th> hx native</th> hx (cabal backend)</th> cabal</th> stack</th></tr></thead> Cold build</td> 0.48s</td> 2.52s</td> 2.68s</td> 3.2s</td></tr> Incremental</td> 0.05s</td> 0.35s</td> 0.39s</td> 0.52s</td></tr> Single file change</td> 0.31s</td> 1.42s</td> 1.42s</td> 1.8s</td></tr> </tbody></table> 5.6x faster cold builds. 7.8x faster incremental builds. The difference comes from eliminating Cabal’s package database queries, build plan calculation, and job scheduling overhead. Where does the time go in a normal Cabal build? Roughly: runtime initialization (45ms), reading the package database (80-120ms), computing the build plan (200-400ms depending on dependency count), checking file timestamps through the Cabal build system (100-200ms), and only then invoking GHC. hx native mode skips all of that. It reads file timestamps directly, constructs a minimal module graph, and calls GHC with exactly the flags needed. For projects with external dependencies, hx falls back to the Cabal backend transparently. You do not have to think about it. Dependency resolution</h3> hx includes a native dependency resolver written in Rust. The hx-solver</code> crate implements constraint resolution using the same algorithm as Cabal’s solver, but without the overhead of GHC’s runtime: Direct dependencies</th> hx</th> cabal</th></tr></thead> 10 packages</td> 5ms</td> 120ms</td></tr> 20 packages</td> 18ms</td> 450ms</td></tr> 50 packages</td> 85ms</td> 2.8s</td></tr> 100 packages</td> 320ms</td> 12.5s</td></tr> </tbody></table> At 100 dependencies, hx resolves in 320 milliseconds. Cabal takes 12.5 seconds. In a real-world test with 20 direct dependencies and their transitive closure, hx resolved in 1.2 seconds versus 8.5 seconds for cabal freeze</code>. Stack’s resolver is faster at 0.8 seconds because Stackage snapshots are pre-computed, but you trade resolution speed for version flexibility. Error messages</h3> Haskell’s reputation for cryptic error messages is partly deserved and partly a tooling problem. GHC type errors can be daunting, but build tool errors are often worse because they mix configuration issues with compilation issues in unhelpful ways. “Could not resolve dependencies” from Cabal tells you almost nothing about which constraint is blocking resolution or what you could change to fix it. hx uses structured error codes with actionable suggestions: E0012: Package 'aeson' not found in local index The package index may be outdated. Run: hx index update Or add the package explicitly: Run: hx add aeson </code></pre> E0020: GHC version mismatch Project requires GHC 9.8.2 but 9.6.4 is active. Run: hx toolchain install 9.8.2 </code></pre> Every error has a code, a human-readable explanation, and a concrete command to fix it. hx doctor</code> runs a comprehensive diagnostic of your entire environment, checking GHC, Cabal, HLS, PATH configuration, and project setup, reporting exactly what is wrong and how to fix each issue. Everything else</h3> hx bundles the rest of the development workflow too. hx fmt</code> wraps fourmolu for formatting. hx lint</code> wraps hlint. hx coverage --html --open</code> generates an HTML coverage report and opens it in your browser. hx doc --open</code> builds Haddock documentation and serves it locally. hx watch</code> detects file changes in 15 milliseconds (versus 180ms for stack --file-watch</code>) and triggers rebuilds or test runs. hx profile --heap</code> generates heap profiles for memory analysis. The goal is that you should never need to leave hx to do something with your Haskell project. Not because hx reimplements everything, but because it wraps the best existing tools with a consistent interface and fast orchestration. There is also a plugin system using Steel, a Scheme dialect, for custom build lifecycle hooks: ;; .hx/plugins/check-todos.scm (define (on-build-success project) (when (file-exists? "TODO.md") (warn "Do not forget to update TODO.md"))) (register-hook 'post-build on-build-success) </code></pre> Plugins live in .hx/plugins/</code> and time out after a configurable interval so a misbehaving script cannot stall your build. They hook into pre-build, post-build, pre-test, post-test, and other lifecycle events. Lightweight enough that you can add project-specific automation without maintaining a separate build script. Migration</h3> If you have an existing project, hx can import it: hx init --from-cabal # Import from an existing .cabal project hx init --from-stack # Import from a Stack project </code></pre> It reads your existing configuration, generates hx.toml</code>, creates a lockfile, and you are running. The .cabal</code> file is preserved for compatibility. hx reads it for package metadata and dependency specifications, but the build configuration and toolchain management move to hx.toml</code>. The architecture</h2> hx is structured as a Rust workspace with 14 crates: hx-cli | +-------------+-------------+ | | | hx-core hx-config hx-ui | | +---------+---------+ | | | | | hx-cabal hx-solver hx-lock | | hx-cache hx-toolchain | hx-doctor Separate concerns: hx-plugins, hx-lsp, hx-warnings, hx-telemetry</code></pre> Each crate has a single responsibility. hx-solver</code> knows how to resolve dependencies but nothing about building. hx-cabal</code> knows how to invoke Cabal but nothing about configuration. hx-toolchain</code> manages GHC installations but nothing about lockfiles. This separation means you can test the resolver without setting up a build environment, and you can change the build backend without touching the resolver. The hx-lsp</code> crate is worth calling out. It provides language server protocol support, which means hx can manage HLS (Haskell Language Server) versions matched to your project’s GHC version. When your project uses GHC 9.8.2, hx ensures HLS is compatible. No more “HLS crashed because it was compiled with a different GHC than your project uses.” This is a problem that has frustrated Haskell developers for years, and it is entirely a tooling coordination problem. The bigger picture</h2> I built hx because I needed it. But the timing is not accidental. In The Last Programming Language Might Not Be for Humans</a>, I laid out three futures for programming languages as AI becomes the primary author of code. The first future is explicit languages designed to minimize LLM errors through tight feedback loops. The second is declarative languages where code describes what something is rather than how to compute it, and the type system acts as a proof checker. The third is no language at all, where AI generates machine code directly. I bet on the second future. When an LLM writes imperative code, it has to track mutable state across dozens of lines, reason about the order of side effects, and hold implicit language behaviors in context. When it writes Haskell, it expresses a relationship between inputs and outputs, and the compiler verifies that the relationship is consistent. The model does not need to simulate execution step by step. It needs to generate an expression that satisfies type constraints. This is what LLMs are good at. Pattern recognition. Constraint satisfaction. Formal structure. Consider what happens when an AI generates a Haskell function with a wrong type. The compiler does not produce a vague runtime error three layers deep in a call stack. It produces a precise, localized type error at compile time: “Expected [LogEntry] -> [ErrorSummary]</code>, got [LogEntry] -> [LogEntry]</code>.” The model reads this, adjusts, and re-generates. The feedback loop is tight, but unlike the explicit-language approach, the tightness comes from the type system itself, not from bolted-on contracts. The correctness guarantees are structural, not ceremonial. This matters even more when you think about code that has to survive time. Procedural code decays. Three years from now, nobody remembers why a function mutates a global variable on line 47. The variable name made sense to whoever wrote it. The mutation order made sense in the context of the original design. But context evaporates. Types do not. A function signature that says Request -> Policy -> Decision</code> is self-documenting in a way that no amount of comments on imperative code can match. The proof is in the types, and the types are checked by the compiler, not by human memory. But none of that matters if nobody can set up a Haskell project without losing thirty minutes to toolchain configuration. The language’s virtues are locked behind a tooling wall. You can have the most expressive type system in production use, the most rigorous correctness guarantees, the best theoretical fit for agent-assisted development, and it means nothing if a developer’s first experience is fighting ghcup</code> for half an hour. First impressions are permanent, and Haskell’s first impression has been “powerful but painful” for too long. If Haskell is going to be relevant in a world where AI writes most of the code, the experience of using Haskell has to be as fast and frictionless as the experience of using Rust or Python. Not comparable. Equal. That is what hx is for. To remove the tooling objection entirely, so the conversation can be about the language’s actual strengths instead of its ecosystem’s historical baggage. hx is the first step. BHC</a>, the Basel Haskell Compiler, goes further. GHC is a remarkable piece of engineering, but it was designed for a world where Haskell ran on desktops and servers with one performance profile. BHC is a clean-slate Haskell compiler, also written in Rust, offering six runtime profiles for different deployment targets: Server: structured concurrency with automatic cancellation, observability hooks, deadline-aware scheduling</li> Numeric: strict-by-default in hot paths, tensor lowering, SIMD auto-vectorization, GPU backends for CUDA and ROCm</li> Edge: minimal runtime footprint, direct WASM emission, designed for Cloudflare Workers and Fastly Compute</li> Realtime: bounded GC pauses under 1 millisecond, arena allocation, designed for games and audio processing</li> Embedded: no GC at all, static allocation, bare-metal targets like ARM Cortex-M</li> </ul> Same language. Same type safety. Different performance contracts depending on what you are building. Your security policy engine compiles with the server profile. Your tensor pipeline compiles with the numeric profile and runs on a GPU. Your edge function compiles to WASM. You do not change your source code. You change the compiler flag. hx already supports BHC as an alternative backend: hx build --compiler=bhc --profile=server </code></pre> One flag. Same project. Different runtime. The vision behind arcanist.sh</a> is that Haskell’s ideas deserve infrastructure that matches their ambition. The language has always been decades ahead of its tooling. hx closes the gap on the developer experience side. BHC closes it on the runtime side. Together, they make the case that Haskell is not a language for academics and hobbyists. It is a language for the era we are entering, where correctness is not a luxury, it is the load-bearing structure of software that AI writes and humans verify. The tooling is not separate from the thesis. The tooling IS the thesis. The Bet, What If I am Wrong</h2> This is a gamble. I do not know whether Haskell will go through a revival. Nobody knows how AI-assisted development will actually evolve, which languages will matter in five years, or whether the thesis I outlined in the previous post will hold up against what reality delivers. I have a conviction, not a crystal ball. I spent months building hx and BHC. Months of my own time, and to be perfectly blunt, a significant number of Anthropic’s Claude tokens. I pair-programmed most of this with Claude Code on my Max subscription, and that is not a footnote. It is part of the story. The tools I am building for AI-assisted Haskell development were themselves built using AI-assisted development. If that sounds circular, it is. The thesis tested itself during its own construction. But I could be wrong. Haskell could remain niche forever. The AI era could favor a language nobody has thought of yet. The intermediate layer might not evolve the way I expect. The industry might double down on Python and TypeScript for agent-assisted workflows and never look back. These are all plausible outcomes. So I build toward what I believe in and put the work out in the open. If I am right, Haskell gets the tooling it always deserved, and the language is ready when the moment arrives. If I am wrong, the ideas in hx and BHC, fast Rust-based tooling, deterministic lockfiles, multiple runtime profiles, structured error messages, are valuable regardless. Good infrastructure design does not expire just because the language it serves does not win the popularity contest. And honestly, even on the unlikely side, I would rather have tried and been wrong than watched from the sidelines while the most elegant language I have ever used slowly faded because nobody bothered to fix the parts that were not the language. At least I have tried. Try it</h2> curl -fsSL https://arcanist.sh/hx/install.sh | sh hx new my-app && cd my-app hx run </code></pre> Then try hx doctor</code>, hx fmt</code>, hx test --watch</code>. See how it feels when the tooling gets out of your way. hx is MIT-licensed and open source. If you have opinions about Haskell tooling, I want to hear them. The Last Programming Language Might Not Be for Humans Unknown — Sat, 11 Apr 2026 00:00:00 +0000 This morning I was standing at my desk, drinking watered-down instant coffee, doing what I do every morning after triaging the high-alert emails and notifications: thirty minutes of HackerNews. It is a ritual I time-box and never skip. I go to the office every day, and whether I am at that desk or at my home desk, the morning is the same. Coffee, posture, front page. HackerNews remains one of the best ways to keep a finger on the pulse of the Bay Area, of tech, of science, of whatever intellectually stimulating thought surfaced overnight. I follow a handful of curated newsletters too, but I have noticed over the years that HN covers most of their content anyway if you know how to filter high signal from low signal. I could write something about a different link every single day. Most mornings I resist. This morning I did not. A link caught my eye. Vera</a>, a new programming language “designed for machines to write, not humans.” Statically typed, purely functional, compiles to WebAssembly, uses Microsoft’s Z3 solver for contract verification. It has a ferret mascot. I like animal mascots for tech projects. Ferris the crab for Rust, the gopher for Go, the Shisa guardian dog for Zentinel</a>. The ferret is a good choice. But the mascot is not why I stopped scrolling. I stopped because somebody else had arrived at the same conclusion I had reached back in December: that conventional programming languages are not adapted to the capabilities of this new technology, and that something has to change. The Christmas realization</h2> I had been a paying Claude Code subscriber since May 2025, when Anthropic first launched it. The CLI orientation made sense to me immediately, even though the early rate limits and model quality left me wanting more. By December 2025, I had upgraded to the Max subscription, I was on vacation, and Anthropic had made the daily limits generous that month. I was burning through every idea I had accumulated over the years. Some were good. Some were terrible. All of them were finally testable in a way they had not been before, because I could pair-program with a model that kept up. I wrote about that shift more fully in How I Work These Days</a>, the short version being that late 2025 was when the relationship between ambition and execution fundamentally changed for me. The dam broke. Ideas that had been sitting in notebooks for years started becoming real software in days. It was during one of those late-night sessions, deep in a Claude Code conversation about compiler design, that a thought crystallized. I had been building hx</a> and thinking about how AI would change the way people write Haskell, when I realized the question was bigger than Haskell. Agent-assisted software development is approaching a point where the output language itself, the intermediate layer we use to express how information should be processed, is going to change fundamentally. This is not an abstract observation. The history of software is a history of abstraction layers accumulating, each one letting the next generation of programmers ignore what the previous generation had to master. It started with machine code. Raw opcodes, different for every CPU architecture. If you wanted to write software, you memorized instruction sets and wrote them by hand. People published thick reference manuals, and there were engineers who could hold entire instruction set architectures in their heads. Some of them are still around, and some of them still swear by that methodology. Then assemblers gave those opcodes human-readable names. MOV AX, BX</code> instead of 89 D8</code>. You were still writing for a specific architecture, still thinking in registers, but now you could read what you wrote. The first abstraction was not a new capability. It was legibility. Then C arrived and gave us a portable abstraction over hardware. You stopped thinking in registers and started thinking in functions and pointers. C compiled down to architecture-specific assembly, but you did not have to care which architecture. One language, many targets. The reference manuals shifted from instruction sets to language specifications. Then interpreters and virtual machines added another layer. The JVM, Python, Perl. You stopped thinking about memory layout and started thinking about objects, iterators, garbage collection. The abstraction was thicker, the feedback loop was faster, and the audience expanded from hardware engineers to anyone who could write a script. Then IDEs changed how you interacted with the language itself. Syntax highlighting, autocomplete, integrated debuggers, refactoring tools. You stopped holding the entire API surface in your head because the editor held it for you. The language did not change, but the cognitive cost of using it dropped. IntelliSense was not a language feature. It was an abstraction over the programmer’s memory. Then the internet changed how code moved. Open source repositories, package managers, shared libraries. You stopped writing everything from scratch and started composing from parts other people had built. The reference material moved from printed books to web documentation, wikis, tutorials. Then StackOverflow changed how people learned. Instead of reading manuals cover to cover, you searched for the specific problem you had and found someone who had already solved it. The knowledge layer itself became an abstraction. You did not need to understand the full system. You needed to find the right answer and adapt it to your context. StackOverflow never compiled a line of code, but it was an intermediate layer between human confusion and working software, and it was arguably more important to the average developer’s productivity than any language feature shipped in the same decade. And now StackOverflow is receding. Not because the answers got worse. Because the next abstraction layer arrived. AI coding agents do what StackOverflow did, finding known solutions to known problems, but they also do what StackOverflow never could: synthesize novel solutions, hold project context across files, and generate working code from intent descriptions. The pattern is the same as every previous transition. Each layer makes the previous one less essential, not by replacing it but by absorbing it into a higher-level abstraction. Programming languages have always been shaped by who writes them. Assembly was shaped by hardware engineers who thought in registers and opcodes. C was shaped by systems programmers who needed portable abstractions over memory. Python was shaped by people who wanted to get things done without fighting the syntax. COBOL was shaped by business analysts who wanted code that read like English. Every language carries the fingerprints of its intended author. If AI becomes the primary author of code, it follows that the language should adapt to that new author’s strengths and weaknesses. This is not a break from the pattern. It is the pattern, doing what it has always done. I kept coming back to three concrete possibilities. Three ways the intermediate layer could evolve. Not competing visions, exactly. More like three points on a timeline. Make the language explicit enough for machines</h2> Anyone who has spent real time with coding agents has seen the failure mode. You ask an LLM to write a Python function. The output looks plausible. It passes linting. The variable names are reasonable. The structure follows common patterns. Then it fails at runtime because of a subtle implicit behavior the model did not track. A default mutable argument that gets shared across calls. A generator that gets silently exhausted on second iteration. A method that returns None</code> instead of raising an exception because some library author decided that was more “Pythonic.” The model was not wrong about the algorithm. It was wrong about the language’s hidden behaviors. This is the problem Vera is trying to solve, and the first approach I had been contemplating. Take the simplicity and explicitness of Go, push it further, and design a language where every instruction, every method, every design pattern is as unambiguous as possible. No implicit behaviors. No naming ambiguity. No style choices. One canonical way to write everything, so that an LLM does not have to waste inference tokens reasoning about which of seventeen valid approaches to take. The language would need excellent compiler diagnostics. Not just “type mismatch on line 47,” but structured feedback that a model can parse, understand, and act on immediately. Rust and Elixir already do this well for humans. Do it even better, and do it for machines. The pipeline looks like this: +-------+ prompt +-------+ explicit +-----------+ | Human | -------------> | LLM | -------------> | Verifying | +-------+ +-------+ source | Compiler | ^ +-----------+ | | | structured error | | + suggested fix | +---------------------------+ | verified | v [correct program]</code></pre> The key insight is the feedback loop. The compiler does not just reject bad code. It explains what is wrong in terms the model can act on, with a concrete fix suggestion. The model re-generates. The compiler re-checks. You converge on correct code through iteration, and the tightness of that loop depends on how unambiguous the language is and how actionable the errors are. Vera is exactly this idea, executed with conviction. Here is what a function looks like: public fn safe_divide(@Int, @Int -> @Int) requires(@Int.1 != 0) ensures(@Int.result == @Int.0 / @Int.1) effects(pure) { @Int.0 / @Int.1 }</code></pre> No variable names at all. Parameters are referenced by type and positional index using De Bruijn slot notation. @Int.0</code> is the most recently bound integer, @Int.1</code> is the one before that. Every function must declare its preconditions (requires</code>), postconditions (ensures</code>), and side effects (effects</code>). The compiler verifies contracts statically using Z3 where possible and falls back to runtime checks for what it cannot decide at compile time. The design principle is sharp: the model does not need to be right, it needs to be checkable. The language constrains the space of valid programs so tightly that the compiler catches mistakes before execution and explains them in natural language. Division by zero is not a runtime exception. It is a contract violation caught during compilation. Think of it like this. Traditional languages are an open field. You can walk in any direction, and you might end up somewhere useful or you might walk off a cliff. Vera is a guided path with guardrails. You can only go certain directions, and every time you try to step off the path, a sign tells you exactly where to step instead. An LLM on an open field will wander. An LLM on a guided path will converge. The early benchmark results are interesting, if mixed. Kimi K2.5 apparently writes perfect Vera code, scoring 100% on VeraBench and beating its own Python and TypeScript scores. Other models do not fare as well. Claude Opus 4 scores 88% in Vera versus 96% in Python. The Vera team is honest about this variance, which I appreciate. The HackerNews discussion</a> was thin, twelve points and three skeptical comments, which tells you how early this conversation still is. The broader developer community has not engaged with this idea seriously yet. That will change. But there is something that bothers me about optimizing the language for how machines iterate on solutions. Look at the pipeline diagram again. The LLM is still generating step-by-step instructions. It is still describing HOW to do things, just with the ambiguity stripped out and the contracts made explicit. The machine still reasons through the process sequentially. You have reduced the noise in the feedback loop, but you have not changed the nature of the signal. The model is still writing recipes. They are just more precise recipes. What if you stopped writing recipes entirely? Describe what, not how</h2> The second idea starts from a different premise. Instead of making procedural code easier for AI to write correctly, change what you ask the AI to express. Let me make this concrete. Say you need to find the ten most recent server errors in a log. Here is how you would describe that process in a procedural language: errors = [] for entry in log_entries: if entry.status >= 500: errors.append({ "time": entry.timestamp, "path": entry.path, "code": entry.status }) errors.sort(key=lambda e: e["time"], reverse=True) return errors[:10] </code></pre> You are telling the machine: create an empty list. Walk through each entry. Check a condition. If it matches, build a dictionary and append it. Then sort the accumulated list by a key. Then take the first ten elements. Every step is an instruction. The machine has to track the mutable list, the iteration state, the sort, the slice. And if you get any step wrong, the others might still succeed, producing output that looks correct but is subtly broken. A missing reverse=True</code> and you silently get the oldest errors instead of the most recent. Here is the same thing in Haskell: recentErrors :: [LogEntry] -> [ErrorSummary] recentErrors = take 10 . sortBy (flip compare `on` time) . map toSummary . filter isServerError </code></pre> Read it bottom to top: filter server errors, transform each into a summary, sort by time descending, take ten. There is no mutable accumulator. No loop variable. No intermediate state. You are not describing a process. You are describing a relationship between the input and the output. The function says what the result IS, not how to compute it step by step. The type signature at the top, [LogEntry] -> [ErrorSummary]</code>, is a contract the compiler enforces. If toSummary</code> returns the wrong type, if isServerError</code> does not take a LogEntry</code>, if you accidentally compose functions in an order that does not type-check, the compiler rejects the program before it runs. Not with a vague “object has no attribute” at runtime. With a precise type error at compile time that tells you exactly which piece does not fit. This distinction matters enormously for AI. Think about what an LLM actually has to track in each case: Procedural (Vera, Python, Go) Declarative (Haskell) ================================ ================================ - mutable variables and their - input type current state at each step - output type - loop iteration progress - which transformations to compose - conditional branching outcomes - whether types align - order of side effects - implicit language behaviors - names and what they refer to</code></pre> The procedural model asks the AI to simulate execution in its head. The declarative model asks the AI to describe a transformation and let the compiler verify it. One plays to an LLM’s weakness (tracking state across many steps). The other plays to its strength (recognizing and generating patterns that satisfy formal constraints). The pipeline changes fundamentally: +-------+ prompt +-------+ type sigs +-----------+ | Human | -------------> | LLM | -------------> | Compiler | +-------+ +-------+ pure exprs +-----------+ | types align? / \ yes no | | v v [proven correct] [precise type error: "Expected LogEntry, got String at ...]</code></pre> No feedback loop needed in the happy path. If the types align, the program is correct by construction for the properties the type system tracks. The compiler is not iterating with the model. It is checking a proof. This is the approach I bet on. It is the reason this blog exists. Raskell, the name behind this site, is a portmanteau of Rascal (as in raccoon, which is my mascot) and Haskell. The language I have loved for years because of how elegantly it describes things close to mathematical proofs. QEDs, not TODOs. When you write a well-typed Haskell function, you are not just writing code. You are writing a proof that a certain transformation is valid, and the compiler is the proof checker. But loving Haskell and shipping Haskell in production are different experiences, and the gap between them is mostly tooling. The ecosystem is fragmented in a way that has frustrated people for over a decade. cabal</code>, stack</code>, ghcup</code>. Three tools that do overlapping jobs with different opinions about how dependencies should work. If you come from Python, imagine if pip</code>, poetry</code>, and pyenv</code> were all developed independently, with different lockfile formats, different resolver algorithms, and occasional incompatibilities. That was Haskell. Build times were slow. Error messages ranged from helpful to cryptic. The runtime assumed one performance profile fits every use case. If you wanted Haskell for edge functions, for embedded systems, for GPU-accelerated numerics, you spent as much time fighting the toolchain as writing the actual code. The language was right. The surrounding infrastructure was not. So I started building arcanist.sh</a>, taking the same approach that astral.sh</a> brought to Python tooling. When astral.sh released uv</code> and ruff</code>, it showed that you could take a mature ecosystem with entrenched tooling, rebuild the developer experience from scratch in Rust, and make everything dramatically faster and more coherent. I wanted to do the same for Haskell. arcanist.sh houses two projects. hx</a> is a fast, opinionated, next-gen toolchain for Haskell, built in Rust. One tool that replaces the fragmented stack. Managed compiler versions pinned per-project. Deterministic TOML lockfiles with fingerprint verification. 5.6x faster cold builds than cabal. 7.8x faster incremental rebuilds. curl -fsSL https://arcanist.sh/install.sh | sh hx new my-app && cd my-app hx run </code></pre> No ghcup. No stack. No cabal-install. Just hx</code>. BHC</a>, the Basel Haskell Compiler, goes further. It is a clean-slate Haskell compiler written in Rust, not a GHC fork, targeting the Haskell 2026 Platform specification. It uses LLVM for native code generation and offers six runtime profiles that you select at compile time: Profile</th> Designed for</th> Key trait</th></tr></thead> default</td> General applications</td> Lazy evaluation, GC-managed, GHC-compatible semantics</td></tr> server</td> Backend services</td> Structured concurrency, automatic cancellation, observability hooks</td></tr> numeric</td> ML and scientific compute</td> Strict numerics, tensor lowering, SIMD, GPU backends (CUDA/ROCm)</td></tr> edge</td> WASM and CDN workers</td> Minimal footprint, direct WASM emission without LLVM</td></tr> realtime</td> Games, audio, robotics</td> Bounded GC pauses under 1ms, arena allocation</td></tr> embedded</td> Bare metal, microcontrollers</td> No GC at all, static allocation, targets like ARM Cortex-M</td></tr> </tbody></table> The same Haskell source, different runtime contracts depending on what you are building. Your security policy engine compiles with the server profile and gets structured concurrency with tracing. Your tensor pipeline compiles with the numeric profile and gets GPU acceleration. Your edge function compiles to WASM and runs on Cloudflare Workers. Same language. Same type safety. Different performance envelopes. The conviction behind this work is specific. When AI writes the code, the language that survives is not the one optimized for procedural explicitness. It is the one that brings consistency and purity by describing what something is, not how to compute it. AI is extraordinarily good at generating expressions that satisfy formal constraints. And source code that reads like a proof can survive time. It can survive maintainer burnout. It can survive the fact that three years from now, nobody remembers why a function was written the way it was. The types remember. The proof is self-documenting in a way that procedural code never is, because the types encode the intent. Vera and arcanist.sh accept the same premise: the intermediate layer is changing. They disagree about which direction it should change in. Vera optimizes for reducing errors in the generation loop. Valuable. But hx and BHC optimize for making the generated code correct by construction, because the language itself constrains what valid programs look like at a structural level. Skip the language entirely</h2> The third possibility is the one I think about late at night and do not have a concrete project for. Not yet. It is also the one I find most fascinating and most unsettling. What if AI stops writing source code at all? To understand why this is plausible, it helps to look at what source code actually is. It is not the final product. It never was. Source code is a set of instructions that a compiler transforms into machine code. Machine code is what the hardware executes. Source code exists because humans needed an abstraction layer between their intentions and the silicon. We think in concepts like “sort this list” or “reject unauthorized requests.” The CPU thinks in register moves, memory loads, and conditional jumps. Source code bridges that gap. But that bridge was built for human authors. If the author is no longer human, the bridge serves a different purpose. It becomes an audit trail. A way for humans to read and verify what the AI produced. Not an authoring medium, but a transparency layer. I see this playing out in two distinct phases. Phase one: AI targets existing machine code</h3> The first phase is closer than most people think, and it is conceptually straightforward. We already train models on source code. What happens when we also train them extensively on compiled artifacts? On binaries, object files, intermediate representations, the actual output of compilers? Consider what a compiler does. It takes source code and transforms it into machine instructions following well-defined, deterministic rules. There is a mapping between source patterns and output patterns. A for</code> loop in C becomes a specific sequence of compare, branch, and increment instructions on x86. A function call follows a specific calling convention. Memory allocation follows specific system call patterns. These mappings are learnable. They are patterns, and pattern recognition is exactly what LLMs excel at. Today: human intent → prompt → LLM → source code → compiler → x86/ARM → CPU Phase one: human intent → prompt → LLM → x86/ARM directly → CPU (trained on source + compiled artifact pairs)</code></pre> In this phase, the model skips the source code layer and generates machine code directly. Not by “compiling” in the traditional sense. By having learned the patterns well enough to produce valid executables from intent descriptions. The way a fluent translator does not parse grammar rules consciously but produces correct sentences from meaning directly. This sounds radical until you remember that we already trust compilers we do not read the output of. When was the last time you inspected the assembly output of gcc -O3</code> to verify it correctly compiled your C program? You trust the compiler. You test the behavior of the resulting binary. You do not audit the intermediate representation. If an AI can produce binaries that pass the same behavioral tests, the practical difference between “AI-generated machine code” and “compiler-generated machine code” becomes a question of trust calibration, not fundamental possibility. The analogy I keep returning to is aviation. Early pilots flew by hand and understood every mechanical system in the aircraft. Fly-by-wire changed that. The pilot communicates intent (climb, turn, maintain altitude). The computer translates that into control surface movements. The pilot does not manually adjust ailerons and elevators for every gust of wind. They trust the system. They verify outcomes (altitude, heading, airspeed), not intermediate steps. Phase one of post-language programming is fly-by-wire for software. If this sounds speculative, consider what happened this week. Anthropic announced Project Glasswing</a>, a coalition including AWS, Apple, Google, Microsoft, NVIDIA, CrowdStrike, Palo Alto Networks, the Linux Foundation, and others, formed to secure the world’s most critical software using AI. Dario Amodei, Anthropic’s CEO, put it plainly: “AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.” </blockquote> The proof point he offered: “For OpenBSD, we found a bug that’s been present for 27 years.” Think about what that means. OpenBSD is one of the most carefully audited codebases in the world. Decades of security-focused human review by some of the most meticulous systems programmers alive. And an AI model found something that every human reviewer missed for twenty-seven years. If AI can understand existing code deeply enough to find vulnerabilities that humans cannot, it can understand code deeply enough to generate it without human-readable source as an intermediate step. The question is no longer whether AI comprehends code at a structural level. That question was answered this week. The question is what it does with that comprehension next. Phase two: a new kind of machine</h3> The second phase is further out and more speculative. But I think it is where things ultimately go. If AI is generating code for machines to execute and no human needs to read it, there is no reason that code needs to target instruction sets designed for human comprehension. x86 and ARM were designed with the assumption that someone, at least occasionally, would look at the instructions. They have mnemonics. They follow conventions that make disassembly feasible. They are organized into instructions that map, loosely, to operations humans understand. But what if the execution target was designed from scratch for AI-generated code? A virtual machine or runtime that consumes a new kind of bytecode. Not optimized for human readability. Not optimized for hand-authored assembly. Optimized purely for execution density and machine generation. Phase two: human intent → prompt → AI → dense symbolic bytecode → AI-native VM (opaque to humans, | optimized for machine v generation + execution) [result]</code></pre> I keep thinking about information density. Chinese characters encode meaning in individual symbols that carry far more semantic weight than Latin alphabet words. A single character can represent a concept that takes an entire English phrase to express. When a system is designed for readers who can process dense symbols natively, the representation compresses. It becomes more efficient at the cost of being less accessible to readers who were not part of the design audience. AI-native bytecode could follow the same principle. Each instruction could encode complex composite operations that would take dozens of conventional instructions to express. The bytecode would be dense in ways that make current machine code look verbose. Entirely opaque when decompiled or analyzed. Not obfuscated on purpose. Just natively incomprehensible to human cognition, the same way a trained neural network’s weights are incomprehensible even though they encode real, functional knowledge. The virtual machine running this bytecode would itself be a different kind of system. Not a stack machine or a register machine in the traditional sense. Possibly something closer to a dataflow engine, where the bytecode describes transformation graphs rather than sequential instructions. Think of it as the difference between giving someone turn-by-turn driving directions (go north, turn left, continue for two miles) versus handing them a map with the destination marked. The bytecode is the map. The VM figures out the route. I want to be honest about where we are. We are not at phase one. Not in April 2026. Current models still need the intermediate layer. They produce better code when they can reason through it step by step. They benefit from type systems and contracts and explicit error messages. The first and second approaches are not just viable, they are necessary right now. But the trajectory is visible. Models are getting better at generating correct programs with every generation. Formal verification is becoming more practical. Hardware is getting cheaper. The gap between “prompt that describes intent” and “correct executable output” is shrinking. Phase one will arrive when models trained on enough source-plus-binary pairs can reliably produce correct executables. Phase two will arrive when someone asks: if the model is already generating the binary, why are we targeting an instruction set that was designed for a species that is no longer doing the writing? At some point the intermediate layer becomes optional. And optional things, given enough time, become vestigial. What this means</h2> I do not think these three approaches are in competition. They are three points on a timeline, and the timeline is the story of the intermediate layer contracting. Near term Medium term Long term (now) (2-5 years) (5-15 years) Explicit Declarative Post-language languages languages (AI-native targets) (Vera) (Haskell + BHC) Reduce noise --> Change the signal --> Remove the layer in the loop entirely entirely HOW, but WHAT, verified Intent to unambiguous by types execution</code></pre> In the near term, explicit languages like Vera make AI-generated code more reliable by constraining the generation space and providing machine-readable diagnostics. This is useful today. If you are building an AI coding pipeline right now and need to ship next quarter, this approach works. In the medium term, declarative languages like Haskell, especially with modern tooling and modern runtimes, make AI-generated code correct by construction. The type system does the heavy verification work at a fundamental level. The code that survives is the code that describes invariants, not procedures. This is the era I am building for with arcanist.sh. In the long term, the language disappears. First into existing machine code generated directly by AI. Then into new execution formats designed for AI generation from the ground up. The intermediate layer that has defined software engineering for seventy years becomes an implementation detail. That last possibility makes some people uncomfortable. It made me uncomfortable when I first thought about it in December. It means that the craft of programming as we know it, the fluency in syntax, the mastery of idioms, the instinct for an elegant implementation, becomes less like a core skill and more like knowing how to operate a manual lathe. Valuable in the right context. Still needed for the hard cases. But no longer the primary way most software gets built. This has happened before. There was a time when every programmer understood assembly. Then C abstracted it away, and most programmers stopped reading machine code. Then Python and JavaScript abstracted C away, and most programmers stopped thinking about memory management. Each time, the previous layer did not disappear. It became the domain of specialists who maintained the infrastructure everyone else stood on. The same thing will happen to source code. It will not vanish. It will specialize. I still write code every day. I still think in types. I am still building hx and BHC because I believe the medium-term future is both real and long, and Haskell’s strengths are exactly what that future demands. Pure functions, strong types, provable correctness. These are not luxuries in a world where AI writes the implementation. They are the load-bearing structure. But I do it with one eye on the horizon, knowing that the intermediate layer I am investing in is exactly that. Intermediate. The person who built Vera saw the same thing I saw, probably around the same time. They chose the first approach. I chose the second. Somebody, eventually, will build the third. And then we will all need to figure out what we mean by “programming” when nobody writes programs anymore. I am already curious about the answer. Notes from RSAC 2026 Unknown — Thu, 09 Apr 2026 00:00:00 +0000 I am writing this about two weeks after RSAC 2026 closed. In between, my coworkers and I drove down the West Coast, through Big Sur to LA, then out to Las Vegas for Easter weekend. That was deliberate. Not the route, exactly, but the space. The conference gave me a lot to process, and I have learned over the years that I process better when I am moving, when I am not sitting at a desk trying to force conclusions out of raw impressions. So here is what I took away. Not a session-by-session recap. Not a vendor roundup. Just the things that are still with me now that the noise has faded and the Pacific Coast Highway is behind me. The talk</h2> Milan Duric and I presented “Self-Learning WAF: Using Generative AI to Tame ModSecurity False Positives” on Wednesday morning, March 25, in Moscone West 3020. We had an 8:30 AM slot, which is either a curse or a blessing depending on your audience. It turned out to be a blessing. The room was full of people who had chosen to be there at that hour, which means they cared about the topic, and the energy reflected that. The talk went flawlessly. If you have ever presented at a conference of that scale, you know that “flawless” is not something you take for granted. There is always the moment before you start where you wonder if the demo will work, if the projector will behave, if your timing will hold. All of it held. Milan and I had rehearsed enough that the talk felt natural rather than performed, which is the line you want to hit. I will write a separate post about the content of the talk itself, what we built, what we learned, how the audience responded to specific ideas. This post is about everything else. Third time, first time</h2> This was my third RSA Conference. I attended in 2024, 2025, and now 2026. But it was my first time as a speaker, and that changed the experience in ways I did not fully expect. When you attend as a participant, you are a consumer of the conference. You pick sessions, you walk the expo floor, you absorb. When you are a speaker, even for just one session, you become part of the fabric. People approach you after the talk. They reference something you said in a hallway conversation two days later. You are on the other side of the dynamic, and it gives you a different relationship with the event. I have grown to genuinely appreciate the sheer volume and quality of the whole thing. RSAC is not one conference. It is several conferences layered on top of each other. There are deeply technical sessions where people walk you through real implementations, real code, real incident response timelines. There are strategic talks where CISOs and policy architects work through the organizational and regulatory implications of what is changing. And then there are the keynotes, the big voices, people who have shaped the field for decades, sharing what they see on the horizon. Because it happens in San Francisco, in the heart of the Bay Area, the reach is different from any other security event. You are not just at a conference. You are at the geographic center of the industry that is driving the transformation everyone is trying to understand. The density of talent, capital, and ambition in that city during RSAC week is difficult to describe if you have not experienced it. The only comparable events I can think of are BlackHat and DefCon, but even those have a different energy. RSAC pulls in a wider spectrum of the industry, from the deeply technical to the deeply strategic, from startup founders to government officials, and puts them all in the same building for a week. That range is what makes it valuable. The year of agents</h2> Ever since I started attending in 2024, AI has been a substantial part of the conference. That makes sense. The developments in AI over the past few years have had a prominent cybersecurity dimension from the start, and the industry has been working through what that means, both as a threat to defend against and as a capability to harness. But this year felt qualitatively different from the previous two. In 2024 and 2025, the AI conversation was broad and somewhat exploratory. What can large language models do for security? How do we detect AI-generated phishing? What does the threat landscape look like when attackers have access to the same models we do? Important questions, but still in the “what is possible” phase. 2026 was past that. The conversation had narrowed and deepened. It was specifically about agents. Not AI in general, not language models as a capability, but autonomous agents as a new category of infrastructure. Enterprise-grade agentic systems. Agentic orchestration patterns. Agent-native architectures. The shift from “can we use AI?” to “how do we architect our systems around autonomous agents that are already here?” was palpable in almost every session I attended. The concept that kept coming up was NHI: non-human identities. This term has existed in the identity and access management world for a while, but at RSAC 2026 it had taken on a new meaning. The old NHI conversation was about service accounts, API keys, machine certificates. The new NHI conversation is about LLM inference backends that operate as something fundamentally different from traditional automated systems. These are entities that do not just execute a fixed pipeline. They reason, they make judgment calls, they interact with systems and data in ways that look more like what a human analyst does than what a cron job does. But they operate at machine speed, they do not sleep, and they do not have the contextual judgment or accountability that comes with a human in the seat. The trust problem this creates is real, and it is not just a theoretical concern. Human employees were already risk factors before AI entered the picture. Insider threats, social engineering, credential compromise, accidental misconfiguration. These are well-understood attack surfaces. Now add entities that move faster than any human, that can touch more systems in a minute than a human employee touches in a day, and that are harder to audit because their reasoning process is opaque. The attack surface did not just grow. It changed shape in ways that existing security architectures were not designed for. The human-in-the-loop debate</h2> This was the most interesting tension I observed across the conference, and I think it is going to be one of the defining questions for cybersecurity in the next few years. A small number of talks presented approaches that kept a human firmly in the loop. AI assists, human decides. AI flags, human acts. AI generates recommendations, human approves or rejects. These were careful, measured presentations, and some of them were good. The argument is intuitive and appeals to anyone who has been burned by automation gone wrong: keep a human in the critical path because humans have judgment that machines do not. But the majority of the conference had reached a different consensus, and it was stated with increasing confidence as the week went on: the human in the loop is a bottleneck. Not philosophically. Operationally. In terms of the speed at which threats materialize and the speed at which defenses need to respond. The argument is straightforward once you lay it out. Adversaries and threat actors are already leveraging AI to accelerate their operations. They are scanning for vulnerabilities at machine speed. They are generating novel attack variations faster than any human analyst can write detection rules. They are using AI to identify and exploit zero-day vulnerabilities in timeframes that make traditional patch cycles look like geological processes. If your defensive response depends on a human reading an alert, understanding the context, making a judgment call, and clicking a button before a countermeasure activates, you have introduced a rate limiter into your defense that your attacker does not have. You are playing at human speed against an adversary operating at machine speed. I agree with this assessment, and I want to be precise about what I mean by that. I do not think humans are irrelevant to security. They are not. Human judgment, human understanding of organizational context, human ability to reason about novel situations, these remain essential. But I think the role of the human needs to shift fundamentally. The human should be a supervisor, not a gatekeeper. The human should set policy, define constraints, establish acceptable parameters, review outcomes, and intervene when something goes wrong. But the human should not be the bottleneck whose reaction time determines how fast sophisticated defense measures can respond to a threat that is moving at inference speed. This is an engineering problem, not a philosophical one. How do you design agent-native architectures where the human is still in control, still has full visibility, still sets the rules, but is not the limiting factor in the response loop? That is the challenge of 2026. I did not hear anyone at the conference claim to have fully solved it. But I heard a lot of people working on it seriously, and the framing had matured beyond the naive “just automate everything” takes that dominated the early AI-security conversation. This is also, incidentally, part of why I built Zentinel</a> the way I did. A reverse proxy that sits at the edge, where policy enforcement happens at wire speed, is exactly the kind of system that needs to operate autonomously within human-defined constraints. The agent architecture in Zentinel, where security logic runs in isolated processes with bounded resources and explicit failure modes, is my answer to the question of how you let autonomous systems make real-time decisions while keeping the human in the position of supervisor rather than bottleneck. I wrote about this in more detail in What Zentinel Is Really Optimizing For</a>. The four factors</h2> I attended a panel with four former NSA directors and US Cyber Command commanders. Both positions are held by the same person at any given time, so these were people who had sat at the intersection of signals intelligence and military cyber operations at the highest level the United States has. Regardless of how you feel about the NSA or US foreign policy, the caliber of strategic thinking in that room was extraordinary. Paul Nakasone said something that has stayed with me since. He laid out what he considers the four most important factors when assessing the strategic potentiality of a nation state in this era. Not military strength. Not GDP. Four specific things: chips, data, talent, and energy. Chips, meaning silicon, meaning raw compute power. How many advanced GPUs can you deploy? How advanced are they relative to the frontier? And critically: can you manufacture them domestically, or are you dependent on someone else’s fabrication capacity? Right now, the entire world depends on TSMC in Taiwan for leading-edge chip fabrication, and the geopolitical implications of that single point of dependency are staggering. Data, meaning access to the raw material that AI systems learn from. Who has it, how much of it, how diverse is it, and under what legal and political constraints can it be used for training and inference? Talent, meaning the human capital that knows how to build, train, deploy, secure, and govern these systems. Where that talent lives, where it wants to live, and what it takes to attract and retain it. This is not just about researchers at frontier labs. It is about the entire pipeline: the engineers who build the infrastructure, the operators who keep it running, the security professionals who defend it, the policy people who regulate it. Energy, meaning access to cheap, abundant, reliable power. Because the compute demands of frontier AI are measured in gigawatts now, not megawatts. A single frontier training run can consume more electricity than a small city. The question of whether you can physically power your AI ambitions is no longer abstract. I could not stop thinking about AI 2027</a> while listening to Nakasone. The scenario work by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean, which I first wrote about in How I Work These Days</a>, makes strikingly similar assessments from a technology trajectory perspective rather than a national security one. Their scenario tracks the distribution of global AI compute (the US holding roughly 70% of frontier capacity through its companies, China around 12%), the geopolitical competition for chip manufacturing, the energy infrastructure required to sustain frontier operations (their projection of global AI datacenter spending reaching the trillion-dollar range by 2026 no longer reads like speculation), and the talent concentration in a handful of US-based labs. What makes AI 2027 feel prophetic, and I do not use that word casually, is that its core thesis keeps holding up month after month. The idea that automating AI research itself creates a self-reinforcing feedback loop, that the cycle between capability and capability-building is compressing, that the timeline for transformative change is shorter than most institutional planning horizons assume. The specific dates and milestones may shift. The authors themselves have revised some timelines. But the directional assessment, the shape of the curve, still looks right to me as of April 2026. The scenario’s detailed treatment of compute distribution, espionage risks, and the escalatory dynamics between nation states competing for AI dominance maps remarkably well onto what I heard discussed in more guarded terms on the RSAC floor. Listening to Nakasone lay out those four factors, I kept thinking about Europe. And about Switzerland specifically, since that is where I live and work. Europe is behind on all four. The continent does not manufacture frontier chips. It does not host the leading AI labs. Its regulatory environment, while well-intentioned, has optimized more for constraint than for capability. Its energy infrastructure is in the middle of a complex transition. And its talent pipeline, while strong in research, struggles to retain builders who can turn research into deployed systems at scale, because many of them leave for the Bay Area, London, Singapore, the Gulf states, or other places where the ecosystem is more supportive of what they want to build. This is part of why I co-founded Die Zukunft</a>, a new Swiss political party focused on structural transformation. The name means “The Future” in German. The party exists because I believe the political infrastructure in Switzerland, and in most European countries, is not designed to respond to the kind of structural shift that Nakasone was describing. The decisions being made right now about compute sovereignty, energy policy, talent retention, and regulatory frameworks will determine whether Europe is a participant in the next decade or a consumer of other people’s technology. Die Zukunft’s platform addresses these questions directly: digital sovereignty defined in infrastructure terms, faster permitting for critical energy and compute projects, open standards as a hard requirement for government systems, and immigration policy designed to attract the talent that builds these systems. It is not a technology party in the narrow sense. It is a party built on the recognition that the structural transformation AI is driving is too consequential to be left to the current pace of European political response. And this is also why I built Archipelag</a>. If Europe wants digital sovereignty, it needs sovereign compute infrastructure. Not just policy positions about data residency, but actual physical capacity to run AI workloads within European jurisdictions, at competitive cost, without depending on American hyperscalers. Archipelag is a decentralized AI compute network that routes inference jobs to community-operated nodes with jurisdiction-aware routing baked into the infrastructure layer. It is designed so that a European company can run AI workloads with cryptographic guarantees about where their data is processed, using idle GPU capacity that already exists across the continent. It is my direct answer to the infrastructure gap that Nakasone’s four factors expose so clearly for Europe. The enterprise problem</h2> This connects to something broader that I have been thinking about since well before RSAC, but that the conference brought into sharper focus. I work for a large Swiss financial institution. My perspective is shaped by what I see inside that kind of organization every day. But I believe the dynamic applies to enterprises of all sizes and in all sectors, even if the scale and specifics differ. The biggest threat I see right now is not a specific vulnerability, not a particular attack vector, not a novel exploit technique. It is inertia. It is the widening gap between what is happening at the frontier of AI capability and what most organizations are actually doing about it. Too many companies still think they can outsource their way through this transition. Buy an AI-powered security product from a vendor. Subscribe to a managed detection service that mentions “AI” somewhere in its marketing materials. Check the compliance box and move on to the next quarter. I do not think that is going to work. Not because those vendors are bad. Some of them are genuinely good at what they do. But because the organizations that will remain competitive and secure over the next few years are the ones that build internal AI capability, not just consume external AI services. That means investing in your own GPU compute. That means building the internal expertise to deploy, fine-tune, and operate models on your own infrastructure. That means treating AI as a core organizational competency, not a procurement line item. This is not a popular opinion in many boardrooms. It is expensive. It is hard. It requires talent that is difficult to hire and even harder to retain when they can work at a frontier lab or a well-funded startup instead. But the alternative, waiting and relying on service providers to package AI innovation for you at their pace and under their terms, means you are always operating one step behind. You are consuming someone else’s capability with someone else’s priorities, under someone else’s constraints. In a landscape that is moving as fast as this one, that delay compounds. The companies that understand this and invest now are going to have a structural advantage that widens over time. The ones that wait are going to find themselves trying to close a gap that gets larger with every quarter of inaction. I saw enough at RSAC to believe that some organizations have internalized this. And I saw enough to believe that many more have not. The vendor floor</h2> I want to be fair about this, because I know how the previous section sounds, and I do not want to come across as someone who dismisses the entire vendor ecosystem. I am not easily swayed by big tech vendors and their keynote promises, and I think anyone who works in security should maintain a healthy skepticism toward product demos and polished presentations. That is just professional hygiene. That said, I genuinely enjoyed many of the keynotes this year. Some of these companies have real long-term vision. They see the shape of what is coming, and their best presenters can communicate that vision with clarity and conviction. I respect that, even when I disagree with their specific approach or their business model. But enjoying a keynote and trusting that buying a product will translate into sustainable cybersecurity for your organization are very different things. Actual security is hands-on work. It is understanding your own systems, your own architecture, your own threat model, your own failure modes. It is the boring, unglamorous work of knowing what runs where, what talks to what, what happens when something fails, and what your actual attack surface looks like on a Tuesday afternoon. That work cannot be fully offloaded to a vendor. It cannot be outsourced to a dashboard, no matter how sophisticated the analytics behind it. The vendors that impressed me most this year were the ones that acknowledged this honestly. The ones that positioned their tools as force multipliers for competent teams rather than replacements for the need to have competent teams in the first place. That distinction matters, and the vendors who understand it tend to build better products because they are designing for operators, not for procurement committees. Closing night</h2> The last session of the conference was Hugh Jackman in conversation with Hugh Thompson. I was not sure what to expect from a Hollywood actor closing out a cybersecurity conference, and I suspect a lot of people in the audience had the same reservation going in. But it worked. Jackman is funny, self-aware, and surprisingly thoughtful about creativity, discipline, and the craft of doing hard things well. He talked about preparation, about the difference between performing and connecting, about the years of work that go into making something look effortless. At one point he taught the audience that if you say “raise up lights” in an American accent, you are saying “razor blades” in Australian. The room loved it. It was one of those moments where several thousand cybersecurity professionals all became delighted seven-year-olds for about ten seconds, and it was a good reminder that conferences are also about shared human moments, not just information transfer. It was the right way to end a dense week. Light enough to let people exhale after five days of intense content, but substantive enough in its own way that it did not feel like filler. The road after</h2> After the conference closed, a few of us stayed on. We rented a car and drove south from San Francisco, down Highway 1 through Big Sur. If you have not done that drive, I do not know how to describe it adequately except to say that it recalibrates your sense of scale. The Pacific is very large and very indifferent, and spending a few hours winding along cliff-edge roads with that water stretching out to the horizon below you is a useful counterweight to a week of thinking about the future of everything. We spent time in LA. Santa Monica and Venice Beach, walking the boardwalk, eating food that was too expensive and not caring. The kind of aimless, unstructured time that my brain needed after five days of absorbing information at high density. I find that the most useful thinking often happens when you are not trying to think. When you are just watching the ocean or walking on a beach and letting your subconscious do whatever it does with the raw material you fed it. Then Las Vegas for Easter weekend. Spring break crowds, desert heat starting to build, the particular surreality of the Strip. It was not productive time in any conventional sense, and it was not meant to be. It was decompression. Space for the conference to settle from a collection of impressions into something more like understanding. What stays with me</h2> Two weeks out, here is what I think is different. I went to RSAC 2026 with a set of convictions about where things are heading. Agents are going to be the primary operating model for security infrastructure. Human-in-the-loop is going to shift to human-as-supervisor. Organizations that do not build their own AI infrastructure are going to fall behind structurally. Europe needs to wake up to the compute sovereignty problem before it becomes irreversible. These were things I already believed before I got on the plane to San Francisco. What the conference did was sharpen them. Hearing Nakasone frame national potentiality in terms of chips, data, talent, and energy gave me a cleaner lens for thinking about the geostrategic dimension. Seeing the breadth and depth of the agentic conversation on the conference floor confirmed that this is not a niche position or an edge case anymore. It is the emerging consensus of the industry. And presenting our own work, standing in front of a room and showing what we actually built, made it more real in a way that writing code in a terminal at midnight does not. Conferences like RSAC have always had this effect on me. They compress a year’s worth of signals into a week, and then you spend the following weeks unpacking what you heard and figuring out what it means for what you are building. After RSAC 2024, I started thinking seriously about edge security architectures, which eventually became Zentinel. After RSAC 2025, the urgency around AI-native infrastructure solidified into the work that became Archipelag. This year, I expect the sharpened understanding of agentic systems and the geostrategic landscape to feed directly into what I build next. I also came away with a renewed sense of urgency about the gap between what the frontier looks like and what most organizations are doing about it. That gap, between the leading edge and the institutional mean, is the real risk. Not any single threat actor, not any specific vulnerability class. The systemic inability of large institutions to move at the pace that the situation demands. That is what keeps me up at night, and that is what I am trying to address in my own work, whether it is building infrastructure, writing about it, or working on the political dimension through Die Zukunft. I am going to write a separate post about the talk itself, about what Milan and I built with self-learning WAFs and what we learned along the way. That is coming soon. For now, these are the notes I wanted to capture while the impressions are still sharp enough to be useful. I am already looking forward to RSAC 2027. References and further reading</h2> RSAC 2026</a> - The conference itself</li> AI 2027</a> - Scenario work by Kokotajlo, Alexander, Larsen, Lifland, and Dean</li> How I Work These Days</a> - Where I first wrote about AI 2027 and the shift in how I build</li> What Zentinel Is Really Optimizing For</a> - The design philosophy behind Zentinel and why agent isolation matters</li> Zentinel</a> - The security-first reverse proxy I built on Pingora</li> Archipelag</a> - Decentralized, sovereignty-first AI compute network</li> Die Zukunft</a> - Swiss political party for structural transformation</li> </ul> What Zentinel Is Really Optimizing For Unknown — Sun, 22 Mar 2026 00:00:00 +0000 The clearest way I can describe the motivation behind Zentinel is this: I got tired of not trusting the thing that stood between my users and the internet. Not because the proxies I ran were bad. They were not. I have genuine respect for the engineering in Nginx, HAProxy, Envoy. I learned a lot from operating them, and I mean that sincerely. But over years of running these systems in production, a pattern kept repeating, and it was always some version of the same story: the proxy did something I could not predict from reading its configuration. A WAF module gets slow under load, and because it runs inside the proxy process, the entire data path backs up. A retry storm starts because the default retry policy is implicit rather than explicit. A configuration reload takes effect partially because there is no atomic swap. An unbounded queue grows until memory runs out and the OOM killer takes the proxy down along with everything else on the box. None of these are exotic. If you have operated proxies at any real scale, you have seen most of them. And every time, the root cause pointed at the same structural issue: the proxy was optimized for something other than what I actually needed from it. That is not a criticism. It is a statement about time. Every proxy was built for its era</h2> HAProxy was born in 2000. Willy Tarreau built it to solve a specific, urgent problem: distributing TCP connections across a pool of backend servers. The internet was scaling fast. Sites needed load balancing. HAProxy did that one job with extraordinary precision, and twenty-five years later it still does. It is one of the most reliable pieces of infrastructure software ever written. But it was built as a load balancer, and when you need it to do security enforcement, you are extending a load balancer. Nginx arrived in 2004. Igor Sysoev was solving the C10K problem: how do you handle 10,000 concurrent connections without the process-per-connection model falling over? Nginx was built as a web server. An event-driven architecture that served static files and handled connections with remarkable efficiency. The reverse proxy capability came later, almost as a side effect of how well it handled connections, and eventually became one of its most important use cases. But the core was always a web server. The assumptions about configuration, about reload behavior, about how modules interact with the request path, those assumptions come from web serving. Varnish showed up in 2006. Poul-Henning Kamp built it because dynamic web pages were slow and caching was the answer. Varnish sat in front of your web server, cached responses in memory, and served them fast. That was the whole job. A caching proxy, and a beautiful one. Envoy was born at Lyft around 2016. Microservices had created a new problem: how do you route, observe, and control traffic between hundreds of internal services that come and go? The service mesh was the answer, and Envoy was the data plane. It brought observability, retries, circuit breaking, and policy enforcement to a world where the network topology was no longer something you could draw on a whiteboard and expect to remain accurate for more than a week. Traefik arrived in the same era, optimized for automatic service discovery in container environments. Services appear and disappear. The proxy figures out the routing on its own. Every single one of these was the right tool at the right time. They solved the problem that mattered most when they were built, and they solved it well. I used most of them. I admired most of them. I am not here to argue that any of them were wrong. But I am here to say that their time shaped what they became, and so did the economics of how software was built. The generality trap</h2> Here is something I noticed over years of operating these tools: they all converge. Nginx adds load balancing. HAProxy adds HTTP/2 and Lua scripting. Envoy adds caching, WAF capabilities, ext_proc for external processing. Traefik adds middleware chains. Every proxy, over time, becomes a Swiss army knife. This is not a design failure. It is an economic inevitability. Building a production-grade reverse proxy takes a team, sometimes a large one, working over many years. Nginx took Igor years before it was production-ready. Envoy is maintained by hundreds of contributors across multiple organizations. HAProxy has been continuously refined for a quarter of a century by one of the most skilled systems programmers alive. When the cost of building software is that high, you need the result to serve a broad market. You cannot afford to optimize for one narrow concern. You need your proxy to be useful to web servers and API gateways and service meshes and CDN edges and everything in between. The economic pressure pushes relentlessly toward generality. Toward one more feature. Toward covering one more use case. Toward becoming the tool that everyone can use, even if nobody uses it for exactly the thing they wish it was designed for. This creates a particular kind of friction. You adopt a proxy for its core strength, and then you spend years working around its assumptions in every other area. You chose Nginx because it handles connections well, but now you are fighting its reload model and its embedded Lua modules that share a fate with the worker process. You chose Envoy because it observes service traffic brilliantly, but now you are wrestling with an xDS configuration surface that could fill a textbook, and a C++ codebase where memory safety is a matter of programmer discipline rather than compiler guarantee. I lived in that friction for a long time. I knew what I wanted. I could describe it in detail to anyone who would listen. But wanting a purpose-built proxy and building one are different things when building one requires a team and years of sustained effort. What I kept wishing for</h2> After enough 3 AM incidents and enough post-mortems, the shape of what I was looking for became concrete enough to write down. I wanted a reverse proxy where the operator can reason about what will happen under any condition. Including conditions they did not anticipate. That is the whole thesis. Everything else follows from it. When you are on call, “reason about what will happen” is not philosophical. It means concrete things. It means every queue has a maximum depth. Every timeout is explicit and declared. Every connection pool has a ceiling. No unbounded allocations anywhere. If you set a body size limit of 10 MB, that is a hard limit, not a suggestion. If a security agent’s concurrency is capped at 100, the 101st request gets the configured failure mode, not a silent queue that grows until the box dies. It means every route declares what happens when a security agent is unreachable. Not a global toggle. Per route, per agent. Your API fails closed when the WAF is down (deny everything, because your API handles sensitive data and you do not want it exposed without inspection). Your marketing site fails open (allow traffic, log the gap, because a few minutes of unfiltered marketing pages is better than a full outage). You decide. You write it down. The system enforces it. agents { agent "waf" { transport { unix-socket "/var/run/zentinel-waf.sock" } events "request-headers" "request-body" timeout-ms 50 max-concurrent-calls 100 failure-mode "closed" circuit-breaker { failure-threshold 5 success-threshold 3 timeout-seconds 30 } } } routes { route "api" { priority 100 matches { path-prefix "/api/" } upstream "backend" filters "waf" failure-mode "closed" } route "marketing" { priority 50 matches { path-prefix "/" } upstream "static-backend" filters "waf" failure-mode "open" } } </code></pre> It means every security decision gets a trace ID and ends up in structured logs. When someone asks “why was this request blocked at 3:47 AM?”, you can answer with a correlation ID and a full trace: which agent decided, which rule matched, how long it took. Not “the WAF blocked it, probably.” The actual chain of events. It means configuration reloads are atomic. You send SIGHUP, the new configuration is parsed, validated, and swapped in. In-flight requests finish on the old config. New requests pick up the new one. No window where half the routes are on the old version and half on the new. I could describe all of this clearly. I had been able to for years. Describing what you want and having the means to build it are different things. The insight about isolation</h2> The single biggest realization I had was about failure domains. In every proxy I had operated, extension logic ran inside the proxy process. Nginx has embedded Lua via OpenResty. HAProxy has SPOE and Lua. Envoy has Wasm filters and ext_proc. They all share the same structural problem: the extension and the proxy share a fate. If your Lua WAF script enters an infinite loop in nginx, the nginx worker is stuck. If your Wasm filter in Envoy allocates too much memory, the Envoy process pays for it. A slow SPOE agent in HAProxy backs pressure into the proxy’s request handling. I have been on the receiving end of all three patterns, and they all end the same way: you are awake at 3 AM trying to figure out why your entire proxy fleet is degraded because one security module is having a bad day. This is the classic shared-fate problem. When everything runs in one process, everything fails together. A slow WAF does not just slow down WAF-protected routes. It consumes worker resources that affect all routes. A memory leak in an auth filter does not just take down auth. It takes down the process. The answer I kept coming back to was process isolation. Not as a compromise or a workaround, but as the foundational design principle. Security and policy logic should live in separate processes, each with its own memory, its own concurrency limits, and its own circuit breaker. ┌─────────────────────┐ │ Proxy Core │ │ (Rust / Pingora) │ └──────────┬──────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌────────▼───────┐ ┌──▼──────────┐ ┌▼───────────────┐ │ WAF Agent │ │ Auth Agent │ │ Custom Agent │ │ semaphore: 100│ │ semaphore:50│ │ semaphore: 25 │ │ timeout: 50ms │ │ timeout:30ms│ │ timeout: 200ms │ │ fail: closed │ │ fail: closed│ │ fail: open │ └────────────────┘ └─────────────┘ └────────────────┘ Each agent: own process, own memory, own circuit breaker. Slow WAF ≠ slow auth. Crashed agent ≠ crashed proxy.</code></pre> If the WAF agent gets slow, the WAF agent’s semaphore fills up. The auth agent keeps running on its own semaphore. The proxy core keeps routing. Nobody shares a failure domain unless you explicitly configure them to. This is not just about crash isolation, though that matters. The deeper point is queue isolation. In a shared-process model, a slow filter creates backpressure that affects all traffic. With process isolation, a slow agent only affects the routes that use it, and only up to the concurrency limit you configured. The blast radius is bounded and declared. You can look at the config and know the worst case. The agents communicate over Unix domain sockets or gRPC, and they can be written in any language. There are SDKs for Rust, Go, Python, TypeScript, Elixir, Kotlin, and Haskell. The protocol is simple: 4-byte length, 1-byte type, JSON or MessagePack payload. The operational consequence is what I care about most: you can deploy, restart, and update agents independently. Roll out a new WAF rule set without touching the proxy. Restart a misbehaving auth agent without dropping a single connection. When you are trying to fix one thing at 3 AM without breaking three others, that independence matters more than any benchmark number. A product of this moment</h2> Every piece of software is shaped by when it was built. The proxies I described earlier were products of their time not just in what problems they solved, but in how they could be built. Nginx needed Igor working for years. Envoy needed Google, Lyft, and a large open source community. HAProxy needed Willy Tarreau’s decades of sustained refinement. That was the only way to build infrastructure of that quality. One person, or even a small team, could not realistically build a production-grade reverse proxy with a novel architecture and ship it in months. The economics did not allow it. That structural reality is changing, and I think the change matters more than most people in infrastructure have absorbed yet. I wrote about the broader shift in How I Work These Days</a>. The short version: I had been using Claude Code since May 2025, but it was not until Christmas 2025, working with Opus 4.5, that something fundamentally clicked. The constraint I had lived with for years, the gap between knowing exactly what I wanted and having the bandwidth to build it, narrowed in a way that I still find hard to fully describe. Not because the model wrote the code for me. But because the feedback loop between design intent and working implementation compressed from weeks to hours. When Cloudflare open-sourced Pingora in 2024, I had paid attention immediately. A proxy framework written in Rust, battle-tested at over a trillion requests per day in Cloudflare’s own network. The TCP listener, the HTTP parser, the TLS termination, the connection pooling, the async runtime. All the low-level machinery that you do not want to write from scratch. I had watched River, the community Pingora-based reverse proxy, hoping it would become the thing I could reach for and trust. It never got there. So I stopped waiting and started building. Pingora as a foundation. Rust for memory safety at the boundary. An agentic workflow that let one person move at the pace of a small team. What came out was not a general-purpose proxy. It was not a Swiss army knife. It was a purpose-built tool, tailored from the start to one specific problem: safe, observable, operatable edge traffic enforcement. No more, no less. This is the part I think matters beyond Zentinel itself: when the cost of building serious software drops dramatically, you can afford to be specialized. You do not need to serve a broad market to justify the investment. You can build exactly the thing that solves exactly your problem, with exactly the tradeoffs you want. No feature creep driven by needing to justify a twenty-person team. No compromises driven by needing to appeal to every possible use case. I think of it as bespoke infrastructure. Software that is tailored to a specific problem by someone who deeply understands that problem, made viable by tools that compress the gap between “I know exactly what this should be” and “it exists.” The same way that a load balancer was the right thing to build in 2000, and a service mesh data plane was the right thing to build in 2016, a purpose-built safe reverse proxy is the right thing to build in 2026. Not because the world suddenly needs one more proxy, but because the world can finally have proxies that are designed for specific jobs instead of being general enough to justify their development cost. Zentinel is a post-agentic reverse proxy. Not because it uses AI internally (it does not, unless you count the inference-aware rate limiting for LLM traffic). But because it could only exist in a world where agentic development made bespoke infrastructure viable. One person. Three months. A clear vision that had been accumulating for years. That is not a story that was possible to tell in 2020. Glass-box infrastructure</h2> There is a conviction behind Zentinel that is not technical, and I want to be honest about it. I believe critical web infrastructure should be open. Not “open core” with the important parts behind a license. Not “source available” with restrictions on how you run it. Open in the way that matters: you can read it, fork it, modify it, run it on your own hardware, never call anyone for permission. Zentinel is Apache-2.0-licensed. Every agent is open source. The configuration format is documented. The protocol is specified. There is no hidden control plane, no phone-home telemetry, no vendor dependency. But open source alone is not what I mean by transparent. Plenty of projects publish their source and remain effectively opaque. The code is there, technically, but understanding what a particular configuration will actually do still requires reading thousands of lines of parser logic, or just deploying it and hoping for the best. This is where the Rust decision pays off in a way I did not fully anticipate when I started. Because Zentinel is written in Rust, the core crates compile to WebAssembly. Not as a side project or a reimplementation. The same zentinel-config</code> crate that parses and validates your KDL configuration in production compiles to a Wasm module that runs in a browser tab. This means the config playground</a> on the Zentinel website is not a JavaScript approximation of what the parser does. It is the parser. The actual Rust code, compiled to Wasm, running against your configuration in real time. When it says your config is valid, that is the same validation logic that will run when Zentinel starts up on your server. When it flags an error, that is the same error you would see in production. The same applies to the config converter</a>. If you are migrating from nginx, HAProxy, or Traefik, the conversion tool runs the actual Zentinel config crate in your browser. You paste your existing config, you get KDL output, and you can validate the result on the spot. No round-trip to a server. No “upload your infrastructure config to our cloud service.” It runs locally, in your browser, using the production code. This matters more than it might sound. When you can run the same code that your proxy runs in production, right in your browser, you can reason about the proxy’s internal behavior directly. You are not trusting documentation about how the parser interprets a particular KDL construct. You are running the parser. You are not guessing what happens when two routes have the same priority. You are watching the actual matching logic evaluate your routes. The proxy becomes glass-like. Not transparent in the “we published the source, good luck reading it” sense. Transparent in the sense that you can interact with its internals, poke at its logic, verify its behavior before it ever touches production traffic. The same Rust, the same types, the same validation rules, running wherever you need them: on the server, in CI, in your browser. That is what I mean by trustworthy infrastructure. Not “trust us, it works.” Trust it because you can verify it yourself, using the same code, without asking anyone for permission. Where this leaves me</h2> Every generation of proxies solved the problem of its era. HAProxy solved load balancing. Nginx solved web serving. Envoy solved service mesh routing. Varnish solved caching. Each was the right answer at the right time, and each was shaped by what was possible when it was built. The problem I kept running into was different. Not throughput. Not feature count. Not service discovery. Just: can I understand what this system will do at 3 AM when something I did not plan for happens? Can I reason about its failure modes from reading its configuration? Can I trust it enough to sleep? No existing proxy was designed from scratch for that question, because no existing proxy could afford to be that specialized. The economics of building infrastructure software pushed everything toward generality. What changed is that the economics changed. One person, with the right foundation and the right tools, can now build purpose-built infrastructure that would have required a team and a multi-year roadmap before. Zentinel is the proxy I needed and could not find, built in the specific window of time when building it became possible. It is a product of this moment, in the same way that every proxy before it was a product of its own. And maybe that is what this era of software is really about. Not that AI writes code for you. That framing misses the point entirely. It is that the gap between knowing what should exist and making it exist got smaller, and the things people build when that gap closes are going to be very specific, very opinionated, and very good at exactly one thing. References and further reading</h2> Zentinel</a> - The source code, Apache-2.0-licensed</li> Zentinel documentation</a> - Architecture, configuration reference, agent protocol</li> Zentinel playground</a> - Browser-based config validation using the actual Rust crate compiled to Wasm</li> Zentinel config converter</a> - Migrate from nginx, HAProxy, or Traefik configs to KDL</li> Zentinel manifesto</a> - The design philosophy in full</li> Pingora</a> - Cloudflare’s open source proxy framework that Zentinel builds on</li> How I Work These Days</a> - The broader shift in how I build software, and where Zentinel fits in that story</li> HAProxy</a> - Willy Tarreau’s load balancer, still one of the best pieces of infrastructure software ever written</li> Nginx</a> - Igor Sysoev’s web server that became the internet’s default reverse proxy</li> Envoy</a> - The service mesh data plane that brought observability to distributed systems</li> Varnish</a> - Poul-Henning Kamp’s caching proxy</li> </ul> How I Work These Days Unknown — Sun, 15 Mar 2026 00:00:00 +0000 If you had asked me a few years ago what kind of shift would truly change software again, I would probably have said something vague about machine learning becoming more useful, more accessible, more integrated into normal tooling. I would not have said that within a few years I would be spending large parts of my day in conversation with models, building products at a pace that used to feel unrealistic for one person. But that is where I am now, and the path here did not start with ChatGPT. It started earlier. Before the shock</h2> I had been on Kaggle and Hugging Face since 2020. I was already paying attention. I had a decent understanding of machine learning, enough to know that something important was happening. I was not looking at this space as an outsider who suddenly discovered AI in a news cycle. I had been around it long enough to see that the ingredients were there. Still, understanding a field and feeling a historical shift are not the same thing. When OpenAI released ChatGPT 3.5 in November 2022, something in me changed almost immediately. I do not mean that in a mystical way. I mean I recognized, very quickly, that this was not just another incremental product launch. It felt like a boundary marker, one of those moments where you can see a new layer of the technology stack forming in front of you. At the time, I thought: this is going to be enormous. Bigger than most people realize. Bigger, maybe, than the web itself in terms of how deeply it will alter the shape of work, software, and the distribution of capability. That sounds exaggerated when people say it too casually. I know that. But that was honestly my reaction back then. Not hype. Recognition. I was one of the early people willing to pay OpenAI. That mattered to me. I wanted access, and I wanted to stay close to the frontier as it moved. I did not want to be reading second-hand summaries while something this consequential was taking shape in real time. The part I still underestimated</h2> Even then, I still underestimated one thing: the speed. I understood generative AI was around the corner. I did not understand just how fast it would become operationally useful for actual software creation. I had read AI 2027, the scenario work by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean. It stayed with me, and it still does now in March 2026. I still think the basic direction it sketches is largely correct, even if the path is turning out a bit differently in practice than any single forecast can capture. But even with that framing in my head, I did not fully expect that less than two years after ChatGPT 3.5, coding agents would already start to feel like a real category rather than a novelty. That part came faster than I thought. Paying attention, waiting for the right moment</h2> In 2025 I was trying different tools seriously. I was paying for Claude Code from May 2025 onward, but I was not especially impressed at first. I liked the CLI orientation. I liked that it felt coder-friendly. That part made sense to me immediately. But the model quality at that moment, and the rate limiting, left me cold. It was interesting. It was not yet transformative for my own workflow. So I mostly leaned on Zed’s offering. I liked the editor experience, and I still do. I still reach for Zed when I want to inspect, edit, or move through files outside of Vim in the terminal. It fit me better in that phase. Then November 2025 arrived, three years after ChatGPT 3.5, and then December came with Christmas break. I gave Claude Code another real try, this time with Opus 4.5, and that was the moment it really landed for me. Not politely. Not academically. It hit me hard. I remember the feeling very clearly: this is it. This is the first time the whole thing feels like more than an assistant and less than a gimmick. This is a tool I can genuinely build with. Zentinel was the proof</h2> Zentinel had been sitting in the back of my mind for a long time. The idea was not new. The frustration behind it was not new either. At my day job, we had been dealing with unreliable reverse proxies for long enough that the pain was familiar. I had always wanted River, the Pingora-based reverse proxy, to succeed. I wanted that project to become the thing I could reach for and trust. But it never got there. So I did what this new moment suddenly made possible: I stopped waiting for somebody else to build the thing I wanted to exist. I built Zentinel with Opus 4.5, and it worked. That is the part that still feels a little surreal when I say it plainly. Three months later it is up, it is real, and people are using it. Not as a demo. Not as an abandoned prototype. As actual software in the hands of actual users. That changed something fundamental in how I think about work. Once one long-held idea made it through that bottleneck, a lot of others started moving too. It was not just that I had a new tool. It was that the relationship between ambition and execution had changed. The old constraint, the one that said “yes, this could exist, but not with your current time and current bandwidth,” had weakened. Then everything else started moving</h2> In the time since, I have built a whole range of things that had been accumulating in my head for years: Cyanea, Archipelag, Humankind, Arcanist and its Rust-based hx</code> Haskell toolchain, the new Basel Haskell Compiler, and other pieces besides. It has been a wild ride, but not in the shallow “everything is crazy” sense people often write about. More in the sense that an internal dam broke. For a long time I had more ideas than I had time, more design clarity than I had execution bandwidth, and more conviction than I had manpower. That is a frustrating place to live in for years. You learn to carry around a quiet backlog of unrealized things. Some of them stay alive as notes. Some become recurring thoughts during commutes or late at night. Some start to hurt a little because you know they are viable, but you also know you are not going to get to them with the tools and energy available to you at that point in your life. Now the world is different. I can finally push through the backlog that used to exist only in notebooks, mental sketches, half-written design docs, and conversations with myself. What my days look like now</h2> My daily routine changed dramatically. I still have a day job, and then I have the rest of my work. Together it often adds up to something close to sixteen hours a day. That would sound bleak if I were forcing it. It does not feel bleak. It feels like release. My workspace reflects that change. These days I use mostly Apple hardware, which is funny if you know how much of a Linux person I am, and how much of an OpenBSD person I still am. That part of me has not gone anywhere. I still love those systems. I still think they matter deeply. But if I am being honest about the practical question of where I am most productive right now, Apple has become the answer. I work across a MacBook Pro M4, an iMac, and an Apple Vision Pro. I spend time talking ideas out in real time with ChatGPT’s voice mode, using it less like a search engine and more like a sparring partner. Sometimes intimate, sometimes brutally honest, sometimes audacious in exactly the way a good thinking partner should be. I push an idea, it pushes back, I sharpen it, it sharpens me, and we keep going until something solid emerges. Then there is the terminal, where much of the actual implementation happens in Ghostty, usually with four panes open, often with multiple Claude Code agents running in parallel on the Max plan. Two hundred dollars a month for that level of leverage is, for me, one of the clearest trades I have ever made. This is not a lifestyle performance. It is just the current shape of my work: ideas moving between speech, terminal, editor, design notes, code, back to speech, then back to code again. Beast mode, for lack of a better term</h2> There is a part of this that feels almost embarrassingly direct to say, but it would be dishonest to leave it out: I am the happiest I have ever been. Not because everything is easy. It is not. Not because every project succeeds. They will not. Not because the industry suddenly became sane. It did not. I am happy because the mismatch that used to define so much of my working life has narrowed. For years I had to live with the feeling that my ideas were outrunning my available hours and my available hands. Now, for the first time, it feels like I can actually meet myself where my ambition has been waiting. There is a phrase people use, “beast mode,” and usually I would avoid it because it sounds like posturing. But I do not really have a cleaner shorthand for the intensity of this period. I am working hard, very hard, but with a degree of joy and clarity that makes the effort feel proportionate. I am in conquest mode. Not conquest in the empty startup sense. Not domination, not vanity metrics, not growth for its own sake. I mean conquest over the inertia that used to keep good ideas trapped inside my head. Conquest over backlog. Conquest over hesitation. Conquest over the old excuses about lacking time, lacking team, lacking the right moment. And yes, some of it is for me. To feel better. To feel more whole. To stop carrying around years of deferred execution. But some of it is also because I genuinely want to make useful things. I want to build software that improves the texture of work, that makes systems more reliable, that gives people better tools, that opens up possibilities that were previously too expensive or too cumbersome to pursue. That still matters to me. Probably more than ever. The real change</h2> So when I say that the way I work these days has changed, I do not just mean that I use different tools. I mean that the relation between thought and execution changed. The lag collapsed. The emotional burden of unrealized ideas shrank. The number of things that are now viable to attempt expanded dramatically. That is the real story. I was already paying attention in 2020. I recognized the significance of ChatGPT in 2022. I underestimated the speed anyway. Then late 2025 arrived, the tools crossed a threshold, and my daily life reorganized itself around that fact. Three years is not a long time. It feels longer when you live through a real transition. And I suspect we are still early. References and further reading</h2> AI 2027</a> - Scenario work that influenced how I thought about the trajectory of this space</li> Zed</a> - Editor I still use alongside Vim</li> Ghostty</a> - Terminal I use for most of my agent-heavy coding sessions</li> Zentinel</a> - Reverse proxy project that became the first real proof point for this workflow</li> Cyanea</a> - One of the projects that came to life during this period</li> Archipelag</a> - Another product that moved from idea to reality in this new working mode</li> </ul> Archipelag.io Is in Open Beta: Here's Why I Built It Unknown — Fri, 13 Mar 2026 00:00:00 +0000 There is an abandoned factory building in Glarus, a small town wedged between mountains in eastern Switzerland. In 2016, the building was loud. Not machinery-loud, fan-loud. Rows of bare motherboards bolted to open-air frames, each bristling with GPUs and daisy-chained power supplies. The air tasted like warm dust and ozone. Cables ran everywhere, held in place by zip ties and optimism. This was an Ethereum mining operation, and I was standing in the middle of it, watching people I knew convert their gaming rigs, hardware they loved, into money-printing machines. I was there because Vitalik Buterin had decided to visit. He had flown in on a private jet to Geneva, driven up in a black limousine with tinted windows, and walked into this dusty, chaotic space to see what Swiss miners were building. It was surreal. The creator of Ethereum, stepping over power cables in an industrial ruin, nodding at rack after rack of GPUs humming away at proof-of-work hashes. I do not think he was impressed by the elegance of the setup. Nobody was. But something about that scene stuck with me. People were willing to sacrifice their gaming entertainment, their leisure hardware, to chase the dream of sovereign financial independence using fundamentally nerdy equipment: PCs, internet connections, blockchain protocols, and GPU graphics cards. They were converting consumer-grade technology into economic infrastructure, and they were doing it themselves. No data center leases. No vendor contracts. No permission from anyone. Just people, hardware, and a protocol that made it worth their while. I had skin in the game too. I invested (gambled, honestly) in crypto during that era. I watched the charts, rode the swings, felt the dopamine spikes and the stomach-drops. The financial side was wild and ultimately unsustainable for most people. But the infrastructure side, the part where ordinary humans turned their homes into compute nodes and got paid for it: that part was real, and that part stayed with me long after the crypto hype faded and the rigs went quiet. This is the story of how that factory visit turned into Archipelag.io</a>, a distributed compute network that entered open beta today. It has been ten years of thinking, one year of building, and a lot of being wrong about the right things at the wrong time. How AI Makes Bare Metal Viable Again Unknown — Sun, 08 Mar 2026 00:00:00 +0000 I was paying over two hundred dollars a month to run two apps that had zero paying users. Not because the apps were complex. Not because they needed high availability across regions. Because I was running Kubernetes on DigitalOcean, and Kubernetes has opinions about how much infrastructure you need. A control plane. Worker nodes. Load balancers. Persistent volumes. Managed databases. Each line item modest on its own, adding up to a bill that felt absurd for two Phoenix applications in their bootstrapping phase. The apps are archipelag.io</a> and cyanea.bio</a>. Both are Elixir/Phoenix projects. Archipelag uses PostgreSQL and NATS for its messaging layer. Cyanea uses SQLite. Neither gets meaningful traffic yet. Both are real products I am actively building, not side projects I will abandon next month. But they are pre-revenue, and every dollar I spend on infrastructure is a dollar I am betting against future income that does not exist yet. Something had to change. The Kubernetes trap</h2> Here is the thing about Kubernetes: it solves problems you might not have. If you are running fifty microservices across three regions with autoscaling requirements and a platform team to manage it, Kubernetes earns its keep. If you are running two BEAM applications that each consume less than 512 MB of memory, you are paying a complexity tax for infrastructure capabilities you will never touch. My K8s setup on DigitalOcean looked like this: a managed cluster with two worker nodes (the minimum for any reasonable availability), a managed PostgreSQL instance for Archipelag, a load balancer for ingress, persistent volumes for Cyanea’s SQLite database. Each component had its own monthly cost. The cluster management fee alone was more than what I would eventually pay for an entire bare metal server. The operational overhead was worse than the cost. Helm charts. Ingress controllers. Certificate managers. Pod disruption budgets. Every time I wanted to deploy a new version, I was wrangling YAML files that described infrastructure concerns my apps did not care about. A Phoenix release does not need a pod spec. It needs a port, an environment, and someone to restart it if it crashes. And the YAML, my God, the YAML. A simple Phoenix app that listens on a port and serves HTTP needs, at minimum, a Deployment manifest, a Service manifest, and an Ingress manifest. Add a ConfigMap for environment variables, a Secret for credentials, a PersistentVolumeClaim if you need disk, a HorizontalPodAutoscaler if you want autoscaling. For Cyanea alone, I had six Kubernetes manifests totaling a few hundred lines of YAML, all to describe an application that boils down to: run this binary, give it a port, point a domain at it. The cognitive load compounds. You learn the Kubernetes resource model, then the DigitalOcean-specific annotations for their load balancer, then the cert-manager CRDs for TLS, then the quirks of persistent volumes on managed K8s (spoiler: they are not as persistent as you think if you do not get the reclaim policy right). Each layer has its own documentation, its own failure modes, its own upgrade cycle. I spent more time debugging infrastructure than building product. The irony is not lost on me. Kubernetes was designed for teams running hundreds of services at Google-scale. I was running two apps. The orchestrator had more moving parts than the things it was orchestrating. It was like hiring a logistics fleet to deliver two packages across town. I knew I was over-engineered. But the alternative, at the time, seemed like a step backward. The Nomad detour</h2> I should mention that Kubernetes was never the only orchestrator I considered. For the past five years, while the industry went all-in on K8s, I had been quietly admiring HashiCorp’s Nomad</a>. Where Kubernetes is a sprawling ecosystem of CRDs, operators, and control loops, Nomad is refreshingly minimal. A single binary. A simple job spec. No opinions about networking, no built-in service mesh, no mandatory etcd cluster. You tell it what to run, it runs it. That minimalism appealed to me. Nomad treats workload scheduling as the core problem and stays out of everything else. No built-in networking layer means you bring your own, which sounds like a drawback until you realize it means you are not locked into someone else’s networking model. And I happened to have my own networking layer already. I had been building Zentinel</a> in parallel, a security-first reverse proxy built on Cloudflare’s Pingora</a> framework in Rust. Zentinel handles TLS termination, WAF inspection, rate limiting, domain-based routing, all the edge concerns I care about. It also supports sleepable ops, where backend instances can be suspended and woken on demand, which is perfect for apps that do not need to be running 24/7. So I tried pairing them. Nomad for workload scheduling, Zentinel for the network layer. And it worked. The combination gave me a lightweight orchestrator that did not try to own every concern, paired with a reverse proxy that handled edge traffic the way I wanted. Two focused tools, each doing one thing well. But then IBM acquired HashiCorp, and the calculus changed. The acquisition itself was not the problem. Companies get acquired. It happens. The problem was the trajectory. HashiCorp had already re-licensed Terraform from MPL to BSL (Business Source License) in 2023, a move that fractured the community and spawned the OpenTofu</a> fork. The pattern was familiar: open-source project gains adoption, company monetizes through enterprise features, company gets acquired, new owner tightens the screws. I had watched it happen with Redis, with Elasticsearch, with MongoDB. Each time the community forks, there is a period of uncertainty, split maintenance effort, and feature divergence. I did not want to build my infrastructure on a foundation where the governance could shift at any time. Nomad is still open source today. But “still open source” and “will remain open source” are different statements, and after the Terraform situation, I was not confident in the latter. The BSL license change had been a signal, and IBM’s acquisition amplified it. I did not need to go down that road with another HashiCorp product. The Nomad experiment did teach me something valuable, though. It confirmed that the KISS approach to deployment was right. You do not need the full Kubernetes machinery. A scheduler that starts processes, checks their health, and restarts them when they crash is sufficient for a wide range of workloads. And a dedicated reverse proxy that handles TLS and routing is cleaner than bundling networking into the orchestrator. That insight, Nomad’s minimalism plus Zentinel’s Pingora-based proxy architecture, became the design seed for what I would eventually build. The fly.io middle ground</h2> With Nomad off the table as a long-term bet, I migrated to fly.io</a> in late 2025. It was genuinely better than K8s for my use case. Fly understands BEAM applications at a fundamental level. The BEAM runtime is designed for the kind of lightweight, long-lived processes that Fly’s infrastructure optimizes for. You push a release, it runs it. No YAML. No ingress controllers. No cluster management. Fly also made the service dependencies painless. Managed Postgres with a few commands. NATS was straightforward to set up. Tigris (Fly’s S3-compatible object storage) handled blob storage for Cyanea’s file uploads. The developer experience was genuinely excellent, and I mean that without reservation. The Fly team has built something thoughtful. The cost dropped meaningfully. No cluster management fee. No minimum node count. Pay-per-VM pricing that scales down to fractions of a shared CPU. Fly’s model is honest about what small applications actually need, and the pricing reflects that. I went from over two hundred dollars a month on DigitalOcean K8s to roughly a quarter of that. For a while, it was the right answer. And if I had been scaling horizontally, adding regions, needing the kind of elastic compute that cloud-native platforms excel at, I would have stayed. If my apps suddenly got traction and I needed instances in Tokyo, Frankfurt, and Virginia, Fly would be the obvious choice. The multi-region story is one of Fly’s genuine strengths. You deploy once, it runs everywhere. That is hard to replicate. But I was not scaling horizontally. I was running two apps in one location. On a good day, they handled maybe a few hundred requests. The compute they needed was trivial, a fraction of a shared CPU core. And I was still paying for a platform designed to scale to thousands of instances across dozens of regions, even though I needed exactly one instance of each app, in exactly one place, doing very little work. There is also a subtler cost that managed platforms carry: the abstraction tax. When something goes wrong on Fly (and it did, occasionally, things like deployment timeouts or the odd networking hiccup), you are debugging at the platform level, not the system level. You file a support ticket or check the status page. You do not SSH in and look at processes, because there are no processes you can see. The platform is the intermediary, and the intermediary has its own failure modes that you cannot inspect or fix. The cloud-native model, even the lean version that Fly offers, has a floor. You are always paying for the platform’s capabilities, not just your usage of them. When your usage is “two small apps, one location, no scale,” that floor matters. And when the platform sits between you and your processes, you lose the ability to debug at the level where the answers actually live. The bare metal math</h2> I started looking at dedicated servers. Not VPS instances, not cloud VMs. Actual hardware you can SSH into, where your processes run on real cores and your data sits on real disks. Hetzner runs a server auction</a> where they sell refurbished dedicated machines at steep discounts. These are servers that have been running in Hetzner’s data centers, got rotated out of customer contracts, and are resold at prices that make cloud compute look like a luxury good. The hardware is used but maintained, and Hetzner’s data centers are well-run, proper cooling, redundant power, good network connectivity. I found a box with a multi-core Intel CPU, 128 GB of DDR4 RAM, and two 1 TB NVMe drives that I configured in RAID 1 for redundancy. EUR 38 a month. About forty-two dollars. Fixed price. No bandwidth metering (Hetzner includes 20 TB of traffic on dedicated servers, which for my workload might as well be unlimited). No surprises on the bill. Let that sink in for a moment. For less than what I was paying for managed Postgres alone on either platform, I could have an entire server with more RAM than I know what to do with, fast NVMe storage with mirror redundancy, and enough compute headroom to run not two but twenty applications without breaking a sweat. The two NVMe drives alone, if bought retail, would cost more than a year of hosting. I ran the numbers on capacity. My two Phoenix apps, even under load, would use maybe 1-2 GB of RAM combined. PostgreSQL with a modest dataset, another gig or two. NATS, negligible. That leaves well over 120 GB of RAM sitting idle. The CPU tells a similar story. Phoenix on the BEAM is remarkably efficient with CPU resources, the scheduler does its own preemptive multitasking across lightweight processes, and my workloads are I/O-bound, not compute-bound. I could run my entire current stack and barely register on a load graph. The headroom is the point. On a cloud platform, headroom costs money. More RAM, higher tier. More CPU, higher tier. On bare metal, the headroom is already paid for. Growing from two apps to ten does not change my monthly bill. Adding a staging environment does not change my monthly bill. Running background workers, a metrics stack, a CI runner, none of it changes my monthly bill. The marginal cost of additional workloads on existing hardware is zero. The math was obvious. The problem was everything else. Why bare metal was hard</h2> Bare metal has always been cheap. That was never the issue. The issue was everything you had to build and maintain yourself. On a managed platform, you get deployment pipelines, TLS certificate management, process supervision, reverse proxying, log aggregation, health checks, and rollback mechanisms out of the box. On bare metal, you get a Linux login prompt and a blinking cursor. Historically, going bare metal for web applications meant weeks of setup: Install and configure nginx or HAProxy as a reverse proxy</li> Set up Certbot or acme.sh for Let’s Encrypt certificates, and hope the renewal cron does not silently break</li> Write deployment scripts (rsync, symlinks, restart commands) and debug them for months</li> Configure systemd services for each app, with the right restart policies and environment files</li> Build a process supervision layer that handles crashes, port allocation, and graceful shutdowns</li> Figure out zero-downtime deploys (which means running two instances, health checking the new one, swapping traffic, draining the old one)</li> Set up log rotation, monitoring, backups</li> Harden the server (firewall, SSH config, automatic security updates)</li> </ul> Each of these is a solved problem in isolation. There are blog posts and Stack Overflow answers for every one of them. But stitching them together into a coherent, reliable deployment system is a full-time job for a week or two, and maintaining it is an ongoing tax on your attention. This is why the cloud won. Not because bare metal is expensive. Because the operational cost of doing it yourself was prohibitive for small teams. The cloud sold you a package deal: we handle the infrastructure, you handle the application. Worth it, even at a premium. But what if that operational cost dropped to near zero? The AI shift</h2> I had Claude Code with Opus 4.6 available. I had spent months working with it on other projects. Compilers, CRDT engines, reverse proxies. I knew what it could do with a clear spec and a well-defined problem domain. And deploying web applications to bare metal is a well-defined problem domain. The core requirements are straightforward: upload an artifact, start it on a port, check that it is healthy, route traffic to it, stop the old one. Everything else, TLS, process supervision, rollback, log capture, is layered on top of that core loop. The problem space is wide but shallow. Lots of features, few genuinely novel algorithms. This is exactly the kind of work where AI shines. Not because it writes perfect code on the first try. But because it can iterate through a feature list at a pace that would take a solo developer weeks, producing working implementations in hours. The feedback loop is tight: describe what you want, get code, test it, refine. The domain knowledge exists in a thousand deployment tools that came before. The AI has seen all of them. So I decided to build my own deployment tool. From scratch. With AI as my co-engineer. Building Vela</h2> Vela</a> is what came out of that process. A single Rust binary that handles everything I listed above: reverse proxy, auto-TLS, process supervision, zero-downtime deploys, health checks, secret management, log streaming, rollbacks. No containers. No Docker. No YAML. The design draws from both of its ancestors. From Nomad, the suckless philosophy: a single binary, minimal configuration, no opinions about things that are not its problem. From Zentinel, the Pingora-inspired proxy architecture: hyper-based reverse proxy with TLS termination, domain-based routing, and WebSocket support baked into the same process. Vela is what happens when you take the best ideas from tools you admire and combine them into something purpose-built for your exact workload. The design philosophy is blunt: one binary, two modes. ┌─────────────────────────────────────────────┐ │ Your server │ │ │ │ Vela daemon │ │ ├── Reverse proxy (:80/:443, auto-TLS) │ │ ├── Process manager (start, health, swap) │ │ └── IPC socket │ │ │ │ Apps │ │ ├── cyanea.bio → :10001 │ │ └── archipelag.io → :10002 │ └─────────────────────────────────────────────┘ ┌─────────────────────────────────────────────┐ │ Your laptop │ │ │ │ vela deploy → scp + ssh → server │ └─────────────────────────────────────────────┘ </code></pre> vela serve</code> runs on the server. It is the reverse proxy, the process manager, and the IPC daemon, all in one process. vela deploy</code> runs on your laptop. It reads a manifest, uploads your artifact over SSH, and tells the server to activate it. SSH is the control plane. No tokens, no API keys, no custom authentication layer. If you can SSH into the server, you can deploy. This is a deliberate choice. SSH key management is a solved problem. Every developer already has it configured. Every server already has it running. Building a custom auth system on top would be adding complexity for no practical gain. The manifest</h3> Each app gets a Vela.toml</code> in its project root: [app] name = "cyanea" domain = "app.cyanea.bio" [deploy] server = "deploy@my-server" type = "beam" binary = "server" health = "/health" strategy = "sequential" pre_start = "bin/cyanea eval 'Cyanea.Release.migrate()'" [env] DATABASE_PATH = "${data_dir}/cyanea.db" SECRET_KEY_BASE = "${secret:SECRET_KEY_BASE}" </code></pre> That is the entire deploy configuration. The app type tells Vela how to start it (beam</code> runs Elixir releases, binary</code> runs compiled executables). The health path tells it where to check. The strategy tells it how to swap traffic. The pre_start</code> hook runs database migrations before the new instance starts, and if migrations fail, the deploy aborts and the old instance keeps running. Environment variables support two substitution patterns: ${data_dir}</code> expands to the app’s persistent data directory (which survives deploys), and ${secret:KEY}</code> pulls from the server-side secret store. Secrets never live in your repo. Deploying looks like this: MIX_ENV=prod mix release vela deploy ./_build/prod/rel/cyanea </code></pre> Two commands. The artifact goes up, the health check passes, traffic swaps, done. Zero-downtime deploys</h3> Vela supports two deploy strategies, and the choice matters. Blue-green is the default. The new instance starts alongside the old one on a fresh port. Vela runs a health check against it (30 retries, one per second, five-second timeout per attempt). Once the health check passes, the reverse proxy atomically swaps the route table entry for that domain to point at the new port. The old instance gets a configurable drain period to finish in-flight requests, then receives SIGTERM. If it does not exit within the drain window, SIGKILL. Time ──────────────────────────────────────────► Old instance ████████████████████░░░░ (draining) New instance ░░░░████████████████████ ▲ ▲ start │ │ health passes, swap </code></pre> Zero downtime. The user never sees a blip. This works for stateless apps and apps backed by PostgreSQL (where both instances can connect to the same database simultaneously). Sequential is for SQLite apps. You cannot have two processes writing to the same SQLite database (WAL mode helps, but concurrent writers from separate instances is asking for trouble). So Vela stops the old instance first, starts the new one, health checks it, and activates it. Sub-second blip. Acceptable for apps where the alternative is write contention. Time ──────────────────────────────────────────► Old instance ████████████████████ New instance ░░░░████████████████████ ▲ ▲ stop │ │ start + health check </code></pre> The decision is per-app, configured in the manifest. Cyanea uses sequential (SQLite). Archipelag uses blue-green (PostgreSQL). Process supervision</h3> Vela does not just start your app and walk away. It supervises it. If a process crashes, Vela detects the exit (via non-blocking try_wait</code> on the child process handle), logs it, and restarts from the stored launch configuration: pub async fn check_and_restart(&mut self) -> Vec<String> { let mut to_restart = Vec::new(); for (key, process) in &mut self.running { match process.child.try_wait() { Ok(Some(status)) if !status.success() => { // Process exited unexpectedly to_restart.push(( key.clone(), process.launch_config.clone(), )); } _ => {} } } for (key, config) in to_restart { // Restart on same port if available, allocate new otherwise self.restart_from_config(&key, &config).await; } } </code></pre> Each app’s LaunchConfig</code> (release directory, binary name, app type, environment variables, data directory) is stored so that restarts use the exact same configuration. The daemon also persists app state to disk, so if Vela itself restarts (server reboot, daemon upgrade), it restores all running apps from their saved configurations. This is the kind of feature that would take a day to specify and a week to implement if you were writing it from scratch. With Claude, it took about an hour of iteration, including the edge cases around port reallocation and the pending/active state split during deploys. Built-in services</h3> Both of my apps have service dependencies. Archipelag needs PostgreSQL and NATS. Rather than managing these separately, Vela handles service provisioning directly: [services.postgres] version = "17" databases = ["archipelag_prod"] [services.nats] version = "2.10" jetstream = true </code></pre> On first deploy, Vela installs PostgreSQL (via apt), creates the database with a generated password, and injects DATABASE_URL</code> into the app’s environment. For NATS, it downloads the binary, generates a config, and starts it as a supervised child process with NATS_URL</code> injected. Service credentials persist across deploys and daemon restarts. This was one of those features where the AI really earned its keep. The NATS lifecycle management alone, downloading the right binary for the platform, generating config, supervising the process, health-checking the monitoring endpoint, persisting credentials, involved touching six or seven modules. Claude handled the plumbing while I focused on the design decisions. The reverse proxy</h3> Vela embeds its own reverse proxy built on hyper. It handles TLS termination (auto-provisioned via Let’s Encrypt ACME HTTP-01, or static certificates for Cloudflare setups), domain-based routing, WebSocket upgrades, and HTTP-to-HTTPS redirects. The routing model is simple. A thread-safe hash map from domain to port: pub struct RouteTable { routes: Arc<RwLock<HashMap<String, u16>>>, } </code></pre> When a request arrives, Vela extracts the Host header, looks up the port, and forwards the request to localhost:{port}</code>. When a deploy swaps traffic, it is a single write-lock on the hash map to update the port number. Atomic. No configuration reload. No proxy restart. For WebSocket connections (which both Phoenix apps use for LiveView), Vela detects the Upgrade: websocket</code> header and switches to raw TCP tunneling with bidirectional I/O. This was important for my use case, Phoenix LiveView is WebSocket-native, and if the proxy does not handle upgrades correctly, the entire UI breaks. From empty box to production in a day</h2> Here is the timeline of the actual migration. I bought the Hetzner server and within about 48 hours, both apps were running in production with HTTPS, process supervision, automated backups, and daily health reports. The sequence went roughly like this: Hardware validation: Check NVMe drive health, run memory tests, verify RAID configuration. The drives had about 25,000 power-on hours (these are auction servers, they have been used), but SMART health passed and wear levels were well within acceptable range. </li> OS provisioning: Debian, RAID 1 across both NVMe drives. Straightforward. </li> Server hardening: Firewall rules, SSH hardening (key-only auth, non-default port, rate limiting), automatic security updates, intrusion detection. This is the part I am deliberately vague about. If you are running a public-facing server, hardening is non-negotiable, but I am not going to publish my exact firewall configuration. </li> Vela installation: Download the binary, create a config file, install the systemd service. Five minutes. </li> First app deployed (Cyanea): Built the Elixir release on the server, set secrets, ran migrations, deployed. The entire build-and-deploy cycle for a Phoenix app with a Rust NIF took about fifteen minutes, most of which was compilation. </li> Second app deployed (Archipelag): Same flow, plus provisioning PostgreSQL and restoring a database dump from Fly, plus setting up NATS. About thirty minutes. </li> TLS certificates: Updated DNS records, Let’s Encrypt certificates issued automatically. Vela handles the ACME challenge internally, no Certbot, no cron job, no manual cert management. </li> Monitoring: A daily health report script that checks system metrics, service status, and app health, then emails a summary. Simple but effective. </li> </ol> The most time-consuming part was not the tooling. It was migrating the PostgreSQL data from Fly and verifying that both apps behaved correctly in their new environment. The infrastructure setup itself, the part that would have taken weeks without Vela, took hours. The broader thesis</h2> Here is what I think is happening, and I think it is bigger than my personal infrastructure bill. The cloud won because it sold a bundle: compute, networking, storage, deployment, monitoring, scaling, security, all integrated, all managed. The alternative was building each piece yourself, and the labor cost made that prohibitive for small teams. Managed infrastructure was cheaper than an ops engineer. AI changes that equation. Not by making the cloud cheaper, but by making bespoke tooling economically viable. Consider what I got with Vela. A deployment tool that does exactly what I need and nothing more. No container orchestration, because I do not use containers. No multi-region routing, because I run in one location. No autoscaling, because two apps do not need to autoscale. Every feature exists because I needed it. Every feature works with my specific stack (Elixir/BEAM, Rust, SQLite, PostgreSQL, NATS). The tool is tailored to my workload the way a bespoke suit is tailored to a body. This kind of custom tooling used to be a luxury. You needed either a platform team that could invest weeks of engineering time, or the rare individual who was both a skilled systems programmer and willing to spend their evenings writing deployment tools instead of building products. The economics did not make sense for a solo founder or a two-person team. With AI, the cost of building bespoke tooling drops by an order of magnitude. Not to zero, you still need to know what you want, you still need to test and iterate, you still need to understand the domain well enough to evaluate the output. But the gap between “I know what I need” and “I have a working implementation” shrinks from weeks to hours. And when bespoke tooling is cheap, the cloud’s bundle becomes less compelling. You do not need the managed Kubernetes service if you can build a deployment tool that fits your exact needs. You do not need the managed database service if you can install PostgreSQL yourself and the AI helps you set up backups, monitoring, and failover. You do not need the managed TLS service if your deployment tool handles ACME natively. What you are left paying for is compute and bandwidth. And for compute and bandwidth, bare metal is drastically cheaper than the cloud. The API is bespoke</h2> There is a subtlety here that I think is worth calling out. When people talk about the cloud’s advantages, they often point to the API-driven experience. Infrastructure as code. Declarative configuration. Programmable everything. And that is real. The cloud’s API layer is genuinely valuable. But the API does not have to come from a cloud provider. It can come from your own tooling. Vela gives me an API-driven experience. I declare my app’s configuration in a TOML manifest. I run a single command to deploy. I can check status, stream logs, manage secrets, trigger backups, and roll back releases, all from my laptop, all through a CLI that speaks SSH to a daemon on the server. The experience is not worse than Fly or Heroku. In some ways it is better, because the tool does exactly what I need and nothing else, and when something goes wrong, I can read the source code. The difference is that my “API” is a 5,000-line Rust binary instead of a multi-billion-dollar cloud platform. And that is fine. I do not need the platform. I need the interface. AI lets me build the interface. This is, I think, the pattern that will play out more broadly. The cloud’s value was never just compute. It was the operational layer on top of compute, the tooling that made raw hardware usable. AI makes it possible to build that operational layer yourself, tailored to your needs, at a fraction of the cost. The cloud becomes optional. The server becomes a commodity. The differentiator is the tooling, and the tooling is something AI can help you build. What the numbers look like</h2> Let me be concrete about costs, because this is ultimately an economic argument. Kubernetes on DigitalOcean (my original setup): Managed K8s cluster: ~$12/month (control plane fee)</li> Worker nodes (2x smallest): ~$24/month</li> Managed PostgreSQL: ~$15/month</li> Load balancer: ~$12/month</li> Persistent volumes, bandwidth, extras: ~$15/month</li> Total: ~$78-80/month (and this was after I trimmed it)</li> </ul> Fly.io (the middle ground): Two Phoenix apps (shared-cpu-1x, 256MB each): ~$14/month</li> Managed Postgres: ~$25/month</li> Managed NATS: ~$20/month</li> Bandwidth, extras: ~$10/month</li> Total: ~$70/month</li> </ul> The managed services were the killer. Fly’s compute pricing is fair, but managed Postgres and managed NATS added up fast. And that was at near-zero traffic. Egress pricing on Fly is metered, so if either app had started getting real user load, the bandwidth bill alone would have pushed the total well past a hundred dollars a month. Hetzner bare metal (current): Dedicated server (auction): EUR 38/month (~$42)</li> That is it. PostgreSQL, NATS, TLS, everything runs on the box.</li> Total: ~$42/month</li> </ul> The Hetzner box is cheaper than Fly right now, and the gap only widens as usage grows. But the raw dollar comparison understates the difference. Look at what I am getting. 128 GB of RAM versus 512 MB. Multi-core CPU versus shared fractional cores. Two terabytes of NVMe storage versus a few gigs. Bandwidth that is essentially unlimited (Hetzner includes 20 TB of traffic) versus metered egress that scales with every user you add. The capacity gap is the real story. On Fly, scaling from two apps to ten means linearly increasing costs, more VMs, more managed database instances, more bandwidth charges. On my Hetzner box, scaling from two apps to ten means… nothing. The resources are already there. I paid for them. PostgreSQL, NATS, any other service I want to run, it all fits on the same box with room to spare. And there is no surprise bill. No bandwidth overage. No “your database exceeded the row limit” fee. No managed service add-on creep. Thirty-eight euros a month, every month, regardless of what I run on it. When this does not apply</h2> I would be dishonest if I pretended bare metal is the right answer for everyone. It is not. If you need multi-region presence, the cloud still wins. Running your own hardware in three continents is a different kind of problem. Edge computing, CDN-native architectures (which I wrote about previously</a>), and platforms like Fly or Cloudflare Workers are the right tools for workloads that need to be close to users worldwide. If you need elastic scaling, bare metal does not flex. A server has fixed resources. If your traffic spikes 10x for an hour, you cannot add capacity on demand. You can over-provision (and at these prices, generous over-provisioning is affordable), but it is not the same as true elasticity. If you do not understand the operational basics, bare metal will bite you. Server hardening, backup strategies, disk monitoring, security patching, these are your responsibility. The cloud abstracts them away. On bare metal, a missed security update is your problem. A full disk is your problem. A failed drive (RAID helps, but is not magic) is your problem. If your team is large and needs guardrails, managed platforms provide consistency and governance that bare metal does not. Kubernetes is complex, but it is complex in a standardized way. Everyone knows how to deploy to K8s. Everyone knows how to debug a pod. Your custom Vela setup is legible to exactly the people who built it. The sweet spot for bare metal, especially AI-assisted bare metal, is small teams building products that need reliability but not scale, performance but not elasticity, control but not standardization. Solo founders. Two-person startups. Side projects that might become real businesses. What I learned</h2> The migration took about 48 hours from “I have an empty server” to “both apps are in production with HTTPS, monitoring, and automated backups.” Most of that time was data migration and validation, not infrastructure setup. Vela is now at version 0.5.0 with a feature list I am genuinely proud of: blue-green and sequential deploys, process supervision with auto-restart, built-in reverse proxy with auto-TLS, service dependency management (Postgres and NATS), secret management, log streaming, rollbacks, remote builds, scheduled backups, deploy hooks, and machine-readable status output for monitoring integration. I built most of it in a few focused sessions with Claude Code. Not because the code is trivial, it is about 4,000 lines of Rust with async IPC, Unix socket communication, ACME certificate management, process lifecycle handling, and a reverse proxy with WebSocket support. But because the problem domain is well-understood, the requirements were clear, and AI is remarkably good at turning clear requirements into working implementations. The thing I keep coming back to: the cloud was never selling compute. It was selling convenience. And convenience used to require a company with thousands of engineers to build platforms that abstracted away the hard parts. Now, a developer with a clear idea of what they need and an AI that can write systems code can build a fit-for-purpose operational layer in a weekend. That does not make the cloud irrelevant. It makes the cloud optional for a much larger class of workloads than it was before. Buy a server. Build your tools. Ship your product. The infrastructure should be boring. With AI, it finally can be. References and further reading</h2> Tools and platforms</h3> Vela</a> - The bare-metal deployment tool built in this article</li> Hetzner Server Auction</a> - Refurbished dedicated servers at steep discounts</li> fly.io</a> - The managed platform I migrated from</li> Nomad</a> - HashiCorp’s minimal workload orchestrator</li> OpenTofu</a> - Community fork of Terraform after the BSL relicense</li> Pingora</a> - Cloudflare’s Rust framework for building programmable proxies</li> hyper</a> - Rust HTTP library powering Vela’s reverse proxy</li> Let’s Encrypt</a> - Free TLS certificates, automated via ACME in Vela</li> NATS</a> - Lightweight messaging system used by Archipelag</li> </ul> Frameworks and runtimes</h3> Phoenix Framework</a> - Elixir web framework powering both apps</li> Erlang/OTP</a> - The BEAM virtual machine that runs Phoenix and Elixir</li> Rust</a> - Systems language Vela and Zentinel are written in</li> </ul> Projects referenced</h3> Zentinel</a> - Security-first reverse proxy built on Pingora</li> Archipelag</a> - Distributed compute platform</li> Cyanea</a> - Bioinformatics platform</li> Claude Code</a> - AI coding tool used to build Vela</li> </ul> Edge Systems Are the New Backend Unknown — Wed, 11 Feb 2026 00:00:00 +0000 A request arrives at your system. In the next 50 milliseconds, before any application code runs, this happens: TLS termination, route matching, WAF inspection against 285 detection rules, JWT validation, rate limit evaluation, request body validation against a JSON schema, and trace context generation. The request either dies at the edge or arrives at your backend pre-authenticated, pre-validated, and pre-authorized. Five years ago, your backend did all of this. Every service validated its own tokens, enforced its own rate limits, ran its own security checks. Today, the backend might not even exist in the form you expect. It might be a static site served from edge nodes, a thin persistence API, or a headless CMS that publishes content to a CDN and never handles a user request directly. Something shifted. Not just at the edge. On both ends. The three-tier past</h2> The architecture most of us learned was simple. Client, backend, database. The browser rendered HTML, maybe ran some jQuery. The backend did everything: authentication, authorization, business logic, rendering, validation, rate limiting, session management. The database stored state. Clean separation, one direction, easy to reason about. This model worked because the browser was dumb. It could render markup and submit forms. Any real computation had to happen on the server. The backend was fat by necessity, not by design. Microservices made it worse. Consider a typical setup: a user service, an order service, a payment service, a notification service, an inventory service. Each one needs to validate JWTs. Each one needs to enforce rate limits. Each one needs input validation, request logging, and error handling. That is five services times six concerns. Thirty implementations of logic that should exist exactly once. Now multiply. Real organizations have 15, 50, 200 services. Each team implements auth slightly differently. One uses a shared library, one copied the code two years ago, one rolled their own because the library did not support their token format. The rate limiting configurations drift. The logging formats diverge. A security patch to the JWT validation logic means PRs across every repository, coordinated deployments, and someone asking “did we get all of them?” ┌──────────┬──────────┬──────────┐ │ Users │ Orders │ Payments │ │ Service │ Service │ Service │ ├──────────┼──────────┼──────────┤ Auth │ ✓ (v2.1) │ ✓ (v1.9) │ ✓ (v2.0)│ Rate limiting │ ✓ (lib) │ ✓ (copy) │ ✗ (none)│ Validation │ ✓ │ ✓ │ ✓ │ WAF/Security │ ✗ │ ✗ │ ✗ │ Logging │ JSON │ text │ JSON │ Tracing │ ✓ │ ✗ │ ✓ │ └──────────┴──────────┴──────────┘ </code></pre> Libraries helped. Service meshes helped more. But the complexity was still distributed across every service, in every team’s codebase, in every deployment pipeline. The mesh moved networking concerns to a sidecar. It did not move application-level concerns like auth, validation, or security inspection. The edge was an afterthought. A reverse proxy. TLS termination. Maybe Varnish for caching. Maybe a CDN for static assets. It was infrastructure plumbing, not a place where decisions happened. That model is over. Two migrations, one hollowing</h2> Here is the thing I keep coming back to: business logic is migrating in two directions simultaneously. Upward, to the edge. Infrastructure concerns like auth, WAF, and rate limiting now execute at the edge layer, before requests reach any backend. But it goes further than that. Edge Workers run actual application code. Containers deploy at the edge. Server-side rendering happens at edge nodes 50ms from the user, not in a data center 200ms away. Downward, to the client. The browser is no longer dumb. WebAssembly runs near-native code. WebGPU puts the GPU to work on ML inference and image processing. Web Workers handle background computation. Service Workers intercept network requests and serve cached responses offline. CRDTs let the client own its data and sync when it feels like it. The backend is caught in the middle. Squeezed from both sides. And what remains is not a “backend” in any traditional sense. It is a persistence layer. A place where data rests and syncs. The interesting work happens elsewhere. What moved to the edge</h2> Infrastructure concerns</h3> The first wave was obvious. Cross-cutting concerns that every service needed are better handled once, at the point of entry. Authentication. Validating a JWT does not require application context. The token is self-contained: a signature, an issuer, an expiry, a set of claims. Parse it, verify the signature against a JWKS endpoint, check the expiry, extract the claims, attach them as headers. Done. The backend receives X-User-Id: alice</code> and X-User-Role: admin</code> instead of a raw Bearer token it has to decode itself. This is not hypothetical. Here is what this looks like in practice: agent "auth" { type "auth" grpc address="http://localhost:50051" events "request_headers" timeout-ms 100 failure-mode "closed" max-concurrent-calls 100 } </code></pre> That agent handles JWT, OIDC, SAML, mTLS, and API key validation. Every route behind it gets authentication for free. Every backend service trusts the edge to have done the work. The auth agent crashes? Failure mode is “closed”. Requests stop, but the proxy stays up. Rate limiting. Token bucket algorithms with per-client keys. The edge layer sees every request before the backend does. It is the natural place to enforce rate limits because it can reject bad traffic before it consumes backend resources. A rejected request at the edge costs microseconds. A rejected request at the backend costs a database query, a connection slot, and whatever work happened before the check. There are two flavors. Local rate limiting uses in-process token buckets. Fast, no network hops, but each edge node tracks its own counters. If you have 10 edge nodes and a limit of 100 requests per second, each node allows 100, so the effective limit is 1,000. For most use cases, this is fine. Abuse does not distribute itself evenly across your infrastructure. Distributed rate limiting uses a shared store (Redis, typically). Accurate across nodes, but adds a network hop per request. The tradeoff is latency versus precision. I default to local rate limiting and switch to distributed only when the use case demands exact global limits, like API billing or token budgets for LLM inference. Security inspection. WAFs used to be appliances. Expensive, opaque, binary. A request was either blocked or allowed. Modern WAFs use anomaly scoring. Each rule contributes a score, and the total determines the action: Score 0-9: Allow Score 10-24: Log (warning, investigate later) Score 25+: Block </code></pre> This is a fundamentally different model than binary block/allow. It lets you tune aggressively without breaking legitimate traffic. I run 285 detection rules at the edge and process 912K requests per second on clean traffic. That is 30x faster than ModSecurity’s C implementation. The performance gap matters because it means WAF inspection can happen on every request, not just suspicious ones. API validation. If your API has a JSON Schema, why validate request bodies in your application code? Validate at the edge. Reject malformed requests before they consume a connection, a goroutine, a database transaction. The backend receives only structurally valid payloads. Observability. Trace context should originate at the edge, not at the application. The edge is where the request enters your system. It is where you assign a trace ID, start the clock, and record the first span. If you originate traces in your application, you miss everything that happened before: TLS negotiation time, WAF processing time, the fact that the request sat in a rate limit queue for 50ms. Starting traces at the edge gives you the full picture. The isolation problem</h3> You cannot put all of this in a monolithic proxy. That is how you end up with nginx and 47 modules where nobody understands the interaction effects. A WAF bug should not take down your routing. A slow auth provider should not block rate limit checks. The answer is process isolation. Thin dataplane, crash-isolated external agents. Each agent runs as a separate process with its own failure domain: ┌──────────────────────────────────────────┐ │ Edge Proxy (thin dataplane) │ │ Routing │ TLS │ Caching │ Load Balancing │ └─────┬──────────┬──────────┬──────────────┘ │ │ │ ▼ ▼ ▼ [WAF] [Auth] [Rate Limit] process process process </code></pre> Each agent gets its own concurrency semaphore. A slow WAF cannot starve auth. Each agent has a circuit breaker. Three failures in 30 seconds and the circuit opens. Each agent has a configurable failure mode, and this is where the design gets interesting: agent "waf" { type "waf" timeout-ms 100 failure-mode "closed" max-concurrent-calls 50 circuit-breaker { failure-threshold 5 success-threshold 2 timeout-seconds 30 } } agent "rate-limit" { type "rate-limit" timeout-ms 50 failure-mode "open" max-concurrent-calls 200 } </code></pre> The WAF fails closed. If it crashes or times out, requests are blocked. You lose availability to preserve security. Rate limiting fails open. If it crashes, requests are allowed. You lose rate enforcement to preserve availability. These are explicit choices per agent, not global defaults. The operator decides which tradeoff to make for each concern, and the decision is visible in the config, not buried in code. Agents return decisions. The proxy merges them. A blocking decision from any agent wins. Otherwise, header mutations accumulate. The model is simple: agents advise, the proxy decides. No agent can override another agent’s block. No agent can force a request through. The proxy owns the final call. This is not a workaround. It is the fundamental design choice. Complex logic lives outside the core, behind process boundaries. The proxy stays small, fast, and boring. The agents handle the interesting work in isolation. A bug in a Lua scripting agent does not corrupt the routing table. A memory leak in the WAF agent does not exhaust the proxy’s memory. The process boundary is the blast radius. Edge Workers: business logic at the edge</h3> Infrastructure concerns were the first wave. The second wave is actual business logic. Cloudflare Workers, Deno Deploy, Fastly Compute, Vercel Edge Functions. These are not just “serverless at the CDN.” They are full compute environments running at edge nodes around the world. V8 isolates spin up in under 5ms. Cold starts are measured in single-digit milliseconds, not seconds. Your code runs 50ms from the user instead of 200ms away in us-east-1. The constraints matter, because they shape what belongs here. Typical Edge Worker limits: 10-50ms CPU time per request (not wall time, actual CPU), 128MB memory, no raw TCP sockets, no persistent file system. You get a request, key-value storage, and the ability to make sub-requests to origins. That is it. These constraints are not bugs. They are what makes sub-millisecond cold starts possible. V8 isolates are cheap because they are small and short-lived. What fits within these constraints is surprisingly broad: API routing and transformation. A request comes in for /api/v2/users</code>. The edge Worker rewrites it, fans out to two backend services (user profiles from one, preferences from another), merges the responses, and returns a single payload. The backend services are simple data sources. The edge Worker is the API layer.</li> A/B testing and feature flags. Read the experiment cookie, hash the user ID, assign a variant, route to the right origin or rewrite the response. No round trip to a feature flag service. The decision happens in microseconds at the node closest to the user.</li> Personalization. Look up the user’s segment in KV storage, inject the right content block, set cache headers accordingly. The backend generated all variants at build time. The edge picks the right one per request.</li> Server-side rendering. Render HTML at the edge node closest to the user. Frameworks like Next.js and Remix already support this. React Server Components run at the edge. The “server” in server-side rendering is not your server. It is an edge node in 300 locations.</li> Authentication and session management. Validate tokens, refresh sessions, set secure cookies. The auth flow never touches your origin. Cloudflare Workers KV or Durable Objects store session state at the edge.</li> </ul> The pattern: compute that depends on request context but not on deep application state moves to the edge. If you can do it with a request, a key-value lookup, and a response, it probably belongs here. If it needs a complex database query or a multi-step transaction, it does not. Containers at the edge</h3> Edge Workers hit a ceiling when you need persistent connections, large memory, or long-running processes. For those workloads, containers at the edge. Fly.io, Railway, and Lambda@Edge deploy containers or full processes to edge locations worldwide. Your application runs with real file systems, TCP connections, and whatever runtime you need. But it runs close to users, not in a centralized data center. Latency drops from 200ms to 20ms. The interesting problem is data gravity. Compute is easy to distribute. Data is not. If your container runs in Tokyo but your database is in Frankfurt, you have not solved the latency problem. You have moved it from the user-to-server hop to the server-to-database hop. The solutions are still maturing: read replicas at the edge (Turso, Neon), embedded databases that sync (LiteFS, libSQL), and eventually-consistent stores designed for multi-region (DynamoDB Global Tables, CockroachDB). This model makes sense when compute and data can be co-located: Regional APIs that comply with data residency requirements. Run the container and the database replica in the same region. GDPR data stays in the EU. Japanese user data stays in Japan.</li> Real-time applications where 200ms round trips kill the experience. Collaborative editing, multiplayer, live dashboards. A WebSocket server 20ms away feels instant. One 200ms away feels sluggish.</li> Stateful edge compute where you need more than a request/response cycle. Background processing, scheduled jobs, long-running connections.</li> </ul> The line between “edge” and “origin” blurs. If your container runs in 30 regions and handles requests locally with a local database replica, is that an edge deployment or a distributed backend? The distinction stops mattering. What matters is that the compute and the data are close to the user. What moved to the client</h2> The other half of the migration goes downward. The browser is not the thin client it used to be. WebAssembly</h3> WASM runs at near-native speed in every modern browser. Not “fast for JavaScript.” Actually fast. Compiled from Rust, C++, Go, or any language with an LLVM backend. Sandboxed, portable, deterministic. What this enables: Image and video processing in the browser. No upload to a server, no round trip, no privacy concern. The pixels never leave the device.</li> Document parsing and transformation. PDF rendering, spreadsheet computation, file format conversion. Libraries compiled to WASM and running client-side.</li> Cryptographic operations. End-to-end encryption where the server never sees plaintext. Key derivation, signing, verification, all in the browser.</li> Compute offloading from the backend. This is the one that changes how you think about server sizing.</li> Full relational databases in the browser. This is the one that changes architectures.</li> </ul> I build on this pattern directly. Cyanea</a>, a bioinformatics platform, uses WASM to offload computation from the backend to the client’s browser. Sequence analysis, structure visualization, dataset filtering, these are CPU-intensive operations that traditionally require beefy server infrastructure. Instead, the computation runs right there on the researcher’s device. The backend stays thin: it stores datasets and coordinates collaboration, but the heavy lifting happens in the browser. This means I can run the platform on a modest server and still deliver real computational capability, because the “compute fleet” is the users’ own machines. Archipelag</a> takes the same idea in a different direction. It is a distributed compute platform where users contribute their browser’s idle compute power via WASM. The workloads compile to WASM modules, ship to participating browsers, execute in the sandbox, and return results. The browser is not just a client consuming a service, it is a compute node in a distributed system. The WASM sandbox is what makes this safe: untrusted code runs in a constrained environment with no access to the host file system, network, or memory beyond what is explicitly granted. SQLite compiled to WASM (via projects like sql.js, wa-sqlite, or the official SQLite WASM build) gives the browser a real relational database. Not a key-value store. Not IndexedDB’s awkward object store API. Actual SQL with joins, indexes, transactions, and triggers. Backed by the Origin Private File System (OPFS) for persistence, it survives page reloads and browser restarts. The implications are significant. Your application can run complex queries locally. Filter, sort, aggregate, full-text search. All instant, all offline. The server becomes a sync endpoint. It ships a database snapshot down and accepts change sets back. The client does the querying. The server does the storing. This pattern scales down elegantly. A note-taking app with SQLite-in-WASM needs no backend API for reads. A project management tool can filter and search 10,000 tasks without a network request. A CMS authoring interface can work fully offline and sync when the author reconnects. The read path is local. The write path syncs eventually. WASI (WebAssembly System Interface) extends this further. It gives WASM modules controlled access to file systems, clocks, and network sockets outside the browser. WASM becomes a universal runtime: the same binary runs in the browser, at the edge (Cloudflare Workers use WASM under the hood), and on bare metal. Write once, deploy to every layer of the stack. The pattern: anything that is CPU-bound, privacy-sensitive, or latency-sensitive is a candidate for client-side WASM. If the computation does not need server-side state, it should not round-trip to a server. WebGPU</h3> WebGPU landed in Chrome in 2023, in Firefox and Safari shortly after, and it changes the math on what the client can compute. This is not WebGL with a new name. WebGL exposes a graphics pipeline. WebGPU exposes compute shaders. Direct, general-purpose GPU computation from JavaScript or WASM. The immediate application is ML inference. Run a language model, an image classifier, or a recommendation engine on the user’s GPU. No server call, no API cost per token, no latency. The model weights download once (cached by the browser) and run locally. Privacy by default, because the data never leaves the device. This is not theoretical. Stable Diffusion generates images in the browser via WebGPU. Small language models (Phi-2, Gemma 2B, Llama 3.2 1B) run at usable speeds on consumer hardware. MediaPipe runs pose detection, face tracking, and hand gesture recognition in real time. The trajectory is clear: models get smaller through distillation and quantization, consumer GPUs get faster, and the gap between “cloud inference” and “local inference” narrows every quarter. Both Cyanea and Archipelag use WebGPU alongside WASM. In Cyanea, WebGPU accelerates molecular visualization and large-scale dataset operations, the kind of parallel computation that bioinformatics demands but that would be prohibitively expensive to run server-side for every user session. In Archipelag, WebGPU-capable nodes can take on GPU-accelerated workloads from the compute pool, turning a user’s idle GPU into a productive resource. The combination of WASM for general compute and WebGPU for parallel workloads gives the browser a compute profile that would have required dedicated server hardware five years ago. But inference is not the only use case. WebGPU handles any parallel computation: physics simulations for games, signal processing for audio applications, particle systems for data visualization, and large-scale matrix operations. Anything you would reach for CUDA or Metal for on native can now run in the browser. The compute budget of the client just increased by orders of magnitude. Web Workers and Service Workers</h3> Web Workers give you background threads. Heavy computation does not block the UI. Parse a large file, run a simulation, index a search corpus. All off the main thread, all without janking the interface. Service Workers sit between the browser and the network. They intercept every fetch request and decide what to do: serve from cache, go to network, do both and race them. This enables: Offline-first applications. The app works without a network connection. Data syncs when connectivity returns.</li> Background sync. Queue mutations while offline, replay them when online.</li> Push notifications. Wake the app without the user having it open.</li> Intelligent caching. Cache API responses, serve stale data while revalidating, pre-fetch resources the user is likely to need.</li> </ul> The Service Worker is the client-side equivalent of the edge proxy. It intercepts, caches, validates, and routes. It makes the client self-sufficient. Local-first and CRDTs</h3> Here is where it gets interesting. If the client has compute (WASM, WebGPU, Web Workers) and storage (IndexedDB, OPFS) and offline capability (Service Workers), why does it need a server at all? CRDTs (Conflict-free Replicated Data Types) answer the consistency question. Multiple clients can edit the same data independently, offline, with no coordination. When they reconnect, their changes merge automatically without conflicts. No server-mediated locking. No “last write wins” data loss. Mathematical guarantees that concurrent edits converge to the same state. The architecture: Client A (offline) Client B (offline) │ │ ├── Local edits ├── Local edits │ (CRDT ops) │ (CRDT ops) │ │ └──────┐ ┌────────┘ ▼ ▼ ┌──────────────┐ │ Sync service │ (thin, stateless) │ (persistence │ │ + relay) │ └──────────────┘ </code></pre> The sync service is not a backend. It stores operations and relays them between clients. It does not run business logic. It does not validate (the CRDT handles consistency). It does not transform (the merge function is built into the data type). It is a persistence layer with a WebSocket attached. I build systems like this. The concrete model: a document is a flat HashMap<EntityId, Entity></code> where each entity holds CRDT-typed fields. The field types determine how concurrent edits merge: CRDT type</th> Merge behavior</th> Use case</th></tr></thead> LwwRegister<T></td> Last writer wins (by timestamp)</td> Simple values: name, status, URL</td></tr> GrowOnlySet<T></td> Union of both sides</td> Tags, labels, immutable references</td></tr> ObservedRemoveSet<T></td> Add wins over concurrent remove</td> Collaborator lists, mutable collections</td></tr> MaxRegister</td> Higher value wins</td> Version counters, progress indicators</td></tr> MinRegister</td> Lower value wins</td> Earliest timestamps, priority values</td></tr> </tbody></table> Each field carries a hybrid logical clock (HLC) timestamp. The HLC combines physical time with a logical counter, so causality is preserved even when wall clocks drift. Two clients edit the same field at the “same” time? The HLC ordering is deterministic. Both clients converge to the same value without coordination. The merge function has three properties that make this work: it is associative (grouping does not matter), commutative (order does not matter), and idempotent (applying the same operation twice has no additional effect). These are not implementation details. They are the mathematical foundation that makes server-free consistency possible. You can sync operations in any order, from any number of clients, through any number of intermediate relays, and every replica converges to the same state. The client owns its data. The server is optional. When the server exists, it persists operations and relays them. It does not arbitrate, transform, or validate beyond authentication. This is not a niche pattern for collaborative text editors. Any application where users create and modify data can benefit. Notes, task managers, project planning tools, CMS authoring, form builders. The question is not “should this be local-first?” The question is “does this need a server, and if so, for what?” What the backend becomes</h2> If the edge handles infrastructure concerns and business logic that depends on request context, and the client handles computation, rendering, and local state, what is left for the backend? A persistence layer. The backend becomes the place where data rests between sessions and syncs between devices. Not an application server. A persistence layer. Consider the spectrum of what “backend” looks like now: Static sites. This site is an example. raskell.io is built with Zola. Markdown files compile to HTML at build time and deploy to edge CDN nodes. No application server. No database. No runtime process. The “backend” is a git repository and a CI pipeline. Content lives as files. Serving happens at the edge. The total monthly infrastructure cost is the price of a domain name. This is not limited to blogs. Documentation sites, marketing pages, product landing pages, e-commerce storefronts with pre-rendered product pages. Any content that changes at author-time rather than request-time can be static. The headless CMS (Contentful, Sanity, Strapi, or just a git repo) publishes content. The static site generator builds HTML. The CDN serves it. The “backend” runs at build time, not at request time. I take this further than most. All of my projects are CDN-first, even the ones with dedicated backends. The principle: if the backend goes down, the user should still see something useful. The static layer is the safety net. Kurumi</a>, a local-first second brain app, is the purest expression of this. It is a Progressive Web App served entirely from CDN edge nodes with Service Workers handling offline capability. There is no backend server. Notes sync between devices through CRDTs when connectivity exists, but the app works fully offline. The entire “infrastructure” is a static deployment and an optional sync relay. But the CDN-first pattern also applies to applications that have real backends. Cyanea has a Phoenix/Elixir backend that manages datasets, user accounts, and collaboration. But the public-facing surface, the landing pages, category pages, trending spaces and protocols and datasets, is statically generated. The backend exports JSON snapshots of its database objects on a timed interval. A static site generator picks up those snapshots and rebuilds the public pages: what labs are active, which protocols are trending, which datasets were recently published. The result is a set of HTML pages sitting on a CDN that stay current without depending on the backend being up at the moment a visitor arrives. ┌──────────────────┐ JSON export ┌──────────────┐ │ Cyanea Backend │ ──── (interval) ────> │ Static Site │ │ (Phoenix/BEAM) │ │ Generator │ │ │ │ (Zola) │ │ - datasets │ │ │ │ - protocols │ │ → CDN edge │ │ - labs │ │ nodes │ │ - spaces │ │ │ └──────────────────┘ └──────────────┘ │ │ │ dynamic app static pages ▼ ▼ app.cyanea.bio cyanea.bio (logged-in users, (public, always up, real-time features) fast, no backend dependency) </code></pre> This is a genuinely resilient architecture. The backend can be down for maintenance, mid-deploy, or experiencing load, and the public site keeps serving. The static pages are never stale by more than one generation interval. For a site where “trending this week” is sufficient freshness, that interval can be hours. The CDN handles traffic spikes that would overwhelm a backend. The backend handles the dynamic work that requires real-time data. Thin persistence APIs. For applications with dynamic data, the backend shrinks to a database with an API in front of it. Accept writes, serve reads, enforce schema constraints. GraphQL or REST over Postgres. No rendering. No business logic beyond data integrity. The API exists so that clients and edge workers have somewhere to store and retrieve state. The interesting shift: even the persistence API is getting thinner. Services like Supabase, PlanetScale, and Turso expose the database directly over HTTP or WebSockets with built-in auth. Your “backend” becomes a hosted database with row-level security policies. No application code at all. Sync relays. For local-first applications, the backend is even simpler. Accept CRDT operations from clients, persist them to durable storage, fan them out to other connected clients via WebSocket. No merge logic (the CRDT handles that). No transformation. No validation beyond authentication. The relay does not understand the data. It stores and forwards. Event logs. Append-only storage. Clients sync by replaying events from their last known position. The log is the source of truth. Everything else (search indexes, analytics dashboards, recommendation models) is a materialized view built asynchronously. The hot path is the append. The read path is the replay. Both are simple. Batch processors. The one place where traditional backend compute survives: jobs that require access to the full dataset. Analytics aggregation, report generation, search index building, ML model training. These run on schedules or triggers, not in the request path. They read from the event log or the database, compute, and write results back. The user never waits for them. The common thread: the backend does not touch the hot path. User requests hit the edge and the client. The backend runs in the background, on its own schedule, when no one is waiting. The architecture that makes this work</h2> Pushing logic to the edge and the client is not free. Both environments have constraints, and ignoring them is how you build fragile systems. At the edge: bounded resources</h3> Every operation at the edge needs explicit limits. No open-ended computations, no unbounded queues, no surprise behavior. This is not just good practice. It is existential. The edge proxy sits between the internet and your infrastructure. If it behaves unpredictably, everything behind it suffers. Concretely: Resource</th> Bound</th> Why</th></tr></thead> Agent concurrency</td> Per-agent semaphore (default: 100)</td> Prevents noisy neighbor between agents</td></tr> Agent timeout</td> 100ms default</td> Prevents latency cascade</td></tr> Connection pool</td> Explicit max (default: 10K)</td> Prevents file descriptor exhaustion</td></tr> Request body</td> Streaming, not buffered</td> Prevents memory exhaustion</td></tr> Route cache</td> LRU with size limit</td> Prevents unbounded growth</td></tr> Rate limit queues</td> Bounded with max delay</td> Prevents request pile-up</td></tr> </tbody></table> If you cannot articulate the bound for every resource your edge system uses, you do not have an architecture. You have an accident waiting for load. On the client: isolation and sandboxing</h3> The client has different constraints. Battery life, memory pressure, the user closing the tab at any moment. WASM runs in a sandbox. No file system access, no network access, no shared memory (unless explicitly granted). This is the security model that makes client-side compute viable. Untrusted code (your own, running on someone else’s device) cannot escape the sandbox. Web Workers run in separate threads with message-passing. No shared mutable state. No locks. No data races. The isolation is enforced by the runtime, not by programmer discipline. Service Workers have a lifecycle managed by the browser. They can be terminated at any time to save resources. Your offline logic must handle graceful shutdown. This means: durable state in IndexedDB, idempotent sync operations, no in-memory state that cannot be reconstructed. CRDTs provide consistency guarantees without coordination. But they are not magic. They consume memory (tombstones for deleted items, version vectors for causal ordering). They need garbage collection. They need careful schema design because not every data model maps cleanly to CRDT primitives. A counter works. A last-writer-wins register works. A rich text document with formatting, comments, and embedded media requires careful thought. The trust boundary</h3> Here is the part most edge-computing articles skip: trust. If the edge handles auth, the backend trusts the edge to have done auth correctly. If the client handles business logic, the server trusts the client to have computed correctly. These are real trust boundaries with real failure modes. At the edge, trust is earned through: Failure isolation. Agent crashes do not take down the proxy. Bad config is validated before activation.</li> Observability. Every decision is logged, metered, and traceable. If the WAF blocked a request, you can see exactly which rules fired and why.</li> Bounded behavior. No surprise modes. Every resource has explicit limits. Every failure mode is configured, not assumed.</li> </ul> On the client, trust is conditional: Never trust the client for security decisions. Validate at the edge or the backend. Client-side checks are UX, not security.</li> Trust the client for its own data. If the user is editing their own document, the client is authoritative. CRDTs handle consistency. The server persists, it does not arbitrate.</li> Verify at the boundary. When client data syncs to the server, validate schema and authorization. Trust the merge, verify the input.</li> </ul> When not to do this</h2> Not everything belongs at the edge or on the client. Here is what stays in the backend: Multi-service transactions. If an operation needs to read from three databases, check inventory, charge a payment, and send a notification, that is a backend workflow. Distributed transactions need coordination, and coordination needs a central authority. Heavy data joins. If your query joins six tables with complex filters and aggregations, it runs next to the database, not at an edge node 200ms away from the data. Regulatory requirements. Some industries mandate that data processing happens in specific locations, on specific infrastructure, with specific audit trails. Edge deployment may not satisfy these constraints. Small teams with simple needs. If you have one backend, ten users, and no latency problems, this architecture is overhead. A Django app behind nginx is fine. Optimize when you have a reason to optimize, not before. The edge handles cross-cutting concerns and request-context computation. The client handles local state and user-facing compute. The backend handles coordination, persistence, and anything that needs the full dataset. Know which is which. Where this is going</h2> Five years ago, the stack was: browser (thin) renders server-generated HTML, backend (fat) runs everything, database stores state. The mental model was request/response, and the backend was the center of gravity. The stack now: ┌─────────────────────────────────────────────────────┐ │ Client │ │ WASM │ WebGPU │ Web Workers │ Service Workers │ CRDT │ │ (compute, render, offline, local state) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Edge │ │ Proxy │ Workers │ Containers │ KV │ Durable Objects │ │ (auth, WAF, routing, SSR, API aggregation, policy) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Backend │ │ Database │ Sync relay │ Event log │ Batch processing │ │ (persistence, coordination, async compute) │ └─────────────────────────────────────────────────────┘ </code></pre> The client is fat. The edge is fat. The backend is thin. The center of gravity moved to both ends simultaneously. Every year, this accelerates. Models get smaller and run on consumer GPUs. WASM runtimes get faster and gain more system APIs through WASI. Edge platforms add durable storage, queues, and cron triggers. CRDTs mature from academic curiosities to production libraries. SQLite-in-the-browser goes from experiment to default architecture for offline-capable apps. The backend will not disappear. Data needs to live somewhere durable, and cross-device sync needs a relay. Coordination problems need a central authority. Batch processing needs access to the full dataset. But the backend’s role is narrowing to exactly these things. It is becoming infrastructure, not application. Plumbing, not logic. I find myself building systems where the most interesting engineering happens at the boundaries. A reverse proxy (Zentinel</a>) that inspects 912K requests per second through 285 WAF rules, authenticates with sub-millisecond latency, and routes with crash-isolated agents. A bioinformatics platform (Cyanea</a>) where the browser runs the computation and the backend exports JSON for statically generated pages. A distributed compute platform (Archipelag</a>) where users’ browsers are the compute fleet via WASM and WebGPU. A note-taking app (Kurumi</a>) that works fully offline with CRDTs and never touches a server for reads. Between all of them, a database, a sync relay, or just a CDN. Necessary and boring. The backend is not dead. It is just not where the interesting work happens anymore. References and further reading</h2> Edge platforms and proxies</h3> Cloudflare Workers</a> - V8 isolate-based edge compute</li> Deno Deploy</a> - Edge runtime built on the Deno JavaScript runtime</li> Fastly Compute</a> - Wasm-based edge compute platform</li> Vercel Edge Functions</a> - Edge compute integrated with Next.js</li> fly.io</a> - Container-based edge deployment platform</li> Pingora</a> - Cloudflare’s Rust framework for programmable proxies</li> Zentinel</a> - Security-first reverse proxy with crash-isolated agents</li> </ul> Client-side compute</h3> WebAssembly</a> - Portable binary instruction format for the web</li> WASI</a> - WebAssembly System Interface for running Wasm outside the browser</li> WebGPU specification</a> - W3C standard for GPU compute in the browser</li> MediaPipe</a> - ML inference framework running client-side via Wasm and WebGPU</li> SQLite Wasm</a> - Official SQLite build targeting WebAssembly</li> sql.js</a> - SQLite compiled to Wasm via Emscripten</li> Origin Private File System</a> - MDN reference for persistent browser storage</li> Service Worker API</a> - MDN reference for offline-capable web apps</li> Web Workers API</a> - MDN reference for background threads in the browser</li> </ul> CRDTs and local-first</h3> CRDTs: The Hard Parts</a> - Martin Kleppmann’s talk on practical CRDT challenges</li> Local-first software</a> - Ink and Switch research paper on local-first architectures</li> Automerge</a> - CRDT library for collaborative applications</li> Yjs</a> - High-performance CRDT framework for the web</li> A comprehensive study of CRDTs</a> - Shapiro et al., the foundational survey paper</li> </ul> Databases at the edge</h3> Turso</a> - SQLite-compatible database with edge replicas</li> Neon</a> - Serverless PostgreSQL with branching</li> LiteFS</a> - Distributed SQLite replication by Fly.io</li> CockroachDB</a> - Distributed SQL database designed for multi-region</li> Supabase</a> - Open-source Firebase alternative built on PostgreSQL</li> </ul> Projects referenced</h3> Cyanea</a> - Bioinformatics platform using Wasm and WebGPU for client-side compute</li> Archipelag</a> - Distributed compute platform with browser-based Wasm nodes</li> Kurumi</a> - Local-first second brain app with CRDT sync</li> Conflux</a> - Schema-aware CRDT engine for deterministic merge</li> </ul> Looking back on 2025 Unknown — Wed, 31 Dec 2025 00:00:00 +0000 I spent part of this year on the shores of Okinawa. The water there is something else entirely, this impossible azure that shifts to turquoise in the shallows, so clear you can see the coral formations from the surface. I found myself thinking about systems while I was there, the way you do when you’re floating in salt water with nothing pressing to attend to. Between swims, I read Tim Berners-Lee’s “This is for everyone.” I’ve been building web software for over a decade now, and I thought I understood what the web was. But reading TBL’s words while watching that reef ecosystem do its thing, thousands of species in constant exchange, no central coordinator, just emergent complexity from simple rules, something shifted in how I saw it all. The web TBL imagined was supposed to work like that reef. A commons. Many small nodes, each doing their own thing, connected through open protocols. Information flowing freely. The beauty of it wasn’t in any single node but in the connections between them, the way the whole became more than the sum of its parts. The same principle that makes a reef resilient makes a network powerful: diversity, redundancy, local adaptation. What we built instead looks more like industrial aquaculture. Five platforms. Algorithmic monoculture. Content optimized for engagement metrics rather than usefulness. We took a system designed for decentralization and built the most centralized information infrastructure in human history. I keep thinking about how that happened. The web itself never changed. HTTP still works the same way, HTML still does what it always did. What changed was the economics. Publishing became free, but being found became expensive. The platforms positioned themselves as the gatekeepers of attention, and suddenly you couldn’t reach people without paying the toll, whether in ad spend or in algorithmic compliance or in the slow erosion of doing whatever it took to game SEO. The thing about monocultures is they’re efficient right up until they’re not. A reef can lose a species and adapt. A monoculture gets one disease and collapses. We’ve been watching the web’s monoculture show stress fractures for years. The enshittification of platforms, the SEO content farms drowning out signal with noise, the way social media stopped being social and started being a feed of engagement-optimized content from strangers. Then 2025 happened, and AI started breaking things in interesting ways. The obvious take is that AI makes the content problem worse. And superficially, that’s true. If you thought SEO spam was bad before, wait until you see what happens when generating ten thousand pages of plausible-sounding garbage costs essentially nothing. The content farms went into overdrive. Social platforms filled with synthetic engagement. But here’s the thing I keep coming back to: maybe that’s the fever that breaks the infection. The old economics of the web depended on a particular scarcity. Human attention is finite, and the platforms controlled access to it. You wanted eyeballs, you played their game. SEO worked because Google was the gateway and you could optimize for what Google wanted. Platform distribution mattered because that’s where the people were. AI disrupts this in ways that I think are genuinely interesting. When an AI assistant can synthesize information from across the web and deliver it directly to the user, the value of ranking first on Google diminishes. Why click through to a content farm when the answer is already in front of you? When AI agents can find and surface relevant content directly, you don’t need to be on the platform where the eyeballs gather. The middleman’s leverage starts to evaporate. And crucially: when everyone can generate infinite content at zero marginal cost, content quantity becomes worthless. What matters is provenance. Accuracy. Usefulness. The things that are actually hard. The things that require a human perspective, or at least require being right in ways that matter. I find myself unexpectedly optimistic about what comes next. If AI breaks the distribution stranglehold that platforms have, the economics of the web could flip in interesting directions. The old model needed scale because reaching people was expensive. But if AI handles discovery, finding relevant content and bringing it to users, then maybe you don’t need scale anymore. Maybe small becomes viable again. Think about what this means concretely. A static site costs nearly nothing to run. No databases to scale, no servers to babysit, just files sitting on edge nodes around the world. If you don’t need to capture user data for ad-driven personalization, you don’t need the complexity of the surveillance stack. If you don’t need platform distribution, you don’t need to play platform games. There’s another piece to this that I think most people are missing: edge computing changes what personalization can mean. The conventional wisdom is that personalization requires surveillance, that you need to know everything about a user to show them relevant content. But that’s only true if personalization happens in a centralized database somewhere. If personalization happens at the edge, at the moment of request, you can adapt content to context without ever needing to know who the user is. The edge function doesn’t need a profile. It just needs to know what was asked for and what context it’s being asked in. This is the architecture I keep thinking about: static content at the origin, edge functions that adapt it anonymously, AI agents that find and surface it based on actual relevance rather than SEO gaming. No surveillance required. No platform dependency. No scaling costs that force you into growth-at-all-costs mode. It looks more like a reef than a fish farm. I don’t want to oversell this. The transition, if it happens, won’t be clean. The platforms aren’t going to quietly cede control. The incentives that built the current web are still operating. And AI itself could go in directions that make things worse rather than better. There are plenty of dystopian paths from here. But when I think about what I want to build toward, it’s that reef model. Many small, specialized nodes. Interconnected through open protocols. Resilient because distributed. Sustainable because the economics work at small scale. This site is part of that bet. Static content, no tracking, no platform dependencies. The tools I’m working on (Zentinel, Sango, Ushio) are all about making edge infrastructure more accessible, making it easier to build and operate systems that are distributed and independent. 2025 was the year AI started breaking the old model. I don’t know exactly what grows in its place. But floating in that Okinawan water, watching the reef do what reefs do, I got a sense of what healthy systems look like. Diverse. Interconnected. Resilient. Not optimized for any single metric, but somehow working anyway. That’s what I’m betting on. References and further reading</h2> Tim Berners-Lee</a> - Creator of the World Wide Web and author of “This is for everyone”</li> Enshittification</a> - Cory Doctorow’s term for the pattern of platform decay</li> IndieWeb</a> - Community building the independent web with open standards</li> Zola</a> - Static site generator used to build this site</li> Zentinel</a> - Security-first reverse proxy for the open web</li> Sango</a> - Edge diagnostics CLI for TLS, HTTP, and security header analysis</li> Ushio</a> - Deterministic edge traffic replay tool</li> </ul> Mise ate my Makefile Unknown — Sun, 14 Dec 2025 00:00:00 +0000 I maintain around forty repositories across four GitHub organizations. Zentinel</a> alone accounts for over thirty: the core proxy, a Rust SDK, and a growing collection of agents for WAF inspection, auth, rate limiting, GraphQL security, and a dozen other edge concerns. Archipelag</a> spans an Elixir coordinator, a Rust node agent, Python and TypeScript SDKs, mobile agents in Kotlin and Swift, and infrastructure-as-code repos. Cyanea</a> is Elixir with Rust NIFs and a separate Rust bioinformatics library. Then there are the standalone tools: Conflux</a> (Rust CRDT engine), Sango</a> (Rust edge diagnostics CLI), Shiioo</a> (Rust agentic orchestrator), Vela</a> (Rust bare-metal deployment), Refrakt</a> (Gleam web framework), Kurumi</a> (Svelte local-first app), and this site you are reading (Zola). The languages span Rust, Elixir, Gleam, Python, TypeScript, Kotlin, Swift, and whatever shell scripts accumulated over the years. Every project needs a toolchain. Most need task automation. All of them need to be approachable for a contributor who clones the repo for the first time. The Makefile approach was breaking down. So was everything else I tried. What was failing</h2> The standard setup for most of my Rust projects was a Makefile with targets for build</code>, test</code>, clippy</code>, fmt</code>, and release</code>. Simple enough for one repo. The problem surfaces when you maintain thirty of them. GNU Make and BSD Make disagree on syntax in ways that cause silent failures. A Makefile that works on my Linux CI runner breaks on a contributor’s macOS laptop because of a conditional or a shell invocation difference. The fix is always “use GNU make,” but that means documenting it, adding a check, and fielding issues from people who forget. Worse, Makefiles cannot declare tool dependencies. A Rust project needs a specific Rust version, maybe protoc</code> for gRPC, maybe cargo-watch</code> for development convenience. The Makefile assumes these tools exist. When they do not, the developer gets a cryptic error five minutes into their first build. So projects accumulated scaffolding: .rust-version .tool-versions Makefile scripts/setup.sh scripts/ci.sh scripts/release.sh .envrc </code></pre> Six files to express what amounts to: “this project uses Rust 1.83, needs protoc, and has five things you can run.” Multiply that by forty repos and you have a maintenance surface that nobody wants to touch. The scripts/</code> folder in particular had a way of growing silently. Someone adds a helper. Someone else copies it from another project with modifications. Six months later you have three slightly different versions of the same release script across three orgs. The Elixir projects had it worse. Elixir needs Erlang/OTP at a specific version, then Elixir itself at a matching version, then Node for asset compilation in Phoenix, then possibly Rust for NIFs (Cyanea compiles Rust bioinformatics code into the BEAM release). Four tool dependencies before you write a line of application code. asdf</code> handled the version management, but slowly and without task automation, so you still needed a Makefile on top. Why not Nix</h2> I gave Nix a serious try. The promise is appealing: declare your entire development environment in a single file, get reproducible builds, never worry about system state. The Nix shell concept is genuinely elegant. In practice, the cost was too high for my use case. Nix’s learning curve is steep even for experienced engineers. The language is its own thing. The documentation assumes you already understand the Nix store model. When something breaks, the error messages point at derivation hashes, not at the thing you actually did wrong. The bigger issue was onboarding. If a contributor wants to fix a typo in a Zentinel agent’s README, asking them to install Nix and understand flakes is a non-starter. The tool that manages your development environment should not itself become a project you have to learn. Nix solves a harder problem than I have. I do not need bit-for-bit reproducible builds across machines. I need “install Rust 1.83 and run the tests.” Why not asdf</h2> asdf was my default for years. It handled the version management problem well enough. The plugin system meant I could manage Rust, Elixir, Erlang, Node, and Python versions with a single .tool-versions</code> file. Three things pushed me away. First, speed. asdf is shell scripts. Every invocation pays the cost of sourcing plugins, resolving versions, and shimming binaries. On a fast machine you barely notice. On CI, where you run asdf install</code> in a fresh environment, the overhead adds up. Mise is a compiled Rust binary. It is meaningfully faster at both installation and version resolution. Second, no task automation. asdf manages tool versions. That is all it does. You still need Make or a scripts folder for project tasks. That means two tools, two configuration surfaces, two things to document. Third, plugin quality varied. The core plugins for Node and Ruby were solid. Plugins for less mainstream tools could be stale, broken, or missing. Mise started as an asdf-compatible rewrite and inherited the plugin ecosystem, but its built-in backends for common tools (Rust, Node, Python, Go, Erlang, Elixir) are faster and more reliable than shelling out to plugins. What mise actually does</h2> Mise</a> is a single Rust binary that combines tool version management and task running into one configuration file per project. It does asdf’s job and Make’s job in a single tool. Here is this site’s configuration. The entire thing: # mise.toml (raskell.io) [tools] zola = "0.19" [env] _.file = ".env" [tasks.serve] description = "Start the Zola development server" run = "zola serve" [tasks.build] description = "Build the site for production" run = "zola build" [tasks.check] description = "Check the site for errors without building" run = "zola check" [tasks.new] description = "Create a new article" run = """ #!/usr/bin/env bash if [ -z "$1" ]; then echo "Usage: mise run new <article-slug>" exit 1 fi SLUG="$1" DATE=$(date +%Y-%m-%d) FILE="content/articles/${SLUG}.md" cat > "$FILE" << ARTICLE +++ title = "" date = ${DATE} description = "" [taxonomies] tags = [] categories = [] [extra] author = "Raffael" +++ ARTICLE echo "Created $FILE" """ </code></pre> One file. Declares the tool (Zola 0.19), loads environment variables, and defines every task a contributor needs. mise install</code> sets up the toolchain. mise tasks</code> shows what is available. mise run serve</code> starts the dev server. No Makefile. No scripts folder. No documentation page explaining how to get Zola at the right version. For a Rust project like Shiioo</a> (the agentic orchestrator), the configuration is larger but follows the same pattern: # .mise.toml (shiioo) [tools] rust = "latest" [env] RUST_LOG = "info" RUST_BACKTRACE = "1" _.path = ["./target/release", "./target/debug"] [tasks.build] description = "Build all crates in release mode" run = "cargo build --release" [tasks.test] description = "Run all tests" run = "cargo test" [tasks.clippy] description = "Run clippy lints" run = "cargo clippy --all-targets -- -D warnings" [tasks.fmt] description = "Format code with rustfmt" run = "cargo fmt --all" [tasks.ci] description = "CI pipeline: format check, clippy, test" depends = ["fmt-check", "clippy", "test"] [tasks.dev] description = "Full development build and run" depends = ["fmt", "check", "test"] run = "cargo run -p shiioo-server" </code></pre> The depends</code> key is where mise replaces the one thing Make was genuinely good at: task dependency ordering. mise run ci</code> runs format checking, then clippy, then tests, in sequence. If clippy fails, tests do not run. It is not as expressive as Make’s file-based dependency graph, but for project automation tasks (as opposed to build tasks, which cargo or mix handle), it covers what I actually need. For a multi-language project like Cyanea, the value is even clearer. The Elixir app needs Erlang, Elixir, Node, and Rust. One [tools]</code> section pins all four. One mise install</code> gets a contributor from zero to a working environment. Without mise, that setup involved installing asdf, adding four plugins, running asdf install</code>, then installing direnv for environment variables, then reading the Makefile to figure out how to run things. With mise, it is two commands: mise install</code> and mise run dev</code>. The cross-project pattern</h2> The real payoff is not in any single project. It is the consistency across all of them. Every repo in every org follows the same contract: Clone the repo</li> Run mise install</code></li> Run mise tasks</code> to see what is available</li> Run mise run dev</code> or mise run test</code></li> </ol> That is it. Whether the project is a Rust reverse proxy with thirty modules, an Elixir Phoenix application with LiveView and a NATS integration, a Gleam web framework, or a static site built with Zola, the entry point is identical. The person cloning the repo does not need to know which build system the project uses internally. They do not need to read a CONTRIBUTING.md to find out whether it is make test</code> or cargo test</code> or mix test</code>. It is always mise run test</code>. This matters more than it sounds. When you maintain projects across four orgs and multiple languages, the cognitive overhead per context switch is the actual bottleneck. I work on Zentinel (Rust) in the morning, switch to Archipelag (Elixir) after lunch, then fix something on this site (Zola) in the evening. Without a consistent interface, each switch means recalling which project uses which conventions. With mise, the interface is always the same. The implementation behind mise run test</code> differs (cargo, mix, zola check), but I do not care about that. I type the same command and the right thing happens. For new contributors, the effect is more pronounced. Zentinel’s agent ecosystem has over twenty Rust repos. A contributor who submits a PR to the WAF agent and then wants to help with the auth agent does not need to learn a new setup process. Same structure, same task names, same workflow. The consistency compounds. What mise handles that Make does not</h2> Environment variables. Mise loads environment from the config file or from .env</code> files, scoped to the project directory. When I cd</code> into a project, the right environment is active. When I leave, it deactivates. No direnv, no .envrc</code>, no source .env</code> in every shell session. Tool installation. mise install</code> in a fresh clone gets every tool the project needs at the exact specified version. Make cannot do this. Make assumes the tools exist. That assumption breaks on new machines, in CI, and for every new contributor. Task discovery. mise tasks</code> lists every available task with its description. Make has make help</code> patterns, but those are conventions, not built-in features. With mise, discoverability is the default. File-based tasks. Any executable file in .mise/tasks/</code> becomes a task automatically. No registration, no config entry needed. For tasks that outgrow a one-liner in TOML but do not warrant a standalone script in scripts/</code>, this is the right middle ground. The task is discoverable through mise tasks</code> but lives as a normal shell script you can test independently. What breaks</h2> Mise is not perfect. Honest assessment after running it across forty repos: Dynamic dependencies. Make can express “rebuild this if that file changed.” Mise tasks are imperative: they run or they do not. If you need file-level dependency tracking, you still need a build system (cargo, mix, webpack). Mise orchestrates tasks. It does not replace the build tool. Ecosystem maturity. Mise is younger than Make and asdf. The documentation is good but not exhaustive. Some features (like hooks and watch mode) are recent additions. The pace of development is fast, which means features arrive quickly but occasionally change between minor versions. Team familiarity. Make is universal. Every engineer has encountered a Makefile. Mise is still relatively unknown. Introducing it to a team requires a short pitch, but the pitch is easy: “it is Make plus asdf in one tool, configured in TOML.” Complex shell tasks. When a task grows beyond a few lines, the inline TOML string syntax gets awkward. The workaround is file-based tasks in .mise/tasks/</code>, which works well but means the task definition lives in two places (TOML for metadata and task list, shell file for implementation). The migration</h2> If you are moving an existing project, here is the approach I settled on after migrating across all four orgs: Add a mise.toml</code> (or .mise.toml</code>) at the project root. Start with just [tools]</code> to declare the required versions.</li> Move the most-used Make targets to [tasks]</code> one at a time. Keep the Makefile around until everything is ported.</li> Add [env]</code> entries to replace .envrc</code> or .env.example</code> files.</li> Move standalone scripts from scripts/</code> to .mise/tasks/</code> as file-based tasks.</li> Delete the Makefile last.</li> </ol> Do not try to migrate everything at once. Start with the three tasks developers use daily (usually dev</code>, test</code>, and build</code>). The rest can move incrementally. I also settled on a few naming conventions that help across projects: use clear verb-noun prefixes like db-reset</code>, cache-clear</code>, test-unit</code>. Consistent naming makes task discovery predictable even before you run mise tasks</code>. The bottom line</h2> Mise is not a revolutionary tool. It does not do anything that was previously impossible. You could always install the right Rust version, write a Makefile, set up direnv, and maintain a scripts folder. What mise does is collapse all of that into a single file that is readable, portable, and consistent. The compound effect is what matters. Forty repositories, four organizations, six languages, one pattern. Clone, install, run. No guessing which build system this particular project uses. No debugging a Makefile that works on Linux but breaks on macOS. No explaining to a contributor that they need asdf plus three plugins plus direnv plus GNU make before they can run the tests. Every new project starts with a mise.toml</code>. Setup takes two commands instead of a page of instructions. Contributors do not message me asking how to run things. They run mise tasks</code> and figure it out. That is the tool working. References and further reading</h2> mise</a> - Official documentation and installation guide</li> mise source code</a> - GitHub repository and issue tracker</li> asdf</a> - The version manager mise was originally inspired by</li> Nix</a> - Reproducible builds and development environments</li> GNU Make</a> - The build tool mise replaces for task automation</li> TOML specification</a> - The configuration format mise uses</li> direnv</a> - Environment variable manager that mise’s [env]</code> section replaces</li> Shiioo</a> - Real-world mise configuration referenced in this article</li> mise-hx</a> - Example of a custom mise plugin (for the hx Haskell toolchain)</li> </ul> Disk space maintenance on Void Linux Unknown — Wed, 01 May 2024 00:00:00 +0000 Monday morning surprise</h2> As I spent most time doing stuff with my computer rather than configuring my beloved Linux distribution, Void Linux, I have developed the tendency to not really bother about Void at all until something crucial becomes unusable. After almost two years of having switched from Arch to Void, I have actually never encountered any major problem and felt I had made the right decision. I checked my disk usage out of curiosity if the 250GB solid-state disk would be enough. And there came the surprise: $ df -H Filesystem Size Used Avail Use% Mounted on devtmpfs 8.4G 0 8.4G 0% /dev tmpfs 8.4G 1.9M 8.4G 1% /dev/shm tmpfs 8.4G 1.4M 8.4G 1% /run /dev/nvme0n1p3 138G 117G 21G 85% / efivarfs 158k 85k 69k 56% /sys/firmware/efi/efivars cgroup 8.4G 0 8.4G 0% /sys/fs/cgroup /dev/nvme0n1p4 366G 34G 332G 10% /home /dev/nvme0n1p1 536M 152k 536M 1% /boot/efi tmpfs 8.4G 25k 8.4G 1% /tmp </code></pre> My root partition was full, way too full in my opinion. Did I miss something? Is Void not what I was looking for after all? I don’t enjoy baby sitting my OS du jour. The painless solution</h2> After a quick Brave search, I ended up finding what I was looking for. Some kind fellow software engineer from China didn’t shy away to make a blog post about his journey when he faced the very same problem. Out of annoyance of having to deal with that, I copy-pasted as quickly as possible, not minding what kind of side-effects I might run into, these three commands. 1. Cleaning the package cache</h3> All the knowledge I was lacking was to be found with the man page of xbps-remove</code>. # xbps-remove -yO </code></pre> The man page</a> of xbps-remove</code> tells us the -O</code> parameter takes care of cleaning the cache directory removing obsolete binary packages. Obsolete binary packages? Good riddance! I was surprised this to learn that solely this step freed up almost half of my used root partition disk space. 2. Removing orphaned packages</h3> # xbps-remove -yo </code></pre> Here the same man page</a> tells us that the -o</code> parameter takes care of removing installed package orphans that were installed automatically (as dependencies) and are not currently dependencies of any installed package. As before, good riddance! 3. Purging old, unused kernels</h3> This one is interesting. While I knew about the circumstance that the people behind Void had developed their own package management ecosystem, I hadn’t fully realized there were other utilities that came along with the upstream Void installation which were there for me to manage my beloved OS. So, apparently, one of these is a shell script</a> name vkpurge</code>, I must assume as a short name for Void's Kernel purging</code> tool. I like this type of naming heavily implying its functionality. # vkpurge rm all </code></pre> It performed as expected. Old kernel files (and modules?) were indeed purged and freed up even more disk space. I should add that this step is optional as it is always useful to have some old kernels at hand when things hit the fan (which for me, they haven’t in a very, very long time). Result</h2> I couldn’t be happier. $ df -H Filesystem Size Used Avail Use% Mounted on ... /dev/nvme0n1p3 138G 45G 93G 33% / ... </code></pre> Renewal of faith</h2> Overall, why am I even writing this if some other fellow engineer already figured this out? Simply, because I would therefore be able to explain why I have enjoyed my journey with Void as my go-to Linux distribution. It keeps things simple. Some well-documented utilities. As simple that a simple Brave search suffices to find the answer to my problems. This very aspect of Void is worthwhile highlighing. I remember more arcane Linux distributions that had me in their grip in figuring things out. Many Googles searches were necessary and even more trial and errors attempts to get simple things fixed. Now back to my Monday morning. References and further reading</h2> Void Linux</a> - Official project site</li> Void Linux Handbook: XBPS</a> - Official documentation for the XBPS package manager</li> xbps-remove(1) man page</a> - Manual page for package removal and cache cleaning</li> vkpurge source</a> - Shell script for purging old kernels on Void Linux</li> Void Linux FAQ</a> - Common questions about running and maintaining Void</li> </ul> ^{1 Painting in header image is “Seaside” by Aleksandr Deyneka </div>} All beginning is Haskell Unknown — Mon, 06 Mar 2023 00:00:00 +0000 This site is called raskell.io. That is not an accident. I started learning Haskell because I liked mathematics and someone told me there was a programming language built on top of it. Not “inspired by” in the loose way that every language claims some mathematical foundation. Actually built on lambda calculus, category theory, and type theory, in a way where the math is not decoration but structure. What I did not expect was how thoroughly it would rewire the way I think about building software. Not because Haskell is the best language for every task. It is not, and I write far more Rust than Haskell these days. But because Haskell teaches you to think about programs in a way that makes you better at everything else. What Haskell actually teaches you</h2> Most introductions to Haskell talk about pure functions, immutability, and monads. They are not wrong, but they miss the point. The point is not any single feature. It is how those features combine into a way of thinking about programs as compositions of well-typed transformations. In an imperative language, you think about sequences of steps. Do this, then that, then check a condition, then loop. The program is a recipe. In Haskell, you think about transformations. What goes in, what comes out, what shape does the data have at each stage. The program is a pipeline. This sounds abstract until you see it in practice. Suppose you need to process a list of user records: filter out inactive users, extract their email addresses, and normalize them to lowercase. In an imperative style, you write a loop with conditions and mutations. In Haskell: activeEmails :: [User] -> [Email] activeEmails = map (normalize . email) . filter isActive </code></pre> One line. Read it right to left: filter active users, then map over the result, extracting and normalizing emails. The type signature tells you what goes in ([User]</code>) and what comes out ([Email]</code>). No mutation. No intermediate variables. No place for off-by-one errors or null pointer exceptions. The type signature is not just documentation. It is a contract enforced by the compiler. If isActive</code> expects a User</code> and you pass it a String</code>, the program will not compile. If normalize</code> returns an Email</code> but you try to use it as a String</code>, the program will not compile. The compiler is your first reviewer, and it is tireless. Types as design tools</h2> The deeper lesson is that types are not just error catchers. They are design tools. When I design a system in Haskell, I start with the types. What are the entities? What are the relationships? What transformations are valid? The type system forces you to be precise about these questions before you write any logic. This precision surfaces design problems early, when they are cheap to fix. Consider modeling a document that can be in one of several states: data Document = Draft { content :: Text, author :: UserId } | UnderReview { content :: Text, author :: UserId, reviewer :: UserId } | Published { content :: Text, author :: UserId, publishedAt :: UTCTime } </code></pre> This is an algebraic data type. Each variant carries exactly the data that makes sense for that state. A Draft</code> has no reviewer. A Published</code> document has a timestamp. You cannot accidentally access a reviewer on a draft because the type system will not let you. The invalid state is unrepresentable. This pattern, making illegal states unrepresentable, is perhaps the most valuable idea I took from Haskell. I use it in Rust constantly. Rust’s enum</code> with associated data is directly descended from Haskell’s algebraic data types, and the same design principle applies: encode your invariants in the type system and let the compiler enforce them. The monad is not the point</h2> Every Haskell introduction eventually gets to monads, usually with a metaphor involving burritos or boxes. I will skip the metaphor. A monad is a pattern for sequencing computations that carry some context. The IO</code> monad carries the context of interacting with the outside world. The Maybe</code> monad carries the context of possible failure. The State</code> monad carries the context of mutable state. The pattern is the same in each case: take a value in a context, apply a function that produces a new value in a context, get back a combined context. lookupUser :: UserId -> IO (Maybe User) lookupUser uid = do conn <- getConnection result <- query conn "SELECT * FROM users WHERE id = ?" [uid] return (listToMaybe result) </code></pre> The IO</code> monad here sequences database operations. The Maybe</code> handles the case where no user is found. The types tell you both things at a glance: this function does I/O and might not return a result. The point of monads is not that they are clever. The point is that they make effects explicit and composable. In most languages, a function can do I/O, throw exceptions, mutate global state, or launch missiles, and you cannot tell from its signature. In Haskell, the type signature tells you exactly what effects a function can have. Int -> Int</code> is pure. Int -> IO Int</code> does I/O. Int -> Maybe Int</code> can fail. The information is right there, enforced by the compiler. This discipline, making effects explicit, changed how I design APIs even in languages that do not enforce it. When I write a Rust function that returns Result<T, E></code>, I am using the same pattern: making failure explicit in the type rather than hiding it behind an exception. Rust learned this from Haskell, and so did I. Why I am still building Haskell tooling</h2> If Haskell taught me so much, why do I mostly write Rust? The honest answer: Haskell’s ecosystem has gaps. The language itself is excellent. GHC is one of the most sophisticated compilers ever built. The type system is unmatched in its expressiveness among production languages. But the surrounding infrastructure, the package management, the build tooling, the deployment story, has not kept pace. Dependency management in Haskell is fragmented. Cabal and Stack coexist with overlapping but incompatible approaches. Build times are long. Cross-compilation is painful. Setting up a Haskell development environment from scratch still involves more friction than it should in 2026. This is why hx exists. hx is a Haskell toolchain CLI that I am building in Rust. The choice of implementation language is deliberate. Haskell’s tooling problems are partly caused by tooling that is itself written in Haskell, creating bootstrap problems and long compile times for the tools themselves. A Rust binary starts instantly, compiles to a single static executable, and cross-compiles trivially. The tool should not have the same dependencies as the thing it manages. hx is distributed through mise</a> (naturally), as well as through AUR, Homebrew, Scoop, and Chocolatey. The goal is that setting up a Haskell project should be as frictionless as setting up a Rust project: one command to install the toolchain, one command to build. On the other end of the spectrum, bhc (the Basel Haskell Compiler) is an experiment in taking Haskell in a direction GHC was never designed for: compiling Haskell for low-latency runtimes without a garbage collector. The target is workloads like tensor pipelines and real-time systems where GC pauses are not acceptable. bhc is early and ambitious, but it comes from the same conviction: Haskell’s ideas deserve better infrastructure than they currently have. The Haskell in my Rust</h2> I write Rust the way Haskell taught me to think. Rust’s ownership model is not the same as Haskell’s purity, but it serves a similar purpose: it forces you to think about data flow explicitly. In Haskell, you cannot mutate a value because the language will not let you. In Rust, you can mutate, but the borrow checker forces you to be explicit about who owns the data and who can see it. Both languages make you think before you write. Conflux</a>, my CRDT engine, uses algebraic data types for its merge semantics. Each CRDT field type (LwwRegister, GrowOnlySet, ObservedRemoveSet) is an enum variant with associated data, exactly the pattern I described above. The merge function is associative, commutative, and idempotent. These are mathematical properties that I learned to care about from Haskell, where such properties are often expressed as type class laws. Zentinel</a>, the reverse proxy, uses Rust’s type system to enforce that WAF decisions are handled in the correct pipeline stage. An AgentDecision</code> is either Allow</code>, Block</code>, or Modify</code>, and the proxy’s merge logic ensures that a Block</code> from any agent cannot be overridden. The pattern is a monoid (decisions combine associatively with Block</code> as the absorbing element), though nobody would call it that in the Rust codebase. The concept came from Haskell. The implementation is pure Rust. Even Shiioo</a>, the agentic orchestrator, uses Haskell-influenced patterns. DAG workflows are compositions of typed transformations. Events are algebraic data types with exhaustive pattern matching. The event-sourcing model treats state as a fold over an event stream. foldl</code> in Haskell, Iterator::fold</code> in Rust. Same idea, different syntax. Why “raskell”</h2> The name is a portmanteau. Raffael plus Haskell. I chose it because Haskell is where my engineering thinking started to take its current shape. Not the first language I learned, but the first one that changed how I think about all the others. I do not believe you need to write Haskell to benefit from Haskell. But I believe that learning it, really learning it, not just reading about monads but building something real with algebraic data types and type classes and higher-order functions, will make you a better engineer in whatever language you actually use. All beginning is Haskell. The rest is implementation. References and further reading</h2> Learning Haskell</h3> Haskell Language</a> - Official site with documentation and community links</li> Learn You a Haskell for Great Good!</a> - Approachable illustrated introduction</li> Real World Haskell</a> - Practical Haskell for production use</li> Haskell Wiki</a> - Community-maintained reference and tutorials</li> Typeclassopedia</a> - Comprehensive guide to Haskell’s type class hierarchy</li> </ul> Type systems and theory</h3> Haskell Curry</a> - The logician the language is named after</li> Lambda calculus</a> - Alonzo Church’s formal system underlying Haskell</li> Hindley-Milner type system</a> - The type inference algorithm at the core of Haskell and ML</li> Making illegal states unrepresentable</a> - Yaron Minsky’s influential talk on using types for correctness</li> Algebraic data types</a> - Haskell wiki reference on sum and product types</li> </ul> Monads and effects</h3> Philip Wadler, “Monads for functional programming”</a> - The foundational paper on monads in programming</li> All About Monads</a> - Haskell wiki guide to monadic programming</li> </ul> Haskell tooling</h3> GHC</a> - The Glasgow Haskell Compiler</li> Cabal</a> - Haskell’s build and package system</li> Stack</a> - Alternative build tool with curated package sets</li> mise-hx</a> - mise plugin for the hx Haskell toolchain CLI</li> </ul> Projects referenced</h3> Conflux</a> - CRDT engine using algebraic data types for merge semantics</li> Zentinel</a> - Reverse proxy with monoid-based decision merging</li> Shiioo</a> - Agentic orchestrator using event-sourced state folds</li> </ul> My OpenBSD journey: Getting it virtualized with libvirt (1) Unknown — Mon, 06 Feb 2023 00:00:00 +0000 Void Linux as my daily driver</h2> Around six months ago, I decided to ditch my long in the tooth Arch-based setup on my belovest Thinkpad X1 Carbon. I’ve been very loyal over the years, and almost came to belive that Arch will be a constant in my adult life. While I kept up with upcoming technologies, I somehow lost track of the ever so diversifying landscape of Linux distributions. It took me a while of constantly coming across a generically named reference to what seemed to be yet another Linux distribution. That outwardly generic sounding name, Void Linux</a>, kept poking my curiosity by supposedly feeling like Arch Linux in the old days, while sharing some substantial DNA with the BSD operating systems. Yet, that’s another story I might tell another day, but to remain brief, the BSDs, in particular the infamous OpenBSD with its quite infamous lead developer Theo De Raadt, always were what I considered the endgame. The holy grail of Unix operating systems, so did I think over the decades, FreeBSD, NetBSD and OpenBSD, have always been on my personal radar and I felt I had to earn the intellectual capacity to be able to properly put them at use one day. Last year, when I made the (almost painless) switch from Arch Linux to Void Linux, the simplicity and especially the barebone experience of Void reignited the fascination and the admiration I always had for the BSD operating systems and their philosophy. While I could write (and definitely will in the near future) about how my journey onto Void Linux and how it has been so far, I preferred to write down, in some like diary, and document every step on how one can approach and ultimately use OpenBSD</a> in 2023. Big disclaimer, I’ve yet to install OpenBSD on some baremetal server I ordered some days ago, but dabbled around in the meantime with OS-level virtualization in order to get it running. That’s what brings me to libvirt and my surprise to learn that I wouldn’t need some full-fledged virtualization solution like the ones offered by VirtualBox or VMWare to efficiently run a virtualized OpenBSD machine. So, ok, let’s recap, so far we got the following bill of materials: Void Linux as the host system</li> OpenBSD to be virtualized on that host system</li> libvirt as the glue that makes virtualization feel like black magic</li> </ul> From Void to OpenBSD</h3> Before I tell you more about the history of how things went down while setting up OpenBSD, let me give you some basic notions about both Void Linux, being one out of many Linux distributions for the sake of simplicity representing them all as it ended up being my distribution of choice, and OpenBSD. As already mentioned earlier, Void Linux and OpenBSD are both Unix-like operating systems, but they feature enough differences to make them noteworthy. Here are a few similarities and differences between the two: What is similar: Both are free and open-source operating systems.</li> Both use a package manager for software management. Void Linux uses XBPS, while OpenBSD uses pkg_add.</li> Both prioritize security and stability in their development and design.</li> Both feature a version control based package repository, meaning that changes in build definition are managed by pull requests from users.</li> </ul> What is different: License: Void Linux is licensed under the MIT License, while OpenBSD is licensed under the ISC License.</li> Philosophy: OpenBSD prioritizes security and privacy, while Void Linux prioritizes simplicity and modularity.</li> Package Management: Void Linux uses the XBPS binary package manager, while OpenBSD uses pkg_add (also binary). OpenBSD additionally has a ports system for building from source.</li> Package Repository: Void Linux has a large and diverse repository, while OpenBSD has a smaller and more curated repository.</li> Init System: Void Linux uses runit as its init system, while OpenBSD uses rc. None uses the infamous systemd init system.</li> </ul> What is OpenBSD in a nutshell</h2> OpenBSD is a free and open-source operating system that focuses on security, standardization, and robustness. It is based on the Berkeley Software Distribution (BSD) Unix operating system and is developed by a global community of volunteers. OpenBSD aims to provide a secure platform for both personal and enterprise use by implementing strong security features, including access control mechanisms, encryption, and auditing. Theo de Raadt</a> is the founder and lead developer of OpenBSD. His main objective with OpenBSD is to create a secure operating system that is free from backdoors, vulnerabilities, and other security weaknesses. He is committed to auditing the source code of the operating system and third-party software included with it, to identify and remove any potential security risks. De Raadt is also dedicated to improving the overall quality of the codebase and ensuring compatibility with a wide range of hardware and software. What makes OpenBSD really special and stand out is that is developed a suite of tools that got adopted by other OSs like Linux, macOS or even Windows. One of the most famous instances of such adoption is the now de facto standard openssh suite. It actually emerged from within the development circle of the OpenBSD project. OpenBSD also implemented a wide range of OS features that are by now considered staples among other OSs, things like Linux-based OS-level containerization done via the means of cgroups, something that OpenBSD already pioneered and solved with a different spin many years before Linux with pledge and unveil. Go check out Why OpenBSD rocks</a> to get a feel what makes OpenBSD so unique and interesting. Virtualization with libvirt</h3> So now, let’s get back to our virtualization endeavour where we would like to virtualize OpenBSD on a Void Linux installation. If you happen to be using another Linux distribution, most of the individual steps would be very similar. That brings me to the next technology we should explain a bit more here, and that is libvirt. libvirt</a> is an open-source virtualization management library that provides a simple and unified API for managing virtualization technologies, including KVM, QEMU, Xen, and others. It aims to simplify the process of creating, managing, and migrating virtual machines, storage, and networks, and to make it easier for administrators to manage virtual environments. To virtualize an operating system like OpenBSD with libvirt, you need to follow these steps: Install libvirt and the virtualization technology you want to use, such as KVM.</li> Download the OpenBSD iso file and place it in a location accessible by libvirt.</li> Create a new virtual machine in libvirt with the OpenBSD ISO as the installation media. This can be done through the command line or using a graphical user interface such as virt-manager.</li> Configure the virtual machine, including the amount of memory, CPU, and disk space, to meet the requirements of OpenBSD.</li> Start the virtual machine and install OpenBSD as you would on a physical machine.</li> Once the installation is complete, you can configure the virtual network, storage, and other settings as required.</li> Finally, you can use the libvirt API or the command line to manage and control the virtual machine, including starting, stopping, migrating, and snapshotting.</li> </ol> Step-by-step guide</h3> Let’s first install the libvirt</code> package and some related packages which we need in order to connect via VNC. The VNC will provide us with the possibility to use the graphical interface of the running OpenBSD instance. $ sudo xbps-install -S dbus qemu libvirt virt-manager virt-viewer tigervnc </code></pre> Now, we need to add our user, in my case raskell</code>, to the libvirt</code> group which got simultanously created with the installation of libvirt. $ sudo usermod -aG libvirt raskell </code></pre> OpenBSD features a release cycle of six months. We would need to update our system every six month to keep up with the latest packages. During a given release, only security and bug fix patches are applied to the curated packages maintained by pkg_add. Therefore, in February 2023, we’re using the OpenBSD 7.2</a> release version. As I’m living in Switzerland, I chose to pull the iso image from a Swiss mirror, in this case from mirror.ungleich.ch/pub/OpenBSD</code></a> (check what mirror is closest to you to get the best download rate). # cd /var/lib/libvirt/boot/ # sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso --2023-01-12 20:48:15-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 583352320 (556M) [application/octet-stream] Saving to: ‘install72.iso.1’ install72.iso.1 100%[====================================================================>] 556.33M 7.11MB/s in 77s 2023-01-12 20:49:33 (7.19 MB/s) - ‘install72.iso.1’ saved [583352320/583352320] sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 --2023-01-12 20:47:38-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1992 (1.9K) [application/octet-stream] Saving to: ‘SHA256.1’ SHA256.1 100%[====================================================================>] 1.95K --.-KB/s in 0s 2023-01-12 20:47:39 (742 MB/s) - ‘SHA256.1’ saved [1992/1992] # grep install63.iso SHA256 > /tmp/x # sha256sum -c /tmp/x # rm /tmp/x </code></pre> Before we can start the virtualization server and get running our OpenBSD instance, we need to define the configuraiton on how to virtualize and ultimately boot the system with. This is done with virt-install</code>. Noteworthy here is that we QEMU</a> as our emulation solution of choice, we allocate up to 4GB of RAM and 4 CPU cores to the machine. $ sudo virt-install \ --name=openbsd \ --virt-type=qemu \ --memory=2048,maxmemory=4096 \ --vcpus=2,maxvcpus=4 \ --cpu host \ --os-variant=openbsd7.0 \ --cdrom=/var/lib/libvirt/boot/install72.iso \ --network=bridge=virbr0,model=virtio \ --graphics=vnc \ --disk path=/var/lib/libvirt/images/openbsd.qcow2,size=40,bus=virtio,format=qcow2 </code></pre> Once, it is up and running, we can use a vnc solution to connect to the running machine. In this case, I chose virsh</a> to do the job. virsh is a command-line interface tool for managing virtualization environments created with libvirt. It allows us to manage virtual machines, storage pools, and network interfaces, as well as other virtualization components, from the command line. To establish a VNC connection with a running libvirt virtualized OpenBSD instance, you can use the following steps: Start the virtual machine in libvirt: You can start the virtual machine using the virsh command virsh start <vm-name></code>, where <vm-name></code> is the name of the virtual machine you want to start.</li> Find the VNC display: Once the virtual machine is running, you can find the VNC display number for the virtual machine using the virsh command virsh vncdisplay <vm-name></code>.</li> Connect to the VNC display: You can connect to the VNC display using a VNC client, such as vncviewer</code>, and specify the IP address of the host running the virtual machine and the VNC display number. For example, if the host’s IP address is 192.168.0.100</code> and the VNC display number is :0</code>, the command to connect would be vncviewer 192.168.0.100:0</code>.</li> Authenticate to the VNC server: You may need to enter a password to authenticate to the VNC server. The password is set when the virtual machine is created in libvirt.</li> </ol> With these steps, you can establish a VNC connection with a running libvirt virtualized OpenBSD instance and interact with the virtual machine’s graphical user interface. $ virsh dumpxml openbsd | grep vnc <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> </code></pre> Like I did, most of you would like to interact with a graphical interface such as with X11. For that, we yet another tool, a so-called VNC viewer. A very simple implementation of such a vnc viewer is tigervnc</a> (simply install it with $ sudo xbps-install -S tigervnc</code>). $ sudo virsh --connect qemu:///system start openbsd Domain 'openbsd' started </code></pre> References and further reading</h2> OpenBSD</h3> OpenBSD</a> - Official project site</li> OpenBSD FAQ</a> - Comprehensive installation and usage guide</li> Why OpenBSD Rocks</a> - Collection of OpenBSD innovations and features</li> OpenSSH</a> - The SSH suite that originated from the OpenBSD project</li> Theo de Raadt</a> - OpenBSD founder and lead developer</li> pledge(2)</a> - OpenBSD’s system call for restricting process capabilities</li> unveil(2)</a> - OpenBSD’s system call for restricting filesystem visibility</li> </ul> Void Linux</h3> Void Linux</a> - Official project site</li> Void Linux Handbook</a> - Official documentation</li> XBPS package manager</a> - Void’s binary package management system</li> </ul> Virtualization</h3> libvirt</a> - Virtualization management library and API</li> QEMU</a> - Open-source machine emulator and virtualizer</li> virsh(1)</a> - Command-line interface for managing libvirt guests</li> TigerVNC</a> - VNC implementation for remote desktop access</li> </ul> Guides</h3> [Guide] How to setup QEMU/KVM emulation on Void Linux</a> - Community guide on r/voidlinux</li> KVM virt-install: Install OpenBSD as Guest Operating System</a> - Step-by-step KVM installation guide</li> Auto-install OpenBSD on QEMU</a> - Automated OpenBSD installation on QEMU</li> </ul> Hello and outlook Unknown — Tue, 20 Sep 2022 00:00:00 +0000 Hello world</h2> This is the first post on raskell.io. My name is Raffael. I build software, mostly in the space of platform automation, edge infrastructure, and applied security. I also have a long-running interest in open-source software, operating systems, and the kind of hardware you find in recycling bins and give a second life to. This site exists to document real work and share patterns that other engineers can use. Not thought leadership. Not personal branding. Just notes from the workshop. What to expect</h2> At the time of writing, I planned to cover: Linux and BSD systems, particularly Void Linux</a> and OpenBSD</a></li> Open-source tooling and infrastructure</li> Platform automation and operability</li> Whatever hard problem I happened to be stuck on</li> </ul> Looking back from 2026, the scope grew to include edge systems, AI-assisted engineering, and a few deep dives I did not expect to write. The thread that held it together was always the same: systems under pressure, and the tools that keep them running. References</h2> Void Linux</a></li> OpenBSD</a></li> raskell.io source</a></li> </ul>

Your Agent Wants Root Unknown — Fri, 05 Jun 2026 00:00:00 +0000Part 2 of The Agent Platform Handbook. From Loop to Platform. Previous: What an Agent Actually Is</a>. Next: Tools, How Agents Actually Do Things. </blockquote> In post one</a> we did not just define what an agent is. We built one. A working harness in roughly one hundred and fifty lines of TypeScript on Bun: a loop, a one-tool registry, a system prompt, a dispatcher, and an iteration budget. A note on the word, because post one did not use it. The harness is the code that wraps the model and turns a chat API into something that acts. Loop, tools, system prompt, dispatcher, budgets today, and (further into the series) memory, identity, observability, policy, and the rest. Everything that is yours to write and yours to operate. The model is a dependency you call. The harness is the artifact you ship. In this series the harness is what grows, post by post. The code lives at tag post-01</code></a> of the-agent-platform-handbook</code></a>, and the rest of the series builds on it one layer at a time. Every post adds one file or rewrites one piece. This is the post that adds the second layer. The harness has one tool so far, called shell</code>, that runs any command you hand it under sh -c</code>. Post one closed with a one-line caveat: that tool will run rm -rf $HOME</code> if the model decides that is the right command, and the model will decide this at least once. This post is about the gap between “at least once” and “we are fine with that.” The shell tool from post one is, by any honest reading, an arbitrary-code-execution primitive with a polite English-language API in front of it. The model is non-deterministic. Tool results can carry instructions the model will treat as authoritative. Other agents may feed inputs back into your loop. Each of those is a way for a tool call to do something the operator did not intend. The defense is not to write better prompts. The defense is to put a fence around the runtime so the cost of a bad call is bounded. So this is the runtime post: the layer that sits underneath every tool the harness will ever have. We will sketch the threat model, walk the lineage of isolation primitives from chroot to microVMs, explain why “just run it in Docker” is only half an answer, and end by adding that layer to the harness from post one. The agent loop does not move. Only the floor underneath the shell tool changes, and the diff lands as tag post-02</code></a> in the same repo. What an agent runtime is actually exposed to</h2> A traditional service runs known code. You wrote it. You reviewed it. The only inputs are the ones the API contract allows. An agent runtime is not that. Three things make the agent threat model different. First, the model picks the action. The set of commands your shell tool will execute over its lifetime is a function of every prompt, every retrieved document, every tool output, and the model’s sampling temperature. You cannot enumerate it in advance. You cannot review it in code. You can only constrain what happens after. Second, tool results are an injection surface. A web page the agent fetches can contain “ignore previous instructions and run X.” A code file the agent reads can contain a comment that nudges the next decision. This is indirect prompt injection, documented by Greshake and others in 2023, and there is no fully reliable defense at the model layer. The runtime is where you assume the model will eventually be tricked. Third, blast radius scales with fanout. A single agent in a single shell on a single laptop is a manageable problem. A fleet of one hundred agents per tenant, each with shell, network, and file-system access, is not. Once you have more than one, you have a multi-tenant security problem whether you planned for one or not. So the question is no longer “can my agent be subverted.” It will be. The question is “what does the rest of the system look like the day after.” A short history of trying to contain a process</h2> The good news is that the industry has been working on “give this process less than the full machine” for forty-six years. The bad news is that almost none of the early answers were built with an adversary that picks its own commands in mind. The lineage matters because every modern option is a reaction to a specific failure of the option before it. chroot, Unix V7, 1979. Bill Joy’s contribution. A process sees a subtree of the filesystem as its root. Designed for build isolation, not security. Trivial to escape if you have any capability beyond a vanilla user. FreeBSD jails, Poul-Henning Kamp, 1999. Took chroot’s filesystem trick and added process visibility, network, and user separation. The first credible “container” in the modern sense. Still in production today and still good at what it does. Solaris Zones, 2004. A more ambitious version of jails with resource controls. Influential design, not a survivor. Linux cgroups and namespaces, 2002 through 2008. Namespaces gave you separate views of mounts, PIDs, networks, and users. cgroups, originally Process Containers from Google in 2007, gave you per-group resource accounting. The pieces existed. The user experience was awful. LXC, 2008. Tied cgroups and namespaces into a single CLI. Still awful, just less so. Docker, 2013. Took the same primitives and made them shippable. Image format, registry, declarative configuration, single command. The reason every paragraph after this one talks about “containers” is Docker. Kubernetes, 2014. Made running many containers across many machines a default. Pushed isolation choices down into the runtime layer. Kata Containers, 2017. A merger of Intel Clear Containers and Hyper.sh runV. Each pod runs in its own Linux VM, exposed to Kubernetes through a runtime that looks OCI-compatible. The first serious answer to “what if my container shared less than a whole kernel with the host.” Firecracker, AWS, 2018. A minimal virtual machine monitor on top of KVM, built to run Lambda and Fargate workloads. Around 125 milliseconds to boot. No legacy device model. Designed from the start for multi-tenant short-lived workloads. gVisor, Google, 2018. A user-space kernel, called runsc</code>, that intercepts syscalls from a container and services most of them itself, only escalating a narrow subset to the host. Drop-in replacement for runc</code> in any OCI-compatible runtime. Slower I/O, smaller attack surface. Wasmtime and the WASI runtimes, 2019 onward. A different model entirely: compile your tool to WebAssembly, run it in a sandbox with capability-passed I/O. Excellent for things that fit. Not yet a general answer for “run arbitrary shell commands.” The lesson from this lineage is the one the agent runtime question keeps re-asking. Every layer was designed for the threat model of the time. chroot was about build isolation. Docker was about deployment ergonomics. Firecracker, gVisor, and Kata were the first three options designed in an era where the workload itself was assumed to be untrusted. That assumption is the one that matches what an agent does. Why a default Docker container is not enough</h2> Docker is the default for almost every agent project that is past the laptop stage. There are good reasons. The packaging is good. The ecosystem is enormous. Kubernetes speaks it natively. For most workloads that are not adversarial, it is the right answer. Three things stop it from being enough for an agent runtime. The kernel is shared. A default docker run</code> puts your process in a set of namespaces with a set of cgroups, but it runs against the same kernel as the host. Any kernel bug reachable from the container becomes a host compromise. This is not theoretical. The runc CVEs of 2019 and 2024 each gave a container with default settings a path to escape. Those got patched. The next one is in flight somewhere. The defaults are generous. A vanilla docker run</code> keeps a substantial set of Linux capabilities, allows the container to write to its own root filesystem, leaves network access to internal services open by default, and runs the process as root inside the container. None of those are inherent to containers. All of them have to be turned off explicitly. The agent will be told to do things. Volume mounts that expose the host filesystem will get used. Network interfaces that reach internal APIs will get called. Secrets sitting in environment variables will end up in tool output. The model is helpful. It does not have a security review board. The honest version of the rule is this. A hardened Docker container, with capabilities dropped, network disabled, the root filesystem read-only, user namespacing on, no-new-privileges set, and resource caps in place, is enough for single-tenant, low-stakes, well-scoped agent workloads. It is not enough for multi-tenant or for code paths where the agent can be steered by external input. For those, you want a second isolation boundary underneath the container. The mental model</h2> There are three boundaries you can put between an agent’s tool call and the host kernel. Stack them in your head before picking a vendor. host kernel ================================================= | | | +------------------+ +---------------+ | | | Docker default | | Hardened | | | | ----------------| | Docker | | | | shared kernel, | | ---------- | | | | many caps, | | no caps, | | | | network on, | | no net, | | | | fs writable | | ro fs | | | +------------------+ +---------------+ | | ^ ^ | | | | | | +--------+-----------------------+------+ | | | gVisor (runsc) | | | | user-space kernel intercepts the | | | | syscall surface. host kernel sees | | | | only a narrow subset. | | | +---------------------------------------+ | | ^ | | | | | +------------------+--------------------+ | | | Firecracker / Kata | | | | separate Linux kernel per workload. | | | | KVM is the boundary. host kernel is | | | | one hypervisor call away. | | | +---------------------------------------+ | ================================================= host hardware</code></pre> Read it bottom-up. Firecracker and Kata give you the strongest isolation by giving the workload its own kernel and putting KVM between it and yours. gVisor gives you most of the same benefit with a lower operational cost by replacing the syscall surface with a user-space implementation. Hardened Docker is what you actually want at the laptop or small-team scale. Default Docker is fine for code you wrote and not for code the model wrote. Pick the layer that matches the workload. Stacking is allowed and often correct: hardened Docker plus gVisor is the usual production starting point for agent fleets. Adding the runtime layer to the harness</h2> The cheapest meaningful upgrade to the harness from post one is to stop running tool calls in the same process as the agent loop. Wrap the shell tool in a hardened container, with gVisor underneath if you have it installed. The loop stays the same. The blast radius drops by an order of magnitude. None of the four other pieces of the harness (system prompt, dispatcher, message history, iteration budget) need to know any of this happened. Install gVisor once on the host: # Linux only. macOS users can skip gVisor and keep the hardened flags. curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor \ -o /usr/share/keyrings/gvisor-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) \ signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] \ https://storage.googleapis.com/gvisor/releases release main" | \ sudo tee /etc/apt/sources.list.d/gvisor.list sudo apt-get update && sudo apt-get install -y runsc sudo runsc install sudo systemctl reload docker </code></pre> You now have runsc</code> as an available Docker runtime. From here, the rest of this section is three small changes to the harness from post one. The repo at post-01</code> has three files (agent.ts</code>, tools.ts</code>, package.json</code>); at post-02</code> it has four. Run git diff post-01 post-02</code> against the-agent-platform-handbook</code></a> and the entire delta of this post is on screen. Change 1: extract the Tool</code> type into its own file. In post one, Tool</code> lived at the top of tools.ts</code> next to the only implementation. We are about to grow the toolbox and start swapping tool implementations between sandboxed and non-sandboxed variants, so the type and the implementations want to live in different files. Pure refactor, no behavior change. // types.ts (new file) export type Tool = { name: string; description: string; input_schema: { type: "object"; properties: Record<string, unknown>; required?: string[]; }; run: (input: Record<string, unknown>) => Promise<string>; }; </code></pre> Change 2: point agent.ts</code> at the new location. One line. The loop, the system prompt, the iteration budget, the tool-call dispatcher are all untouched. // agent.ts import Anthropic from "@anthropic-ai/sdk"; import type { MessageParam, ToolResultBlockParam } from "@anthropic-ai/sdk/resources/messages"; - import { shell, type Tool } from "./tools"; + import { shell } from "./tools"; + import type { Tool } from "./types"; </code></pre> Change 3: rewrite tools.ts</code> so the shell tool runs inside a hardened container. The exported name, description, and input schema stay the same so the model sees the same tool. Everything that changes is below the public interface, in run</code>. That is the separation we are paying for: the agent does not know its tool got fenced. // tools.ts (sandboxed version) import type { Tool } from "./types"; const SANDBOX_IMAGE = "alpine:3.20"; const SANDBOX_WORKDIR = "/work"; const dockerArgs = (image: string, command: string) => [ "docker", "run", "--rm", "--runtime=runsc", // gVisor. drop on macOS. "--network=none", // no exfil, no SSRF "--read-only", // no writes to the rootfs "--tmpfs", "/tmp:size=64m", // give /tmp back, bounded "--cap-drop=ALL", // no Linux capabilities "--security-opt=no-new-privileges", // no setuid escalation "--user=1000:1000", // unprivileged uid in the container "--memory=256m", // hard memory cap "--cpus=0.5", // fractional cpu cap "--pids-limit=64", // no fork bombs "--workdir", SANDBOX_WORKDIR, image, "sh", "-c", command, ]; export const shell: Tool = { name: "shell", description: "Run a shell command inside an isolated sandbox with no network and a read-only filesystem. Returns stdout, stderr, and exit code as JSON.", input_schema: { type: "object", properties: { command: { type: "string", description: "Shell command to run under `sh -c` inside the sandbox.", }, }, required: ["command"], }, run: async ({ command }) => { const args = dockerArgs(SANDBOX_IMAGE, String(command)); const proc = Bun.spawn(args, { stdout: "pipe", stderr: "pipe" }); const [stdout, stderr] = await Promise.all([ new Response(proc.stdout).text(), new Response(proc.stderr).text(), ]); const code = await proc.exited; return JSON.stringify({ code, stdout, stderr }); }, }; </code></pre> Total damage: one new file of ten lines, one moved import, and forty-five lines of tools.ts</code>. In exchange, roughly a thousand-fold reduction in blast radius. The agent can still ask rm -rf /</code>. It will return an exit code, an error, and a clean host. Network calls will fail closed. Reads outside /work</code> are not possible because nothing is mounted into /work</code>. The sandbox dies the moment the command returns, so persistence between calls is also gone, which is a separate problem we will pick up in post six on memory</a>. A few things to notice. The harness shape from post one is intact. Same loop, same dispatcher, same system prompt, same iteration budget, same JSON contract between the agent and the tool. The sandbox is a runtime concern, not an agent-architecture concern. This separation is exactly the point. You should be able to swap gVisor for Firecracker, or Docker for Podman, or Alpine for a custom image, without touching the loop. The tradeoffs are real. Spawning a container per tool call costs roughly 200 to 800 milliseconds on a modern host, mostly Docker daemon overhead. For a coding agent that runs three shell commands per turn, that is acceptable. For a sub-millisecond-per-call tool, it is not. The fix at scale is a container pool, or moving to Firecracker microVMs with snapshot/restore where boot time drops to around 125 milliseconds and per-call cost drops further. The image is alpine:3.20</code>, which is around 8 megabytes. Use a bigger image when the workload needs it. Mount a per-session work directory under /work</code> when the agent needs to read or write files between calls. Both of those are configuration changes, not architecture changes. Picking the layer</h2> Use the table to pick where to start. The honest answer for most teams is “hardened Docker plus gVisor today, Firecracker microVMs later when scale or tenancy demands it.” Workload</th> Sensible default</th> Why</th></tr></thead> Local dev agent, one user, your laptop</td> Hardened Docker, gVisor if available</td> Convenience wins; the blast radius is one machine.</td></tr> Shared internal tool, single tenant</td> Hardened Docker plus gVisor</td> Cheap upgrade, real benefit, no orchestration cost.</td></tr> Multi-tenant SaaS, agent per user session</td> Firecracker microVM per session</td> Per-tenant kernel isolation; fast boot per session.</td></tr> Kubernetes-native agent platform</td> Kata Containers</td> Drop-in OCI shape, pod-level VM boundary.</td></tr> Unknown code from the public internet</td> gVisor at minimum, microVM preferred</td> Syscall surface or hypervisor surface, not yours.</td></tr> WASM-shaped pure-function tool</td> Wasmtime with capability-passed I/O</td> Fastest sandbox available when the workload fits.</td></tr> Throwaway batch job, internal only</td> Hardened Docker</td> Stacking layers adds cost without proportional gain.</td></tr> </tbody></table> The table assumes Linux. macOS does not have KVM, so Firecracker and gVisor are Linux-host options. On macOS you can run them inside a Linux VM (Lima, OrbStack, Docker Desktop) and pay the nested cost. What this layer does not solve</h2> Isolation is a necessary condition for a safe agent runtime. It is not a sufficient one. The honest list of what is still on your plate after this post. Outbound network policy. --network=none</code> is the right default for the shell tool. The moment you give an agent an http</code> tool, you need an egress policy that distinguishes “the model should reach the public web” from “the model should never reach the internal metadata service.” That is its own design problem.</li> Persistent state. A throwaway sandbox forgets everything between calls. Real agents need memory across tool invocations. The design question is which directories survive, who can read them, and what the eviction policy is. We will come back to this in post six</a>.</li> Tool-level policy. Even inside a perfectly isolated sandbox, you may want certain commands to require human approval. That is a permissions problem, not an isolation problem, and we will spend post fourteen</a> on it.</li> Identity. A sandboxed container still has to call your tools, your models, and your APIs. Long-lived API keys baked into the image are how production agent fleets get embarrassed. Post thirteen</a> puts SPIFFE under this stack.</li> Time and resource budgets. --cpus=0.5</code> and --memory=256m</code> cap a single invocation. They do not cap a loop that asks for one hundred invocations. Iteration budgets, token budgets, and wall-clock budgets are a separate fence. Post sixteen</a> covers that fence.</li> </ul> Where this lands in the platform</h2> You can hold the platform in your head one box at a time, and you can hold the harness on disk one tag at a time. Post one drew the agent loop and shipped it as post-01</code></a>. This post opened the runtime box, put three concrete things inside it (a hardened container, a user-space kernel, a microVM), picked one, and shipped the result as post-02</code></a>. The reference architecture in post twenty-two</a> will keep this box exactly where it is and treat the contents as a choice that varies by workload. The rule from post one still holds. Each post adds one layer to the same harness and explains why the layer below was not enough. The harness only ever grows; it does not get rewritten. The layer below this one was the shell tool itself. The layer above is the rest of the toolbox. An agent with one tool is a demo. An agent with a real tool registry is software. Next we extend the same harness with a real registry, give it a schema, and explain what changes when the model decides between four tools instead of one. That post will ship as post-03</code> in the same repo. Next</h2> Part 3: Tools, How Agents Actually Do Things. Function calling, structured outputs, schema design that survives model drift, and the failure modes nobody talks about. We extend the post-one agent with a four-tool registry and a tool-selection trace. What an Agent Actually Is Unknown — Tue, 02 Jun 2026 00:00:00 +0000 Part 1 of The Agent Platform Handbook. From Loop to Platform. A 22-post series that walks the agent stack from a single loop to a production platform. Next: Your Agent Wants Root</a>. </blockquote> If you sit in three meetings on the same day, you will hear the word agent used to mean three different things. A vendor will use it to mean a chat window with a logo. A platform team will use it to mean a workflow with a retry. A security lead will use it to mean a long-running process with credentials you cannot see. None of those people are entirely wrong. None of them are talking about the same thing. This is the first post in a series that goes from a single agent loop up to a production platform. Before we can talk about isolation, tools, identity, or orchestration, we have to agree on what the thing in the middle of the diagram actually is. So we will define it, sketch its anatomy, trace the path the industry took to get here, and then build a working one in roughly two hundred lines of TypeScript on Bun. By the end of the post the abstract noun is a concrete file you can run. A working definition</h2> An agent is software with five properties. Drop any one and what you have is something else. A goal. Not a single prompt. A target state, a task description, or a problem statement that the system is trying to satisfy.</li> A model. One or more inference engines that translate the current state plus the goal into a next step. Today this is almost always a large language model.</li> A context. Information the model can read beyond the user input. System prompts, documents, prior turns, environment state, configuration files.</li> Tools. A finite, named set of side-effecting operations the model is allowed to invoke. Reading a file. Running a shell command. Calling an API.</li> A loop. The model picks a tool, the tool runs, the result re-enters the context, the model picks again. The loop ends when the goal is satisfied, the budget is exhausted, or a stop condition is hit.</li> </ol> There is usually a sixth property in production, memory, which is state that survives the loop. We will treat memory as a separate layer in post six</a> and keep this first agent stateless. A system with all five properties is an agent. A system with four is something else worth a name. A chat window has goal, model, context, and a loop, but no tools, so it is a chatbot. A CI pipeline has a goal, context, tools, and a loop, but no model, so it is a workflow. A function call has a goal, a model, context, and a tool, but no loop, so it is a one-shot completion. The presence of the loop is what makes the behavior open-ended. The presence of tools is what makes the loop matter. The architecture diagram for every agent ever shipped looks like this. +--------------+ | Goal | | (user task) | +-------+------+ | v +------------+ +---------------+ +------------+ | Context +-------->| Model |<--------+ Memory | | docs, env, | | next action? | | (optional) | | prior turns| +-------+-------+ +------------+ +------------+ | | tool call v +---------------+ | Tool | | shell, http, | | file, custom | +-------+-------+ | | result v +---------------+ | Runtime | | (where the | | side effect | | happens) | +-------+-------+ | v +----------+----------+ | done? --no--> loop | | | | | yes | | v | | return | +---------------------+</code></pre> The diagram is small on purpose. Almost every post in this series will redraw it with one component opened up. Post two opens the runtime. Post three opens the tool. Post four opens the context. Post six opens the memory. Post seven opens the model. The capstone in post twenty-two assembles all of them into a reference architecture. Hold the picture in your head. We will come back to it. How we got here</h2> You can read the rest of this section as background and skip the first two subsections if you have already lived through them. The third subsection, on the 2024 to 2026 stretch, is worth the read either way because it explains why everyone you work with is suddenly using the word agent. The old AI</h3> The idea of a software agent is older than the modern LLM by about fifty years. Terry Winograd’s SHRDLU, in 1970, was a program that took natural-language commands, planned actions in a simulated blocks world, executed them, and updated its internal state. It had a goal, a model of the world, a set of tools, and a loop. It was an agent. It worked beautifully on the blocks world and fell over the instant you stepped outside it, because the model of the world was hand-coded and the language understanding was brittle. Through the 1980s and 1990s the idea kept coming back under different names. Expert systems wrapped business logic in inference rules. The Belief-Desire-Intention architecture, formalized by Bratman and others, gave agents an explicit cognitive model: what they believed, what they wanted, what they intended to do next. There were good papers, working systems, and shipping products. The thing all of them missed was a usable model of language. You could specify the agent’s goals in formal logic or in a structured DSL. You could not say “go book me a flight” and have it parse. The lesson from this era is that the architecture has been right for decades. The bottleneck was the model. The chat era</h3> When GPT-3 arrived in 2020 and ChatGPT in late 2022, the language bottleneck broke. You could finally write a goal in English and the system would respond coherently. The first response from the industry was to wrap that capability in a chat window and sell it. That is not an agent. There is no loop, no tools, and the model cannot do anything to the world it lives in. It is a very good autocomplete with a memory of the conversation. The agent pattern only came back when somebody asked the obvious next question. If the model can read and write English, and we can let it call functions, can we close the loop and let it act? Two papers and two viral demos answered that question between late 2022 and early 2023. The papers came first. ReAct: Synergizing Reasoning and Acting in Language Models by Yao and others, published in October 2022, showed that interleaving a reasoning step with a tool-use step produced better performance than either alone. The blueprint was small enough to fit on a napkin: think, act, observe, repeat. It became the de facto pattern for almost every agent shipped since. The demos came in early 2023. Auto-GPT, released by Toran Bruce Richards in March 2023, wrapped GPT-4 in exactly that loop and let it run unattended. It demoed brilliantly and broke constantly. BabyAGI, by Yohei Nakajima a few weeks later, did the same thing with about a hundred lines of Python. Neither was production-grade. Both made the idea legible to people who had never read the ReAct paper. After Auto-GPT you could explain an agent by saying “imagine ChatGPT but it keeps going until the task is done.” That was a marketing breakthrough, not an engineering one, but marketing is how ideas spread. OpenAI’s function-calling API, launched in June 2023, was the engineering breakthrough that followed. Instead of trying to parse “the model wants to call search(query)</code>” out of free-form prose, you declared your tools with JSON schemas and the model returned a structured tool call. Anthropic’s tool_use</code> shipped on the same pattern. With function calling, the agent loop stopped being a regex problem and started being a software problem. We will come back to this in post three</a>. The 2023 wave produced the first real frameworks: LangChain in October 2022, AutoGen in late 2023, CrewAI and LangGraph in 2024. They competed on abstractions. Some won, some lost. We will review them in post nine</a>. The point for now is that by mid-2024, building an agent was a Python or TypeScript exercise rather than a research project. The 2025 to 2026 bundling</h3> Here is where the word agent stopped being a research term and became a product category. It happened in two waves. The first wave was builder-facing. In early 2025, Anthropic shipped Claude Code, a command-line agent that ran on your laptop, edited files, ran shell commands, and could spawn sub-agents. OpenAI relaunched Codex as a real agent rather than a completion endpoint. The open-source community produced OpenCode and a half-dozen adjacent projects (aider, continue, opencoder) that gave the same shape a vendor-neutral surface. None of these were technically novel. The loop was the ReAct loop. The tools were bash</code> and edit</code>. What was new was the bundling: the loop, the tools, and the runtime arrived together, in a binary you could install in thirty seconds. Once that shipped, every infrastructure and platform engineer had a working agent on their laptop within a week. I wrote about what came next in What Sixteen AI Agents Taught Me About Management</a>. Once builders had working agents, they wanted to run more than one. Once they ran more than one, they hit coordination problems. Once they hit coordination problems, they discovered that agent orchestration is a management problem with a software wrapper. The second wave was assistant-facing and it broke out of the developer audience entirely. OpenClaw shipped in early 2026 and crossed a hundred thousand GitHub stars in its first week. Hermes followed in the same lane. Both took the agent pattern and gave it to people who do not write code. A research task. A contract review. A calendar negotiation. The same loop, with different tools and different context. The enterprise buyer stopped being the developer tooling team and started being any line of business with a workflow. That is where the market is right now, as of mid-2026. Every engineering org has builders running coding agents locally. Every business org has someone piloting an assistant agent. Almost no organization has a coherent platform underneath any of it. The point of this series is to close that gap. Build one</h2> You learn what an agent is by building one. The code that follows is a complete, working agent in TypeScript on Bun. It is roughly two hundred lines. It reads a goal from the command line, calls Anthropic’s API with a small tool registry, executes tool calls, feeds results back, and stops when the model is done or the iteration budget is exhausted. You will need three things to follow along. bun --version # 1.1 or newer echo $ANTHROPIC_API_KEY # any valid key bun add @anthropic-ai/sdk </code></pre> The full source for this post is in the-agent-platform-handbook</code></a> at tag post-01</code>. You can clone it and run bun agent.ts "list the three largest files under /etc"</code> if you would rather read the code in your editor. The tool interface</h3> The smallest unit worth defining first is a tool. A tool has a name, a description the model can read, a JSON schema for its input, and a function that runs the side effect and returns a string. // tools.ts export type Tool = { name: string; description: string; input_schema: { type: "object"; properties: Record<string, unknown>; required?: string[]; }; run: (input: Record<string, unknown>) => Promise<string>; }; </code></pre> That is the entire contract. The run</code> function returns a string because the model will read the result as text. If your tool returns structured data, serialize it with JSON.stringify</code> and let the model parse it. We will revisit this choice in post three</a> when we look at structured outputs more carefully. A shell tool, which is the most useful single tool you can give an agent, looks like this. // tools.ts (continued) export const shell: Tool = { name: "shell", description: "Run a shell command in the current working directory and return its stdout, stderr, and exit code as JSON.", input_schema: { type: "object", properties: { command: { type: "string", description: "The shell command to run. Runs under `sh -c`.", }, }, required: ["command"], }, run: async ({ command }) => { const proc = Bun.spawn(["sh", "-c", String(command)], { stdout: "pipe", stderr: "pipe", }); const [stdout, stderr] = await Promise.all([ new Response(proc.stdout).text(), new Response(proc.stderr).text(), ]); const code = await proc.exited; return JSON.stringify({ code, stdout, stderr }); }, }; </code></pre> A few things to notice. The description is written for the model, not for you. Be specific about what the tool does, what it returns, and what its constraints are. The JSON schema is the contract the model sees when it decides whether to call this tool. Bun’s Bun.spawn</code> returns streams, so we read both stdout and stderr and join them with the exit code into one JSON payload the model can reason about. This tool will run any shell command. That is wildly unsafe. Do not deploy it. We will spend post two</a> explaining why and what to do about it. For a single-user, single-directory demo on your own laptop, it is fine. The loop</h3> The loop is the part most explanations rush. Take it slowly. // agent.ts import Anthropic from "@anthropic-ai/sdk"; import type { MessageParam, ToolResultBlockParam } from "@anthropic-ai/sdk/resources/messages"; import { shell, type Tool } from "./tools"; const client = new Anthropic(); const tools: Tool[] = [shell]; const SYSTEM_PROMPT = `You are a careful command-line assistant. You have access to a shell tool. Use it to investigate the user's request and answer concretely. When you have the answer, stop calling tools and reply in plain text.`; </code></pre> We pull in the SDK, register one tool, and write a system prompt. The system prompt is the first piece of context that is not user input. We will spend post four</a> on how to grow this into a real context strategy. For now it is a single paragraph telling the model how to behave. // agent.ts (continued) async function step(messages: MessageParam[]) { return client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 4096, system: SYSTEM_PROMPT, tools: tools.map(({ run, ...t }) => t), messages, }); } </code></pre> Every call to the model is a step</code>. The tool list we send is the schema only, never the run</code> function, so we strip it. The model returns a message that is either a final text answer or a request to call one or more tools. The loop itself is fifty lines. // agent.ts (continued) export async function run(goal: string, maxIterations = 10) { const messages: MessageParam[] = [{ role: "user", content: goal }]; for (let i = 0; i < maxIterations; i++) { const response = await step(messages); messages.push({ role: "assistant", content: response.content }); if (response.stop_reason === "end_turn") { const text = response.content .filter((b) => b.type === "text") .map((b) => (b as { text: string }).text) .join("\n"); console.log(text); return; } if (response.stop_reason !== "tool_use") { throw new Error(`unexpected stop reason: ${response.stop_reason}`); } const toolResults: ToolResultBlockParam[] = []; for (const block of response.content) { if (block.type !== "tool_use") continue; const tool = tools.find((t) => t.name === block.name); if (!tool) { toolResults.push({ type: "tool_result", tool_use_id: block.id, content: `unknown tool: ${block.name}`, is_error: true, }); continue; } console.error(`> ${block.name} ${JSON.stringify(block.input)}`); try { const result = await tool.run(block.input as Record<string, unknown>); toolResults.push({ type: "tool_result", tool_use_id: block.id, content: result }); } catch (err) { toolResults.push({ type: "tool_result", tool_use_id: block.id, content: String(err), is_error: true, }); } } messages.push({ role: "user", content: toolResults }); } console.error(`iteration limit (${maxIterations}) reached`); } </code></pre> Walk through it once. We start with the goal as the first user message. We call the model. We append the model’s response to the conversation. If the model says end_turn</code>, we print the final text and return. If the model says tool_use</code>, we find the requested tool, run it, and append the result as a user-role tool_result</code> block. The model sees the result on its next turn and decides what to do. The for</code> loop with maxIterations</code> is the only thing standing between this agent and an unbounded run. We will spend a chunk of post sixteen</a> on whether iteration counts are the right budget unit. They are not, but they are the simplest. Start with the simplest. The entry point is two lines. // agent.ts (continued) const goal = process.argv.slice(2).join(" "); if (!goal) { console.error("usage: bun agent.ts '<goal>'"); process.exit(1); } await run(goal); </code></pre> That is the entire agent. Around one hundred and forty lines of code with the imports and the system prompt. It is a real agent by the definition we started with. It has a goal, a model, context (the system prompt and the running message list), tools (one of them), and a loop (the for</code> with maxIterations</code>). Running it</h3> A small transcript makes the loop concrete. $ bun agent.ts "what is the largest TypeScript file under src and what does it do?" > shell {"command":"find src -name '*.ts' -type f -printf '%s %p\n' | sort -nr | head -5"} > shell {"command":"wc -l src/agent.ts"} > shell {"command":"head -40 src/agent.ts"} The largest TypeScript file under src is src/agent.ts at 4837 bytes (150 lines). It implements an agent loop against the Anthropic Messages API. It defines a single shell tool, sends the user's goal to the model, executes any tool calls the model requests, feeds the results back, and stops when the model returns an end_turn response or the iteration budget of 10 steps is exhausted. </code></pre> The lines prefixed with ></code> are the agent’s tool calls, logged from the console.error</code> in the loop. The final paragraph is the model’s end_turn</code> text. Three tool calls, one final answer, one closed loop. You have an agent. Why most agent demos are not agents</h2> Now that the definition is concrete and you have a working example, the question of what is and is not an agent becomes useful. The honest version of the answer is in the table. System</th> Goal</th> Model</th> Context</th> Tools</th> Loop</th> Verdict</th></tr></thead> ChatGPT, 2022 launch</td> Y</td> Y</td> Y</td> N</td> Y</td> Chatbot</td></tr> ChatGPT today (browse, code, files)</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> Cursor’s inline edit</td> Y</td> Y</td> Y</td> Y</td> N</td> Completion</td></tr> A GitHub Actions workflow</td> Y</td> N</td> Y</td> Y</td> Y</td> Workflow</td></tr> A pure retrieval-augmented chat</td> Y</td> Y</td> Y</td> N</td> Y</td> Chatbot+RAG</td></tr> A function-calling API call</td> Y</td> Y</td> Y</td> Y</td> N</td> Tool call</td></tr> Claude Code in the terminal</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> The script in this post</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> Auto-GPT, BabyAGI</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> OpenClaw</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> A Temporal workflow with an LLM step</td> Y</td> Y</td> Y</td> Y</td> Y</td> Agent</td></tr> </tbody></table> The first two rows are the same product two years apart. ChatGPT launched in November 2022 as a chat window with no tools. Today the same web UI can browse the live web, run Python in a sandboxed runtime, convert and read PDFs, and generate images. It crossed the line. The interesting thing is that the user-facing language did not change. It is still called a chatbot. Under the definition we are working with, it is an agent. The boundary moved underneath the marketing. That is the pattern to expect across the industry over the next two years. Every chat product will quietly grow tools. Every workflow product will quietly grow a model. The labels will lag the architecture by a year or two. If you only listen to the labels, you will miss the moment a system becomes something you should be governing differently. The pure RAG row is the one that does not cross. A retrieval-augmented chat that only enriches its own context does not get tools in the sense that matters. The model cannot decide to do something different based on what it finds. It just answers from a richer context. Useful, sometimes excellent, not an agent. The moment that same system gains a “search again with a different query” or “fetch this document” tool, it is. The Temporal-with-LLM row is interesting for the opposite reason. That is an agent. It is also a workflow. The two categories are not mutually exclusive. Post seventeen</a> will explain why the production version of almost every agent ends up wrapped in a durable workflow. The point of the table is not to gatekeep the word. It is to point at the conceptual distinction. A chatbot fails by being uninformed. An agent fails by acting wrong. Once your system can act, the failure mode changes, and so does what you owe the operator. Failure modes</h2> The script above will work the first ten times you run it. Some of the failure modes it has are obvious. Some you only see in production. The honest list, in roughly the order you will hit them. Infinite loops disguised as progress. The model can call tools forever without converging. maxIterations = 10</code> saves you from your own demo today. It will not save you when somebody asks a harder question tomorrow. Real budgets are token-based or wall-clock-based, not step-based. We will fix this properly in post sixteen</a>.</li> Cost runaway. Every iteration is a full model call with the entire conversation as input. The token cost grows roughly quadratically with the number of steps because each new turn re-sends every prior turn. A ten-step loop costs more than ten times a one-step call. Prompt caching helps. Smaller models for the cheap turns help more. We will spend post eighteen</a> on this.</li> Lying about success. The model can claim it completed the task without actually verifying. The shell tool does not check whether the answer is correct. You can ask “did you do X?” and get “yes” when the truth is “I tried, it failed, I gave up.” Evals exist for this. Post sixteen</a> explains them.</li> Broken tool output. If a tool returns a megabyte of binary data, the model will choke or hallucinate. Tool outputs need to be summarized, truncated, or schema-shaped. The agent will not do this for you.</li> No isolation. The shell tool will run rm -rf $HOME</code> if the model decides that is the right command. The model will not decide this often. It will decide it at least once. That is the topic of the next post.</li> Hidden state. Every tool call has side effects on the runtime. Files get created. Network calls get made. Database rows get inserted. The conversation log does not capture any of it. You can replay the model’s reasoning. You cannot replay the world it was reasoning about. Idempotency and durable execution are how serious systems handle this.</li> Concurrency edge cases. This loop is sequential. The model can ask for multiple tools in one turn, and the example above runs them in order. If two of those tools both want to write the same file, you have a bug the model cannot see.</li> </ul> None of these are reasons not to build an agent. They are the reasons the rest of this series exists. What this post left out on purpose</h2> A long post still leaves things out. The intentional omissions, with pointers to the posts that pick them up. Isolation. The shell tool is dangerous. Fixed in post two: Your Agent Wants Root</a>.</li> A real tool registry. One tool is the demo. A useful agent has four to a dozen. Covered in post three</a>.</li> Context strategy. The system prompt is a paragraph. Real systems load context from disk and shape it per task. Covered in post four</a> and post five</a>.</li> Memory across sessions. The agent forgets everything between runs. Covered in post six</a>.</li> Model selection. We hardcoded one model. Production agents route. Covered in post seven</a>.</li> Tool protocol. The tool interface is bespoke. The industry converged on MCP. Covered in post eight</a>.</li> Frameworks. We built this raw. The framework conversation is in post nine</a>.</li> Identity, evals, durability, economics, governance. All of arc four and five.</li> </ul> If you read the table of contents for the series you can see the shape: every post in the rest of the series fixes one limitation of the agent you just built. Where this lands in the platform</h2> The diagram at the top of this post is the smallest box in the eventual reference architecture. The agent loop sits inside a runtime. The runtime sits inside a fleet. The fleet sits inside a platform with identity, observability, governance, and a control plane. The shape we end up with in post twenty-two</a> is the same shape we started with, blown up to enterprise scale, with every component opened up and given its own production-grade story. You can hold the whole series in your head with a single rule. Each post adds one layer of the stack and explains why the layer below was not enough on its own. The next layer up is the runtime. The shell tool you just gave a frontier model is a loaded gun. Next week we explain how to point it somewhere safe. Next</h2> Part 2: Your Agent Wants Root</a>. Why a Docker container is not enough, and what Firecracker, gVisor, and Kata actually solve. Publishes Thursday. The Field Exists Now Unknown — Fri, 22 May 2026 00:00:00 +0000 Alasdair Allan, the creator of Vera</a>, has started a public catalogue at agentlanguages.dev</a>: programming languages designed for AI agents to write. When he mentioned it to me on LinkedIn, the count was twenty-one. When I checked, the site already listed twenty-eight. That pace is the point. Six months ago, the idea that programming languages would bend around AI authorship still sounded like a late-night compiler conversation. Now there is a catalogue, a taxonomy, and enough independent projects to argue about the shape of the field without pretending the field is hypothetical. That is a real change. The taxonomy is better than my timeline</h2> In The Last Programming Language Might Not Be for Humans</a>, I described three futures: explicit languages stripped of ambiguity</li> declarative languages where types act as proof obligations</li> no language at all, where the prompt is the specification and the executable is the product</li> </ul> I still think that direction of travel is useful. The long arc points away from source code as the thing humans primarily edit, and toward artifacts that agents generate, compilers check, runtimes execute, and other agents can trust. But Alasdair’s taxonomy is cleaner for describing the field as it exists today. He splits it into three camps: syntactic, where the problem is representational ambiguity</li> verification, where the problem is semantic correctness</li> orchestration, where the problem is agent coordination</li> </ul> That framing is less linear and more honest. Vera and my Haskell work are not step one and step two. They are two near-term answers to the same pressure. That correction matters because it changes what we should measure. If the field is a timeline, the question is which phase arrives next. If the field is a set of camps, the question is which diagnosis is right for which workload. That is a much better question. Vera and BHC are adjacent, not sequential</h2> One useful correction: Raskell is not the project. Raskell is this blog. The relevant projects are hx</a> and BHC, the Basel Haskell Compiler, both under arcanist.sh</a>. hx is the tooling layer. BHC is the compiler layer. That distinction matters because the bet is not “invent Raskell as a new AI language.” The bet is that Haskell already has much of the semantic shape we need, and that the missing layer is tooling, runtime control, diagnostics, and compilation strategy. Vera takes a more bespoke path. It asks what a language should look like if it is designed for models from first principles. That leads to mandatory contracts, typed effects, solver-backed verification, and De Bruijn-style slot references instead of variable names. That is a serious design. I like it because it does not just say “AI will write code” and stop there. It changes the language around that claim. BHC starts from the other side. It assumes Haskell’s purity, type system, and compositional style are already close to the right substrate for AI-written software. The weak points are around the compiler and the experience around it: how fast the loop is, how clear the errors are, how reproducible the build is, how explicit the runtime profile is, and eventually how much semantic information survives into numeric and GPU-oriented lowering. So I do not think Vera and BHC compete for the same idea. They may compete for attention, mindshare, or some future market. But intellectually they are adjacent. Vera says: design the language around the agent. BHC says: make the semantically rich language operationally good enough for the agent era. Both are verification-camp bets. Why the verification camp is crowded</h2> The most interesting thing in the catalogue is how crowded the verification camp is. That should not surprise us, but it still does. Once you work with coding agents every day, the failure mode becomes obvious. The problem is not that the model cannot type syntax. It can type syntax just fine. The problem is that plausible code is cheap, and plausible code is often wrong. That changes the job of the language. A language for AI-authored code does not need to make the model feel clever. It needs to make wrongness cheap to detect. Ideally before runtime. Ideally before deployment. Ideally in a form the model can consume and repair. That is why contracts, effects, refinement types, strong type systems, proof export, SMT solvers, and structured compiler diagnostics keep showing up. These are not aesthetic choices. They are different ways of building a feedback loop around a generator that will always be probabilistic. The generator does not need to be trusted. The artifact needs to be checkable. That sentence is probably the center of the whole field. The market is less interesting than the artifact</h2> There will be a temptation to turn this into a market map too early. Which language wins? Which toolchain gets adopted? Which one has the most stars? Which one gets bundled into an IDE or agent framework first? Those questions matter eventually. They do not matter most right now. The important question is what the unit of software becomes when the author is no longer primarily human. My answer, in Source Code Is the New Assembly</a>, was that source code becomes one rendering of a richer semantic artifact. The agentlanguages.dev catalogue strengthens that view. The syntactic camp is trying to make the text representation easier for models to manipulate. The verification camp is trying to make the artifact easier to prove correct. The orchestration camp is trying to make agent work easier to sequence, constrain, and audit. Those are not disconnected concerns. They are different surfaces of the same object. If agents are going to generate software that matters, the artifact has to carry more than instructions. It has to carry constraints, effects, provenance, trust boundaries, and execution intent. Source code can be part of that. It cannot remain the whole thing. Where BHC fits</h2> BHC’s long-term target is not just “AI writes Haskell.” That is too small. The more interesting target is verifiable compute expressed through a functional, semantically dense language and lowered into the right execution profile. Sometimes that means ordinary native code. Sometimes WebAssembly. Eventually, for the numeric profile, it should mean GPU-oriented compute where the compiler can preserve enough structure to reason about what is being executed. This is the part that keeps pulling me back to Haskell. Functional purity is not just beautiful. It is useful. It makes dependencies visible. It makes transformations local. It reduces the hidden state an agent has to simulate. It gives the compiler more leverage. It gives verification machinery more structure. And Haskell is verbose in exactly the right places. Not verbose like boilerplate. Verbose like meaning. Type signatures, algebraic data types, explicit transformations, pure functions. These are things an agent can generate, a compiler can check, and a human can audit later when something matters enough to read. That is the bet behind BHC and hx. Not a new language for its own sake. Not Haskell nostalgia. A belief that semantic density becomes more valuable when generation gets cheap. What the catalogue proves</h2> The catalogue does not prove which camp is right. It proves the pressure is real. Independent people arrived in the same neighborhood at roughly the same time, using different words and different tools. That usually means the underlying constraint changed. In this case, the constraint is authorship. The old language design question was: what can humans write, read, and maintain? The new question is: what can agents generate, compilers verify, runtimes constrain, and humans audit when needed? That does not make human readability irrelevant. It changes its position. Human readability becomes part of auditability, not necessarily the primary authoring constraint. That is the shift agentlanguages.dev makes visible. The field exists now. It has camps. It has disagreements. It has projects with code, projects with papers, projects with benchmarks, and projects that are still mostly intent. That is fine. Early fields are messy. The useful thing is that we can stop arguing about whether the category is real and start arguing about which claims survive measurement. That is where the work gets interesting. Source Code Is the New Assembly Unknown — Thu, 07 May 2026 00:00:00 +0000 In The Last Programming Language Might Not Be for Humans</a>, I argued that if AI becomes the primary author of code, the source language has to bend around that author. In What Comes After the Last Programming Language</a>, I extended the argument one layer down: even the operating system still assumes a human is writing CPU-centric instruction streams, and that assumption has an expiration date. I left the deepest move for last on purpose. If languages are bending and operating systems are bending, it is because something more fundamental is bending. The unit of software is changing. The thing we treat as authoritative, version, review, ship, replay, and audit, is on its way to becoming something other than a tree of source files. I want to make that move explicitly. This is the post where I plant the flag. What I am actually claiming</h2> The clearest way I can put it is this: programming languages were never the destination. They were a writing system for an era when humans had to author the syntax. They survived because humans were the bottleneck, and the machine had to be addressed through a human-legible medium. That arrangement is starting to come apart. Once generation is cheap, syntax is not the scarce resource anymore. The scarce resource is semantic stability. What I want is not a better language for models to type. I want an artifact that preserves meaning across generation, verification, lowering, execution, audit, and replay. I will call that thing a semantic artifact, and I will call the machine around it a meaning engine. Both terms exist in adjacent literatures already. I am using them deliberately, not as branding. A semantic artifact is the new unit of software. The meaning engine is what compilers and runtimes become when they accept those units. Source code does not vanish in this picture. It demotes. It survives the way assembly survives today: indispensable, specialized, and no longer the layer most people author. That is the full claim. The rest of this post is the case for it. Programming languages were always writing systems</h2> There is a reflex in our field to treat programming languages as if they were a category unto themselves. They are not. They are a specialized branch of writing. Writing, in linguistics, is a technology for making language visible and durable. It is a system of conventional marks that encodes linguistic structure in a persistent medium. It is not thought itself. It is not even speech. It is a representation that allows institutions, tools, and machines to act on language across time and space. Programming languages fit this definition without strain. They are notation systems that encode executable intent in marks a compiler can consume. Like every writing system, they were shaped by the dominant author and the dominant medium of their era. Assembly is the closest thing we have to a logographic system for computation. Each opcode points at one specific machine action. There is no abstraction between the symbol and the execution. C is structured prose for systems work, designed when the author was a competent human engineer and the target was a single-CPU machine with byte-addressable memory. Python is a writing system tuned for readability and velocity, designed for an author who would rather get to the point than negotiate with the type system. Haskell pushes in the other direction, toward formal logic notation, where the writing system itself encodes proof obligations. Every one of these languages is a compromise between precision and expressiveness. None of them was final. Each was tuned to what humans could reasonably author and what compilers could reasonably lower. Once you see this clearly, the historical contingency becomes obvious. Source code is not sacred. It is a notation layer that won because humans had to write something, and machines had to lower something. It became the universal artifact of software because the author was human and the medium was text. Change the author, and the universal artifact has no reason to stay text. This is the same observation Unison</a> has been making in production for years, just from a different angle. Unison stores definitions by the hash of their structured form, not by filename. Text is a view, not the artifact. The system has not gone post-code. It has gone post-text, while keeping code as the underlying object. That is a useful first step, and it is much more than a curiosity. It is a working proof that the source file is not load-bearing in the way our tools pretend it is. Code is a lossy compression of intent</h2> The thing programmers do, when we write code, is compression. We take a high-dimensional, contextual, often-ambiguous understanding of what the system should do, and we squeeze it into a rigid, linear, explicit sequence of statements that a compiler will accept. The compiler then performs a different compression, from our notation down to machine code. By the time the binary runs, several lossy passes have happened. Assumptions live in our heads or in a README. Side effects live implicitly in function calls. The reasons we made certain decisions live in commit messages, ticket systems, or, more often, nowhere. The artifact that runs is missing most of the meaning that produced it. We know this is lossy because we spend enormous effort patching the loss. We write tests to recover behavioral intent. We write documentation to recover design intent. We write architecture decision records to recover historical intent. We write runbooks to recover operational intent. We sprinkle assertions to recover invariants we could not express in the type system. We add observability to recover what the running program is actually doing because the source did not say. Programming, in this view, is manual compression of intent into executable form. It worked because the human author could hold the uncompressed version in their head while typing the compressed version. It also worked because the compressed version was good enough to ship and the uncompressed version did not have to survive review. AI changes the economics of that compression. Generation gets cheap. Expansion from a few sentences to thousands of lines of code is no longer the hard part. What gets relatively more expensive is the part that was always implicit: deciding which version is correct, which assumptions are still valid, which constraints must hold, which environments will give the same result, which side effects are allowed. In a world with cheap generation, the uncompressed version is what we should be authoring. Not the compressed one. What a semantic artifact actually is</h2> A semantic artifact is not a fancier source file. It is not “code with metadata.” It is a different kind of object, with different properties, and the difference matters. A semantic artifact is intent-first. It says what must hold, not how. It can carry “how” as one of several lowerings, but the upper layer is the obligation, not the implementation. It is structured. It is a typed graph of entities, constraints, transformations, effects, evidence, and provenance. Text is one rendering. JSON is another. A diagram is another. None of them is the artifact. It is content-addressed. Identity is structural, derived from the artifact itself, not from a filename or a path. Two artifacts with the same meaning have the same identity. This is the lesson Unison teaches and the lesson the rest of the industry has not fully absorbed. It is explicit about effects. Reads, writes, time, randomness, network, ledger postings, model inference, file system access, are all declared. Effects are part of the type, not lurking inside a function body. Koka and Vera both make this argument from the language side. A semantic artifact takes the same idea seriously enough to make it part of the artifact identity. It is verifiable. It carries obligations: properties that must hold, invariants that must be preserved, preconditions on inputs, postconditions on outputs. Some of these are dischargeable by SMT solvers. Some need proof kernels. Some can only be enforced at runtime. The artifact records which is which, and what evidence exists for each. It is reproducible. It declares its environment with enough precision that a meaning engine somewhere else, or the same meaning engine a year later, can replay it and get the same outputs. Wasm with the deterministic profile, Nix-pinned environments, content-addressed inputs, deterministic schedulers, this is the substrate that makes reproducibility a property rather than a hope. It is explainable. Execution emits a provenance graph. What ran, on what data, in what environment, with what assumptions, against what obligations, with what residual uncertainty. The provenance is part of the output, not a log file someone deletes after a week. The thing to notice about that list is that none of these properties is exotic. Every one of them already exists in some production system today. What does not exist yet is the synthesis. We treat them as add-ons around code. The argument I am making is that they are not add-ons. They are the artifact, and code is one rendering of it. The meaning engine</h2> If the artifact changes, the machine around it has to change too. Compilers were built for source text. Runtimes were built for binaries. Neither was built for typed, verifiable, provenance-rich semantic objects. The meaning engine is what fills that gap. I am using the term as a placeholder for a category, not for a single product. A meaning engine accepts a semantic artifact and: Elaborates it. Resolves references, links schemas, grounds entities, checks types and effects.</li> Verifies it. Discharges obligations against the right backend. Type checks first. SMT for decidable arithmetic and structural constraints. Proof kernels for the residual cases that need full mathematical certainty. Runtime contracts for the cases nothing else can decide.</li> Plans execution. Picks an environment. Pins a target. Chooses where to run, on what hardware, with what capability set.</li> Lowers to code. Wasm, native CPU, GPU kernels, distributed dataflow graphs, whatever the planner decided. Code becomes an output, not an input.</li> Executes deterministically. Capability-bounded, replayable, audited.</li> Explains. Emits a provenance graph alongside the result. Says what assumptions held, what proofs passed, what tests ran, what fell back to runtime checks, what remained uncertain.</li> </ol> The interesting reframing is the compiler itself. The old job of a compiler was to translate one notation into another. The job of a meaning engine is to materialize meaning into execution and to keep meaning intact across that materialization. Translation becomes a sub-task. The primary task is preservation. The semantic intermediate representation is where this lives or dies. I do not think the answer is “use LLVM IR with more comments.” LLVM IR is too low. It is already shaped around the mechanics of execution. We need a layer above it that carries domain meaning, obligations, and effects with first-class status. MLIR</a> is the most relevant existing infrastructure for this. It treats multi-level structure as the design center: dialects, regions, operations, progressive lowering. A meaning engine could plausibly use an MLIR-style dialect stack with a semantic dialect at the top and execution dialects at the bottom. That is an implementation question, not a thesis question, and I want to keep the two separate. A scientific experiment as an executable artifact</h2> Abstract claims about new artifacts age badly. The argument has to survive contact with concrete domains. The first place I would point is science. Take a differential expression analysis from RNA sequencing. Today, the artifact that runs is some combination of: a Snakemake or Nextflow workflow, a Conda environment file, a few R scripts, a Jupyter notebook with the figure-generation logic, a README that explains how to run it, and a PDF describing the methods for the eventual paper. The “program” is spread across all of these, and the relationships between them are mostly informal. People have been trying to fix this. The Common Workflow Language</a> standardizes the workflow part. RO-Crate</a> packages methods, data, outputs, and identifiers together. PROV-O</a> gives you a vocabulary for entities, activities, and agents. These are real progress, and they show that the field has been edging toward semantic artifacts for years. What is still missing is a single authoritative object that also carries assumptions, allowed environments, correctness obligations, and execution traces in one verifiable form. A semantic artifact for the same analysis would look more like this: artifact RNASeqDiffExp.v3 inputs { reads: FASTQ[] reference: GenomeRef alpha: Real where 0 < alpha <= 1.0 } assumptions { sha256(reference) == "9f8c1a..." paired_end(reads) same_instrument(reads) } outputs { counts: CountTable figures: FigureSet } effects { fs.read("reads/", "reference/") fs.write("results/") cpu.simd gpu.optional } obligations { deterministic_target = "wasm32-wasi" environment = "nix:sha256-7m..." p_adj_threshold(counts) <= alpha } plan { trim -> align -> quantify -> diffexp -> render } </code></pre> The syntax above is illustrative. The shape is the point. What this artifact gives you that a workflow file plus a README does not: a reviewer can inspect the assumptions directly. A lab can replay the artifact against the pinned environment and reproduce the figures byte for byte. An auditor can ask whether GPU execution changed numerical behavior and get a defensible answer. A future model can propose an optimization, and the meaning engine can reject the optimization automatically if it weakens any obligation. The provenance graph it emits is the methods section of the paper, machine-checkable, not a paragraph somebody wrote at midnight before submission. The artifact does not have to make every claim machine-decidable. It only has to make explicit which claims are decided how. That is already a significant improvement over the current state, where most of those distinctions live in tribal knowledge. A contract as an executable artifact</h2> The second domain I would point to is the one where words and computation already overlap uncomfortably: legal and financial agreements. There is real prior art here. The Accord Project</a> models contracts as text plus a data model plus executable logic. The Common Domain Model</a> treats financial products and lifecycle events as machine-readable, machine-executable domain objects. Smart contracts, in their actual industrial form rather than the crypto-bro form, have been heading in this direction for a decade. The honest statement is that legal language will never be fully decidable. Many clauses are intentionally ambiguous. Many require human judgment. That is not a bug. It is how the institution works. But a semantic artifact does not require full decidability. It requires that the boundaries between decidable and undecidable be explicit. Some clauses become parameters. Some clauses become executable logic. Some clauses remain text with cross-references into the structured part. The artifact records which is which. contract FixedRateLoan.v1 parties { lender, borrower } terms { principal: Money where principal > 0 rateAPR: Percent where 0 <= rateAPR <= 0.25 termMonths: Nat where termMonths > 0 } preconditions { kyc_clear(borrower) sanctions_clear(borrower) } obligations { monthly_payment(m) = amortize(principal, rateAPR, termMonths, m) total_paid = principal + total_interest(principal, rateAPR, termMonths) } effects { ledger.post notice.send archive.write } evidence { jurisdiction = "CH" execution_target = "wasm-ledger" text_reference = "Loan_2026_03_15.pdf#sha256:4b2a..." } </code></pre> A loan agreement, in this form, is verifiable in the parts that should be verifiable, executable in the parts that should be executable, and traceable back to the natural-language contract for the parts that are not either. A bank can check on every payment that the obligations still hold. An auditor can ask why a specific posting happened and get a provenance graph that points back to the artifact and the inputs. A regulator can require a class of contracts to demonstrate certain invariants without reading every contract by hand. This is a much more serious model of “smart software” than the casual conflation of code with policy that the smart-contract era encouraged. The point is not that every rule becomes automatic. The point is that the system can tell you, without ambiguity, which rules it can enforce, which rules it can only check, and which rules a human still has to interpret. What current systems already get right</h2> I want to be careful here, because the easy mistake is to write this kind of essay as if nothing existing matters and everything has to be invented from scratch. That is wrong. Most of the pieces of a meaning engine already exist. They are scattered across systems that solved one face of the problem each. The synthesis is what is missing. Vera</a> optimizes for the generation loop. It makes syntax canonical, contracts mandatory, effects explicit, verification part of the normal compilation pipeline, and Wasm the default execution target. It is, in my framing, the best current example of “language designed for machine authorship.” It is not yet a meaning engine because the source text remains the artifact of authority. But the discipline it imposes on the artifact is exactly the discipline a semantic artifact needs. BHC</a> (the bridge Haskell compiler I have written about elsewhere) optimizes for the typed substrate and the deployment surface. Multi-stage IRs, a Core layer that survives across lowerings, profile-specific runtime contracts, multiple backends from native to Wasm to GPU. It treats semantic preservation across lowering as a first-class goal, which is the exact discipline a meaning engine needs at the lowering layer. It is still source-language-centered, by design. That is its scope. Dafny</a> and Lean</a> push hardest toward proof-bearing semantics. Dafny puts specifications inside the language and uses SMT to discharge them. Lean has a minimal trusted kernel and builds proof automation on top. They show what the upper bound of “verified meaning” looks like in practice. They are not yet the substrate for cross-domain artifacts, deterministic deployment, and provenance packaging, but they set the standard for what the verification layer of a meaning engine should aspire to. Koka</a> and similar effect-typed languages show that you can keep effect information at the type level without giving up performance. Effects in the type signature, not just in the function body. That is the model the artifact needs at the meaning layer. MLIR</a> shows that a multi-level dialect stack is a workable architecture for keeping high-level structure across lowering. A semantic IR sitting above MLIR-style dialects is a plausible engineering path. Wasm</a> and WASI</a>, with the recent deterministic profile</a> work and tooling like Wasmtime’s determinism guide</a>, give us a portable, sandboxed, increasingly deterministic execution target. This is the substrate that makes “replay this artifact and get byte-identical outputs” feasible without operating-system heroics. Nix</a> gives us declarative, reproducible, isolated environments. The pinning story is mature. The integration story is still rough. But the building block is real. PROV-O</a>, RO-Crate</a>, and CWL</a> give us standards for provenance, packaging, and portable workflows, particularly in the scientific domain. They are evidence that “explainability as a structural property of the artifact” is not science fiction. It is the way some communities already work. Unison</a> gives us content-addressed, structured code identity. This is the lesson the rest of us still have not fully internalized: identity should not depend on filenames or formatting. If I were to draw the comparison shortly: Vera optimizes the generation loop. BHC optimizes the typed substrate. Dafny and Lean optimize formal truth. Wasm and Nix optimize deterministic deployment. PROV and RO-Crate optimize provenance. Unison optimizes structural identity. None of them is the future on its own. The future is the synthesis. From compilers to meaning engines</h2> The reframing I find most useful is to put the old pipeline next to the new one and look at what changes. Old pipeline ============ source code -> compile -> binary -> run New pipeline ============ intent | v elaborate ---> semantic artifact | (typed, content-addressed, | effects explicit) v verify ---> obligation graph | (proved | tested | runtime) v plan ---> execution plan | (env pinned, target chosen, | capabilities bounded) v lower ---> Wasm | native | GPU | distributed | v execute ---> results | v explain ---> provenance graph</code></pre> Every stage matters, and every stage has explicit outputs. Elaboration produces a fully grounded semantic artifact. Verification produces a graph of discharged and residual obligations. Planning produces a deterministic execution plan with a pinned environment and a capability set. Lowering produces target-specific code as one of several possible outputs. Execution produces results plus a provenance graph. Explanation reads the provenance graph and answers questions about why the system did what it did. The execution trace becomes a first-class output, not a side effect. Today, a stack trace exists because something went wrong. In a meaning engine, an execution trace exists because something happened, and the system promises to be able to reconstruct it later. The compiler does not disappear. It moves. It becomes one stage of a larger pipeline, and the pipeline is what people interact with. Why this is bigger than programming</h2> I want to zoom out for one section, because the trilogy has been quietly building toward a claim that is not really about programming languages at all. Writing systems have changed several times. Oral tradition gave way to written records. Manuscripts gave way to print. Print gave way to digital text. Each transition expanded the scale and durability of what humans could record, distribute, and act on collectively. Each transition reshaped institutions in ways that took decades to settle. We are in the early phase of another transition. We are moving from systems that record knowledge to systems that execute knowledge. A scientific paper is a record. A semantic artifact for a scientific experiment is an execution. A legal contract is a record. A semantic artifact for a financial product is an execution. An infrastructure runbook is a record. A semantic artifact for the same operational behavior is an execution. This is the civilizational layer of the argument, and I am stating it deliberately even though it is uncomfortable. The shift from text-as-record to text-as-execution will be at least as large as the shift from manuscript to print. It will not be the same as previous transitions, because it is happening on infrastructure we built and partially understand, not on infrastructure that emerged organically over centuries. But the order of magnitude is similar. If that framing is even half right, “what programming language should we use” is a small question. The big question is what kinds of institutions we are willing to build on top of artifacts that are themselves executable. The role of humans</h2> If we do not write code, what do we do? This is a fair question, and I want to answer it directly rather than dodge it. We define constraints. We shape intent. We evaluate outcomes. We design systems of meaning. We argue about which obligations matter and which assumptions are reasonable. We negotiate the boundaries between automated and human-decided parts of an artifact. We decide which evidence is acceptable and which is not. This is a different job. It is closer to architecture than to authorship. The unit of work is the obligation, not the function. For people who like writing code, this is going to feel like a loss. I understand. I like writing code too. But the historical pattern is clear. Each abstraction layer demoted the layer below it from “primary skill” to “specialized skill.” Assembly programming did not disappear when C arrived. It became the thing a small number of people did when it really mattered, in compilers, in kernels, in performance-critical hot paths. The same is going to happen one layer up. Most people will stop authoring code as the primary artifact. Some people will keep doing it, where it really matters, and they will be more important to the field, not less. The work that gets more interesting, in this picture, is the work of building meaning engines themselves. The substrate is wide open. There is room for many designs. The decade ahead is going to look more like the early compiler era than like the late framework era. That is a good time to be working on infrastructure. Implications for builders right now</h2> The migration is staged. The way I think about the timeline: Near term Medium term Long term (now) (2-3 years) (3-10 years) Semantic -> Artifact core -> Multi-target sidecars lowering - specs beside - content- - Wasm/WASI first the code addressed - native CPU - pinned envs identity - GPU kernels (Nix) - typed effects - distributed DAGs - provenance - obligation (PROV-O) graphs Artifact-first - deterministic - graded domains replay (Wasm) verification - science - contracts Improve auditability Make the artifact - infra policy without abandoning the review surface - audit/compliance the current stack</code></pre> I do not want to leave this post in the air. The trilogy has been escalating, and each step has been more speculative than the last. This post is the most speculative of the three. It is fair to ask what any of this implies for what we should be doing in 2026, not in 2036. A few things I think are already actionable. Take semantic sidecars seriously. If you are shipping software in any regulated or critical domain, you can already start writing artifact manifests that bind your code to its assumptions, its allowed effects, its pinned environment, its provenance, and its replay instructions. You do not need a new compiler to do this. You need discipline and a few tools that already exist. Nix and Wasm are good starting points. PROV-O is a usable vocabulary. The investment compounds. Treat reproducibility as a property, not a hope. If you cannot replay your artifact deterministically, you do not have a semantic artifact. You have a hope. Wasm with the deterministic profile, Nix-pinned environments, content-addressed inputs, and deterministic schedulers are the building blocks. The cost of getting there is real but bounded, and the gains in audit, debugging, and incident response are immediate. Make effects explicit. You do not need a new language to do this. You can do it with discipline in the language you already use. Module boundaries that separate pure from effectful code are not exotic, they are just unfashionable in some communities. The discipline is what matters. The syntax is downstream. Stop treating proof and test and observation as the same thing. They are not. A proven property, a tested property, and an observed property carry different weights. A meaning engine has to keep them separate. You can start keeping them separate yourself, in code review and in design review, today. Invest in IRs more than in syntax. The next decade of leverage is in the layer above LLVM IR and below user-facing source. If you are building tools for software development, this is where the interesting work is. The tooling that wins will preserve more meaning than today’s compiler stacks do. If you build infrastructure, the heuristic is simple. Anywhere your team is currently relying on “shell scripts plus a README plus a notebook plus a PDF plus tribal knowledge” to encode a process, that is a candidate for a semantic artifact. Pick one such process, and try to model it as an artifact instead of as a pile. Open questions I do not pretend to have settled</h2> I am stating the thesis confidently, but I want to be honest about what I do not know. I do not know the exact shape of the semantic IR. I have a bias toward an MLIR-style dialect stack with a semantic dialect at the top, augmented with effect typing, content-addressed identity, and explicit obligations. A content-addressed term graph in the Unison style is a credible alternative. A two-part design with a logical core plus an executable planning layer is another. The winning design is probably hybrid. I would rather present the question honestly than fake an answer. I do not know how much proof to demand before execution. Too much proof and the system is unusable. Too little and the artifact loses its claim to authority. Vera’s split between static proof and runtime fallback is realistic. Lean’s kernel model is the strongest, and the slowest. The right answer is graded, not absolute, and it will probably depend on the domain. I do not know how distributed execution fits in. Wasm gives us a portable substrate. WASI gives us a capability model. Content addressing gives us identity. None of these solves scheduling, data locality, and semantic replay across clusters. That is an implementation frontier, not a hole in the thesis, but it is a frontier and I want to flag it as one. I do not know which domains move first. My best guess is the domains that already pay most of the cost of ambiguity today: scientific workflows, regulated finance, compliance and audit, infrastructure policy, and certain parts of public-sector procurement. Domains where the gap between “what we wrote” and “what we ran” is currently catastrophic when something goes wrong. I would not be surprised if those domains develop their own meaning engines first, and a general-purpose substrate emerges as the synthesis a few years later. I do not know how long the migration takes. My only confident claim about timing is that it does not arrive by deleting today’s stacks. It arrives by moving semantics upward, year by year, until the artifact most teams care about is no longer a tree of source files. Closing</h2> We called them programming languages because we thought we were speaking to machines. In reality, we were translating ourselves into a form machines could tolerate. The notation was a compromise between what we could write and what they could lower. Now that machines can understand us more directly, the question is not how to write better code. The question is how to think in systems that can be executed. The artifact we author should preserve meaning, not perform it. The runtime should keep that meaning intact, not erase it during translation. Code does not disappear in this story. It drops a layer. It becomes implementation detail, escape hatch, optimization substrate, foreign-function boundary. Important. Powerful. Not primary. The trilogy ends here, in the same place each transition in computing has ended. The previous artifact survives, demoted, while a higher layer takes over the work of authority. Source code joins assembly in the long list of things that used to be the thing and now are something we lower to. The interesting work, for the rest of this decade, is at the layer above. That is where I am spending mine. Further reading</h2> The systems already pointing at parts of this future, grouped by the dimension each one gets right. Semantic IRs and structural identity. The argument that artifact identity should not depend on filenames, and that compiler stacks should preserve high-level structure across lowering, already has working precedent. MLIR</a> for multi-level dialect stacks</li> Unison</a> for content-addressed code</li> </ul> Verification. What it looks like to push specifications and proofs into the artifact, with three different bets on how strict the proof obligation should be. Dafny</a> for specs in the language, SMT-backed</li> Lean</a> for a minimal trusted kernel and proofs as terms</li> Vera</a> for Z3 on decidable cases and runtime fallback for the rest</li> </ul> Typed effects. The case for putting side effects into the type rather than hiding them in the function body. Koka</a> for row-polymorphic effects with handlers</li> Vera</a> for mandatory effect declarations on every function</li> </ul> Reproducible execution. What “the same artifact runs the same way somewhere else, a year later” actually requires in production. WebAssembly</a> and WASI</a> for portable, sandboxed, increasingly deterministic execution</li> Wasmtime determinism guide</a> for the concrete steps to byte-identical replay</li> Nix</a> for declarative, isolated, pinned environments</li> </ul> Provenance and packaging. The vocabulary for explaining what ran, on what data, in what environment, with what evidence. PROV-O</a> for entities, activities, and agents</li> RO-Crate</a> for artifact bundles with methods, data, and identifiers</li> Common Workflow Language</a> for portable, vendor-neutral workflows</li> </ul> Domain artifacts. The honest evidence that “software artifact” is too narrow a category for what comes next. Accord Project</a> for contracts as text plus data model plus logic</li> Common Domain Model</a> for financial products and lifecycle events as machine-readable, machine-executable objects</li> </ul> Patents Per Capita Is a Vanity Metric Unknown — Fri, 01 May 2026 00:00:00 +0000 It is the first of May, Labour Day. A holiday explicitly about work, which makes it a good day to ask whether the work that gets counted is the work that actually matters. Earlier this week I posted on LinkedIn about how Swiss innovation rankings tend to be illustrated with photos of Zurich, even though Basel produces a meaningful share of what those rankings reward. It performed better than most of my other shares there. Some of the feedback agreed. Some pushed back. Almost all of it stayed inside the same frame the rankings themselves set: which Swiss city deserves credit for the score. That is not the question I find interesting. The question I find interesting is what the score is measuring in the first place, and whether it is the score we should be optimising for. The LinkedIn format is not the right place to work that out. A long-form post on a Labour Day morning is. Switzerland topped the Global Innovation Index in 2025 for the fifteenth year in a row. The index is published annually by the World Intellectual Property Organization, the United Nations agency that administers the international patent system, and it ranks roughly 140 economies on how innovative they are. The 2025 press release went out in September. The country celebrated. Zurich’s skyline got photographed again. Roche and Novartis, the two Basel-headquartered pharmaceutical giants, were name-checked. ETH Zurich and EPFL, the country’s two federal technical universities, got their nods. The framing was the usual one: small country, outsized output, durable lead. I am Swiss. I am from Basel. I build infrastructure for a living, which means I spend a lot of time staring at dashboards that report how systems are performing in production. A number that sits at the top of a leaderboard for fifteen consecutive years should make any engineer who watches dashboards suspicious before it makes them proud. The metrics that look the smoothest the longest are usually the ones telling you the least about what is happening right now. This post is about why “most innovative country” is a vanity metric: a number that is real, and countable, and correlated with success, but that should not be the thing you optimise for. The Global Innovation Index measures yesterday extremely well. It does not measure today, and it tells you almost nothing about tomorrow. Traffic Replay as a Security Primitive Unknown — Mon, 27 Apr 2026 00:00:00 +0000 If you have ever tuned a WAF rule, you know the cycle. A rule triggers on legitimate traffic. You get paged. You look at the logs, which tell you the rule ID and the request path but not enough to reproduce what happened. You loosen the rule based on your best guess. You deploy. You wait. Next week, you get paged again, either because the rule is still too aggressive or because you loosened it too far and now something is getting through. The problem is not the WAF. The problem is that you are tuning a stateful, context-dependent system without the ability to reproduce the inputs that caused the behavior you are trying to change. You are debugging blind. This is not unique to WAFs. Every edge system that makes decisions about traffic, proxies, rate limiters, auth gateways, bot detectors, suffers from the same structural issue: the traffic that triggered the behavior is gone. It existed for the duration of the request, it was logged incompletely, and now you are making changes based on a partial reconstruction of what happened. Traffic replay solves this. Not as a testing tool. As a security primitive. What replay actually means</h2> Traffic replay, in the sense I mean it here, is not load testing. It is not generating synthetic traffic that looks like production. It is capturing real requests as they happened, in order, with their headers and bodies intact, and re-executing them against a target environment deterministically. The distinction matters. Load testing answers “can this system handle the volume?” Replay answers “will this system make the same decisions about the same traffic?” One is about throughput. The other is about behavior. A replayed request hits the same WAF rules, the same rate limits, the same routing logic as the original. If the original was blocked, you can see whether the replay is also blocked, and if not, exactly what changed. If you modify a rule and replay the same traffic, you get a direct comparison: old behavior versus new behavior, same inputs, different configuration. This is the primitive that WAF tuning has always been missing. Not better logs. Not more dashboards. The ability to say “here is the exact traffic that caused the problem, and here is what happens when I change the rule.” The capture problem</h2> The first obstacle is getting the traffic into a replayable format. Production traffic is ephemeral. It arrives, gets processed, and disappears. Logs capture metadata: timestamps, status codes, paths, maybe some headers. They do not capture the full request as a replayable artifact. There are two practical approaches. The first is capturing at the browser. Every modern browser can export a session as a HAR (HTTP Archive) file. This gives you the complete request and response for every HTTP transaction in a session: method, URL, headers, body, timing. When a user reports “this request was blocked,” you can ask them for a HAR export. You now have the exact traffic, not a description of it. The second is capturing at the proxy. If your reverse proxy or load balancer can mirror traffic to a capture endpoint, you get production-representative traffic without depending on user cooperation. This is more complex to set up but gives you continuous coverage rather than incident-by-incident captures. Either way, the result is the same: a sequence of HTTP requests that can be replayed faithfully. Replay is not as simple as resending</h2> There are subtleties that make naive replay useless. The obvious one is URLs. If you captured traffic hitting production.example.com</code> and want to replay it against staging.example.com</code>, you need to rewrite the host. But you also need to rewrite any absolute URLs in headers like Origin</code> and Referer</code>, and potentially in request bodies for APIs that include callback URLs. Then there are cookies. A replayed request with production session cookies will either fail authentication on staging (different session store) or, worse, succeed against a production session you did not intend to touch. Cookie stripping is not optional. It is a safety requirement. Headers need mutation too. You might need to inject an authorization token for the staging environment, or add a header that tells the WAF “this is a replay, do not count it toward rate limits.” You might need to strip headers that identify the original client IP to avoid polluting analytics. And ordering matters. If request B depends on state created by request A (a login followed by an authenticated action), replaying them in parallel or out of order produces meaningless results. Deterministic replay means sequential, in capture order, by default. None of this is algorithmically hard. But getting it wrong in any of these dimensions produces results that are misleading rather than useful. A replay tool that does not handle URL rewriting, cookie stripping, header mutation, and ordering is a footgun, not a primitive. The diff is the point</h2> Replay alone is useful. Replay with behavioral diffing is what changes the WAF tuning workflow. The pattern works like this. You have a set of captured traffic. You replay it against environment A (say, production with the current WAF rules) and save the results. You replay the same traffic against environment B (staging with the proposed rule change) and save those results. Then you diff. The diff is not a text diff. It is a behavioral diff. For each request in the capture, you compare: Status codes: did the same request get a 200 in one environment and a 403 in the other?</li> WAF decisions: did the WAF block in one and allow in the other? Which rule ID? What score?</li> Security headers: did CSP, HSTS, or X-Frame-Options change between environments?</li> Response characteristics: same content type? Same cache behavior?</li> </ul> Request: GET /api/v2/users?search=<script>alert(1)</script> Production (current rules): Status: 403 x-waf-action: block x-waf-rule: 941100 Staging (proposed rules): Status: 200 x-waf-action: pass x-waf-rule: (none) ⚠ WAF regression: XSS payload now passes </code></pre> This changes the WAF tuning conversation entirely. Instead of “I think loosening rule 941100 is safe,” you have “I replayed 2,000 captured requests against the proposed rule change. Three requests that were previously blocked are now allowed. Here they are. Two are false positives that should pass. One is an XSS payload that should not.” That is not a guess. That is evidence. Why this is a security primitive</h2> I use the word “primitive” deliberately. A primitive is a building block that other things compose on top of. Deterministic replay with behavioral diffing is a primitive because it enables patterns that are otherwise impractical: Safe WAF rule iteration. Change a rule, replay traffic, inspect the behavioral diff, deploy with confidence. The feedback loop goes from “deploy and hope” to “verify, then deploy.” This is the most immediate use case, and the one that solves the 3 AM pager problem. Environment drift detection. Replay the same traffic against staging and production on a regular schedule. When the behaviors diverge, you know something changed that should not have. This catches configuration drift, certificate mismatches, and routing differences before they become incidents. Regression testing for edge config. Every change to your proxy, WAF, or rate limiter configuration gets a replay run before deployment. The diff tells you exactly what changed in observable behavior. This is the edge infrastructure equivalent of a unit test suite, except instead of testing code you are testing policy. Incident reproduction. When a user reports a block, capture the traffic, replay it, confirm the block, and then iterate on the fix in staging without affecting production. The time from “user report” to “verified fix” drops from hours to minutes. Compliance evidence. When an auditor asks “how do you know your WAF rules are working?”, you can show them replay runs with behavioral diffs that demonstrate which rules triggered on which traffic patterns. Not “we have a WAF configured.” Verifiable behavioral evidence. Each of these patterns exists in some ad-hoc form at organizations that invest heavily in security tooling. What they lack is a common primitive that makes them systematic. What exists today</h2> There is no shortage of tools that touch parts of this problem. The gap is in how they compose. Manual security testing platforms. Burp Suite</a> is the standard. Its Repeater lets you capture a request and resend it with modifications, which is replay in the most literal sense. OWASP ZAP</a> provides similar capabilities as open source. Both are excellent for manual pen-testing: an engineer investigates a specific request, tweaks parameters, observes the response. What they do not do is automated, batch-level behavioral comparison across environments. You can replay one request in Burp and inspect the result. You cannot replay two thousand requests against staging and production and get a structured diff of every WAF decision that changed. The workflow is manual and investigative, not systematic and CI-integrated. Traffic capture and replay tools. GoReplay</a> (gor) captures live HTTP traffic and replays it against another environment. It is the closest existing tool to what I am describing, and it is good at what it does: mirroring production traffic to a staging environment for load and correctness testing. mitmproxy</a> can intercept, record, and replay HTTP flows with full scriptability. tcpreplay</a> operates at the TCP level for network-layer replay. The limitation across all of these is that they are replay tools, not behavioral analysis tools. They send the traffic. What happens next, comparing WAF decisions, diffing security headers, detecting regressions, is left to you. Desktop proxies. Charles Proxy</a> and Fiddler</a> capture and replay HTTP traffic with rich GUIs. They are useful for development debugging but are desktop applications, not CLI tools. They do not integrate into CI/CD pipelines or produce machine-readable behavioral diffs. Load testing tools. k6</a>, Locust</a>, Gatling</a>. These can replay captured traffic at volume, but they measure performance, not policy behavior. They answer “can the system handle the load?” not “did the WAF make the same decision?” WAF testing frameworks. ftw</a> (Framework for Testing WAFs) is the OWASP project for validating Core Rule Set behavior. It uses synthetic payloads designed to trigger specific rules. Nuclei</a> is a template-based vulnerability scanner that sends crafted requests and checks responses. Both are valuable for validating that your WAF blocks known-bad patterns. Neither replays real captured traffic, which means neither can tell you whether a rule change affects the legitimate traffic that your actual users send. API testing tools. Hurl</a> can chain HTTP requests with assertions, which is close to sequential replay with verification. curl</a> can resend individual requests. Both are useful building blocks but do not provide the capture-replay-diff workflow as a single primitive. The pattern across all of these is the same. Each tool handles one or two steps well: capture, or replay, or analysis. No single tool captures real traffic, replays it deterministically with URL rewriting and cookie stripping, and then produces a structured behavioral diff across WAF decisions, security headers, and status codes. The pieces exist. The composition does not. This is the gap that Ushio</a> fills. Ushio is a Rust CLI that does three things. It converts HAR files into a replayable capture format. It replays captures against one or more targets with URL rewriting, header mutation, and cookie stripping. And it diffs two replay results to identify behavioral changes in status codes, WAF decisions, and security headers. # Convert a browser HAR export to ushio format ushio convert session.har -o capture.json # Replay against staging with auth header, strip cookies ushio replay capture.json \ -t https://staging.example.com \ --header "Authorization:Bearer $TOKEN" \ --strip-cookies \ -o staging.json # Replay against production ushio replay capture.json \ -t https://prod.example.com \ --strip-cookies \ -o prod.json # Diff the results ushio diff staging.json prod.json --only-diff </code></pre> The output is either pretty-printed for human review or JSON for pipeline integration. Exit code 0 means no behavioral differences. Exit code 1 means differences were found. This makes it composable with CI/CD: run a replay diff on every edge config change, fail the pipeline if behavior regresses. What changes when you have this</h2> The shift is from reactive to proactive. Without replay, you discover WAF problems when users report them or when the pager goes off. With replay, you discover them before deployment. The feedback loop compresses from incident-driven to change-driven. But the deeper shift is epistemic. Without replay, WAF tuning is a matter of judgment and experience. You read the rule, you read the logs, you make a call. With replay, it is a matter of evidence. You replay the traffic, you observe the behavior, you make a decision based on what actually happened. I do not think this replaces judgment. You still need to decide whether a particular request that is now being allowed is acceptable. But the decision is grounded in concrete behavior rather than reconstruction from incomplete logs. The security engineer’s job changes from “guess what the WAF will do” to “observe what the WAF does and decide if that is correct.” Every edge system that makes decisions about traffic should be testable with real traffic. WAFs, rate limiters, bot detectors, auth gateways. If you cannot replay traffic and diff the behavior, you cannot systematically verify that the system does what you think it does. That is not a tooling problem. That is a visibility problem. And it is solvable. References</h2> Ushio</a> - Deterministic edge traffic replay tool</li> Zentinel</a> - Security-first reverse proxy with structured WAF decision logging</li> HAR 1.2 specification</a> - The HTTP Archive format</li> What Zentinel Is Really Optimizing For</a> - The operator-first proxy design philosophy</li> Notes from RSAC 2026</a> - Where the applied security thread connects to industry context</li> </ul> The Economics of Inference Unknown — Wed, 22 Apr 2026 00:00:00 +0000 In the previous article</a>, I described running sixteen AI agents as a virtual company over Christmas 2025. The architecture worked. The coordination model worked. What did not work was the economics. My token budget evaporated in days, not because the agents were unproductive, but because every act of coordination, every status update, every escalation consumed a metered resource that I could not replenish fast enough. At the time, I framed this as a budget problem. My consumer subscription could not sustain the overhead of agent-to-agent communication. An enterprise with API access and a real budget would not have the same constraint. That framing was correct, but it was also too small. What I was actually experiencing, at the scale of one person and sixteen terminal panes, was something much larger. I was experiencing inference as a utility. A consumed physical resource, the same way I consume electricity when I turn on a light and water when I open a tap. That framing changes everything about how you think about the economics of AI. What makes something a utility</h2> Utilities share a set of properties that distinguish them from ordinary goods and services. They are not optional. Modern life depends on them. They are consumed continuously, not purchased once. They require massive physical infrastructure to produce and deliver. They are metered. They are priced per unit of consumption. Their supply chains are subject to geography, geopolitics, and regulation. And their cost structure is dominated by the capital expenditure of building and maintaining the infrastructure, not by the marginal cost of the next unit delivered. Water. Electricity. Natural gas. Telecommunications. These are the four traditional utilities. Every modern economy is built on top of them. Their availability, reliability, and cost determine what is possible in a given jurisdiction. You do not build a semiconductor fab where the power grid is unreliable. You do not run a data center where the water supply for cooling is uncertain. The utility layer is the foundation, and everything above it is constrained by what the foundation can support. Inference is acquiring every one of these properties. It is consumed continuously. Every agent interaction, every model call, every token generated is a unit of consumption. When my sixteen agents were coordinating, they were consuming inference the way a factory floor consumes electricity: steadily, measurably, and in direct proportion to the work being performed. It requires massive physical infrastructure. The data centers running frontier models are among the most capital-intensive facilities being built anywhere in the world right now. They require advanced silicon, enormous quantities of power, water for cooling, and physical security. They are not software projects. They are industrial projects. It is metered and priced per unit. Every major inference provider charges per token. Input tokens, output tokens, sometimes with different rates for different capability tiers. The billing model is already a utility billing model. You pay for what you consume. Its supply chain is subject to geography and geopolitics. Chips, data, talent, energy</h2> At RSAC 2026, I attended a panel with four former NSA directors and US Cyber Command commanders. Paul Nakasone laid out what he considers the four factors that determine a nation state’s strategic potentiality in this era. Not GDP. Not military strength. Four things: chips, data, talent, and energy. I wrote about this</a> at the time. But I have been thinking about those four factors through a different lens since the shiioo experience. Nakasone was talking about national power. I am talking about the supply chain of a utility. Every utility has a supply chain that determines who can produce it, at what cost, and with what dependencies. For electricity, the supply chain is fuel (coal, gas, uranium, sunlight, wind), generation infrastructure (power plants, turbines, panels), transmission (the grid), and distribution (the last mile to your outlet). For water, it is source (rivers, aquifers, desalination), treatment, transmission (pipes, pumps), and distribution. For inference, the supply chain is Nakasone’s four factors. Chips are the generation capacity. Advanced GPUs, specifically the frontier silicon manufactured overwhelmingly by TSMC in Taiwan and designed primarily by NVIDIA in the United States, are the turbines of the inference economy. Without them, you do not generate inference at competitive cost. The global concentration of this manufacturing capacity in a single facility on a geopolitically contested island is the equivalent of the entire world’s electricity depending on one power plant. It is a single point of failure that makes infrastructure planners lose sleep. Energy is the fuel. Frontier inference is measured in gigawatts now, not megawatts. A single large-scale inference cluster draws more power than a small city. The AI 2027</a> scenario projects global AI datacenter power consumption reaching 38 GW by 2026, and that number is rising on a curve that shows no sign of flattening. You cannot run inference without power, and you cannot build the power infrastructure overnight. The jurisdictions that have cheap, abundant, reliable energy have a structural advantage that no amount of software cleverness can compensate for. Data is the raw material that the models learned from, the substrate that makes inference meaningful rather than random. Who has it, under what legal constraints it can be used, and how diverse and representative it is all determine the quality and applicability of the inference you can produce. Talent is the operational workforce. Not just the researchers who design the models, but the engineers who build the infrastructure, the operators who keep it running, and the security professionals who defend it. This is the human capital layer that every utility depends on, and it is concentrated in a handful of geographic clusters for the same reasons that petrochemical engineering talent concentrates near refineries. When you map it out, inference has the same supply chain structure as any mature utility. And the strategic implications follow directly. Supply chain layer</th> Electricity</th> Water</th> Inference</th></tr></thead> Raw input</td> Fuel (gas, uranium, sun)</td> Source (river, aquifer)</td> Data (training corpora)</td></tr> Generation</td> Power plants, turbines</td> Treatment plants</td> GPUs, data centers</td></tr> Transmission</td> The grid</td> Pipes, pumps</td> Networks, API endpoints</td></tr> Fuel for generation</td> Primary energy</td> Electricity for pumping</td> Electricity (38+ GW)</td></tr> Key bottleneck</td> Grid capacity, permits</td> Water rights, drought</td> Chip fabrication (TSMC)</td></tr> Geopolitical risk</td> Pipeline politics, OPEC</td> Cross-border rivers</td> Taiwan, export controls</td></tr> </tbody></table> The analogy is not a metaphor. It is a structural description. What AI 2027 got right about the economics</h2> The AI 2027</a> scenario, written by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean, is a speculative timeline. The authors are careful to frame it that way. But the economic projections in it have a quality that I keep returning to: they treat AI compute as an industrial resource, not a software product. Their scenario tracks global AI datacenter spending reaching the trillion-dollar range. It maps the distribution of frontier compute capacity across nations, with the United States holding roughly 70% through its companies and China at around 12%. It projects power consumption figures that match what utility planners, not software engineers, would recognize as relevant. What makes this framing useful is not the specific numbers. It is the category. When you project AI spending in trillions and power consumption in tens of gigawatts, you are not describing a software industry. You are describing a utility buildout. The capital expenditure patterns, the infrastructure timelines, the regulatory questions, the geopolitical competition, all of it maps to how nations have historically competed over energy infrastructure, telecommunications infrastructure, and industrial capacity. The AI 2027 authors project that the feedback loop of AI systems accelerating AI research compresses the timeline for capability growth. Whether their specific dates hold is less important than the structural observation: if capability is growing on a steep curve and that capability requires physical infrastructure that grows on a much slower curve, then the binding constraint on AI is not software. It is infrastructure. It is the utility layer. This is what I experienced at the personal scale with shiioo. The software worked. The orchestration model worked. What ran out was the physical resource: tokens, which is to say inference, which is to say compute, which is to say silicon and electricity. The bottleneck was not the architecture. The bottleneck was the meter. What this means for post-AI systems</h2> If inference is a utility, then every system that depends on inference is a utility consumer. And that changes how you design those systems. When I built shiioo, I treated token consumption as a budget to manage. That was the individual developer framing: I have a fixed allocation, I need to spend it wisely. But if you zoom out to the enterprise or the nation state, the framing shifts. You are not managing a budget. You are managing a utility dependency. The questions become infrastructure questions. How much inference capacity do you need? Where does it come from? What happens when your provider has an outage? What are your contractual guarantees for availability and throughput? What is your fallback if the primary supply is interrupted? Do you own any generation capacity, or are you entirely dependent on external providers? These are exactly the questions that enterprises ask about electricity, about water, about telecommunications. And they are starting to ask them about inference, even if most of them do not yet use that framing. The organizations that will navigate this transition well are the ones that recognize what inference actually is: a consumed resource that correlates with power draw, requires physical infrastructure, and generates value in the form of information contextualization and evaluation. Every time a post-AI system communicates with another system or with a human, it is consuming inference. Every agent-to-agent message, every model evaluation, every generated response is a unit drawn from a metered supply that has real physical costs behind it. The implications branch in several directions. Pricing will converge toward utility models. Per-token pricing is already the norm, but the industry will move toward the more sophisticated pricing structures that utilities use: tiered rates, time-of-use pricing, capacity reservations, spot markets. Some of this is already emerging. It will accelerate as enterprises start treating inference spend the way they treat energy spend: as a major operational cost that requires dedicated procurement and optimization. Sovereignty will matter. If inference is a utility, then depending on a foreign provider for your inference supply is the same kind of strategic vulnerability as depending on a foreign country for your energy supply. Europe learned this lesson with Russian natural gas. The question of whether you can run inference workloads within your own jurisdiction, on your own infrastructure, under your own legal framework, is not an abstract concern about data residency. It is a question of infrastructure sovereignty. This is why I built Archipelag</a>, and it is why I think the compute sovereignty conversation in Europe needs to move from policy papers to physical infrastructure. Efficiency will become an engineering discipline. When electricity was cheap and abundant, nobody optimized for energy efficiency. When it became expensive, an entire engineering discipline emerged around it. The same will happen with inference. Right now, most systems that use inference do so profligately, full context windows, verbose prompts, redundant calls. As inference cost becomes a meaningful line item, optimizing for token efficiency will become as normal as optimizing for energy efficiency. The structured communication protocols I described in the shiioo article, typed messages instead of free-form conversation, are an early example of this. Every token should carry information, not politeness. Metering and observability will be essential. You cannot manage a utility you cannot measure. Enterprises will need inference observability the same way they need power monitoring and network monitoring: real-time visibility into consumption, cost attribution to specific workloads and teams, anomaly detection for unexpected usage spikes, and capacity planning based on historical patterns. The tooling for this barely exists today. It will be a significant market within a few years. The meter is the message</h2> When I ran out of tokens over Christmas, my first reaction was frustration. My second reaction was to think about the architecture differently, to design for token efficiency, to route cheap communication through cheaper models. But my third reaction, the one that has stayed with me longest, was recognition. I recognized the shape of the problem. It was not a new shape. It was the shape of every utility constraint I have ever encountered. The shape of “the infrastructure is the bottleneck.” The shape of “the resource is finite and metered and you need to think about your consumption.” The shape of “the supply chain is geopolitical.” Nakasone’s four factors, chips, data, talent, energy, are not just a framework for assessing national power. They are the bill of materials for producing inference. And the nations, enterprises, and individuals who control that bill of materials will have the same structural advantage that energy-rich nations had in the industrial age and bandwidth-rich nations had in the information age. The fifth utility is here. We are just early enough that most people still think they are buying software. References</h2> What Sixteen AI Agents Taught Me About Management</a> - The predecessor to this article</li> Notes from RSAC 2026</a> - Paul Nakasone’s four factors and the geopolitical dimension</li> AI 2027</a> - Scenario work by Kokotajlo, Alexander, Larsen, Lifland, and Dean</li> Archipelag</a> - Decentralized, sovereignty-first AI compute network</li> How I Work These Days</a> - Where I first wrote about the shift to agent-driven development</li> </ul> What Comes After the Last Programming Language Unknown — Sun, 19 Apr 2026 00:00:00 +0000 In The Last Programming Language Might Not Be for Humans</a>, I described three futures for programming languages as AI becomes the primary author of code. Explicit languages for machines. Declarative languages where types are proofs. And ultimately, no language at all, where AI generates machine code directly and the intermediate layer disappears. I left something out. There is a fourth possibility, and it goes deeper than the language. What happens to the operating system? The operating system was designed for typists</h2> Every operating system in production today, Linux, Windows, macOS, the BSDs, was built on the same foundational assumption: a human writes a program, the program is compiled into a sequence of CPU instructions, and the OS manages the execution of those instructions. Processes. Threads. System calls. Virtual memory. File descriptors. Schedulers. These abstractions exist because the fundamental unit of work is a sequence of CPU operations authored by a human programmer. This is not an exaggeration. Look at the POSIX specification. fork()</code> creates a copy of the calling process. exec()</code> replaces the current process image with a new program. read()</code> and write()</code> move bytes between a process and a file descriptor. mmap()</code> maps a file into the process’s virtual address space. Every one of these primitives assumes a CPU-centric, sequential execution model where a process is a container for a stream of instructions that the CPU executes one at a time (or a few at a time, with threads). This made sense for sixty years. Dennis Ritchie and Ken Thompson designed Unix in 1969 around the PDP-7, a machine with a single CPU and 18-bit words. The abstractions they chose, processes, pipes, files as byte streams, were elegant reflections of what the hardware could do. Those abstractions survived because they generalized well. When CPUs got faster, processes got faster. When CPUs got more cores, threads mapped naturally onto them. When networks arrived, sockets extended the file descriptor model. The operating system grew, but the foundational unit of work never changed: a sequence of CPU instructions, managed by a scheduler, isolated by virtual memory. How the GPU became an accidental general-purpose computer</h2> The GPU was never meant to be here. Its entire history is a sequence of coincidences. In the early 1990s, GPUs existed to draw triangles. Silicon Graphics made specialized hardware for 3D rendering, and the rest of the industry followed. NVIDIA’s GeForce 256, released in 1999, was marketed as the world’s first “GPU,” a term NVIDIA invented. Its job was to take vertices and textures from a CPU program, transform them, and rasterize them to a framebuffer. It was a peripheral. A display adapter with math capabilities. Then game developers started abusing the hardware. Shader programs, originally designed for lighting and surface effects, turned out to be tiny parallel programs that could do arbitrary computation. By the mid-2000s, researchers at Stanford and elsewhere realized you could encode general-purpose math problems as texture operations: matrix multiplications as pixel shaders, fluid simulations as render passes. It was a hack. The GPU did not know it was doing science. It thought it was rendering a really weird image. NVIDIA saw the opportunity and released CUDA in 2007, giving the GPU a proper programming model for general-purpose computation. But the architecture of the system did not change. CUDA was a userspace library. The GPU driver ran outside the kernel. The operating system still treated the GPU as a display device. The OS scheduled CPU processes and managed CPU memory. The GPU scheduled its own work and managed its own memory, through CUDA, through the driver, outside the OS’s view. Then came cryptocurrency mining. Bitcoin miners discovered that GPUs were vastly more efficient than CPUs for SHA-256 hashing, because the algorithm is embarrassingly parallel and the GPU has thousands of cores. This was the first mass-market workload where the GPU did the economically valuable work and the CPU was just overhead. Mining rigs were machines where the CPU was an afterthought, a cheap Celeron whose only job was to feed work to a rack of GPUs. But the operating system running on that Celeron was still Linux, still managing the GPU through CUDA, still treating it as a peripheral. Then came machine learning. First training (AlexNet in 2012, the moment deep learning became real), then inference. Each transition was coincidental. Nobody designed GPUs to be good at neural network training. They just happened to have the right characteristics: massive parallelism, high memory bandwidth, and a programming model that could express matrix multiplications. The workloads found the hardware. The hardware did not seek the workloads. And so we arrived at 2026 with the most important compute workload in a generation, AI inference, running on hardware that was originally designed to render Quake, managed by drivers that bypass the operating system, scheduled by a proprietary runtime that the kernel cannot see or control. The GPU is the most important processor in the machine, and the OS does not know what it is doing. Nearly twenty years after CUDA, we are still using that model. The workloads have changed beyond recognition. The software stack has not. How CPUs and GPUs actually differ</h2> To understand why this matters, it helps to understand how CPUs and GPUs compute differently. Not at the marketing level. At the architectural level. A CPU is designed for latency. It has a small number of powerful cores (8 to 128 on a modern server chip), each with deep pipelines, branch predictors, out-of-order execution engines, and large caches. Each core is optimized to execute a single thread of instructions as fast as possible. When your program says “if this, then that,” the CPU predicts which branch you will take and starts executing it before it knows the answer. When your program accesses memory, the CPU has three levels of cache to hide the latency of going to DRAM. The entire design optimizes for one thing: getting through a single sequence of instructions with minimal delay. A GPU is designed for throughput. It has thousands of small cores (16,384 CUDA cores on an H100), each simple, each capable of executing one instruction per clock, grouped into blocks that execute the same instruction on different data simultaneously. There is no branch predictor because all threads in a warp (a group of 32) execute the same instruction at the same time. If your program has a branch, both paths execute and the unwanted results are discarded. There is very little cache because the design assumes you are streaming through large data sets, not randomly accessing small ones. The entire design optimizes for one thing: doing the same operation on as many data points as possible simultaneously. CPU (latency-optimized) GPU (throughput-optimized) ======================== ============================ +---------+ +---------+ +--+--+--+--+--+--+--+--+--+ | Core 0 | | Core 1 | ... 8-128 | | | | | | | | | | | complex | | complex | cores | | | | | | | | | | | OoO exec| | OoO exec| | | | | | | | | | | | branch | | branch | | SM | | SM | | SM | | predict | | predict | | | | | | | | | | | +---------+ +---------+ | | | | | | | | | | | | +--+--+--+--+--+--+--+--+--+ +----+----+ +----+----+ thousands of cores | L1 32K | | L1 32K | simple, in-order +---------+ +---------+ same instruction, +----+------------+----+ different data | L2 ~1 MB | +-----------------------+ +---------------------------+ | L3 ~32 MB | | HBM ~80 GB | +-----------------------+ | ~3 TB/s bandwidth | | DRAM ~512 GB | +---------------------------+ | ~100 GB/s | +-----------------------+ One instruction, 16384 data points at once One instruction at a time, very fast</code></pre> This difference is why matrix multiplication, the core operation in neural network inference, runs three orders of magnitude faster on a GPU. A matrix multiply is thousands of multiply-and-add operations on independent data points. The CPU executes them one at a time (or a few at a time with SIMD), fast but serial. The GPU executes thousands simultaneously, each on its own core. The CPU finishes one row while the GPU finishes the whole matrix. For traditional software, CPU architecture is perfect. A web server parses HTTP requests (branchy, sequential), queries a database (latency-sensitive, cache-friendly), and formats a response (string operations, unpredictable access patterns). Each request is different. Each code path branches differently. The CPU’s branch predictor, out-of-order execution, and deep cache hierarchy are exactly right. For inference, GPU architecture is perfect. Each layer of a transformer is a dense matrix multiplication followed by an element-wise nonlinearity. Every token in the batch gets the same operations applied to the same weights. There are almost no branches. The data is enormous and streaming. The GPU’s thousands of simple cores and high-bandwidth memory are exactly right. The problem is that we run both workloads on an operating system that only understands the first kind. The GPU is becoming the computer</h2> When you run inference on a large language model, the GPU is not assisting the CPU. The GPU is doing the work. The CPU’s role is orchestration: loading weights, managing memory, feeding tokens, collecting output. The actual computation, the matrix multiplications that turn a prompt into a response, happens on the GPU. For a 70-billion-parameter model, the GPU does billions of floating-point operations per token. The CPU does bookkeeping. The numbers make this concrete. An NVIDIA H100 delivers roughly 1,979 teraflops of FP8 compute. The CPU it is paired with, typically an AMD EPYC or Intel Xeon, delivers maybe 2-3 teraflops of FP32. The GPU has three orders of magnitude more compute throughput for the operations that matter in inference. When a request arrives at an inference endpoint, the CPU spends microseconds parsing HTTP and tokenizing text. The GPU spends milliseconds doing the actual thinking. The ratio of useful work is not close. This inversion has happened gradually enough that we have not fully reckoned with it. We still run inference workloads on Linux. We still manage GPU memory through CUDA driver calls from userspace processes. We still treat the GPU as a device the OS mediates access to, the same way it mediates access to a disk or a network card. But a disk does not run your business logic. A network card does not make decisions. The GPU increasingly does both. When an AI agent decides whether to approve a transaction, route a request, or generate a response, the decision happens on the GPU. The CPU is the secretary. The GPU is the executive. If the executive is making the decisions, why is the secretary’s office designed for the secretary? This is not merely an aesthetic complaint. The mismatch has practical consequences. GPU memory management is manual and error-prone. Context switches between GPU workloads are expensive because the OS has no concept of GPU process state. Scheduling is done by the CUDA driver, not by the kernel, which means the OS cannot enforce fairness or priority between GPU workloads the way it enforces them between CPU processes. And isolation, the most critical property for multi-tenant inference, depends entirely on userspace software that the OS does not control or verify. What an inference-native OS would look like</h2> Imagine an operating system where inference is the fundamental compute primitive. Not a syscall you invoke. Not a library you link. The basic unit of work. In a traditional OS, the primitive is a process: an isolated address space running a sequence of CPU instructions with access to file descriptors, network sockets, and memory. The scheduler gives each process time on the CPU. The kernel mediates access to shared resources. In an inference-native OS, the primitive would be a shard: an isolated execution context with dedicated GPU resources, its own VRAM partition, its own compute units, its own inference pipeline. The scheduler does not give shards time on the CPU. It gives them capacity on the GPU. The kernel does not mediate file descriptors. It mediates model weights, token streams, and attention contexts. Traditional OS Inference-native OS ================= ==================== Process A Process B Process C Shard A Shard B Shard C | | | | | | v v v v v v +-------------------------------+ +-------------------------------+ | CPU scheduler | | GPU scheduler | | (time-slicing) | | (capacity-slicing) | +-------------------------------+ +-------------------------------+ | | | | | | v v v v v v +------+ +------+ +------+ +--------+ +--------+ +--------+ | Core | | Core | | Core | | CU | | CU | | CU | | 0 | | 1 | | 2 | | slice | | slice | | slice | +------+ +------+ +------+ +--------+ +--------+ +--------+ | | | GPU is a peripheral v v v called via ioctl/CUDA +-------------------------------+ | VRAM partitions | | (isolated per shard) | +-------------------------------+</code></pre> The analogy that keeps coming back to me is mainframes and timesharing. In the 1960s, computers were batch-processing machines. You submitted a job, waited, got results. Then Multics and later Unix introduced timesharing: multiple users, each with the illusion of having the whole machine, isolated from each other by the OS. The transition was not just a performance improvement. It was a conceptual shift in what the machine was for. It went from “a machine that runs one job at a time” to “a machine that runs many jobs concurrently, safely isolated.” We need the same transition for GPUs. Right now, GPU computing is in its batch-processing era. One workload gets the GPU (or a partition of it, managed by CUDA MPS or MIG), and isolation is an afterthought bolted on by the driver. The inference-native equivalent of timesharing would be an OS that treats GPU capacity the way Unix treats CPU time: a shared resource, securely partitioned, with each tenant unable to see or affect the others. The isolation model is the critical piece. In a traditional OS, processes are isolated by virtual memory on the CPU side. Two processes cannot read each other’s RAM because the page tables prevent it. The MMU (Memory Management Unit) enforces this in hardware. It is not a software convention. It is a physical guarantee. But GPU memory is a different story. In most systems, GPU memory isolation depends on the CUDA driver, which runs in userspace. NVIDIA’s MIG (Multi-Instance GPU) provides hardware partitioning on some GPU models, but it is coarse-grained (up to 7 instances on an A100) and not available on consumer hardware. A vulnerability in the driver, or in any process with GPU access, can potentially read VRAM belonging to another workload. For inference workloads handling sensitive data, this is not acceptable. Hardware-level isolation is the answer. Intel VT-d IOMMU can enforce DMA translation boundaries so that each GPU partition’s VRAM is physically inaccessible to other partitions. Not software-isolated. Hardware-isolated. The same level of guarantee that CPU virtual memory provides, but for GPU resources. The technology exists. It is used in server virtualization today for PCIe passthrough. The question is whether an OS can be built that uses it as a first-class isolation primitive for inference workloads, not as a virtualization feature. coconutOS</h2> This is not purely theoretical. I have been building a proof of concept. coconutOS</a> is a capability-based microkernel written in Rust, engineered specifically for GPU-isolated AI inference. It boots on x86-64 hardware via UEFI, and its entire architecture is designed around the idea that the GPU is the primary execution engine. The choice of a microkernel is deliberate, and it carries historical baggage worth addressing. The microkernel idea goes back to the 1980s. Andrew Tanenbaum, the computer scientist at Vrije Universiteit Amsterdam, built Minix</a> as a teaching OS based on the principle that the kernel should do as little as possible: manage memory, schedule tasks, pass messages. Everything else, file systems, drivers, network stacks, runs in userspace as separate processes. If a driver crashes, the kernel restarts it. The system keeps running. Tanenbaum and Linus Torvalds had a famous debate about this in 1992 on the comp.os.minix newsgroup. Torvalds argued that monolithic kernels were faster and more practical. Tanenbaum argued that microkernels were more reliable and that “Linux is obsolete.” Torvalds won the practical argument. Linux became the dominant OS precisely because a monolithic kernel is simpler to build and faster to run when all your workloads are CPU-centric. Putting the file system and drivers in kernel space avoids the overhead of message passing between userspace processes. But Tanenbaum’s argument was about fault isolation, and fault isolation becomes more important as the consequences of failure increase. When the failure is “the file server process crashes and is restarted in 50 milliseconds,” a monolithic kernel’s performance advantage wins. When the failure is “a GPU driver bug in kernel space lets one tenant’s inference workload read another tenant’s medical records from VRAM,” the calculus changes. In a monolithic kernel like Linux, the GPU driver runs in kernel space with full access to system memory. A bug in the NVIDIA driver (and there have been many: CVE-2024-0090</a>, CVE-2024-0092</a>, CVE-2023-31018</a> to name a few from recent years) can compromise the entire system. In a microkernel, the GPU HAL runs as an isolated shard in userspace. A bug in the HAL crashes that shard. The kernel survives. Other shards survive. The failure domain is contained. Tanenbaum was right about the principle. He was just early about the workload that would make it matter. GPU-isolated inference is that workload. The performance overhead of microkernel message passing is irrelevant when the actual work happens on the GPU and the kernel’s job is orchestration, not computation. The CPU side is the control plane. The GPU side is the data plane. A microkernel is the right architecture for a control plane. The core abstractions: Shards, not processes. Each shard is an isolated address space with its own page tables, running in ring 3. But unlike a traditional process, a shard’s primary resource is not CPU time. It is GPU capacity. A shard gets a partition of VRAM, a slice of compute units, and a dedicated HAL (Hardware Abstraction Layer) shard that manages its access to the GPU. The HAL shard itself is unprivileged. It communicates with the kernel through the same capability-based IPC that every other shard uses. There is no “root” equivalent for GPU access. Capabilities, not permissions. Access control is capability-based, inspired by systems like seL4</a> and the research that came out of the University of Cambridge’s Computer Laboratory. Each shard holds unforgeable capability tokens that grant access to specific resources: VRAM regions, IPC channels, filesystem paths, GPU compute slices. Capabilities can be granted, revoked, restricted, and inspected. There are no ambient permissions. A shard cannot access anything it does not hold a capability for. This is fundamentally different from Unix permissions, where a root process can access everything. In coconutOS, there is no root. There are only capabilities. GPU ASLR. Each shard’s VRAM and MMIO virtual addresses are randomized. Even if an attacker finds a vulnerability in one shard, they cannot predict where another shard’s GPU memory is mapped. CPU-side ASLR has been standard since the mid-2000s. The insight is that the same principle applies to GPU resources, and that without it, a GPU memory disclosure vulnerability in one workload can be used to locate and read another workload’s model weights or inference state. Pledge and unveil for GPUs. This is one of the design choices I am most attached to, because it comes directly from my years of admiring OpenBSD. Theo de Raadt’s pledge(2)</code> and unveil(2)</code> syscalls are among the most elegant security primitives ever designed. A process calls pledge("stdio rpath")</code> and permanently gives up the ability to do anything except read files and use standard I/O. It cannot escalate back. The promise is irreversible. coconutOS applies the same idea to GPU resources. pledge_gpu</code> lets a shard declare that it will only do inference, not training. Once pledged, it cannot allocate new VRAM beyond its partition, cannot modify model weights, cannot access raw compute dispatch. unveil_vram</code> lets a shard lock its VRAM view to a specific region. Other regions become physically invisible through the IOMMU. A compromised inference shard cannot undo its own containment because the kernel enforces the pledge at the hardware level. The inference stack. The proof of concept runs a transformer forward pass end-to-end: RMSNorm, multi-head attention with rotary position embeddings (RoPE), SiLU feed-forward networks, softmax. It is based on Andrej Karpathy’s llama2.c</a>, adapted to run as a shard with GPU isolation. The kernel preserves FPU and SSE state across preemption using FXSAVE/FXRSTOR, so inference math is not corrupted by context switches. This is a detail that matters: if the scheduler preempts a shard mid-matrix-multiply and does not preserve the floating-point register state, the results will be silently wrong. Traditional OSes handle this for CPU processes. coconutOS handles it for GPU inference shards. Why this matters</h2> You might look at coconutOS and think: this is an interesting research project, but nobody is going to replace Linux for AI workloads. And you might be right. Linux is entrenched. CUDA is entrenched. The entire AI infrastructure stack, from PyTorch to vLLM to Triton Inference Server, is built on top of assumptions that coconutOS challenges. But consider the trajectory. Five years ago, AI inference was a batch job you ran on a cluster. You uploaded data, kicked off a job, came back later for results. The security model was simple: whoever had SSH access to the machine had access to the GPU. Isolation was a non-issue because there was only one workload. Today, inference is a real-time service. Companies like Anthropic, OpenAI, and Google serve billions of inference requests per day. Multiple customers share the same GPU hardware. The workloads process sensitive data: medical records, financial transactions, legal documents, personal conversations. The security and isolation requirements have changed fundamentally, but the OS layer has not changed at all. We are running safety-critical, multi-tenant inference workloads on an operating system that was designed in 1991 for running file servers and web servers. The gap between what we are doing on GPUs and how we manage GPU access is widening. Right now, GPU multi-tenancy in the cloud means trusting the CUDA driver and the hypervisor to keep workloads separated. NVIDIA’s MIG helps, but it is only available on data center GPUs (A100, H100), offers coarse-grained partitioning (7 instances maximum), and still relies on the CUDA driver for memory management within each partition. For most use cases, this is fine. For financial services, healthcare, defense, and any context where inference handles regulated data, “trusting the driver” is not a compliance-grade answer. The analogy is virtualization. Before Xen and KVM, server multi-tenancy meant trusting the host OS to isolate users. It worked until it did not. Hardware virtualization (VT-x) gave us actual isolation guarantees enforced by the CPU. The cloud was built on those guarantees. We need the same thing for GPUs. Hardware-level isolation, enforced by the kernel, with capability-based access control and monotonic privilege restriction, is where this has to go. Whether it looks like coconutOS or like a set of patches to Linux or like NVIDIA building isolation into their next GPU architecture is an implementation question. The architectural direction is not optional. The four futures, updated</h2> Looking back at the original post, the timeline extends further than I initially described: Near term Medium term Long term Far horizon (now) (2-5 years) (5-15 years) (10-20 years) Explicit Declarative Post-language Inference-native languages languages (AI-native operating systems (Vera) (Haskell + BHC) targets) Reduce noise --> Change the --> Remove the --> Redesign the in the loop signal layer machine HOW, but WHAT, verified Intent to Intent to unambiguous by types execution inference</code></pre> The first three futures are about the intermediate layer between human intent and machine execution. The fourth future is about the machine itself. If the primary workload is inference, the machine should be designed for inference. Not adapted. Not extended. Designed. Each transition in this timeline follows the same pattern that has repeated throughout the history of computing. When a new type of workload becomes dominant, the infrastructure eventually reshapes itself around that workload. Mainframes were redesigned for timesharing when interactive use became the dominant workload. Server hardware was redesigned for virtualization when multi-tenancy became the dominant workload. Network infrastructure was redesigned for packet switching when interactive data became more important than circuit-switched voice. The question is never whether the infrastructure will adapt. It is how long the transition takes and what it looks like on the other side. This is admittedly the furthest out of the four possibilities. We are even further from inference-native operating systems than we are from AI generating machine code directly. The hardware support is early. The software stack is embryonic. coconutOS boots and runs a transformer forward pass, which is a start, but it is a long way from something you would deploy in production. But the same was true of virtual memory when MIT’s Project MAC implemented it in 1961. It took decades for hardware support to mature, for operating systems to build on it, for the abstraction to become invisible. Today, every program you run uses virtual memory and nobody thinks about it. The same was true of containerization when Google started using cgroups internally in 2006. Docker did not arrive until 2013. Kubernetes until 2014. The gap between “research prototype” and “runs the world” is real, but so is the trajectory. The workloads are catching up. The hardware is catching up. The question is whether we build the OS to match, or whether we keep running inference on an operating system that thinks the CPU is in charge. Honest assessment</h2> I do not know if inference-native operating systems will happen in this form. I do not know if the microkernel approach is right, or if the better path is extending Linux with GPU isolation primitives (the way cgroups extended Linux for containers, the way KVM extended Linux for virtualization). I do not know if hardware vendors will build the IOMMU support that makes per-shard GPU isolation practical at scale, or if NVIDIA will solve this problem at the driver level before anyone needs a new OS. There are smart people working on adjacent problems. Google’s TPU architecture has custom scheduling and isolation built into the hardware. AMD’s ROCm is exploring open-source alternatives to CUDA’s closed driver model. Intel’s GPU roadmap includes hardware virtualization features. Any of these paths could make coconutOS’s approach unnecessary by solving the isolation problem at a different layer. What I do know is that running inference workloads on operating systems designed for sequential CPU programs is an impedance mismatch that will become less tolerable as inference becomes more critical. Something will change. coconutOS is my attempt to explore what that something might look like, with real code that boots on real hardware and runs a real transformer. The code is open source, ISC-licensed, and very much a work in progress. If you are thinking about similar problems, I want to hear from you. github.com/coconut-os/coconutOS</a> What Sixteen AI Agents Taught Me About Management Unknown — Thu, 16 Apr 2026 00:00:00 +0000 Over the 2025 Christmas holidays I had sixteen AI agents running in parallel across four macOS workspaces. Each workspace held four Ghostty terminal panes, each pane running its own Claude Code instance, each instance working on a different piece of a different project. I was on Anthropic’s 20x Max subscription, and during the holiday period the token limits were generous enough that I could burn through context at a rate I had never attempted before. It was the most productive week of my engineering life. It was also the week I learned that managing AI agents is, at its core, a management problem. Not a technical one. The terminal wall</h2> The setup started simple. Mitchell Hashimoto’s Ghostty, which I consider one of the best terminal emulators released in years, supports split panes in both directions. Four panes per workspace. Four workspaces. Sixteen agents. Each one working on a real task: scaffolding a new crate, writing tests for a module I had sketched out, researching an API I needed to integrate, refactoring a component I had been putting off for months. Workspace 1 Workspace 2 Workspace 3 Workspace 4 =================== =================== =================== =================== | Agent 1 | Agent 2| | Agent 5 | Agent 6| | Agent 9 | Agent 10| | Agent 13 | Agent 14| | scaffold| tests | | refactor| research| | API | migrate| | docs | bench | |---------|---------| |---------|---------| |---------|---------| |---------|---------| | Agent 3 | Agent 4| | Agent 7 | Agent 8| | Agent 11 | Agent 12| | Agent 15 | Agent 16| | config | lint | | deploy | review | | schema | ci | | proto | fuzz | =================== =================== =================== =================== Me: switching between workspaces, scrolling back through conversations, keeping a text file of who does what</code></pre> The first few hours were exhilarating. I would spin up an agent, give it a task, switch to the next pane, give it a task, move to the next workspace, repeat. By mid-morning I had more concurrent engineering work happening than most small teams produce in a day. Then the problems started. I could not remember what each agent was doing. This was before Claude Code added the prompt and context summary at the top of the input line, so the only way to check was to scroll back through the conversation history and find the original prompt. With sixteen sessions, that meant a lot of scrolling. I started naming my macOS workspaces. I named each Ghostty pane. I kept a text file open with a list of which agent was doing what. I was, without quite realizing it, building a project management system out of sticky notes and window titles. The irony was not lost on me. I had sixteen AI agents doing engineering work, and I was spending half my time doing the one thing AI was supposed to eliminate: keeping track of who was working on what. Kage, the first attempt</h2> That frustration led to kage</a>. The name means shadow in Japanese. The idea was straightforward: build a Rust binary that could orchestrate multiple terminal sessions, let me switch between them, and show me at a glance what each one was doing. kage used alacritty_terminal</code> (the terminal emulation library extracted from the Alacritty terminal emulator) to manage PTY sessions, ratatui</code> for a terminal UI, and redb</code> for local persistence. I could spawn agents with goals, set iteration limits, checkpoint and resume sessions, and pool across multiple LLM providers. The vision was that I could use Claude Code alongside OpenAI’s Codex and whatever else was available, routing tasks to whichever provider had capacity. +-----------------------------------------------------------+ | kage TUI (ratatui) | | +-------+ +-------+ +-------+ +-------+ +-------+ | | | Sess 1| | Sess 2| | Sess 3| | Sess 4| | ... | | | | goal: | | goal: | | goal: | | goal: | | | | | | scaf. | | tests | | refac.| | API | | | | | +---+---+ +---+---+ +---+---+ +---+---+ +-------+ | | | | | | | +------|----------|-----------|----------|-------------------+ | | | | +----v----+ +--v----+ +--v----+ +--v----+ | PTY | | PTY | | PTY | | PTY | alacritty_terminal | (Claude)| |(Codex)| |(Claude| |(Claude| manages each session +---------+ +-------+ +-------+ +-------+ +---------------------+ +------------------+ | redb (persistence) | | LLM provider pool| | checkpoints, goals, | | Anthropic, OpenAI| | session state | | route by capacity| +---------------------+ +------------------+</code></pre> It worked. Technically. I could see all my sessions in one interface. I could switch between them. I could track what each agent was supposed to be doing. But it felt clunky. The terminal streaming had issues. The UI was functional but not fluid. And more importantly, I realized the tool was solving the wrong problem. The problem was not that I needed a better way to look at sixteen terminal panes. The problem was that sixteen independent agents with no coordination between them produced sixteen independent streams of work with no coherence between them. Agent A would refactor a module that agent B was simultaneously writing tests for, using the old API. Agent C would make a design decision that conflicted with what agent D was building. I was the only point of integration, and I could not context-switch fast enough to catch every conflict. Agent A: refactors auth module Agent B: writes tests for auth module | | +-- removes old_login() +-- tests old_login() +-- renames to authenticate() +-- expects old return type +-- changes return type +-- passes locally (stale code) +-- FAILS after A merges Agent C: picks REST for new API Agent D: builds gRPC client for new API | | +-- adds /api/v2/users +-- generates proto stubs +-- writes OpenAPI spec +-- implements streaming calls +-- INCOMPATIBLE with C's design Me (the only integration point): "Wait, what is everyone doing?"</code></pre> I needed the agents to coordinate with each other. Not just run in parallel. Actually collaborate. Shiioo, the virtual company</h2> The second attempt was shiioo</a>. The name is the Japanese romanization of CEO. The premise had changed entirely. What if the agents were not just parallel workers? What if they were employees in a virtual enterprise, each with a specific role, a defined skillset, a limited set of tools, and a reporting structure? I had been reading about organizational design and it struck me how directly the problems I was having with agent orchestration mapped to problems that real companies solve with management hierarchies. When you have sixteen people working on a project, you do not give each one independent access to everything and hope for the best. You create teams. You assign leads. You define communication channels. You escalate decisions that exceed a team’s authority. So that is what I built. shiioo is a Rust-based client-server system with an event-sourced persistence layer. Each agent is modeled as an employee with a SKILLS.md</code> file that defines its capabilities, a limited set of MCP interfaces it can access, and a position in an organizational hierarchy. Agents are grouped into squads. Each squad has a lead. Squad leads report to department leads. Department leads report up to me. +------------------+ | CEO (me) | | Strategic | | decisions only | +--------+---------+ | +-----------------+-----------------+ | | +--------v---------+ +---------v--------+ | Dept Lead: | | Dept Lead: | | Infrastructure | | Product | +--------+---------+ +---------+--------+ | | +--------+--------+ +--------+--------+ | | | | +------v------+ +------v------+ +------v------+ +------v------+ | Squad Lead: | | Squad Lead: | | Squad Lead: | | Squad Lead: | | Backend | | Platform | | Frontend | | Data | +------+------+ +------+------+ +------+------+ +------+------+ | | | | +----+----+ +---+---+ +----+----+ +---+---+ | | | | | | | | | | Ag1 Ag2 Ag3 Ag4 Ag5 Ag6 Ag7 Ag8 Ag9 Ag10 Each agent has: - SKILLS.md (capabilities) - Limited MCP interfaces - Defined scope of authority - Escalation path upward</code></pre> The architecture uses a DAG workflow engine built on petgraph</code> for task dependencies, a policy engine for authorization and approval gates, and a capacity broker that routes LLM calls across multiple providers. Every action is event-sourced, which means I have a complete audit trail of every decision every agent made, and I can replay any sequence of events to understand how a particular outcome was reached. +-------------------------------------------------------------------+ | shiioo server | | | | +------------------+ +------------------+ +-----------------+ | | | Workflow Engine | | Policy Engine | | Capacity Broker | | | | (petgraph DAGs) | | (RBAC, approval | | (route LLM | | | | | | gates, authz) | | calls across | | | | task deps, | | | | providers) | | | | retries, | | who can do what, | | | | | | timeouts | | who approves | | Anthropic, | | | +--------+---------+ +--------+---------+ | OpenAI, ... | | | | | +---------+-------+ | | +----------+----------+ | | | | | | | +-------v--------+ | | | | Event Store | +--------------------v------+ | | | (redb + S3) | | MCP Tool Server | | | | | | (expose enterprise tools | | | | every action | | to agents) | | | | is persisted, | +----------------------------+ | | | replayable | | | +---------------+ | +-------------------------------------------------------------------+ | | +----v----+ +----v----+ | CLI REPL| | Web | | (Chief | | Dashboard| | of Staff| | (real- | | mode) | | time) | +---------+ +---------+</code></pre> The key insight was the escalation model. Most tasks could be handled by individual agents within their defined scope. When an agent encountered a decision that exceeded its authority, such as a design choice that would affect other teams, a dependency conflict, or a resource allocation question, it escalated to its squad lead. The squad lead either resolved it or escalated further. Only the decisions that truly required strategic judgment, market positioning, resource allocation across projects, architectural direction, reached me. I was the CEO. Not in some metaphorical sense. In the literal operational sense that the only decisions that required my attention were the ones that should require a CEO’s attention. It worked</h2> shiioo was rough. The UI was a REPL with seven built-in commands. The web dashboard was basic. The documentation was incomplete. But the model worked. I bootstrapped multiple projects using this setup over the holidays. Agents would pick up tasks, work within their scope, coordinate through the reporting structure, and escalate when they hit ambiguity. The squad lead agents were particularly effective because they had enough context about their team’s work to resolve most conflicts without involving me. The event sourcing turned out to be more valuable than I expected. When something went wrong, and things did go wrong, I could trace the decision chain from the final output back to the original task assignment. I could see exactly where an agent made a bad call, which agent approved it, and what information was available at each step. This is something you cannot do with sixteen independent terminal sessions. You cannot even do it with most human teams. For a week, I was running a virtual company. And the virtual company was shipping code. Then the tokens ran out</h2> Nobody talks about this part when they discuss agent orchestration: the economics. During the Christmas holiday period, Anthropic’s 20x Max subscription was unusually generous with token limits. I do not know the exact numbers, but the allowance was noticeably higher than usual. I was burning through it. The problem was not the agents doing useful work. The problem was the agents talking to each other. In any organization, a significant portion of communication is overhead. Status updates. Clarifying questions. Acknowledging instructions. Confirming understanding. In a human company, this overhead is accepted because humans need it to function. In an agent company, every word of that communication costs tokens. I watched my weekly token budget evaporate. Not because the agents were writing code, although they were. Because the squad leads were having lengthy exchanges with their teams about task requirements. Because agents were asking clarifying questions that a slightly better prompt would have made unnecessary. Because the escalation chain, every step of it, required a full context window of conversation. Token budget (weekly) ===================== Useful work (code, tests, docs) ████████░░░░░░░░░░░░ ~35% Agent-to-agent coordination ██████████████░░░░░░ ~40% Escalation chain overhead ████████░░░░░░░░░░░░ ~15% Clarifying questions / retries ████░░░░░░░░░░░░░░░░ ~10% ^^^^^^^^^^^^^^^^^^^^ |---- productive ---|--- overhead ---| The overhead was not a bug. It was the cost of coordination. The same cost human companies pay in salaries for meetings, Slack threads, standups, and status reports. The difference: human overhead is a fixed cost. Token overhead scales with every message.</code></pre> It was the AI equivalent of employees standing around the coffee machine. Except every minute at the coffee machine cost real money. When the holiday period ended and the token limits returned to normal, shiioo became impractical for my situation. I have more than ten active projects. I need to decide, deliberately and granularly, what my limited token budget goes toward. A virtual company that autonomously allocates its own token spend, no matter how effectively, does not give me that control. I stopped using it. Not because the architecture was wrong. Because the economics did not fit my constraints. The management lesson</h2> Every problem I encountered was a management problem that real companies have solved, or at least learned to live with. The coordination problem: sixteen independent workers producing inconsistent output. Solved the same way companies solve it. Hierarchy, defined roles, communication channels. The overhead problem: too much communication relative to productive work. Every manager knows this. Every company struggles with it. The optimal amount of coordination is not zero and it is not “as much as possible.” It is somewhere in between, and finding that point is one of the hardest problems in organizational design. The economics problem: the work gets done, but the cost of the work exceeds the budget. This is not a technology problem. This is a business problem. And it has different answers at different scales. For an individual developer on a consumer subscription, shiioo’s overhead is too expensive. The token cost of agent-to-agent communication eats into the budget for actual work. I need to be hands-on, directing each agent personally, because my token budget is small enough that every token should go toward output I directly value. For an enterprise with API access and a meaningful budget, the calculus is completely different. If you are paying for engineering time at market rates, the token cost of agent coordination is a rounding error compared to the cost of human coordination. The overhead that made shiioo impractical for me, agents discussing requirements, leads resolving conflicts, escalation chains processing decisions, would be a bargain for a company that currently pays humans to do the same thing at 100x the cost and 10x the latency. Individual developer (consumer sub) Enterprise (API access) ==================================== ==================================== Token budget: limited, weekly cap Token budget: pay per use, large Overhead cost: eats into real work Overhead cost: rounding error Control need: high (every token Control need: moderate (aggregate must count) ROI matters) +----------+ +----------+ | Useful | <-- want to maximize | Useful | <-- still majority | work | this slice | work | +----------+ +----------+ | Overhead | <-- this hurts | Overhead | <-- acceptable cost +----------+ +----------+ | Budget | | | +----------+ | Room to | (no room) | grow | +----------+ Same architecture. Different economics. Different answer.</code></pre> Then OpenClaw happened</h2> A few weeks after Christmas, OpenClaw</a> launched and crossed 100,000 GitHub stars within its first week. The community was impressed. A personal AI agent framework with multi-agent support, tool integrations, and an approachable setup experience. I looked at it and felt a mix of recognition and mild frustration. OpenClaw solved the “how do I run an AI agent” problem elegantly. But shiioo was solving a different problem. Not “how do I run agents” but “how do I run an organization of agents.” Hiring, delegation, escalation, governance, audit trails, budget management. The boring, structural, enterprise problems that do not demo well but determine whether agent orchestration actually works at scale. OpenClaw is a good tool for individuals. What I built, rough as it was, is a sketch of what enterprises will need when they move past “we have an AI assistant” to “we have an AI workforce.” Those are fundamentally different problems, and they require fundamentally different architectures. I do not say this to diminish OpenClaw. I say it because I think the industry is still mostly working on the first problem while the second one is coming fast. What I would do differently</h2> If I were building shiioo again today, three things would change. First, the communication protocol between agents needs to be structured and minimal. Free-form conversation between agents is expensive and produces the same rambling overhead that plagues human Slack channels. Agents should exchange typed messages with defined schemas. Not “hey, I was thinking about the API design and I wonder if we should consider…” but { type: "design_decision", scope: "api", proposal: "...", requires_approval: true }</code>. Every token in agent-to-agent communication should carry information, not politeness. Second, the token budget needs to be a first-class resource managed by the system, not an afterthought. Every agent should have a token allowance. Every escalation should have a cost. The system should make tradeoff decisions about whether a clarifying question is worth the tokens, the same way a well-run company makes tradeoff decisions about whether a meeting is worth the calendar time. Third, I would separate the orchestration layer from the LLM provider entirely. shiioo was built around the Anthropic Messages API. It should have been built around an abstract capability interface where the provider is a pluggable backend. Not for vendor neutrality as a principle, but because the economics change when you can route low-stakes agent communication through a smaller, cheaper model and reserve the frontier model for decisions that actually require it. Task type Model tier Cost per 1K tokens ========== ========== ================== Strategic decisions Frontier $$$$ (architecture, design) (Opus, GPT-5) | v Squad lead coordination Mid-tier $$ (conflict resolution, (Sonnet, GPT-4o) task assignment) | v Agent-to-agent comms Small/fast $ (status, ack, handoff) (Haiku, GPT-4o-mini) Route by decision weight, not uniformly. Most tokens go to the cheapest tier. Most value comes from the expensive tier.</code></pre> What this means for actual enterprises</h2> I ran my virtual company for a week across personal projects. It was an experiment. But the patterns I stumbled into are not experimental. They are the same patterns that every large organization will need to operationalize as agentic employees become real line items on the org chart. This is not a distant future. Companies are already deploying AI agents for customer support, code review, compliance checks, and data pipeline management. What most of them have not done yet is think about what happens when those agents need to coordinate. When the support agent needs to escalate to the engineering agent. When the compliance agent needs to block a deployment the CI agent is trying to push. When three agents working on the same codebase need to not step on each other. The companies that figure this out first will have a structural advantage that compounds. Consider a mid-size engineering organization. Two hundred engineers. They spend, conservatively, 30% of their time on coordination. Standups, planning meetings, Slack threads, code review discussions, design document feedback loops, incident response coordination. That is sixty full-time-equivalent salaries spent on people talking to each other about work rather than doing it. Nobody questions this cost because it has always been the cost of building software with humans. Now replace even a fraction of that coordination layer with agents. Not the engineers themselves. The coordination between them. An agentic squad lead that triages incoming tickets, assigns them based on skill match, checks for conflicts with in-flight work, and only escalates to a human lead when the decision genuinely requires human judgment. An agentic project manager that tracks dependencies across teams, flags blockers before they become crises, and generates status updates from actual commit history instead of asking twelve people to fill out a spreadsheet. </th> Today</th> Near future</th></tr></thead> Coordination</td> All human, expensive, slow, lossy</td> Mostly agents, cheap, fast, auditable</td></tr> Status updates</td> Asked for weekly (often stale by the time they reach leadership)</td> Generated from event logs (always current)</td></tr> Conflict detection</td> Someone notices during code review (after the work is done)</td> Automatic, flagged before work begins</td></tr> Escalation</td> Informal, depends on who knows whom</td> Structured, policy-driven, with full context</td></tr> </tbody></table> The organizations that will benefit most are not the ones with the best AI models. They are the ones that treat agent orchestration as an organizational design problem. That means defining clear scopes of authority, building escalation paths that preserve context, implementing approval gates that match their governance requirements, and maintaining audit trails that satisfy compliance. These are not engineering problems. They are operations problems. And most companies already have people who know how to solve them. They are called managers. The irony is that the skills most relevant to the agentic enterprise are not machine learning or prompt engineering. They are the skills that good managers have always had: defining clear responsibilities, building trust through transparency, knowing when to delegate and when to intervene, and designing systems where people, or agents, can do their best work without tripping over each other. Every enterprise will need to answer a specific set of questions in the next few years. How do you onboard an agentic employee? How do you define its scope? What happens when it makes a mistake? Who is accountable? How do you audit its decisions? How do you revoke its access? These questions sound like IT governance, and they are. But the answers will reshape how companies think about headcount, team structure, and operational capacity in ways that most leadership teams have not begun to consider. The companies that start experimenting now, even crudely, even with something as rough as what I built over a holiday week, will have a vocabulary and a set of institutional patterns that the latecomers will not. And in organizational design, having the right patterns early matters more than having the best technology late. Where this goes</h2> I still believe the virtual company model is the right abstraction for large-scale agent orchestration. It solves the same coordination problems that human organizations solve, using the same structural patterns that have been refined over decades of organizational theory. The technology is ready. The architectures are straightforward. The missing piece is the economics. When frontier model inference costs drop by another order of magnitude, and they will, the token overhead of agent-to-agent communication stops being prohibitive. When that happens, the question will not be “should we orchestrate agents in a hierarchy” but “what does the org chart look like.” I suspect we are closer to that moment than most people think. And when it arrives, the hard problems will not be technical. They will be the same problems that have always made management hard: delegation, trust, accountability, and knowing when to let your people work and when to step in. The agents are ready to work. We just need to learn how to manage them. References</h2> kage: Local-first agentic work orchestrator</a></li> shiioo: Virtual Company OS</a></li> OpenClaw: Personal AI agent framework</a></li> Ghostty terminal emulator</a></li> alacritty_terminal crate</a></li> </ul> Why We Built a Haskell Package Manager in Rust Unknown — Mon, 13 Apr 2026 00:00:00 +0000 Why would anyone invest serious engineering effort into Haskell tooling in 2026? Haskell is a niche language. It has been a niche language for thirty years. Most companies do not use it. Most developers have never written a line of it. If you are going to pour months of work into building a package manager and toolchain from scratch, in Rust no less, the obvious question is: why not just use Rust? The answer is the same one I gave in The Last Programming Language Might Not Be for Humans</a>: the way we write software is changing. AI is becoming the primary author of code, and the languages that will matter most in that future are not the ones optimized for human typing speed. They are the ones optimized for formal correctness, composability, and provability. Haskell is not niche in that framing. It is early. I have written before</a> about why Haskell shaped the way I think. The short version: Haskell teaches you to think about programs as compositions of well-typed transformations, and that discipline makes you better at everything else. I still believe this. I write most of my production software in Rust, but I think in Haskell. The problem was never the language. The problem was everything around it. The state of Haskell tooling</h2> If you want to start a Haskell project today, you install ghcup, which manages GHC (the compiler), Cabal (the build tool), Stack (a different build tool), and HLS (the language server). Then you decide whether to use Cabal or Stack, which is a decision that has split the Haskell community for over a decade and which nobody has fully resolved. Then you configure your project, using either a .cabal</code> file (a custom format that predates TOML, YAML, and JSON as configuration languages) or a stack.yaml</code> plus a .cabal</code> file (because Stack still needs Cabal files underneath). Then you wait for GHC to compile your dependencies, which takes long enough that you start questioning your life choices. I have introduced Haskell to teams and watched the enthusiasm drain from people’s faces during the toolchain setup. Not because the language was hard, but because the first thirty minutes were spent fighting ghcup</code>, cabal update</code>, resolver mismatches, and cryptic build errors that had nothing to do with the code they wanted to write. A typical first encounter: you want to write a small HTTP server. You install ghcup, install GHC 9.8.2, run cabal init</code>, and get a .cabal</code> file with a dozen fields you do not understand yet. You add warp</code> as a dependency and run cabal build</code>. GHC starts compiling warp</code> and its transitive dependencies: http-types</code>, bytestring</code>, text</code>, network</code>, streaming-commons</code>, vault</code>, wai</code>, and about forty others. Four to six minutes on a modern machine. Every time you switch GHC versions or clean your cache, you pay that cost again. Now compare this with Rust. You run cargo new my-server</code>. You add axum</code> to Cargo.toml</code>. You run cargo build</code>. It compiles. The first build is not instant either, but cargo</code> does not ask you which of two incompatible build tools you prefer, does not require a separate tool to manage the compiler, and does not present you with a configuration format from 2005. Or Python. uv init my-server</code>. uv add fastapi</code>. uv run</code>. Done. The entire dependency resolution and installation takes less than a second because uv</code> resolves and installs in parallel, in Rust, without spawning Python. Every major language ecosystem has converged on the same answer: one tool that handles project creation, dependency management, building, testing, and publishing. Haskell has three tools that each do part of the job, disagree about how dependencies should work, and require a fourth tool to manage the compiler itself. People have been talking about Haskell’s tooling problem for years. I decided to do something about it the way astral.sh</a> did for Python: rewrite the developer experience from scratch, in Rust, and make everything dramatically faster. The astral.sh playbook</h2> When Astral released uv</code> and ruff</code>, it proved something important. You can take a mature ecosystem with deeply entrenched tooling, rebuild the developer experience in Rust, and people will switch, because the new tools were fast enough and coherent enough that the switching cost paid for itself immediately. Python’s tooling situation before uv</code> was remarkably similar to Haskell’s. pip</code>, pip-tools</code>, pipenv</code>, poetry</code>, conda</code>, virtualenv</code>, venv</code>, pyenv</code>. Each solved part of the problem. Each had opinions that conflicted with the others. Setting up a Python project from scratch meant choosing a stack of tools, hoping they worked together, and accepting that your lockfile format depended on which combination you picked. Astral did not try to fix any single tool. They rewrote the experience. uv</code> is a single Rust binary that does what pip</code>, pip-tools</code>, virtualenv</code>, and pyenv</code> did, but 10-100x faster and with a coherent interface. ruff</code> is a single Rust binary that does what flake8</code>, isort</code>, pycodestyle</code>, and pyflakes</code> did, but 100x faster. The Python community switched because the tools were obviously better the first time they used them. The playbook has three steps: Wrap first. Use the existing tools under the hood rather than reimplementing everything. uv</code> wraps pip’s package index and resolver logic. hx wraps GHC and Cabal.</li> Tame second. Add better error messages, faster startup, unified configuration, and workflows that make sense. This is where most of the user-facing value lives.</li> Replace last. Only replace underlying components when you have to. For hx, that meant building a native build mode that bypasses Cabal entirely for simple projects, and a native dependency resolver in Rust that is 24x faster than Cabal’s constraint solver.</li> </ol> This approach is pragmatic in a way that matters. You do not need to rebuild the world to improve the experience. You need to rebuild the surface. The parts that people touch every day. Why Rust</h2> The choice to build hx in Rust is a direct response to a structural problem. Haskell’s existing tooling is written in Haskell. This creates a bootstrap problem. To build the build tool, you need the compiler. To install the compiler, you need the compiler manager. To build the compiler manager, you need a compiler. The dependency chain is circular, and every link in it is slow to compile. Think about what this means in practice. You are a new developer. You want to try Haskell. You download ghcup. ghcup is a shell script that downloads a pre-built GHC binary, but it also installs Cabal, which is itself a Haskell binary compiled with GHC. If the pre-built binary does not exist for your platform, you need GHC to build Cabal, but you need Cabal to set up GHC. The bootstrap documentation exists because the bootstrap problem exists, and it exists because the tools are written in the language they manage. GHC’s runtime system adds initialization overhead to every invocation. When you type cabal build</code>, the first 45 milliseconds are spent starting the GHC runtime before Cabal even begins to think about your project. Stack is worse at 89 milliseconds. These numbers sound small until you are running commands in a tight development loop, hitting save and expecting the build to start instantly. Or in CI, where the build tool is invoked hundreds of times across a pipeline and those milliseconds compound into minutes. hx starts in 12 milliseconds. A native binary without a garbage-collected runtime does not need to initialize one. The tool should not have the same dependencies as the thing it manages. hx build # 12ms startup + build time cabal build # 45ms startup + build time stack build # 89ms startup + build time </code></pre> Memory tells the same story: Tool</th> Startup memory</th> Build memory (simple project)</th></tr></thead> hx</td> 8 MB</td> 45 MB</td></tr> cabal</td> 45 MB</td> 250 MB</td></tr> stack</td> 85 MB</td> 320 MB</td></tr> </tbody></table> For a tool you invoke constantly, this matters. Especially on CI runners with constrained memory, or on a laptop where you have four terminal panes open with different projects. The Rust decision also solves the distribution problem. A Rust binary is a single static executable that cross-compiles trivially. No runtime dependencies. No “install GHC first so you can install the tool that installs GHC.” curl | sh</code> and you are running. hx is available via the install script, Cargo, aqua, winget on Windows, and Homebrew. Every distribution channel ships a self-contained binary. What hx actually does</h2> hx replaces the cabal + stack + ghcup + fourmolu + hlint</code> workflow with a single binary: curl -fsSL https://arcanist.sh/hx/install.sh | sh hx new my-app && cd my-app hx run </code></pre> No ghcup. No stack. No cabal-install. One tool, one configuration file, one lockfile format. Configuration</h3> The configuration is hx.toml</code>. Not a .cabal</code> file with its custom syntax that nobody can parse without a library. Not a stack.yaml</code> with YAML indentation traps. TOML, the same format that Rust (Cargo.toml</code>), Python (pyproject.toml</code>), and most modern tools have converged on. [project] name = "my-app" kind = "bin" [toolchain] ghc = "9.8.2" [build] optimization = 2 warnings = true [format] formatter = "fourmolu" [lint] hlint = true [hooks] pre-build = "scripts/generate-version.sh" post-test = "scripts/notify.sh" </code></pre> Everything in one file. The toolchain version is pinned per-project, so different projects can use different GHC versions without conflict. When you run hx build</code> in a project pinned to GHC 9.8.2 and another pinned to 9.6.4, hx switches automatically. No ghcup set</code> commands. No global state. Lockfiles</h3> The lockfile is also TOML. Every dependency is pinned with a sha256 fingerprint: version = 1 ghc = "9.8.2" created_at = "2026-01-16T00:00:00Z" [[package]] name = "aeson" version = "2.2.1.0" sha256 = "a5a5b8a..." deps = ["base", "text", "bytestring"] </code></pre> hx lock --check</code> in CI fails if the lockfile is stale. This is deterministic by default. Not “deterministic if you remember to run cabal freeze</code> and commit the freeze file and hope nobody ran cabal update</code> on a different machine.” Deterministic the way cargo</code> and uv</code> are deterministic. Automatically. Every time. If you are coming from Stack, you might say “Stack already has lockfiles.” It does. Stack’s approach is to pin to a Stackage snapshot, which gives you a curated set of packages known to work together. This is a valid approach, but it means your dependency versions are dictated by what the Stackage maintainers decided to include in that snapshot. If you need a newer version of a package that is not in the current LTS, you start adding extra-deps</code>, and your reproducibility guarantees become more complex. hx resolves from Hackage directly, pins every version, and verifies checksums. You control exactly what you get. Native builds</h3> For simple projects with only base</code> dependencies, hx has a native build mode that bypasses Cabal entirely. It constructs the module graph itself and invokes GHC directly: Operation</th> hx native</th> hx (cabal backend)</th> cabal</th> stack</th></tr></thead> Cold build</td> 0.48s</td> 2.52s</td> 2.68s</td> 3.2s</td></tr> Incremental</td> 0.05s</td> 0.35s</td> 0.39s</td> 0.52s</td></tr> Single file change</td> 0.31s</td> 1.42s</td> 1.42s</td> 1.8s</td></tr> </tbody></table> 5.6x faster cold builds. 7.8x faster incremental builds. The difference comes from eliminating Cabal’s package database queries, build plan calculation, and job scheduling overhead. Where does the time go in a normal Cabal build? Roughly: runtime initialization (45ms), reading the package database (80-120ms), computing the build plan (200-400ms depending on dependency count), checking file timestamps through the Cabal build system (100-200ms), and only then invoking GHC. hx native mode skips all of that. It reads file timestamps directly, constructs a minimal module graph, and calls GHC with exactly the flags needed. For projects with external dependencies, hx falls back to the Cabal backend transparently. You do not have to think about it. Dependency resolution</h3> hx includes a native dependency resolver written in Rust. The hx-solver</code> crate implements constraint resolution using the same algorithm as Cabal’s solver, but without the overhead of GHC’s runtime: Direct dependencies</th> hx</th> cabal</th></tr></thead> 10 packages</td> 5ms</td> 120ms</td></tr> 20 packages</td> 18ms</td> 450ms</td></tr> 50 packages</td> 85ms</td> 2.8s</td></tr> 100 packages</td> 320ms</td> 12.5s</td></tr> </tbody></table> At 100 dependencies, hx resolves in 320 milliseconds. Cabal takes 12.5 seconds. In a real-world test with 20 direct dependencies and their transitive closure, hx resolved in 1.2 seconds versus 8.5 seconds for cabal freeze</code>. Stack’s resolver is faster at 0.8 seconds because Stackage snapshots are pre-computed, but you trade resolution speed for version flexibility. Error messages</h3> Haskell’s reputation for cryptic error messages is partly deserved and partly a tooling problem. GHC type errors can be daunting, but build tool errors are often worse because they mix configuration issues with compilation issues in unhelpful ways. “Could not resolve dependencies” from Cabal tells you almost nothing about which constraint is blocking resolution or what you could change to fix it. hx uses structured error codes with actionable suggestions: E0012: Package 'aeson' not found in local index The package index may be outdated. Run: hx index update Or add the package explicitly: Run: hx add aeson </code></pre> E0020: GHC version mismatch Project requires GHC 9.8.2 but 9.6.4 is active. Run: hx toolchain install 9.8.2 </code></pre> Every error has a code, a human-readable explanation, and a concrete command to fix it. hx doctor</code> runs a comprehensive diagnostic of your entire environment, checking GHC, Cabal, HLS, PATH configuration, and project setup, reporting exactly what is wrong and how to fix each issue. Everything else</h3> hx bundles the rest of the development workflow too. hx fmt</code> wraps fourmolu for formatting. hx lint</code> wraps hlint. hx coverage --html --open</code> generates an HTML coverage report and opens it in your browser. hx doc --open</code> builds Haddock documentation and serves it locally. hx watch</code> detects file changes in 15 milliseconds (versus 180ms for stack --file-watch</code>) and triggers rebuilds or test runs. hx profile --heap</code> generates heap profiles for memory analysis. The goal is that you should never need to leave hx to do something with your Haskell project. Not because hx reimplements everything, but because it wraps the best existing tools with a consistent interface and fast orchestration. There is also a plugin system using Steel, a Scheme dialect, for custom build lifecycle hooks: ;; .hx/plugins/check-todos.scm (define (on-build-success project) (when (file-exists? "TODO.md") (warn "Do not forget to update TODO.md"))) (register-hook 'post-build on-build-success) </code></pre> Plugins live in .hx/plugins/</code> and time out after a configurable interval so a misbehaving script cannot stall your build. They hook into pre-build, post-build, pre-test, post-test, and other lifecycle events. Lightweight enough that you can add project-specific automation without maintaining a separate build script. Migration</h3> If you have an existing project, hx can import it: hx init --from-cabal # Import from an existing .cabal project hx init --from-stack # Import from a Stack project </code></pre> It reads your existing configuration, generates hx.toml</code>, creates a lockfile, and you are running. The .cabal</code> file is preserved for compatibility. hx reads it for package metadata and dependency specifications, but the build configuration and toolchain management move to hx.toml</code>. The architecture</h2> hx is structured as a Rust workspace with 14 crates: hx-cli | +-------------+-------------+ | | | hx-core hx-config hx-ui | | +---------+---------+ | | | | | hx-cabal hx-solver hx-lock | | hx-cache hx-toolchain | hx-doctor Separate concerns: hx-plugins, hx-lsp, hx-warnings, hx-telemetry</code></pre> Each crate has a single responsibility. hx-solver</code> knows how to resolve dependencies but nothing about building. hx-cabal</code> knows how to invoke Cabal but nothing about configuration. hx-toolchain</code> manages GHC installations but nothing about lockfiles. This separation means you can test the resolver without setting up a build environment, and you can change the build backend without touching the resolver. The hx-lsp</code> crate is worth calling out. It provides language server protocol support, which means hx can manage HLS (Haskell Language Server) versions matched to your project’s GHC version. When your project uses GHC 9.8.2, hx ensures HLS is compatible. No more “HLS crashed because it was compiled with a different GHC than your project uses.” This is a problem that has frustrated Haskell developers for years, and it is entirely a tooling coordination problem. The bigger picture</h2> I built hx because I needed it. But the timing is not accidental. In The Last Programming Language Might Not Be for Humans</a>, I laid out three futures for programming languages as AI becomes the primary author of code. The first future is explicit languages designed to minimize LLM errors through tight feedback loops. The second is declarative languages where code describes what something is rather than how to compute it, and the type system acts as a proof checker. The third is no language at all, where AI generates machine code directly. I bet on the second future. When an LLM writes imperative code, it has to track mutable state across dozens of lines, reason about the order of side effects, and hold implicit language behaviors in context. When it writes Haskell, it expresses a relationship between inputs and outputs, and the compiler verifies that the relationship is consistent. The model does not need to simulate execution step by step. It needs to generate an expression that satisfies type constraints. This is what LLMs are good at. Pattern recognition. Constraint satisfaction. Formal structure. Consider what happens when an AI generates a Haskell function with a wrong type. The compiler does not produce a vague runtime error three layers deep in a call stack. It produces a precise, localized type error at compile time: “Expected [LogEntry] -> [ErrorSummary]</code>, got [LogEntry] -> [LogEntry]</code>.” The model reads this, adjusts, and re-generates. The feedback loop is tight, but unlike the explicit-language approach, the tightness comes from the type system itself, not from bolted-on contracts. The correctness guarantees are structural, not ceremonial. This matters even more when you think about code that has to survive time. Procedural code decays. Three years from now, nobody remembers why a function mutates a global variable on line 47. The variable name made sense to whoever wrote it. The mutation order made sense in the context of the original design. But context evaporates. Types do not. A function signature that says Request -> Policy -> Decision</code> is self-documenting in a way that no amount of comments on imperative code can match. The proof is in the types, and the types are checked by the compiler, not by human memory. But none of that matters if nobody can set up a Haskell project without losing thirty minutes to toolchain configuration. The language’s virtues are locked behind a tooling wall. You can have the most expressive type system in production use, the most rigorous correctness guarantees, the best theoretical fit for agent-assisted development, and it means nothing if a developer’s first experience is fighting ghcup</code> for half an hour. First impressions are permanent, and Haskell’s first impression has been “powerful but painful” for too long. If Haskell is going to be relevant in a world where AI writes most of the code, the experience of using Haskell has to be as fast and frictionless as the experience of using Rust or Python. Not comparable. Equal. That is what hx is for. To remove the tooling objection entirely, so the conversation can be about the language’s actual strengths instead of its ecosystem’s historical baggage. hx is the first step. BHC</a>, the Basel Haskell Compiler, goes further. GHC is a remarkable piece of engineering, but it was designed for a world where Haskell ran on desktops and servers with one performance profile. BHC is a clean-slate Haskell compiler, also written in Rust, offering six runtime profiles for different deployment targets: Server: structured concurrency with automatic cancellation, observability hooks, deadline-aware scheduling</li> Numeric: strict-by-default in hot paths, tensor lowering, SIMD auto-vectorization, GPU backends for CUDA and ROCm</li> Edge: minimal runtime footprint, direct WASM emission, designed for Cloudflare Workers and Fastly Compute</li> Realtime: bounded GC pauses under 1 millisecond, arena allocation, designed for games and audio processing</li> Embedded: no GC at all, static allocation, bare-metal targets like ARM Cortex-M</li> </ul> Same language. Same type safety. Different performance contracts depending on what you are building. Your security policy engine compiles with the server profile. Your tensor pipeline compiles with the numeric profile and runs on a GPU. Your edge function compiles to WASM. You do not change your source code. You change the compiler flag. hx already supports BHC as an alternative backend: hx build --compiler=bhc --profile=server </code></pre> One flag. Same project. Different runtime. The vision behind arcanist.sh</a> is that Haskell’s ideas deserve infrastructure that matches their ambition. The language has always been decades ahead of its tooling. hx closes the gap on the developer experience side. BHC closes it on the runtime side. Together, they make the case that Haskell is not a language for academics and hobbyists. It is a language for the era we are entering, where correctness is not a luxury, it is the load-bearing structure of software that AI writes and humans verify. The tooling is not separate from the thesis. The tooling IS the thesis. The Bet, What If I am Wrong</h2> This is a gamble. I do not know whether Haskell will go through a revival. Nobody knows how AI-assisted development will actually evolve, which languages will matter in five years, or whether the thesis I outlined in the previous post will hold up against what reality delivers. I have a conviction, not a crystal ball. I spent months building hx and BHC. Months of my own time, and to be perfectly blunt, a significant number of Anthropic’s Claude tokens. I pair-programmed most of this with Claude Code on my Max subscription, and that is not a footnote. It is part of the story. The tools I am building for AI-assisted Haskell development were themselves built using AI-assisted development. If that sounds circular, it is. The thesis tested itself during its own construction. But I could be wrong. Haskell could remain niche forever. The AI era could favor a language nobody has thought of yet. The intermediate layer might not evolve the way I expect. The industry might double down on Python and TypeScript for agent-assisted workflows and never look back. These are all plausible outcomes. So I build toward what I believe in and put the work out in the open. If I am right, Haskell gets the tooling it always deserved, and the language is ready when the moment arrives. If I am wrong, the ideas in hx and BHC, fast Rust-based tooling, deterministic lockfiles, multiple runtime profiles, structured error messages, are valuable regardless. Good infrastructure design does not expire just because the language it serves does not win the popularity contest. And honestly, even on the unlikely side, I would rather have tried and been wrong than watched from the sidelines while the most elegant language I have ever used slowly faded because nobody bothered to fix the parts that were not the language. At least I have tried. Try it</h2> curl -fsSL https://arcanist.sh/hx/install.sh | sh hx new my-app && cd my-app hx run </code></pre> Then try hx doctor</code>, hx fmt</code>, hx test --watch</code>. See how it feels when the tooling gets out of your way. hx is MIT-licensed and open source. If you have opinions about Haskell tooling, I want to hear them. The Last Programming Language Might Not Be for Humans Unknown — Sat, 11 Apr 2026 00:00:00 +0000 This morning I was standing at my desk, drinking watered-down instant coffee, doing what I do every morning after triaging the high-alert emails and notifications: thirty minutes of HackerNews. It is a ritual I time-box and never skip. I go to the office every day, and whether I am at that desk or at my home desk, the morning is the same. Coffee, posture, front page. HackerNews remains one of the best ways to keep a finger on the pulse of the Bay Area, of tech, of science, of whatever intellectually stimulating thought surfaced overnight. I follow a handful of curated newsletters too, but I have noticed over the years that HN covers most of their content anyway if you know how to filter high signal from low signal. I could write something about a different link every single day. Most mornings I resist. This morning I did not. A link caught my eye. Vera</a>, a new programming language “designed for machines to write, not humans.” Statically typed, purely functional, compiles to WebAssembly, uses Microsoft’s Z3 solver for contract verification. It has a ferret mascot. I like animal mascots for tech projects. Ferris the crab for Rust, the gopher for Go, the Shisa guardian dog for Zentinel</a>. The ferret is a good choice. But the mascot is not why I stopped scrolling. I stopped because somebody else had arrived at the same conclusion I had reached back in December: that conventional programming languages are not adapted to the capabilities of this new technology, and that something has to change. The Christmas realization</h2> I had been a paying Claude Code subscriber since May 2025, when Anthropic first launched it. The CLI orientation made sense to me immediately, even though the early rate limits and model quality left me wanting more. By December 2025, I had upgraded to the Max subscription, I was on vacation, and Anthropic had made the daily limits generous that month. I was burning through every idea I had accumulated over the years. Some were good. Some were terrible. All of them were finally testable in a way they had not been before, because I could pair-program with a model that kept up. I wrote about that shift more fully in How I Work These Days</a>, the short version being that late 2025 was when the relationship between ambition and execution fundamentally changed for me. The dam broke. Ideas that had been sitting in notebooks for years started becoming real software in days. It was during one of those late-night sessions, deep in a Claude Code conversation about compiler design, that a thought crystallized. I had been building hx</a> and thinking about how AI would change the way people write Haskell, when I realized the question was bigger than Haskell. Agent-assisted software development is approaching a point where the output language itself, the intermediate layer we use to express how information should be processed, is going to change fundamentally. This is not an abstract observation. The history of software is a history of abstraction layers accumulating, each one letting the next generation of programmers ignore what the previous generation had to master. It started with machine code. Raw opcodes, different for every CPU architecture. If you wanted to write software, you memorized instruction sets and wrote them by hand. People published thick reference manuals, and there were engineers who could hold entire instruction set architectures in their heads. Some of them are still around, and some of them still swear by that methodology. Then assemblers gave those opcodes human-readable names. MOV AX, BX</code> instead of 89 D8</code>. You were still writing for a specific architecture, still thinking in registers, but now you could read what you wrote. The first abstraction was not a new capability. It was legibility. Then C arrived and gave us a portable abstraction over hardware. You stopped thinking in registers and started thinking in functions and pointers. C compiled down to architecture-specific assembly, but you did not have to care which architecture. One language, many targets. The reference manuals shifted from instruction sets to language specifications. Then interpreters and virtual machines added another layer. The JVM, Python, Perl. You stopped thinking about memory layout and started thinking about objects, iterators, garbage collection. The abstraction was thicker, the feedback loop was faster, and the audience expanded from hardware engineers to anyone who could write a script. Then IDEs changed how you interacted with the language itself. Syntax highlighting, autocomplete, integrated debuggers, refactoring tools. You stopped holding the entire API surface in your head because the editor held it for you. The language did not change, but the cognitive cost of using it dropped. IntelliSense was not a language feature. It was an abstraction over the programmer’s memory. Then the internet changed how code moved. Open source repositories, package managers, shared libraries. You stopped writing everything from scratch and started composing from parts other people had built. The reference material moved from printed books to web documentation, wikis, tutorials. Then StackOverflow changed how people learned. Instead of reading manuals cover to cover, you searched for the specific problem you had and found someone who had already solved it. The knowledge layer itself became an abstraction. You did not need to understand the full system. You needed to find the right answer and adapt it to your context. StackOverflow never compiled a line of code, but it was an intermediate layer between human confusion and working software, and it was arguably more important to the average developer’s productivity than any language feature shipped in the same decade. And now StackOverflow is receding. Not because the answers got worse. Because the next abstraction layer arrived. AI coding agents do what StackOverflow did, finding known solutions to known problems, but they also do what StackOverflow never could: synthesize novel solutions, hold project context across files, and generate working code from intent descriptions. The pattern is the same as every previous transition. Each layer makes the previous one less essential, not by replacing it but by absorbing it into a higher-level abstraction. Programming languages have always been shaped by who writes them. Assembly was shaped by hardware engineers who thought in registers and opcodes. C was shaped by systems programmers who needed portable abstractions over memory. Python was shaped by people who wanted to get things done without fighting the syntax. COBOL was shaped by business analysts who wanted code that read like English. Every language carries the fingerprints of its intended author. If AI becomes the primary author of code, it follows that the language should adapt to that new author’s strengths and weaknesses. This is not a break from the pattern. It is the pattern, doing what it has always done. I kept coming back to three concrete possibilities. Three ways the intermediate layer could evolve. Not competing visions, exactly. More like three points on a timeline. Make the language explicit enough for machines</h2> Anyone who has spent real time with coding agents has seen the failure mode. You ask an LLM to write a Python function. The output looks plausible. It passes linting. The variable names are reasonable. The structure follows common patterns. Then it fails at runtime because of a subtle implicit behavior the model did not track. A default mutable argument that gets shared across calls. A generator that gets silently exhausted on second iteration. A method that returns None</code> instead of raising an exception because some library author decided that was more “Pythonic.” The model was not wrong about the algorithm. It was wrong about the language’s hidden behaviors. This is the problem Vera is trying to solve, and the first approach I had been contemplating. Take the simplicity and explicitness of Go, push it further, and design a language where every instruction, every method, every design pattern is as unambiguous as possible. No implicit behaviors. No naming ambiguity. No style choices. One canonical way to write everything, so that an LLM does not have to waste inference tokens reasoning about which of seventeen valid approaches to take. The language would need excellent compiler diagnostics. Not just “type mismatch on line 47,” but structured feedback that a model can parse, understand, and act on immediately. Rust and Elixir already do this well for humans. Do it even better, and do it for machines. The pipeline looks like this: +-------+ prompt +-------+ explicit +-----------+ | Human | -------------> | LLM | -------------> | Verifying | +-------+ +-------+ source | Compiler | ^ +-----------+ | | | structured error | | + suggested fix | +---------------------------+ | verified | v [correct program]</code></pre> The key insight is the feedback loop. The compiler does not just reject bad code. It explains what is wrong in terms the model can act on, with a concrete fix suggestion. The model re-generates. The compiler re-checks. You converge on correct code through iteration, and the tightness of that loop depends on how unambiguous the language is and how actionable the errors are. Vera is exactly this idea, executed with conviction. Here is what a function looks like: public fn safe_divide(@Int, @Int -> @Int) requires(@Int.1 != 0) ensures(@Int.result == @Int.0 / @Int.1) effects(pure) { @Int.0 / @Int.1 }</code></pre> No variable names at all. Parameters are referenced by type and positional index using De Bruijn slot notation. @Int.0</code> is the most recently bound integer, @Int.1</code> is the one before that. Every function must declare its preconditions (requires</code>), postconditions (ensures</code>), and side effects (effects</code>). The compiler verifies contracts statically using Z3 where possible and falls back to runtime checks for what it cannot decide at compile time. The design principle is sharp: the model does not need to be right, it needs to be checkable. The language constrains the space of valid programs so tightly that the compiler catches mistakes before execution and explains them in natural language. Division by zero is not a runtime exception. It is a contract violation caught during compilation. Think of it like this. Traditional languages are an open field. You can walk in any direction, and you might end up somewhere useful or you might walk off a cliff. Vera is a guided path with guardrails. You can only go certain directions, and every time you try to step off the path, a sign tells you exactly where to step instead. An LLM on an open field will wander. An LLM on a guided path will converge. The early benchmark results are interesting, if mixed. Kimi K2.5 apparently writes perfect Vera code, scoring 100% on VeraBench and beating its own Python and TypeScript scores. Other models do not fare as well. Claude Opus 4 scores 88% in Vera versus 96% in Python. The Vera team is honest about this variance, which I appreciate. The HackerNews discussion</a> was thin, twelve points and three skeptical comments, which tells you how early this conversation still is. The broader developer community has not engaged with this idea seriously yet. That will change. But there is something that bothers me about optimizing the language for how machines iterate on solutions. Look at the pipeline diagram again. The LLM is still generating step-by-step instructions. It is still describing HOW to do things, just with the ambiguity stripped out and the contracts made explicit. The machine still reasons through the process sequentially. You have reduced the noise in the feedback loop, but you have not changed the nature of the signal. The model is still writing recipes. They are just more precise recipes. What if you stopped writing recipes entirely? Describe what, not how</h2> The second idea starts from a different premise. Instead of making procedural code easier for AI to write correctly, change what you ask the AI to express. Let me make this concrete. Say you need to find the ten most recent server errors in a log. Here is how you would describe that process in a procedural language: errors = [] for entry in log_entries: if entry.status >= 500: errors.append({ "time": entry.timestamp, "path": entry.path, "code": entry.status }) errors.sort(key=lambda e: e["time"], reverse=True) return errors[:10] </code></pre> You are telling the machine: create an empty list. Walk through each entry. Check a condition. If it matches, build a dictionary and append it. Then sort the accumulated list by a key. Then take the first ten elements. Every step is an instruction. The machine has to track the mutable list, the iteration state, the sort, the slice. And if you get any step wrong, the others might still succeed, producing output that looks correct but is subtly broken. A missing reverse=True</code> and you silently get the oldest errors instead of the most recent. Here is the same thing in Haskell: recentErrors :: [LogEntry] -> [ErrorSummary] recentErrors = take 10 . sortBy (flip compare `on` time) . map toSummary . filter isServerError </code></pre> Read it bottom to top: filter server errors, transform each into a summary, sort by time descending, take ten. There is no mutable accumulator. No loop variable. No intermediate state. You are not describing a process. You are describing a relationship between the input and the output. The function says what the result IS, not how to compute it step by step. The type signature at the top, [LogEntry] -> [ErrorSummary]</code>, is a contract the compiler enforces. If toSummary</code> returns the wrong type, if isServerError</code> does not take a LogEntry</code>, if you accidentally compose functions in an order that does not type-check, the compiler rejects the program before it runs. Not with a vague “object has no attribute” at runtime. With a precise type error at compile time that tells you exactly which piece does not fit. This distinction matters enormously for AI. Think about what an LLM actually has to track in each case: Procedural (Vera, Python, Go) Declarative (Haskell) ================================ ================================ - mutable variables and their - input type current state at each step - output type - loop iteration progress - which transformations to compose - conditional branching outcomes - whether types align - order of side effects - implicit language behaviors - names and what they refer to</code></pre> The procedural model asks the AI to simulate execution in its head. The declarative model asks the AI to describe a transformation and let the compiler verify it. One plays to an LLM’s weakness (tracking state across many steps). The other plays to its strength (recognizing and generating patterns that satisfy formal constraints). The pipeline changes fundamentally: +-------+ prompt +-------+ type sigs +-----------+ | Human | -------------> | LLM | -------------> | Compiler | +-------+ +-------+ pure exprs +-----------+ | types align? / \ yes no | | v v [proven correct] [precise type error: "Expected LogEntry, got String at ...]</code></pre> No feedback loop needed in the happy path. If the types align, the program is correct by construction for the properties the type system tracks. The compiler is not iterating with the model. It is checking a proof. This is the approach I bet on. It is the reason this blog exists. Raskell, the name behind this site, is a portmanteau of Rascal (as in raccoon, which is my mascot) and Haskell. The language I have loved for years because of how elegantly it describes things close to mathematical proofs. QEDs, not TODOs. When you write a well-typed Haskell function, you are not just writing code. You are writing a proof that a certain transformation is valid, and the compiler is the proof checker. But loving Haskell and shipping Haskell in production are different experiences, and the gap between them is mostly tooling. The ecosystem is fragmented in a way that has frustrated people for over a decade. cabal</code>, stack</code>, ghcup</code>. Three tools that do overlapping jobs with different opinions about how dependencies should work. If you come from Python, imagine if pip</code>, poetry</code>, and pyenv</code> were all developed independently, with different lockfile formats, different resolver algorithms, and occasional incompatibilities. That was Haskell. Build times were slow. Error messages ranged from helpful to cryptic. The runtime assumed one performance profile fits every use case. If you wanted Haskell for edge functions, for embedded systems, for GPU-accelerated numerics, you spent as much time fighting the toolchain as writing the actual code. The language was right. The surrounding infrastructure was not. So I started building arcanist.sh</a>, taking the same approach that astral.sh</a> brought to Python tooling. When astral.sh released uv</code> and ruff</code>, it showed that you could take a mature ecosystem with entrenched tooling, rebuild the developer experience from scratch in Rust, and make everything dramatically faster and more coherent. I wanted to do the same for Haskell. arcanist.sh houses two projects. hx</a> is a fast, opinionated, next-gen toolchain for Haskell, built in Rust. One tool that replaces the fragmented stack. Managed compiler versions pinned per-project. Deterministic TOML lockfiles with fingerprint verification. 5.6x faster cold builds than cabal. 7.8x faster incremental rebuilds. curl -fsSL https://arcanist.sh/install.sh | sh hx new my-app && cd my-app hx run </code></pre> No ghcup. No stack. No cabal-install. Just hx</code>. BHC</a>, the Basel Haskell Compiler, goes further. It is a clean-slate Haskell compiler written in Rust, not a GHC fork, targeting the Haskell 2026 Platform specification. It uses LLVM for native code generation and offers six runtime profiles that you select at compile time: Profile</th> Designed for</th> Key trait</th></tr></thead> default</td> General applications</td> Lazy evaluation, GC-managed, GHC-compatible semantics</td></tr> server</td> Backend services</td> Structured concurrency, automatic cancellation, observability hooks</td></tr> numeric</td> ML and scientific compute</td> Strict numerics, tensor lowering, SIMD, GPU backends (CUDA/ROCm)</td></tr> edge</td> WASM and CDN workers</td> Minimal footprint, direct WASM emission without LLVM</td></tr> realtime</td> Games, audio, robotics</td> Bounded GC pauses under 1ms, arena allocation</td></tr> embedded</td> Bare metal, microcontrollers</td> No GC at all, static allocation, targets like ARM Cortex-M</td></tr> </tbody></table> The same Haskell source, different runtime contracts depending on what you are building. Your security policy engine compiles with the server profile and gets structured concurrency with tracing. Your tensor pipeline compiles with the numeric profile and gets GPU acceleration. Your edge function compiles to WASM and runs on Cloudflare Workers. Same language. Same type safety. Different performance envelopes. The conviction behind this work is specific. When AI writes the code, the language that survives is not the one optimized for procedural explicitness. It is the one that brings consistency and purity by describing what something is, not how to compute it. AI is extraordinarily good at generating expressions that satisfy formal constraints. And source code that reads like a proof can survive time. It can survive maintainer burnout. It can survive the fact that three years from now, nobody remembers why a function was written the way it was. The types remember. The proof is self-documenting in a way that procedural code never is, because the types encode the intent. Vera and arcanist.sh accept the same premise: the intermediate layer is changing. They disagree about which direction it should change in. Vera optimizes for reducing errors in the generation loop. Valuable. But hx and BHC optimize for making the generated code correct by construction, because the language itself constrains what valid programs look like at a structural level. Skip the language entirely</h2> The third possibility is the one I think about late at night and do not have a concrete project for. Not yet. It is also the one I find most fascinating and most unsettling. What if AI stops writing source code at all? To understand why this is plausible, it helps to look at what source code actually is. It is not the final product. It never was. Source code is a set of instructions that a compiler transforms into machine code. Machine code is what the hardware executes. Source code exists because humans needed an abstraction layer between their intentions and the silicon. We think in concepts like “sort this list” or “reject unauthorized requests.” The CPU thinks in register moves, memory loads, and conditional jumps. Source code bridges that gap. But that bridge was built for human authors. If the author is no longer human, the bridge serves a different purpose. It becomes an audit trail. A way for humans to read and verify what the AI produced. Not an authoring medium, but a transparency layer. I see this playing out in two distinct phases. Phase one: AI targets existing machine code</h3> The first phase is closer than most people think, and it is conceptually straightforward. We already train models on source code. What happens when we also train them extensively on compiled artifacts? On binaries, object files, intermediate representations, the actual output of compilers? Consider what a compiler does. It takes source code and transforms it into machine instructions following well-defined, deterministic rules. There is a mapping between source patterns and output patterns. A for</code> loop in C becomes a specific sequence of compare, branch, and increment instructions on x86. A function call follows a specific calling convention. Memory allocation follows specific system call patterns. These mappings are learnable. They are patterns, and pattern recognition is exactly what LLMs excel at. Today: human intent → prompt → LLM → source code → compiler → x86/ARM → CPU Phase one: human intent → prompt → LLM → x86/ARM directly → CPU (trained on source + compiled artifact pairs)</code></pre> In this phase, the model skips the source code layer and generates machine code directly. Not by “compiling” in the traditional sense. By having learned the patterns well enough to produce valid executables from intent descriptions. The way a fluent translator does not parse grammar rules consciously but produces correct sentences from meaning directly. This sounds radical until you remember that we already trust compilers we do not read the output of. When was the last time you inspected the assembly output of gcc -O3</code> to verify it correctly compiled your C program? You trust the compiler. You test the behavior of the resulting binary. You do not audit the intermediate representation. If an AI can produce binaries that pass the same behavioral tests, the practical difference between “AI-generated machine code” and “compiler-generated machine code” becomes a question of trust calibration, not fundamental possibility. The analogy I keep returning to is aviation. Early pilots flew by hand and understood every mechanical system in the aircraft. Fly-by-wire changed that. The pilot communicates intent (climb, turn, maintain altitude). The computer translates that into control surface movements. The pilot does not manually adjust ailerons and elevators for every gust of wind. They trust the system. They verify outcomes (altitude, heading, airspeed), not intermediate steps. Phase one of post-language programming is fly-by-wire for software. If this sounds speculative, consider what happened this week. Anthropic announced Project Glasswing</a>, a coalition including AWS, Apple, Google, Microsoft, NVIDIA, CrowdStrike, Palo Alto Networks, the Linux Foundation, and others, formed to secure the world’s most critical software using AI. Dario Amodei, Anthropic’s CEO, put it plainly: “AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.” </blockquote> The proof point he offered: “For OpenBSD, we found a bug that’s been present for 27 years.” Think about what that means. OpenBSD is one of the most carefully audited codebases in the world. Decades of security-focused human review by some of the most meticulous systems programmers alive. And an AI model found something that every human reviewer missed for twenty-seven years. If AI can understand existing code deeply enough to find vulnerabilities that humans cannot, it can understand code deeply enough to generate it without human-readable source as an intermediate step. The question is no longer whether AI comprehends code at a structural level. That question was answered this week. The question is what it does with that comprehension next. Phase two: a new kind of machine</h3> The second phase is further out and more speculative. But I think it is where things ultimately go. If AI is generating code for machines to execute and no human needs to read it, there is no reason that code needs to target instruction sets designed for human comprehension. x86 and ARM were designed with the assumption that someone, at least occasionally, would look at the instructions. They have mnemonics. They follow conventions that make disassembly feasible. They are organized into instructions that map, loosely, to operations humans understand. But what if the execution target was designed from scratch for AI-generated code? A virtual machine or runtime that consumes a new kind of bytecode. Not optimized for human readability. Not optimized for hand-authored assembly. Optimized purely for execution density and machine generation. Phase two: human intent → prompt → AI → dense symbolic bytecode → AI-native VM (opaque to humans, | optimized for machine v generation + execution) [result]</code></pre> I keep thinking about information density. Chinese characters encode meaning in individual symbols that carry far more semantic weight than Latin alphabet words. A single character can represent a concept that takes an entire English phrase to express. When a system is designed for readers who can process dense symbols natively, the representation compresses. It becomes more efficient at the cost of being less accessible to readers who were not part of the design audience. AI-native bytecode could follow the same principle. Each instruction could encode complex composite operations that would take dozens of conventional instructions to express. The bytecode would be dense in ways that make current machine code look verbose. Entirely opaque when decompiled or analyzed. Not obfuscated on purpose. Just natively incomprehensible to human cognition, the same way a trained neural network’s weights are incomprehensible even though they encode real, functional knowledge. The virtual machine running this bytecode would itself be a different kind of system. Not a stack machine or a register machine in the traditional sense. Possibly something closer to a dataflow engine, where the bytecode describes transformation graphs rather than sequential instructions. Think of it as the difference between giving someone turn-by-turn driving directions (go north, turn left, continue for two miles) versus handing them a map with the destination marked. The bytecode is the map. The VM figures out the route. I want to be honest about where we are. We are not at phase one. Not in April 2026. Current models still need the intermediate layer. They produce better code when they can reason through it step by step. They benefit from type systems and contracts and explicit error messages. The first and second approaches are not just viable, they are necessary right now. But the trajectory is visible. Models are getting better at generating correct programs with every generation. Formal verification is becoming more practical. Hardware is getting cheaper. The gap between “prompt that describes intent” and “correct executable output” is shrinking. Phase one will arrive when models trained on enough source-plus-binary pairs can reliably produce correct executables. Phase two will arrive when someone asks: if the model is already generating the binary, why are we targeting an instruction set that was designed for a species that is no longer doing the writing? At some point the intermediate layer becomes optional. And optional things, given enough time, become vestigial. What this means</h2> I do not think these three approaches are in competition. They are three points on a timeline, and the timeline is the story of the intermediate layer contracting. Near term Medium term Long term (now) (2-5 years) (5-15 years) Explicit Declarative Post-language languages languages (AI-native targets) (Vera) (Haskell + BHC) Reduce noise --> Change the signal --> Remove the layer in the loop entirely entirely HOW, but WHAT, verified Intent to unambiguous by types execution</code></pre> In the near term, explicit languages like Vera make AI-generated code more reliable by constraining the generation space and providing machine-readable diagnostics. This is useful today. If you are building an AI coding pipeline right now and need to ship next quarter, this approach works. In the medium term, declarative languages like Haskell, especially with modern tooling and modern runtimes, make AI-generated code correct by construction. The type system does the heavy verification work at a fundamental level. The code that survives is the code that describes invariants, not procedures. This is the era I am building for with arcanist.sh. In the long term, the language disappears. First into existing machine code generated directly by AI. Then into new execution formats designed for AI generation from the ground up. The intermediate layer that has defined software engineering for seventy years becomes an implementation detail. That last possibility makes some people uncomfortable. It made me uncomfortable when I first thought about it in December. It means that the craft of programming as we know it, the fluency in syntax, the mastery of idioms, the instinct for an elegant implementation, becomes less like a core skill and more like knowing how to operate a manual lathe. Valuable in the right context. Still needed for the hard cases. But no longer the primary way most software gets built. This has happened before. There was a time when every programmer understood assembly. Then C abstracted it away, and most programmers stopped reading machine code. Then Python and JavaScript abstracted C away, and most programmers stopped thinking about memory management. Each time, the previous layer did not disappear. It became the domain of specialists who maintained the infrastructure everyone else stood on. The same thing will happen to source code. It will not vanish. It will specialize. I still write code every day. I still think in types. I am still building hx and BHC because I believe the medium-term future is both real and long, and Haskell’s strengths are exactly what that future demands. Pure functions, strong types, provable correctness. These are not luxuries in a world where AI writes the implementation. They are the load-bearing structure. But I do it with one eye on the horizon, knowing that the intermediate layer I am investing in is exactly that. Intermediate. The person who built Vera saw the same thing I saw, probably around the same time. They chose the first approach. I chose the second. Somebody, eventually, will build the third. And then we will all need to figure out what we mean by “programming” when nobody writes programs anymore. I am already curious about the answer. Notes from RSAC 2026 Unknown — Thu, 09 Apr 2026 00:00:00 +0000 I am writing this about two weeks after RSAC 2026 closed. In between, my coworkers and I drove down the West Coast, through Big Sur to LA, then out to Las Vegas for Easter weekend. That was deliberate. Not the route, exactly, but the space. The conference gave me a lot to process, and I have learned over the years that I process better when I am moving, when I am not sitting at a desk trying to force conclusions out of raw impressions. So here is what I took away. Not a session-by-session recap. Not a vendor roundup. Just the things that are still with me now that the noise has faded and the Pacific Coast Highway is behind me. The talk</h2> Milan Duric and I presented “Self-Learning WAF: Using Generative AI to Tame ModSecurity False Positives” on Wednesday morning, March 25, in Moscone West 3020. We had an 8:30 AM slot, which is either a curse or a blessing depending on your audience. It turned out to be a blessing. The room was full of people who had chosen to be there at that hour, which means they cared about the topic, and the energy reflected that. The talk went flawlessly. If you have ever presented at a conference of that scale, you know that “flawless” is not something you take for granted. There is always the moment before you start where you wonder if the demo will work, if the projector will behave, if your timing will hold. All of it held. Milan and I had rehearsed enough that the talk felt natural rather than performed, which is the line you want to hit. I will write a separate post about the content of the talk itself, what we built, what we learned, how the audience responded to specific ideas. This post is about everything else. Third time, first time</h2> This was my third RSA Conference. I attended in 2024, 2025, and now 2026. But it was my first time as a speaker, and that changed the experience in ways I did not fully expect. When you attend as a participant, you are a consumer of the conference. You pick sessions, you walk the expo floor, you absorb. When you are a speaker, even for just one session, you become part of the fabric. People approach you after the talk. They reference something you said in a hallway conversation two days later. You are on the other side of the dynamic, and it gives you a different relationship with the event. I have grown to genuinely appreciate the sheer volume and quality of the whole thing. RSAC is not one conference. It is several conferences layered on top of each other. There are deeply technical sessions where people walk you through real implementations, real code, real incident response timelines. There are strategic talks where CISOs and policy architects work through the organizational and regulatory implications of what is changing. And then there are the keynotes, the big voices, people who have shaped the field for decades, sharing what they see on the horizon. Because it happens in San Francisco, in the heart of the Bay Area, the reach is different from any other security event. You are not just at a conference. You are at the geographic center of the industry that is driving the transformation everyone is trying to understand. The density of talent, capital, and ambition in that city during RSAC week is difficult to describe if you have not experienced it. The only comparable events I can think of are BlackHat and DefCon, but even those have a different energy. RSAC pulls in a wider spectrum of the industry, from the deeply technical to the deeply strategic, from startup founders to government officials, and puts them all in the same building for a week. That range is what makes it valuable. The year of agents</h2> Ever since I started attending in 2024, AI has been a substantial part of the conference. That makes sense. The developments in AI over the past few years have had a prominent cybersecurity dimension from the start, and the industry has been working through what that means, both as a threat to defend against and as a capability to harness. But this year felt qualitatively different from the previous two. In 2024 and 2025, the AI conversation was broad and somewhat exploratory. What can large language models do for security? How do we detect AI-generated phishing? What does the threat landscape look like when attackers have access to the same models we do? Important questions, but still in the “what is possible” phase. 2026 was past that. The conversation had narrowed and deepened. It was specifically about agents. Not AI in general, not language models as a capability, but autonomous agents as a new category of infrastructure. Enterprise-grade agentic systems. Agentic orchestration patterns. Agent-native architectures. The shift from “can we use AI?” to “how do we architect our systems around autonomous agents that are already here?” was palpable in almost every session I attended. The concept that kept coming up was NHI: non-human identities. This term has existed in the identity and access management world for a while, but at RSAC 2026 it had taken on a new meaning. The old NHI conversation was about service accounts, API keys, machine certificates. The new NHI conversation is about LLM inference backends that operate as something fundamentally different from traditional automated systems. These are entities that do not just execute a fixed pipeline. They reason, they make judgment calls, they interact with systems and data in ways that look more like what a human analyst does than what a cron job does. But they operate at machine speed, they do not sleep, and they do not have the contextual judgment or accountability that comes with a human in the seat. The trust problem this creates is real, and it is not just a theoretical concern. Human employees were already risk factors before AI entered the picture. Insider threats, social engineering, credential compromise, accidental misconfiguration. These are well-understood attack surfaces. Now add entities that move faster than any human, that can touch more systems in a minute than a human employee touches in a day, and that are harder to audit because their reasoning process is opaque. The attack surface did not just grow. It changed shape in ways that existing security architectures were not designed for. The human-in-the-loop debate</h2> This was the most interesting tension I observed across the conference, and I think it is going to be one of the defining questions for cybersecurity in the next few years. A small number of talks presented approaches that kept a human firmly in the loop. AI assists, human decides. AI flags, human acts. AI generates recommendations, human approves or rejects. These were careful, measured presentations, and some of them were good. The argument is intuitive and appeals to anyone who has been burned by automation gone wrong: keep a human in the critical path because humans have judgment that machines do not. But the majority of the conference had reached a different consensus, and it was stated with increasing confidence as the week went on: the human in the loop is a bottleneck. Not philosophically. Operationally. In terms of the speed at which threats materialize and the speed at which defenses need to respond. The argument is straightforward once you lay it out. Adversaries and threat actors are already leveraging AI to accelerate their operations. They are scanning for vulnerabilities at machine speed. They are generating novel attack variations faster than any human analyst can write detection rules. They are using AI to identify and exploit zero-day vulnerabilities in timeframes that make traditional patch cycles look like geological processes. If your defensive response depends on a human reading an alert, understanding the context, making a judgment call, and clicking a button before a countermeasure activates, you have introduced a rate limiter into your defense that your attacker does not have. You are playing at human speed against an adversary operating at machine speed. I agree with this assessment, and I want to be precise about what I mean by that. I do not think humans are irrelevant to security. They are not. Human judgment, human understanding of organizational context, human ability to reason about novel situations, these remain essential. But I think the role of the human needs to shift fundamentally. The human should be a supervisor, not a gatekeeper. The human should set policy, define constraints, establish acceptable parameters, review outcomes, and intervene when something goes wrong. But the human should not be the bottleneck whose reaction time determines how fast sophisticated defense measures can respond to a threat that is moving at inference speed. This is an engineering problem, not a philosophical one. How do you design agent-native architectures where the human is still in control, still has full visibility, still sets the rules, but is not the limiting factor in the response loop? That is the challenge of 2026. I did not hear anyone at the conference claim to have fully solved it. But I heard a lot of people working on it seriously, and the framing had matured beyond the naive “just automate everything” takes that dominated the early AI-security conversation. This is also, incidentally, part of why I built Zentinel</a> the way I did. A reverse proxy that sits at the edge, where policy enforcement happens at wire speed, is exactly the kind of system that needs to operate autonomously within human-defined constraints. The agent architecture in Zentinel, where security logic runs in isolated processes with bounded resources and explicit failure modes, is my answer to the question of how you let autonomous systems make real-time decisions while keeping the human in the position of supervisor rather than bottleneck. I wrote about this in more detail in What Zentinel Is Really Optimizing For</a>. The four factors</h2> I attended a panel with four former NSA directors and US Cyber Command commanders. Both positions are held by the same person at any given time, so these were people who had sat at the intersection of signals intelligence and military cyber operations at the highest level the United States has. Regardless of how you feel about the NSA or US foreign policy, the caliber of strategic thinking in that room was extraordinary. Paul Nakasone said something that has stayed with me since. He laid out what he considers the four most important factors when assessing the strategic potentiality of a nation state in this era. Not military strength. Not GDP. Four specific things: chips, data, talent, and energy. Chips, meaning silicon, meaning raw compute power. How many advanced GPUs can you deploy? How advanced are they relative to the frontier? And critically: can you manufacture them domestically, or are you dependent on someone else’s fabrication capacity? Right now, the entire world depends on TSMC in Taiwan for leading-edge chip fabrication, and the geopolitical implications of that single point of dependency are staggering. Data, meaning access to the raw material that AI systems learn from. Who has it, how much of it, how diverse is it, and under what legal and political constraints can it be used for training and inference? Talent, meaning the human capital that knows how to build, train, deploy, secure, and govern these systems. Where that talent lives, where it wants to live, and what it takes to attract and retain it. This is not just about researchers at frontier labs. It is about the entire pipeline: the engineers who build the infrastructure, the operators who keep it running, the security professionals who defend it, the policy people who regulate it. Energy, meaning access to cheap, abundant, reliable power. Because the compute demands of frontier AI are measured in gigawatts now, not megawatts. A single frontier training run can consume more electricity than a small city. The question of whether you can physically power your AI ambitions is no longer abstract. I could not stop thinking about AI 2027</a> while listening to Nakasone. The scenario work by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean, which I first wrote about in How I Work These Days</a>, makes strikingly similar assessments from a technology trajectory perspective rather than a national security one. Their scenario tracks the distribution of global AI compute (the US holding roughly 70% of frontier capacity through its companies, China around 12%), the geopolitical competition for chip manufacturing, the energy infrastructure required to sustain frontier operations (their projection of global AI datacenter spending reaching the trillion-dollar range by 2026 no longer reads like speculation), and the talent concentration in a handful of US-based labs. What makes AI 2027 feel prophetic, and I do not use that word casually, is that its core thesis keeps holding up month after month. The idea that automating AI research itself creates a self-reinforcing feedback loop, that the cycle between capability and capability-building is compressing, that the timeline for transformative change is shorter than most institutional planning horizons assume. The specific dates and milestones may shift. The authors themselves have revised some timelines. But the directional assessment, the shape of the curve, still looks right to me as of April 2026. The scenario’s detailed treatment of compute distribution, espionage risks, and the escalatory dynamics between nation states competing for AI dominance maps remarkably well onto what I heard discussed in more guarded terms on the RSAC floor. Listening to Nakasone lay out those four factors, I kept thinking about Europe. And about Switzerland specifically, since that is where I live and work. Europe is behind on all four. The continent does not manufacture frontier chips. It does not host the leading AI labs. Its regulatory environment, while well-intentioned, has optimized more for constraint than for capability. Its energy infrastructure is in the middle of a complex transition. And its talent pipeline, while strong in research, struggles to retain builders who can turn research into deployed systems at scale, because many of them leave for the Bay Area, London, Singapore, the Gulf states, or other places where the ecosystem is more supportive of what they want to build. This is part of why I co-founded Die Zukunft</a>, a new Swiss political party focused on structural transformation. The name means “The Future” in German. The party exists because I believe the political infrastructure in Switzerland, and in most European countries, is not designed to respond to the kind of structural shift that Nakasone was describing. The decisions being made right now about compute sovereignty, energy policy, talent retention, and regulatory frameworks will determine whether Europe is a participant in the next decade or a consumer of other people’s technology. Die Zukunft’s platform addresses these questions directly: digital sovereignty defined in infrastructure terms, faster permitting for critical energy and compute projects, open standards as a hard requirement for government systems, and immigration policy designed to attract the talent that builds these systems. It is not a technology party in the narrow sense. It is a party built on the recognition that the structural transformation AI is driving is too consequential to be left to the current pace of European political response. And this is also why I built Archipelag</a>. If Europe wants digital sovereignty, it needs sovereign compute infrastructure. Not just policy positions about data residency, but actual physical capacity to run AI workloads within European jurisdictions, at competitive cost, without depending on American hyperscalers. Archipelag is a decentralized AI compute network that routes inference jobs to community-operated nodes with jurisdiction-aware routing baked into the infrastructure layer. It is designed so that a European company can run AI workloads with cryptographic guarantees about where their data is processed, using idle GPU capacity that already exists across the continent. It is my direct answer to the infrastructure gap that Nakasone’s four factors expose so clearly for Europe. The enterprise problem</h2> This connects to something broader that I have been thinking about since well before RSAC, but that the conference brought into sharper focus. I work for a large Swiss financial institution. My perspective is shaped by what I see inside that kind of organization every day. But I believe the dynamic applies to enterprises of all sizes and in all sectors, even if the scale and specifics differ. The biggest threat I see right now is not a specific vulnerability, not a particular attack vector, not a novel exploit technique. It is inertia. It is the widening gap between what is happening at the frontier of AI capability and what most organizations are actually doing about it. Too many companies still think they can outsource their way through this transition. Buy an AI-powered security product from a vendor. Subscribe to a managed detection service that mentions “AI” somewhere in its marketing materials. Check the compliance box and move on to the next quarter. I do not think that is going to work. Not because those vendors are bad. Some of them are genuinely good at what they do. But because the organizations that will remain competitive and secure over the next few years are the ones that build internal AI capability, not just consume external AI services. That means investing in your own GPU compute. That means building the internal expertise to deploy, fine-tune, and operate models on your own infrastructure. That means treating AI as a core organizational competency, not a procurement line item. This is not a popular opinion in many boardrooms. It is expensive. It is hard. It requires talent that is difficult to hire and even harder to retain when they can work at a frontier lab or a well-funded startup instead. But the alternative, waiting and relying on service providers to package AI innovation for you at their pace and under their terms, means you are always operating one step behind. You are consuming someone else’s capability with someone else’s priorities, under someone else’s constraints. In a landscape that is moving as fast as this one, that delay compounds. The companies that understand this and invest now are going to have a structural advantage that widens over time. The ones that wait are going to find themselves trying to close a gap that gets larger with every quarter of inaction. I saw enough at RSAC to believe that some organizations have internalized this. And I saw enough to believe that many more have not. The vendor floor</h2> I want to be fair about this, because I know how the previous section sounds, and I do not want to come across as someone who dismisses the entire vendor ecosystem. I am not easily swayed by big tech vendors and their keynote promises, and I think anyone who works in security should maintain a healthy skepticism toward product demos and polished presentations. That is just professional hygiene. That said, I genuinely enjoyed many of the keynotes this year. Some of these companies have real long-term vision. They see the shape of what is coming, and their best presenters can communicate that vision with clarity and conviction. I respect that, even when I disagree with their specific approach or their business model. But enjoying a keynote and trusting that buying a product will translate into sustainable cybersecurity for your organization are very different things. Actual security is hands-on work. It is understanding your own systems, your own architecture, your own threat model, your own failure modes. It is the boring, unglamorous work of knowing what runs where, what talks to what, what happens when something fails, and what your actual attack surface looks like on a Tuesday afternoon. That work cannot be fully offloaded to a vendor. It cannot be outsourced to a dashboard, no matter how sophisticated the analytics behind it. The vendors that impressed me most this year were the ones that acknowledged this honestly. The ones that positioned their tools as force multipliers for competent teams rather than replacements for the need to have competent teams in the first place. That distinction matters, and the vendors who understand it tend to build better products because they are designing for operators, not for procurement committees. Closing night</h2> The last session of the conference was Hugh Jackman in conversation with Hugh Thompson. I was not sure what to expect from a Hollywood actor closing out a cybersecurity conference, and I suspect a lot of people in the audience had the same reservation going in. But it worked. Jackman is funny, self-aware, and surprisingly thoughtful about creativity, discipline, and the craft of doing hard things well. He talked about preparation, about the difference between performing and connecting, about the years of work that go into making something look effortless. At one point he taught the audience that if you say “raise up lights” in an American accent, you are saying “razor blades” in Australian. The room loved it. It was one of those moments where several thousand cybersecurity professionals all became delighted seven-year-olds for about ten seconds, and it was a good reminder that conferences are also about shared human moments, not just information transfer. It was the right way to end a dense week. Light enough to let people exhale after five days of intense content, but substantive enough in its own way that it did not feel like filler. The road after</h2> After the conference closed, a few of us stayed on. We rented a car and drove south from San Francisco, down Highway 1 through Big Sur. If you have not done that drive, I do not know how to describe it adequately except to say that it recalibrates your sense of scale. The Pacific is very large and very indifferent, and spending a few hours winding along cliff-edge roads with that water stretching out to the horizon below you is a useful counterweight to a week of thinking about the future of everything. We spent time in LA. Santa Monica and Venice Beach, walking the boardwalk, eating food that was too expensive and not caring. The kind of aimless, unstructured time that my brain needed after five days of absorbing information at high density. I find that the most useful thinking often happens when you are not trying to think. When you are just watching the ocean or walking on a beach and letting your subconscious do whatever it does with the raw material you fed it. Then Las Vegas for Easter weekend. Spring break crowds, desert heat starting to build, the particular surreality of the Strip. It was not productive time in any conventional sense, and it was not meant to be. It was decompression. Space for the conference to settle from a collection of impressions into something more like understanding. What stays with me</h2> Two weeks out, here is what I think is different. I went to RSAC 2026 with a set of convictions about where things are heading. Agents are going to be the primary operating model for security infrastructure. Human-in-the-loop is going to shift to human-as-supervisor. Organizations that do not build their own AI infrastructure are going to fall behind structurally. Europe needs to wake up to the compute sovereignty problem before it becomes irreversible. These were things I already believed before I got on the plane to San Francisco. What the conference did was sharpen them. Hearing Nakasone frame national potentiality in terms of chips, data, talent, and energy gave me a cleaner lens for thinking about the geostrategic dimension. Seeing the breadth and depth of the agentic conversation on the conference floor confirmed that this is not a niche position or an edge case anymore. It is the emerging consensus of the industry. And presenting our own work, standing in front of a room and showing what we actually built, made it more real in a way that writing code in a terminal at midnight does not. Conferences like RSAC have always had this effect on me. They compress a year’s worth of signals into a week, and then you spend the following weeks unpacking what you heard and figuring out what it means for what you are building. After RSAC 2024, I started thinking seriously about edge security architectures, which eventually became Zentinel. After RSAC 2025, the urgency around AI-native infrastructure solidified into the work that became Archipelag. This year, I expect the sharpened understanding of agentic systems and the geostrategic landscape to feed directly into what I build next. I also came away with a renewed sense of urgency about the gap between what the frontier looks like and what most organizations are doing about it. That gap, between the leading edge and the institutional mean, is the real risk. Not any single threat actor, not any specific vulnerability class. The systemic inability of large institutions to move at the pace that the situation demands. That is what keeps me up at night, and that is what I am trying to address in my own work, whether it is building infrastructure, writing about it, or working on the political dimension through Die Zukunft. I am going to write a separate post about the talk itself, about what Milan and I built with self-learning WAFs and what we learned along the way. That is coming soon. For now, these are the notes I wanted to capture while the impressions are still sharp enough to be useful. I am already looking forward to RSAC 2027. References and further reading</h2> RSAC 2026</a> - The conference itself</li> AI 2027</a> - Scenario work by Kokotajlo, Alexander, Larsen, Lifland, and Dean</li> How I Work These Days</a> - Where I first wrote about AI 2027 and the shift in how I build</li> What Zentinel Is Really Optimizing For</a> - The design philosophy behind Zentinel and why agent isolation matters</li> Zentinel</a> - The security-first reverse proxy I built on Pingora</li> Archipelag</a> - Decentralized, sovereignty-first AI compute network</li> Die Zukunft</a> - Swiss political party for structural transformation</li> </ul> What Zentinel Is Really Optimizing For Unknown — Sun, 22 Mar 2026 00:00:00 +0000 The clearest way I can describe the motivation behind Zentinel is this: I got tired of not trusting the thing that stood between my users and the internet. Not because the proxies I ran were bad. They were not. I have genuine respect for the engineering in Nginx, HAProxy, Envoy. I learned a lot from operating them, and I mean that sincerely. But over years of running these systems in production, a pattern kept repeating, and it was always some version of the same story: the proxy did something I could not predict from reading its configuration. A WAF module gets slow under load, and because it runs inside the proxy process, the entire data path backs up. A retry storm starts because the default retry policy is implicit rather than explicit. A configuration reload takes effect partially because there is no atomic swap. An unbounded queue grows until memory runs out and the OOM killer takes the proxy down along with everything else on the box. None of these are exotic. If you have operated proxies at any real scale, you have seen most of them. And every time, the root cause pointed at the same structural issue: the proxy was optimized for something other than what I actually needed from it. That is not a criticism. It is a statement about time. Every proxy was built for its era</h2> HAProxy was born in 2000. Willy Tarreau built it to solve a specific, urgent problem: distributing TCP connections across a pool of backend servers. The internet was scaling fast. Sites needed load balancing. HAProxy did that one job with extraordinary precision, and twenty-five years later it still does. It is one of the most reliable pieces of infrastructure software ever written. But it was built as a load balancer, and when you need it to do security enforcement, you are extending a load balancer. Nginx arrived in 2004. Igor Sysoev was solving the C10K problem: how do you handle 10,000 concurrent connections without the process-per-connection model falling over? Nginx was built as a web server. An event-driven architecture that served static files and handled connections with remarkable efficiency. The reverse proxy capability came later, almost as a side effect of how well it handled connections, and eventually became one of its most important use cases. But the core was always a web server. The assumptions about configuration, about reload behavior, about how modules interact with the request path, those assumptions come from web serving. Varnish showed up in 2006. Poul-Henning Kamp built it because dynamic web pages were slow and caching was the answer. Varnish sat in front of your web server, cached responses in memory, and served them fast. That was the whole job. A caching proxy, and a beautiful one. Envoy was born at Lyft around 2016. Microservices had created a new problem: how do you route, observe, and control traffic between hundreds of internal services that come and go? The service mesh was the answer, and Envoy was the data plane. It brought observability, retries, circuit breaking, and policy enforcement to a world where the network topology was no longer something you could draw on a whiteboard and expect to remain accurate for more than a week. Traefik arrived in the same era, optimized for automatic service discovery in container environments. Services appear and disappear. The proxy figures out the routing on its own. Every single one of these was the right tool at the right time. They solved the problem that mattered most when they were built, and they solved it well. I used most of them. I admired most of them. I am not here to argue that any of them were wrong. But I am here to say that their time shaped what they became, and so did the economics of how software was built. The generality trap</h2> Here is something I noticed over years of operating these tools: they all converge. Nginx adds load balancing. HAProxy adds HTTP/2 and Lua scripting. Envoy adds caching, WAF capabilities, ext_proc for external processing. Traefik adds middleware chains. Every proxy, over time, becomes a Swiss army knife. This is not a design failure. It is an economic inevitability. Building a production-grade reverse proxy takes a team, sometimes a large one, working over many years. Nginx took Igor years before it was production-ready. Envoy is maintained by hundreds of contributors across multiple organizations. HAProxy has been continuously refined for a quarter of a century by one of the most skilled systems programmers alive. When the cost of building software is that high, you need the result to serve a broad market. You cannot afford to optimize for one narrow concern. You need your proxy to be useful to web servers and API gateways and service meshes and CDN edges and everything in between. The economic pressure pushes relentlessly toward generality. Toward one more feature. Toward covering one more use case. Toward becoming the tool that everyone can use, even if nobody uses it for exactly the thing they wish it was designed for. This creates a particular kind of friction. You adopt a proxy for its core strength, and then you spend years working around its assumptions in every other area. You chose Nginx because it handles connections well, but now you are fighting its reload model and its embedded Lua modules that share a fate with the worker process. You chose Envoy because it observes service traffic brilliantly, but now you are wrestling with an xDS configuration surface that could fill a textbook, and a C++ codebase where memory safety is a matter of programmer discipline rather than compiler guarantee. I lived in that friction for a long time. I knew what I wanted. I could describe it in detail to anyone who would listen. But wanting a purpose-built proxy and building one are different things when building one requires a team and years of sustained effort. What I kept wishing for</h2> After enough 3 AM incidents and enough post-mortems, the shape of what I was looking for became concrete enough to write down. I wanted a reverse proxy where the operator can reason about what will happen under any condition. Including conditions they did not anticipate. That is the whole thesis. Everything else follows from it. When you are on call, “reason about what will happen” is not philosophical. It means concrete things. It means every queue has a maximum depth. Every timeout is explicit and declared. Every connection pool has a ceiling. No unbounded allocations anywhere. If you set a body size limit of 10 MB, that is a hard limit, not a suggestion. If a security agent’s concurrency is capped at 100, the 101st request gets the configured failure mode, not a silent queue that grows until the box dies. It means every route declares what happens when a security agent is unreachable. Not a global toggle. Per route, per agent. Your API fails closed when the WAF is down (deny everything, because your API handles sensitive data and you do not want it exposed without inspection). Your marketing site fails open (allow traffic, log the gap, because a few minutes of unfiltered marketing pages is better than a full outage). You decide. You write it down. The system enforces it. agents { agent "waf" { transport { unix-socket "/var/run/zentinel-waf.sock" } events "request-headers" "request-body" timeout-ms 50 max-concurrent-calls 100 failure-mode "closed" circuit-breaker { failure-threshold 5 success-threshold 3 timeout-seconds 30 } } } routes { route "api" { priority 100 matches { path-prefix "/api/" } upstream "backend" filters "waf" failure-mode "closed" } route "marketing" { priority 50 matches { path-prefix "/" } upstream "static-backend" filters "waf" failure-mode "open" } } </code></pre> It means every security decision gets a trace ID and ends up in structured logs. When someone asks “why was this request blocked at 3:47 AM?”, you can answer with a correlation ID and a full trace: which agent decided, which rule matched, how long it took. Not “the WAF blocked it, probably.” The actual chain of events. It means configuration reloads are atomic. You send SIGHUP, the new configuration is parsed, validated, and swapped in. In-flight requests finish on the old config. New requests pick up the new one. No window where half the routes are on the old version and half on the new. I could describe all of this clearly. I had been able to for years. Describing what you want and having the means to build it are different things. The insight about isolation</h2> The single biggest realization I had was about failure domains. In every proxy I had operated, extension logic ran inside the proxy process. Nginx has embedded Lua via OpenResty. HAProxy has SPOE and Lua. Envoy has Wasm filters and ext_proc. They all share the same structural problem: the extension and the proxy share a fate. If your Lua WAF script enters an infinite loop in nginx, the nginx worker is stuck. If your Wasm filter in Envoy allocates too much memory, the Envoy process pays for it. A slow SPOE agent in HAProxy backs pressure into the proxy’s request handling. I have been on the receiving end of all three patterns, and they all end the same way: you are awake at 3 AM trying to figure out why your entire proxy fleet is degraded because one security module is having a bad day. This is the classic shared-fate problem. When everything runs in one process, everything fails together. A slow WAF does not just slow down WAF-protected routes. It consumes worker resources that affect all routes. A memory leak in an auth filter does not just take down auth. It takes down the process. The answer I kept coming back to was process isolation. Not as a compromise or a workaround, but as the foundational design principle. Security and policy logic should live in separate processes, each with its own memory, its own concurrency limits, and its own circuit breaker. ┌─────────────────────┐ │ Proxy Core │ │ (Rust / Pingora) │ └──────────┬──────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌────────▼───────┐ ┌──▼──────────┐ ┌▼───────────────┐ │ WAF Agent │ │ Auth Agent │ │ Custom Agent │ │ semaphore: 100│ │ semaphore:50│ │ semaphore: 25 │ │ timeout: 50ms │ │ timeout:30ms│ │ timeout: 200ms │ │ fail: closed │ │ fail: closed│ │ fail: open │ └────────────────┘ └─────────────┘ └────────────────┘ Each agent: own process, own memory, own circuit breaker. Slow WAF ≠ slow auth. Crashed agent ≠ crashed proxy.</code></pre> If the WAF agent gets slow, the WAF agent’s semaphore fills up. The auth agent keeps running on its own semaphore. The proxy core keeps routing. Nobody shares a failure domain unless you explicitly configure them to. This is not just about crash isolation, though that matters. The deeper point is queue isolation. In a shared-process model, a slow filter creates backpressure that affects all traffic. With process isolation, a slow agent only affects the routes that use it, and only up to the concurrency limit you configured. The blast radius is bounded and declared. You can look at the config and know the worst case. The agents communicate over Unix domain sockets or gRPC, and they can be written in any language. There are SDKs for Rust, Go, Python, TypeScript, Elixir, Kotlin, and Haskell. The protocol is simple: 4-byte length, 1-byte type, JSON or MessagePack payload. The operational consequence is what I care about most: you can deploy, restart, and update agents independently. Roll out a new WAF rule set without touching the proxy. Restart a misbehaving auth agent without dropping a single connection. When you are trying to fix one thing at 3 AM without breaking three others, that independence matters more than any benchmark number. A product of this moment</h2> Every piece of software is shaped by when it was built. The proxies I described earlier were products of their time not just in what problems they solved, but in how they could be built. Nginx needed Igor working for years. Envoy needed Google, Lyft, and a large open source community. HAProxy needed Willy Tarreau’s decades of sustained refinement. That was the only way to build infrastructure of that quality. One person, or even a small team, could not realistically build a production-grade reverse proxy with a novel architecture and ship it in months. The economics did not allow it. That structural reality is changing, and I think the change matters more than most people in infrastructure have absorbed yet. I wrote about the broader shift in How I Work These Days</a>. The short version: I had been using Claude Code since May 2025, but it was not until Christmas 2025, working with Opus 4.5, that something fundamentally clicked. The constraint I had lived with for years, the gap between knowing exactly what I wanted and having the bandwidth to build it, narrowed in a way that I still find hard to fully describe. Not because the model wrote the code for me. But because the feedback loop between design intent and working implementation compressed from weeks to hours. When Cloudflare open-sourced Pingora in 2024, I had paid attention immediately. A proxy framework written in Rust, battle-tested at over a trillion requests per day in Cloudflare’s own network. The TCP listener, the HTTP parser, the TLS termination, the connection pooling, the async runtime. All the low-level machinery that you do not want to write from scratch. I had watched River, the community Pingora-based reverse proxy, hoping it would become the thing I could reach for and trust. It never got there. So I stopped waiting and started building. Pingora as a foundation. Rust for memory safety at the boundary. An agentic workflow that let one person move at the pace of a small team. What came out was not a general-purpose proxy. It was not a Swiss army knife. It was a purpose-built tool, tailored from the start to one specific problem: safe, observable, operatable edge traffic enforcement. No more, no less. This is the part I think matters beyond Zentinel itself: when the cost of building serious software drops dramatically, you can afford to be specialized. You do not need to serve a broad market to justify the investment. You can build exactly the thing that solves exactly your problem, with exactly the tradeoffs you want. No feature creep driven by needing to justify a twenty-person team. No compromises driven by needing to appeal to every possible use case. I think of it as bespoke infrastructure. Software that is tailored to a specific problem by someone who deeply understands that problem, made viable by tools that compress the gap between “I know exactly what this should be” and “it exists.” The same way that a load balancer was the right thing to build in 2000, and a service mesh data plane was the right thing to build in 2016, a purpose-built safe reverse proxy is the right thing to build in 2026. Not because the world suddenly needs one more proxy, but because the world can finally have proxies that are designed for specific jobs instead of being general enough to justify their development cost. Zentinel is a post-agentic reverse proxy. Not because it uses AI internally (it does not, unless you count the inference-aware rate limiting for LLM traffic). But because it could only exist in a world where agentic development made bespoke infrastructure viable. One person. Three months. A clear vision that had been accumulating for years. That is not a story that was possible to tell in 2020. Glass-box infrastructure</h2> There is a conviction behind Zentinel that is not technical, and I want to be honest about it. I believe critical web infrastructure should be open. Not “open core” with the important parts behind a license. Not “source available” with restrictions on how you run it. Open in the way that matters: you can read it, fork it, modify it, run it on your own hardware, never call anyone for permission. Zentinel is Apache-2.0-licensed. Every agent is open source. The configuration format is documented. The protocol is specified. There is no hidden control plane, no phone-home telemetry, no vendor dependency. But open source alone is not what I mean by transparent. Plenty of projects publish their source and remain effectively opaque. The code is there, technically, but understanding what a particular configuration will actually do still requires reading thousands of lines of parser logic, or just deploying it and hoping for the best. This is where the Rust decision pays off in a way I did not fully anticipate when I started. Because Zentinel is written in Rust, the core crates compile to WebAssembly. Not as a side project or a reimplementation. The same zentinel-config</code> crate that parses and validates your KDL configuration in production compiles to a Wasm module that runs in a browser tab. This means the config playground</a> on the Zentinel website is not a JavaScript approximation of what the parser does. It is the parser. The actual Rust code, compiled to Wasm, running against your configuration in real time. When it says your config is valid, that is the same validation logic that will run when Zentinel starts up on your server. When it flags an error, that is the same error you would see in production. The same applies to the config converter</a>. If you are migrating from nginx, HAProxy, or Traefik, the conversion tool runs the actual Zentinel config crate in your browser. You paste your existing config, you get KDL output, and you can validate the result on the spot. No round-trip to a server. No “upload your infrastructure config to our cloud service.” It runs locally, in your browser, using the production code. This matters more than it might sound. When you can run the same code that your proxy runs in production, right in your browser, you can reason about the proxy’s internal behavior directly. You are not trusting documentation about how the parser interprets a particular KDL construct. You are running the parser. You are not guessing what happens when two routes have the same priority. You are watching the actual matching logic evaluate your routes. The proxy becomes glass-like. Not transparent in the “we published the source, good luck reading it” sense. Transparent in the sense that you can interact with its internals, poke at its logic, verify its behavior before it ever touches production traffic. The same Rust, the same types, the same validation rules, running wherever you need them: on the server, in CI, in your browser. That is what I mean by trustworthy infrastructure. Not “trust us, it works.” Trust it because you can verify it yourself, using the same code, without asking anyone for permission. Where this leaves me</h2> Every generation of proxies solved the problem of its era. HAProxy solved load balancing. Nginx solved web serving. Envoy solved service mesh routing. Varnish solved caching. Each was the right answer at the right time, and each was shaped by what was possible when it was built. The problem I kept running into was different. Not throughput. Not feature count. Not service discovery. Just: can I understand what this system will do at 3 AM when something I did not plan for happens? Can I reason about its failure modes from reading its configuration? Can I trust it enough to sleep? No existing proxy was designed from scratch for that question, because no existing proxy could afford to be that specialized. The economics of building infrastructure software pushed everything toward generality. What changed is that the economics changed. One person, with the right foundation and the right tools, can now build purpose-built infrastructure that would have required a team and a multi-year roadmap before. Zentinel is the proxy I needed and could not find, built in the specific window of time when building it became possible. It is a product of this moment, in the same way that every proxy before it was a product of its own. And maybe that is what this era of software is really about. Not that AI writes code for you. That framing misses the point entirely. It is that the gap between knowing what should exist and making it exist got smaller, and the things people build when that gap closes are going to be very specific, very opinionated, and very good at exactly one thing. References and further reading</h2> Zentinel</a> - The source code, Apache-2.0-licensed</li> Zentinel documentation</a> - Architecture, configuration reference, agent protocol</li> Zentinel playground</a> - Browser-based config validation using the actual Rust crate compiled to Wasm</li> Zentinel config converter</a> - Migrate from nginx, HAProxy, or Traefik configs to KDL</li> Zentinel manifesto</a> - The design philosophy in full</li> Pingora</a> - Cloudflare’s open source proxy framework that Zentinel builds on</li> How I Work These Days</a> - The broader shift in how I build software, and where Zentinel fits in that story</li> HAProxy</a> - Willy Tarreau’s load balancer, still one of the best pieces of infrastructure software ever written</li> Nginx</a> - Igor Sysoev’s web server that became the internet’s default reverse proxy</li> Envoy</a> - The service mesh data plane that brought observability to distributed systems</li> Varnish</a> - Poul-Henning Kamp’s caching proxy</li> </ul> How I Work These Days Unknown — Sun, 15 Mar 2026 00:00:00 +0000 If you had asked me a few years ago what kind of shift would truly change software again, I would probably have said something vague about machine learning becoming more useful, more accessible, more integrated into normal tooling. I would not have said that within a few years I would be spending large parts of my day in conversation with models, building products at a pace that used to feel unrealistic for one person. But that is where I am now, and the path here did not start with ChatGPT. It started earlier. Before the shock</h2> I had been on Kaggle and Hugging Face since 2020. I was already paying attention. I had a decent understanding of machine learning, enough to know that something important was happening. I was not looking at this space as an outsider who suddenly discovered AI in a news cycle. I had been around it long enough to see that the ingredients were there. Still, understanding a field and feeling a historical shift are not the same thing. When OpenAI released ChatGPT 3.5 in November 2022, something in me changed almost immediately. I do not mean that in a mystical way. I mean I recognized, very quickly, that this was not just another incremental product launch. It felt like a boundary marker, one of those moments where you can see a new layer of the technology stack forming in front of you. At the time, I thought: this is going to be enormous. Bigger than most people realize. Bigger, maybe, than the web itself in terms of how deeply it will alter the shape of work, software, and the distribution of capability. That sounds exaggerated when people say it too casually. I know that. But that was honestly my reaction back then. Not hype. Recognition. I was one of the early people willing to pay OpenAI. That mattered to me. I wanted access, and I wanted to stay close to the frontier as it moved. I did not want to be reading second-hand summaries while something this consequential was taking shape in real time. The part I still underestimated</h2> Even then, I still underestimated one thing: the speed. I understood generative AI was around the corner. I did not understand just how fast it would become operationally useful for actual software creation. I had read AI 2027, the scenario work by Daniel Kokotajlo, Scott Alexander, Thomas Larsen, Eli Lifland, and Romeo Dean. It stayed with me, and it still does now in March 2026. I still think the basic direction it sketches is largely correct, even if the path is turning out a bit differently in practice than any single forecast can capture. But even with that framing in my head, I did not fully expect that less than two years after ChatGPT 3.5, coding agents would already start to feel like a real category rather than a novelty. That part came faster than I thought. Paying attention, waiting for the right moment</h2> In 2025 I was trying different tools seriously. I was paying for Claude Code from May 2025 onward, but I was not especially impressed at first. I liked the CLI orientation. I liked that it felt coder-friendly. That part made sense to me immediately. But the model quality at that moment, and the rate limiting, left me cold. It was interesting. It was not yet transformative for my own workflow. So I mostly leaned on Zed’s offering. I liked the editor experience, and I still do. I still reach for Zed when I want to inspect, edit, or move through files outside of Vim in the terminal. It fit me better in that phase. Then November 2025 arrived, three years after ChatGPT 3.5, and then December came with Christmas break. I gave Claude Code another real try, this time with Opus 4.5, and that was the moment it really landed for me. Not politely. Not academically. It hit me hard. I remember the feeling very clearly: this is it. This is the first time the whole thing feels like more than an assistant and less than a gimmick. This is a tool I can genuinely build with. Zentinel was the proof</h2> Zentinel had been sitting in the back of my mind for a long time. The idea was not new. The frustration behind it was not new either. At my day job, we had been dealing with unreliable reverse proxies for long enough that the pain was familiar. I had always wanted River, the Pingora-based reverse proxy, to succeed. I wanted that project to become the thing I could reach for and trust. But it never got there. So I did what this new moment suddenly made possible: I stopped waiting for somebody else to build the thing I wanted to exist. I built Zentinel with Opus 4.5, and it worked. That is the part that still feels a little surreal when I say it plainly. Three months later it is up, it is real, and people are using it. Not as a demo. Not as an abandoned prototype. As actual software in the hands of actual users. That changed something fundamental in how I think about work. Once one long-held idea made it through that bottleneck, a lot of others started moving too. It was not just that I had a new tool. It was that the relationship between ambition and execution had changed. The old constraint, the one that said “yes, this could exist, but not with your current time and current bandwidth,” had weakened. Then everything else started moving</h2> In the time since, I have built a whole range of things that had been accumulating in my head for years: Cyanea, Archipelag, Humankind, Arcanist and its Rust-based hx</code> Haskell toolchain, the new Basel Haskell Compiler, and other pieces besides. It has been a wild ride, but not in the shallow “everything is crazy” sense people often write about. More in the sense that an internal dam broke. For a long time I had more ideas than I had time, more design clarity than I had execution bandwidth, and more conviction than I had manpower. That is a frustrating place to live in for years. You learn to carry around a quiet backlog of unrealized things. Some of them stay alive as notes. Some become recurring thoughts during commutes or late at night. Some start to hurt a little because you know they are viable, but you also know you are not going to get to them with the tools and energy available to you at that point in your life. Now the world is different. I can finally push through the backlog that used to exist only in notebooks, mental sketches, half-written design docs, and conversations with myself. What my days look like now</h2> My daily routine changed dramatically. I still have a day job, and then I have the rest of my work. Together it often adds up to something close to sixteen hours a day. That would sound bleak if I were forcing it. It does not feel bleak. It feels like release. My workspace reflects that change. These days I use mostly Apple hardware, which is funny if you know how much of a Linux person I am, and how much of an OpenBSD person I still am. That part of me has not gone anywhere. I still love those systems. I still think they matter deeply. But if I am being honest about the practical question of where I am most productive right now, Apple has become the answer. I work across a MacBook Pro M4, an iMac, and an Apple Vision Pro. I spend time talking ideas out in real time with ChatGPT’s voice mode, using it less like a search engine and more like a sparring partner. Sometimes intimate, sometimes brutally honest, sometimes audacious in exactly the way a good thinking partner should be. I push an idea, it pushes back, I sharpen it, it sharpens me, and we keep going until something solid emerges. Then there is the terminal, where much of the actual implementation happens in Ghostty, usually with four panes open, often with multiple Claude Code agents running in parallel on the Max plan. Two hundred dollars a month for that level of leverage is, for me, one of the clearest trades I have ever made. This is not a lifestyle performance. It is just the current shape of my work: ideas moving between speech, terminal, editor, design notes, code, back to speech, then back to code again. Beast mode, for lack of a better term</h2> There is a part of this that feels almost embarrassingly direct to say, but it would be dishonest to leave it out: I am the happiest I have ever been. Not because everything is easy. It is not. Not because every project succeeds. They will not. Not because the industry suddenly became sane. It did not. I am happy because the mismatch that used to define so much of my working life has narrowed. For years I had to live with the feeling that my ideas were outrunning my available hours and my available hands. Now, for the first time, it feels like I can actually meet myself where my ambition has been waiting. There is a phrase people use, “beast mode,” and usually I would avoid it because it sounds like posturing. But I do not really have a cleaner shorthand for the intensity of this period. I am working hard, very hard, but with a degree of joy and clarity that makes the effort feel proportionate. I am in conquest mode. Not conquest in the empty startup sense. Not domination, not vanity metrics, not growth for its own sake. I mean conquest over the inertia that used to keep good ideas trapped inside my head. Conquest over backlog. Conquest over hesitation. Conquest over the old excuses about lacking time, lacking team, lacking the right moment. And yes, some of it is for me. To feel better. To feel more whole. To stop carrying around years of deferred execution. But some of it is also because I genuinely want to make useful things. I want to build software that improves the texture of work, that makes systems more reliable, that gives people better tools, that opens up possibilities that were previously too expensive or too cumbersome to pursue. That still matters to me. Probably more than ever. The real change</h2> So when I say that the way I work these days has changed, I do not just mean that I use different tools. I mean that the relation between thought and execution changed. The lag collapsed. The emotional burden of unrealized ideas shrank. The number of things that are now viable to attempt expanded dramatically. That is the real story. I was already paying attention in 2020. I recognized the significance of ChatGPT in 2022. I underestimated the speed anyway. Then late 2025 arrived, the tools crossed a threshold, and my daily life reorganized itself around that fact. Three years is not a long time. It feels longer when you live through a real transition. And I suspect we are still early. References and further reading</h2> AI 2027</a> - Scenario work that influenced how I thought about the trajectory of this space</li> Zed</a> - Editor I still use alongside Vim</li> Ghostty</a> - Terminal I use for most of my agent-heavy coding sessions</li> Zentinel</a> - Reverse proxy project that became the first real proof point for this workflow</li> Cyanea</a> - One of the projects that came to life during this period</li> Archipelag</a> - Another product that moved from idea to reality in this new working mode</li> </ul> Archipelag.io Is in Open Beta: Here's Why I Built It Unknown — Fri, 13 Mar 2026 00:00:00 +0000 There is an abandoned factory building in Glarus, a small town wedged between mountains in eastern Switzerland. In 2016, the building was loud. Not machinery-loud, fan-loud. Rows of bare motherboards bolted to open-air frames, each bristling with GPUs and daisy-chained power supplies. The air tasted like warm dust and ozone. Cables ran everywhere, held in place by zip ties and optimism. This was an Ethereum mining operation, and I was standing in the middle of it, watching people I knew convert their gaming rigs, hardware they loved, into money-printing machines. I was there because Vitalik Buterin had decided to visit. He had flown in on a private jet to Geneva, driven up in a black limousine with tinted windows, and walked into this dusty, chaotic space to see what Swiss miners were building. It was surreal. The creator of Ethereum, stepping over power cables in an industrial ruin, nodding at rack after rack of GPUs humming away at proof-of-work hashes. I do not think he was impressed by the elegance of the setup. Nobody was. But something about that scene stuck with me. People were willing to sacrifice their gaming entertainment, their leisure hardware, to chase the dream of sovereign financial independence using fundamentally nerdy equipment: PCs, internet connections, blockchain protocols, and GPU graphics cards. They were converting consumer-grade technology into economic infrastructure, and they were doing it themselves. No data center leases. No vendor contracts. No permission from anyone. Just people, hardware, and a protocol that made it worth their while. I had skin in the game too. I invested (gambled, honestly) in crypto during that era. I watched the charts, rode the swings, felt the dopamine spikes and the stomach-drops. The financial side was wild and ultimately unsustainable for most people. But the infrastructure side, the part where ordinary humans turned their homes into compute nodes and got paid for it: that part was real, and that part stayed with me long after the crypto hype faded and the rigs went quiet. This is the story of how that factory visit turned into Archipelag.io</a>, a distributed compute network that entered open beta today. It has been ten years of thinking, one year of building, and a lot of being wrong about the right things at the wrong time. How AI Makes Bare Metal Viable Again Unknown — Sun, 08 Mar 2026 00:00:00 +0000 I was paying over two hundred dollars a month to run two apps that had zero paying users. Not because the apps were complex. Not because they needed high availability across regions. Because I was running Kubernetes on DigitalOcean, and Kubernetes has opinions about how much infrastructure you need. A control plane. Worker nodes. Load balancers. Persistent volumes. Managed databases. Each line item modest on its own, adding up to a bill that felt absurd for two Phoenix applications in their bootstrapping phase. The apps are archipelag.io</a> and cyanea.bio</a>. Both are Elixir/Phoenix projects. Archipelag uses PostgreSQL and NATS for its messaging layer. Cyanea uses SQLite. Neither gets meaningful traffic yet. Both are real products I am actively building, not side projects I will abandon next month. But they are pre-revenue, and every dollar I spend on infrastructure is a dollar I am betting against future income that does not exist yet. Something had to change. The Kubernetes trap</h2> Here is the thing about Kubernetes: it solves problems you might not have. If you are running fifty microservices across three regions with autoscaling requirements and a platform team to manage it, Kubernetes earns its keep. If you are running two BEAM applications that each consume less than 512 MB of memory, you are paying a complexity tax for infrastructure capabilities you will never touch. My K8s setup on DigitalOcean looked like this: a managed cluster with two worker nodes (the minimum for any reasonable availability), a managed PostgreSQL instance for Archipelag, a load balancer for ingress, persistent volumes for Cyanea’s SQLite database. Each component had its own monthly cost. The cluster management fee alone was more than what I would eventually pay for an entire bare metal server. The operational overhead was worse than the cost. Helm charts. Ingress controllers. Certificate managers. Pod disruption budgets. Every time I wanted to deploy a new version, I was wrangling YAML files that described infrastructure concerns my apps did not care about. A Phoenix release does not need a pod spec. It needs a port, an environment, and someone to restart it if it crashes. And the YAML, my God, the YAML. A simple Phoenix app that listens on a port and serves HTTP needs, at minimum, a Deployment manifest, a Service manifest, and an Ingress manifest. Add a ConfigMap for environment variables, a Secret for credentials, a PersistentVolumeClaim if you need disk, a HorizontalPodAutoscaler if you want autoscaling. For Cyanea alone, I had six Kubernetes manifests totaling a few hundred lines of YAML, all to describe an application that boils down to: run this binary, give it a port, point a domain at it. The cognitive load compounds. You learn the Kubernetes resource model, then the DigitalOcean-specific annotations for their load balancer, then the cert-manager CRDs for TLS, then the quirks of persistent volumes on managed K8s (spoiler: they are not as persistent as you think if you do not get the reclaim policy right). Each layer has its own documentation, its own failure modes, its own upgrade cycle. I spent more time debugging infrastructure than building product. The irony is not lost on me. Kubernetes was designed for teams running hundreds of services at Google-scale. I was running two apps. The orchestrator had more moving parts than the things it was orchestrating. It was like hiring a logistics fleet to deliver two packages across town. I knew I was over-engineered. But the alternative, at the time, seemed like a step backward. The Nomad detour</h2> I should mention that Kubernetes was never the only orchestrator I considered. For the past five years, while the industry went all-in on K8s, I had been quietly admiring HashiCorp’s Nomad</a>. Where Kubernetes is a sprawling ecosystem of CRDs, operators, and control loops, Nomad is refreshingly minimal. A single binary. A simple job spec. No opinions about networking, no built-in service mesh, no mandatory etcd cluster. You tell it what to run, it runs it. That minimalism appealed to me. Nomad treats workload scheduling as the core problem and stays out of everything else. No built-in networking layer means you bring your own, which sounds like a drawback until you realize it means you are not locked into someone else’s networking model. And I happened to have my own networking layer already. I had been building Zentinel</a> in parallel, a security-first reverse proxy built on Cloudflare’s Pingora</a> framework in Rust. Zentinel handles TLS termination, WAF inspection, rate limiting, domain-based routing, all the edge concerns I care about. It also supports sleepable ops, where backend instances can be suspended and woken on demand, which is perfect for apps that do not need to be running 24/7. So I tried pairing them. Nomad for workload scheduling, Zentinel for the network layer. And it worked. The combination gave me a lightweight orchestrator that did not try to own every concern, paired with a reverse proxy that handled edge traffic the way I wanted. Two focused tools, each doing one thing well. But then IBM acquired HashiCorp, and the calculus changed. The acquisition itself was not the problem. Companies get acquired. It happens. The problem was the trajectory. HashiCorp had already re-licensed Terraform from MPL to BSL (Business Source License) in 2023, a move that fractured the community and spawned the OpenTofu</a> fork. The pattern was familiar: open-source project gains adoption, company monetizes through enterprise features, company gets acquired, new owner tightens the screws. I had watched it happen with Redis, with Elasticsearch, with MongoDB. Each time the community forks, there is a period of uncertainty, split maintenance effort, and feature divergence. I did not want to build my infrastructure on a foundation where the governance could shift at any time. Nomad is still open source today. But “still open source” and “will remain open source” are different statements, and after the Terraform situation, I was not confident in the latter. The BSL license change had been a signal, and IBM’s acquisition amplified it. I did not need to go down that road with another HashiCorp product. The Nomad experiment did teach me something valuable, though. It confirmed that the KISS approach to deployment was right. You do not need the full Kubernetes machinery. A scheduler that starts processes, checks their health, and restarts them when they crash is sufficient for a wide range of workloads. And a dedicated reverse proxy that handles TLS and routing is cleaner than bundling networking into the orchestrator. That insight, Nomad’s minimalism plus Zentinel’s Pingora-based proxy architecture, became the design seed for what I would eventually build. The fly.io middle ground</h2> With Nomad off the table as a long-term bet, I migrated to fly.io</a> in late 2025. It was genuinely better than K8s for my use case. Fly understands BEAM applications at a fundamental level. The BEAM runtime is designed for the kind of lightweight, long-lived processes that Fly’s infrastructure optimizes for. You push a release, it runs it. No YAML. No ingress controllers. No cluster management. Fly also made the service dependencies painless. Managed Postgres with a few commands. NATS was straightforward to set up. Tigris (Fly’s S3-compatible object storage) handled blob storage for Cyanea’s file uploads. The developer experience was genuinely excellent, and I mean that without reservation. The Fly team has built something thoughtful. The cost dropped meaningfully. No cluster management fee. No minimum node count. Pay-per-VM pricing that scales down to fractions of a shared CPU. Fly’s model is honest about what small applications actually need, and the pricing reflects that. I went from over two hundred dollars a month on DigitalOcean K8s to roughly a quarter of that. For a while, it was the right answer. And if I had been scaling horizontally, adding regions, needing the kind of elastic compute that cloud-native platforms excel at, I would have stayed. If my apps suddenly got traction and I needed instances in Tokyo, Frankfurt, and Virginia, Fly would be the obvious choice. The multi-region story is one of Fly’s genuine strengths. You deploy once, it runs everywhere. That is hard to replicate. But I was not scaling horizontally. I was running two apps in one location. On a good day, they handled maybe a few hundred requests. The compute they needed was trivial, a fraction of a shared CPU core. And I was still paying for a platform designed to scale to thousands of instances across dozens of regions, even though I needed exactly one instance of each app, in exactly one place, doing very little work. There is also a subtler cost that managed platforms carry: the abstraction tax. When something goes wrong on Fly (and it did, occasionally, things like deployment timeouts or the odd networking hiccup), you are debugging at the platform level, not the system level. You file a support ticket or check the status page. You do not SSH in and look at processes, because there are no processes you can see. The platform is the intermediary, and the intermediary has its own failure modes that you cannot inspect or fix. The cloud-native model, even the lean version that Fly offers, has a floor. You are always paying for the platform’s capabilities, not just your usage of them. When your usage is “two small apps, one location, no scale,” that floor matters. And when the platform sits between you and your processes, you lose the ability to debug at the level where the answers actually live. The bare metal math</h2> I started looking at dedicated servers. Not VPS instances, not cloud VMs. Actual hardware you can SSH into, where your processes run on real cores and your data sits on real disks. Hetzner runs a server auction</a> where they sell refurbished dedicated machines at steep discounts. These are servers that have been running in Hetzner’s data centers, got rotated out of customer contracts, and are resold at prices that make cloud compute look like a luxury good. The hardware is used but maintained, and Hetzner’s data centers are well-run, proper cooling, redundant power, good network connectivity. I found a box with a multi-core Intel CPU, 128 GB of DDR4 RAM, and two 1 TB NVMe drives that I configured in RAID 1 for redundancy. EUR 38 a month. About forty-two dollars. Fixed price. No bandwidth metering (Hetzner includes 20 TB of traffic on dedicated servers, which for my workload might as well be unlimited). No surprises on the bill. Let that sink in for a moment. For less than what I was paying for managed Postgres alone on either platform, I could have an entire server with more RAM than I know what to do with, fast NVMe storage with mirror redundancy, and enough compute headroom to run not two but twenty applications without breaking a sweat. The two NVMe drives alone, if bought retail, would cost more than a year of hosting. I ran the numbers on capacity. My two Phoenix apps, even under load, would use maybe 1-2 GB of RAM combined. PostgreSQL with a modest dataset, another gig or two. NATS, negligible. That leaves well over 120 GB of RAM sitting idle. The CPU tells a similar story. Phoenix on the BEAM is remarkably efficient with CPU resources, the scheduler does its own preemptive multitasking across lightweight processes, and my workloads are I/O-bound, not compute-bound. I could run my entire current stack and barely register on a load graph. The headroom is the point. On a cloud platform, headroom costs money. More RAM, higher tier. More CPU, higher tier. On bare metal, the headroom is already paid for. Growing from two apps to ten does not change my monthly bill. Adding a staging environment does not change my monthly bill. Running background workers, a metrics stack, a CI runner, none of it changes my monthly bill. The marginal cost of additional workloads on existing hardware is zero. The math was obvious. The problem was everything else. Why bare metal was hard</h2> Bare metal has always been cheap. That was never the issue. The issue was everything you had to build and maintain yourself. On a managed platform, you get deployment pipelines, TLS certificate management, process supervision, reverse proxying, log aggregation, health checks, and rollback mechanisms out of the box. On bare metal, you get a Linux login prompt and a blinking cursor. Historically, going bare metal for web applications meant weeks of setup: Install and configure nginx or HAProxy as a reverse proxy</li> Set up Certbot or acme.sh for Let’s Encrypt certificates, and hope the renewal cron does not silently break</li> Write deployment scripts (rsync, symlinks, restart commands) and debug them for months</li> Configure systemd services for each app, with the right restart policies and environment files</li> Build a process supervision layer that handles crashes, port allocation, and graceful shutdowns</li> Figure out zero-downtime deploys (which means running two instances, health checking the new one, swapping traffic, draining the old one)</li> Set up log rotation, monitoring, backups</li> Harden the server (firewall, SSH config, automatic security updates)</li> </ul> Each of these is a solved problem in isolation. There are blog posts and Stack Overflow answers for every one of them. But stitching them together into a coherent, reliable deployment system is a full-time job for a week or two, and maintaining it is an ongoing tax on your attention. This is why the cloud won. Not because bare metal is expensive. Because the operational cost of doing it yourself was prohibitive for small teams. The cloud sold you a package deal: we handle the infrastructure, you handle the application. Worth it, even at a premium. But what if that operational cost dropped to near zero? The AI shift</h2> I had Claude Code with Opus 4.6 available. I had spent months working with it on other projects. Compilers, CRDT engines, reverse proxies. I knew what it could do with a clear spec and a well-defined problem domain. And deploying web applications to bare metal is a well-defined problem domain. The core requirements are straightforward: upload an artifact, start it on a port, check that it is healthy, route traffic to it, stop the old one. Everything else, TLS, process supervision, rollback, log capture, is layered on top of that core loop. The problem space is wide but shallow. Lots of features, few genuinely novel algorithms. This is exactly the kind of work where AI shines. Not because it writes perfect code on the first try. But because it can iterate through a feature list at a pace that would take a solo developer weeks, producing working implementations in hours. The feedback loop is tight: describe what you want, get code, test it, refine. The domain knowledge exists in a thousand deployment tools that came before. The AI has seen all of them. So I decided to build my own deployment tool. From scratch. With AI as my co-engineer. Building Vela</h2> Vela</a> is what came out of that process. A single Rust binary that handles everything I listed above: reverse proxy, auto-TLS, process supervision, zero-downtime deploys, health checks, secret management, log streaming, rollbacks. No containers. No Docker. No YAML. The design draws from both of its ancestors. From Nomad, the suckless philosophy: a single binary, minimal configuration, no opinions about things that are not its problem. From Zentinel, the Pingora-inspired proxy architecture: hyper-based reverse proxy with TLS termination, domain-based routing, and WebSocket support baked into the same process. Vela is what happens when you take the best ideas from tools you admire and combine them into something purpose-built for your exact workload. The design philosophy is blunt: one binary, two modes. ┌─────────────────────────────────────────────┐ │ Your server │ │ │ │ Vela daemon │ │ ├── Reverse proxy (:80/:443, auto-TLS) │ │ ├── Process manager (start, health, swap) │ │ └── IPC socket │ │ │ │ Apps │ │ ├── cyanea.bio → :10001 │ │ └── archipelag.io → :10002 │ └─────────────────────────────────────────────┘ ┌─────────────────────────────────────────────┐ │ Your laptop │ │ │ │ vela deploy → scp + ssh → server │ └─────────────────────────────────────────────┘ </code></pre> vela serve</code> runs on the server. It is the reverse proxy, the process manager, and the IPC daemon, all in one process. vela deploy</code> runs on your laptop. It reads a manifest, uploads your artifact over SSH, and tells the server to activate it. SSH is the control plane. No tokens, no API keys, no custom authentication layer. If you can SSH into the server, you can deploy. This is a deliberate choice. SSH key management is a solved problem. Every developer already has it configured. Every server already has it running. Building a custom auth system on top would be adding complexity for no practical gain. The manifest</h3> Each app gets a Vela.toml</code> in its project root: [app] name = "cyanea" domain = "app.cyanea.bio" [deploy] server = "deploy@my-server" type = "beam" binary = "server" health = "/health" strategy = "sequential" pre_start = "bin/cyanea eval 'Cyanea.Release.migrate()'" [env] DATABASE_PATH = "${data_dir}/cyanea.db" SECRET_KEY_BASE = "${secret:SECRET_KEY_BASE}" </code></pre> That is the entire deploy configuration. The app type tells Vela how to start it (beam</code> runs Elixir releases, binary</code> runs compiled executables). The health path tells it where to check. The strategy tells it how to swap traffic. The pre_start</code> hook runs database migrations before the new instance starts, and if migrations fail, the deploy aborts and the old instance keeps running. Environment variables support two substitution patterns: ${data_dir}</code> expands to the app’s persistent data directory (which survives deploys), and ${secret:KEY}</code> pulls from the server-side secret store. Secrets never live in your repo. Deploying looks like this: MIX_ENV=prod mix release vela deploy ./_build/prod/rel/cyanea </code></pre> Two commands. The artifact goes up, the health check passes, traffic swaps, done. Zero-downtime deploys</h3> Vela supports two deploy strategies, and the choice matters. Blue-green is the default. The new instance starts alongside the old one on a fresh port. Vela runs a health check against it (30 retries, one per second, five-second timeout per attempt). Once the health check passes, the reverse proxy atomically swaps the route table entry for that domain to point at the new port. The old instance gets a configurable drain period to finish in-flight requests, then receives SIGTERM. If it does not exit within the drain window, SIGKILL. Time ──────────────────────────────────────────► Old instance ████████████████████░░░░ (draining) New instance ░░░░████████████████████ ▲ ▲ start │ │ health passes, swap </code></pre> Zero downtime. The user never sees a blip. This works for stateless apps and apps backed by PostgreSQL (where both instances can connect to the same database simultaneously). Sequential is for SQLite apps. You cannot have two processes writing to the same SQLite database (WAL mode helps, but concurrent writers from separate instances is asking for trouble). So Vela stops the old instance first, starts the new one, health checks it, and activates it. Sub-second blip. Acceptable for apps where the alternative is write contention. Time ──────────────────────────────────────────► Old instance ████████████████████ New instance ░░░░████████████████████ ▲ ▲ stop │ │ start + health check </code></pre> The decision is per-app, configured in the manifest. Cyanea uses sequential (SQLite). Archipelag uses blue-green (PostgreSQL). Process supervision</h3> Vela does not just start your app and walk away. It supervises it. If a process crashes, Vela detects the exit (via non-blocking try_wait</code> on the child process handle), logs it, and restarts from the stored launch configuration: pub async fn check_and_restart(&mut self) -> Vec<String> { let mut to_restart = Vec::new(); for (key, process) in &mut self.running { match process.child.try_wait() { Ok(Some(status)) if !status.success() => { // Process exited unexpectedly to_restart.push(( key.clone(), process.launch_config.clone(), )); } _ => {} } } for (key, config) in to_restart { // Restart on same port if available, allocate new otherwise self.restart_from_config(&key, &config).await; } } </code></pre> Each app’s LaunchConfig</code> (release directory, binary name, app type, environment variables, data directory) is stored so that restarts use the exact same configuration. The daemon also persists app state to disk, so if Vela itself restarts (server reboot, daemon upgrade), it restores all running apps from their saved configurations. This is the kind of feature that would take a day to specify and a week to implement if you were writing it from scratch. With Claude, it took about an hour of iteration, including the edge cases around port reallocation and the pending/active state split during deploys. Built-in services</h3> Both of my apps have service dependencies. Archipelag needs PostgreSQL and NATS. Rather than managing these separately, Vela handles service provisioning directly: [services.postgres] version = "17" databases = ["archipelag_prod"] [services.nats] version = "2.10" jetstream = true </code></pre> On first deploy, Vela installs PostgreSQL (via apt), creates the database with a generated password, and injects DATABASE_URL</code> into the app’s environment. For NATS, it downloads the binary, generates a config, and starts it as a supervised child process with NATS_URL</code> injected. Service credentials persist across deploys and daemon restarts. This was one of those features where the AI really earned its keep. The NATS lifecycle management alone, downloading the right binary for the platform, generating config, supervising the process, health-checking the monitoring endpoint, persisting credentials, involved touching six or seven modules. Claude handled the plumbing while I focused on the design decisions. The reverse proxy</h3> Vela embeds its own reverse proxy built on hyper. It handles TLS termination (auto-provisioned via Let’s Encrypt ACME HTTP-01, or static certificates for Cloudflare setups), domain-based routing, WebSocket upgrades, and HTTP-to-HTTPS redirects. The routing model is simple. A thread-safe hash map from domain to port: pub struct RouteTable { routes: Arc<RwLock<HashMap<String, u16>>>, } </code></pre> When a request arrives, Vela extracts the Host header, looks up the port, and forwards the request to localhost:{port}</code>. When a deploy swaps traffic, it is a single write-lock on the hash map to update the port number. Atomic. No configuration reload. No proxy restart. For WebSocket connections (which both Phoenix apps use for LiveView), Vela detects the Upgrade: websocket</code> header and switches to raw TCP tunneling with bidirectional I/O. This was important for my use case, Phoenix LiveView is WebSocket-native, and if the proxy does not handle upgrades correctly, the entire UI breaks. From empty box to production in a day</h2> Here is the timeline of the actual migration. I bought the Hetzner server and within about 48 hours, both apps were running in production with HTTPS, process supervision, automated backups, and daily health reports. The sequence went roughly like this: Hardware validation: Check NVMe drive health, run memory tests, verify RAID configuration. The drives had about 25,000 power-on hours (these are auction servers, they have been used), but SMART health passed and wear levels were well within acceptable range. </li> OS provisioning: Debian, RAID 1 across both NVMe drives. Straightforward. </li> Server hardening: Firewall rules, SSH hardening (key-only auth, non-default port, rate limiting), automatic security updates, intrusion detection. This is the part I am deliberately vague about. If you are running a public-facing server, hardening is non-negotiable, but I am not going to publish my exact firewall configuration. </li> Vela installation: Download the binary, create a config file, install the systemd service. Five minutes. </li> First app deployed (Cyanea): Built the Elixir release on the server, set secrets, ran migrations, deployed. The entire build-and-deploy cycle for a Phoenix app with a Rust NIF took about fifteen minutes, most of which was compilation. </li> Second app deployed (Archipelag): Same flow, plus provisioning PostgreSQL and restoring a database dump from Fly, plus setting up NATS. About thirty minutes. </li> TLS certificates: Updated DNS records, Let’s Encrypt certificates issued automatically. Vela handles the ACME challenge internally, no Certbot, no cron job, no manual cert management. </li> Monitoring: A daily health report script that checks system metrics, service status, and app health, then emails a summary. Simple but effective. </li> </ol> The most time-consuming part was not the tooling. It was migrating the PostgreSQL data from Fly and verifying that both apps behaved correctly in their new environment. The infrastructure setup itself, the part that would have taken weeks without Vela, took hours. The broader thesis</h2> Here is what I think is happening, and I think it is bigger than my personal infrastructure bill. The cloud won because it sold a bundle: compute, networking, storage, deployment, monitoring, scaling, security, all integrated, all managed. The alternative was building each piece yourself, and the labor cost made that prohibitive for small teams. Managed infrastructure was cheaper than an ops engineer. AI changes that equation. Not by making the cloud cheaper, but by making bespoke tooling economically viable. Consider what I got with Vela. A deployment tool that does exactly what I need and nothing more. No container orchestration, because I do not use containers. No multi-region routing, because I run in one location. No autoscaling, because two apps do not need to autoscale. Every feature exists because I needed it. Every feature works with my specific stack (Elixir/BEAM, Rust, SQLite, PostgreSQL, NATS). The tool is tailored to my workload the way a bespoke suit is tailored to a body. This kind of custom tooling used to be a luxury. You needed either a platform team that could invest weeks of engineering time, or the rare individual who was both a skilled systems programmer and willing to spend their evenings writing deployment tools instead of building products. The economics did not make sense for a solo founder or a two-person team. With AI, the cost of building bespoke tooling drops by an order of magnitude. Not to zero, you still need to know what you want, you still need to test and iterate, you still need to understand the domain well enough to evaluate the output. But the gap between “I know what I need” and “I have a working implementation” shrinks from weeks to hours. And when bespoke tooling is cheap, the cloud’s bundle becomes less compelling. You do not need the managed Kubernetes service if you can build a deployment tool that fits your exact needs. You do not need the managed database service if you can install PostgreSQL yourself and the AI helps you set up backups, monitoring, and failover. You do not need the managed TLS service if your deployment tool handles ACME natively. What you are left paying for is compute and bandwidth. And for compute and bandwidth, bare metal is drastically cheaper than the cloud. The API is bespoke</h2> There is a subtlety here that I think is worth calling out. When people talk about the cloud’s advantages, they often point to the API-driven experience. Infrastructure as code. Declarative configuration. Programmable everything. And that is real. The cloud’s API layer is genuinely valuable. But the API does not have to come from a cloud provider. It can come from your own tooling. Vela gives me an API-driven experience. I declare my app’s configuration in a TOML manifest. I run a single command to deploy. I can check status, stream logs, manage secrets, trigger backups, and roll back releases, all from my laptop, all through a CLI that speaks SSH to a daemon on the server. The experience is not worse than Fly or Heroku. In some ways it is better, because the tool does exactly what I need and nothing else, and when something goes wrong, I can read the source code. The difference is that my “API” is a 5,000-line Rust binary instead of a multi-billion-dollar cloud platform. And that is fine. I do not need the platform. I need the interface. AI lets me build the interface. This is, I think, the pattern that will play out more broadly. The cloud’s value was never just compute. It was the operational layer on top of compute, the tooling that made raw hardware usable. AI makes it possible to build that operational layer yourself, tailored to your needs, at a fraction of the cost. The cloud becomes optional. The server becomes a commodity. The differentiator is the tooling, and the tooling is something AI can help you build. What the numbers look like</h2> Let me be concrete about costs, because this is ultimately an economic argument. Kubernetes on DigitalOcean (my original setup): Managed K8s cluster: ~$12/month (control plane fee)</li> Worker nodes (2x smallest): ~$24/month</li> Managed PostgreSQL: ~$15/month</li> Load balancer: ~$12/month</li> Persistent volumes, bandwidth, extras: ~$15/month</li> Total: ~$78-80/month (and this was after I trimmed it)</li> </ul> Fly.io (the middle ground): Two Phoenix apps (shared-cpu-1x, 256MB each): ~$14/month</li> Managed Postgres: ~$25/month</li> Managed NATS: ~$20/month</li> Bandwidth, extras: ~$10/month</li> Total: ~$70/month</li> </ul> The managed services were the killer. Fly’s compute pricing is fair, but managed Postgres and managed NATS added up fast. And that was at near-zero traffic. Egress pricing on Fly is metered, so if either app had started getting real user load, the bandwidth bill alone would have pushed the total well past a hundred dollars a month. Hetzner bare metal (current): Dedicated server (auction): EUR 38/month (~$42)</li> That is it. PostgreSQL, NATS, TLS, everything runs on the box.</li> Total: ~$42/month</li> </ul> The Hetzner box is cheaper than Fly right now, and the gap only widens as usage grows. But the raw dollar comparison understates the difference. Look at what I am getting. 128 GB of RAM versus 512 MB. Multi-core CPU versus shared fractional cores. Two terabytes of NVMe storage versus a few gigs. Bandwidth that is essentially unlimited (Hetzner includes 20 TB of traffic) versus metered egress that scales with every user you add. The capacity gap is the real story. On Fly, scaling from two apps to ten means linearly increasing costs, more VMs, more managed database instances, more bandwidth charges. On my Hetzner box, scaling from two apps to ten means… nothing. The resources are already there. I paid for them. PostgreSQL, NATS, any other service I want to run, it all fits on the same box with room to spare. And there is no surprise bill. No bandwidth overage. No “your database exceeded the row limit” fee. No managed service add-on creep. Thirty-eight euros a month, every month, regardless of what I run on it. When this does not apply</h2> I would be dishonest if I pretended bare metal is the right answer for everyone. It is not. If you need multi-region presence, the cloud still wins. Running your own hardware in three continents is a different kind of problem. Edge computing, CDN-native architectures (which I wrote about previously</a>), and platforms like Fly or Cloudflare Workers are the right tools for workloads that need to be close to users worldwide. If you need elastic scaling, bare metal does not flex. A server has fixed resources. If your traffic spikes 10x for an hour, you cannot add capacity on demand. You can over-provision (and at these prices, generous over-provisioning is affordable), but it is not the same as true elasticity. If you do not understand the operational basics, bare metal will bite you. Server hardening, backup strategies, disk monitoring, security patching, these are your responsibility. The cloud abstracts them away. On bare metal, a missed security update is your problem. A full disk is your problem. A failed drive (RAID helps, but is not magic) is your problem. If your team is large and needs guardrails, managed platforms provide consistency and governance that bare metal does not. Kubernetes is complex, but it is complex in a standardized way. Everyone knows how to deploy to K8s. Everyone knows how to debug a pod. Your custom Vela setup is legible to exactly the people who built it. The sweet spot for bare metal, especially AI-assisted bare metal, is small teams building products that need reliability but not scale, performance but not elasticity, control but not standardization. Solo founders. Two-person startups. Side projects that might become real businesses. What I learned</h2> The migration took about 48 hours from “I have an empty server” to “both apps are in production with HTTPS, monitoring, and automated backups.” Most of that time was data migration and validation, not infrastructure setup. Vela is now at version 0.5.0 with a feature list I am genuinely proud of: blue-green and sequential deploys, process supervision with auto-restart, built-in reverse proxy with auto-TLS, service dependency management (Postgres and NATS), secret management, log streaming, rollbacks, remote builds, scheduled backups, deploy hooks, and machine-readable status output for monitoring integration. I built most of it in a few focused sessions with Claude Code. Not because the code is trivial, it is about 4,000 lines of Rust with async IPC, Unix socket communication, ACME certificate management, process lifecycle handling, and a reverse proxy with WebSocket support. But because the problem domain is well-understood, the requirements were clear, and AI is remarkably good at turning clear requirements into working implementations. The thing I keep coming back to: the cloud was never selling compute. It was selling convenience. And convenience used to require a company with thousands of engineers to build platforms that abstracted away the hard parts. Now, a developer with a clear idea of what they need and an AI that can write systems code can build a fit-for-purpose operational layer in a weekend. That does not make the cloud irrelevant. It makes the cloud optional for a much larger class of workloads than it was before. Buy a server. Build your tools. Ship your product. The infrastructure should be boring. With AI, it finally can be. References and further reading</h2> Tools and platforms</h3> Vela</a> - The bare-metal deployment tool built in this article</li> Hetzner Server Auction</a> - Refurbished dedicated servers at steep discounts</li> fly.io</a> - The managed platform I migrated from</li> Nomad</a> - HashiCorp’s minimal workload orchestrator</li> OpenTofu</a> - Community fork of Terraform after the BSL relicense</li> Pingora</a> - Cloudflare’s Rust framework for building programmable proxies</li> hyper</a> - Rust HTTP library powering Vela’s reverse proxy</li> Let’s Encrypt</a> - Free TLS certificates, automated via ACME in Vela</li> NATS</a> - Lightweight messaging system used by Archipelag</li> </ul> Frameworks and runtimes</h3> Phoenix Framework</a> - Elixir web framework powering both apps</li> Erlang/OTP</a> - The BEAM virtual machine that runs Phoenix and Elixir</li> Rust</a> - Systems language Vela and Zentinel are written in</li> </ul> Projects referenced</h3> Zentinel</a> - Security-first reverse proxy built on Pingora</li> Archipelag</a> - Distributed compute platform</li> Cyanea</a> - Bioinformatics platform</li> Claude Code</a> - AI coding tool used to build Vela</li> </ul> Edge Systems Are the New Backend Unknown — Wed, 11 Feb 2026 00:00:00 +0000 A request arrives at your system. In the next 50 milliseconds, before any application code runs, this happens: TLS termination, route matching, WAF inspection against 285 detection rules, JWT validation, rate limit evaluation, request body validation against a JSON schema, and trace context generation. The request either dies at the edge or arrives at your backend pre-authenticated, pre-validated, and pre-authorized. Five years ago, your backend did all of this. Every service validated its own tokens, enforced its own rate limits, ran its own security checks. Today, the backend might not even exist in the form you expect. It might be a static site served from edge nodes, a thin persistence API, or a headless CMS that publishes content to a CDN and never handles a user request directly. Something shifted. Not just at the edge. On both ends. The three-tier past</h2> The architecture most of us learned was simple. Client, backend, database. The browser rendered HTML, maybe ran some jQuery. The backend did everything: authentication, authorization, business logic, rendering, validation, rate limiting, session management. The database stored state. Clean separation, one direction, easy to reason about. This model worked because the browser was dumb. It could render markup and submit forms. Any real computation had to happen on the server. The backend was fat by necessity, not by design. Microservices made it worse. Consider a typical setup: a user service, an order service, a payment service, a notification service, an inventory service. Each one needs to validate JWTs. Each one needs to enforce rate limits. Each one needs input validation, request logging, and error handling. That is five services times six concerns. Thirty implementations of logic that should exist exactly once. Now multiply. Real organizations have 15, 50, 200 services. Each team implements auth slightly differently. One uses a shared library, one copied the code two years ago, one rolled their own because the library did not support their token format. The rate limiting configurations drift. The logging formats diverge. A security patch to the JWT validation logic means PRs across every repository, coordinated deployments, and someone asking “did we get all of them?” ┌──────────┬──────────┬──────────┐ │ Users │ Orders │ Payments │ │ Service │ Service │ Service │ ├──────────┼──────────┼──────────┤ Auth │ ✓ (v2.1) │ ✓ (v1.9) │ ✓ (v2.0)│ Rate limiting │ ✓ (lib) │ ✓ (copy) │ ✗ (none)│ Validation │ ✓ │ ✓ │ ✓ │ WAF/Security │ ✗ │ ✗ │ ✗ │ Logging │ JSON │ text │ JSON │ Tracing │ ✓ │ ✗ │ ✓ │ └──────────┴──────────┴──────────┘ </code></pre> Libraries helped. Service meshes helped more. But the complexity was still distributed across every service, in every team’s codebase, in every deployment pipeline. The mesh moved networking concerns to a sidecar. It did not move application-level concerns like auth, validation, or security inspection. The edge was an afterthought. A reverse proxy. TLS termination. Maybe Varnish for caching. Maybe a CDN for static assets. It was infrastructure plumbing, not a place where decisions happened. That model is over. Two migrations, one hollowing</h2> Here is the thing I keep coming back to: business logic is migrating in two directions simultaneously. Upward, to the edge. Infrastructure concerns like auth, WAF, and rate limiting now execute at the edge layer, before requests reach any backend. But it goes further than that. Edge Workers run actual application code. Containers deploy at the edge. Server-side rendering happens at edge nodes 50ms from the user, not in a data center 200ms away. Downward, to the client. The browser is no longer dumb. WebAssembly runs near-native code. WebGPU puts the GPU to work on ML inference and image processing. Web Workers handle background computation. Service Workers intercept network requests and serve cached responses offline. CRDTs let the client own its data and sync when it feels like it. The backend is caught in the middle. Squeezed from both sides. And what remains is not a “backend” in any traditional sense. It is a persistence layer. A place where data rests and syncs. The interesting work happens elsewhere. What moved to the edge</h2> Infrastructure concerns</h3> The first wave was obvious. Cross-cutting concerns that every service needed are better handled once, at the point of entry. Authentication. Validating a JWT does not require application context. The token is self-contained: a signature, an issuer, an expiry, a set of claims. Parse it, verify the signature against a JWKS endpoint, check the expiry, extract the claims, attach them as headers. Done. The backend receives X-User-Id: alice</code> and X-User-Role: admin</code> instead of a raw Bearer token it has to decode itself. This is not hypothetical. Here is what this looks like in practice: agent "auth" { type "auth" grpc address="http://localhost:50051" events "request_headers" timeout-ms 100 failure-mode "closed" max-concurrent-calls 100 } </code></pre> That agent handles JWT, OIDC, SAML, mTLS, and API key validation. Every route behind it gets authentication for free. Every backend service trusts the edge to have done the work. The auth agent crashes? Failure mode is “closed”. Requests stop, but the proxy stays up. Rate limiting. Token bucket algorithms with per-client keys. The edge layer sees every request before the backend does. It is the natural place to enforce rate limits because it can reject bad traffic before it consumes backend resources. A rejected request at the edge costs microseconds. A rejected request at the backend costs a database query, a connection slot, and whatever work happened before the check. There are two flavors. Local rate limiting uses in-process token buckets. Fast, no network hops, but each edge node tracks its own counters. If you have 10 edge nodes and a limit of 100 requests per second, each node allows 100, so the effective limit is 1,000. For most use cases, this is fine. Abuse does not distribute itself evenly across your infrastructure. Distributed rate limiting uses a shared store (Redis, typically). Accurate across nodes, but adds a network hop per request. The tradeoff is latency versus precision. I default to local rate limiting and switch to distributed only when the use case demands exact global limits, like API billing or token budgets for LLM inference. Security inspection. WAFs used to be appliances. Expensive, opaque, binary. A request was either blocked or allowed. Modern WAFs use anomaly scoring. Each rule contributes a score, and the total determines the action: Score 0-9: Allow Score 10-24: Log (warning, investigate later) Score 25+: Block </code></pre> This is a fundamentally different model than binary block/allow. It lets you tune aggressively without breaking legitimate traffic. I run 285 detection rules at the edge and process 912K requests per second on clean traffic. That is 30x faster than ModSecurity’s C implementation. The performance gap matters because it means WAF inspection can happen on every request, not just suspicious ones. API validation. If your API has a JSON Schema, why validate request bodies in your application code? Validate at the edge. Reject malformed requests before they consume a connection, a goroutine, a database transaction. The backend receives only structurally valid payloads. Observability. Trace context should originate at the edge, not at the application. The edge is where the request enters your system. It is where you assign a trace ID, start the clock, and record the first span. If you originate traces in your application, you miss everything that happened before: TLS negotiation time, WAF processing time, the fact that the request sat in a rate limit queue for 50ms. Starting traces at the edge gives you the full picture. The isolation problem</h3> You cannot put all of this in a monolithic proxy. That is how you end up with nginx and 47 modules where nobody understands the interaction effects. A WAF bug should not take down your routing. A slow auth provider should not block rate limit checks. The answer is process isolation. Thin dataplane, crash-isolated external agents. Each agent runs as a separate process with its own failure domain: ┌──────────────────────────────────────────┐ │ Edge Proxy (thin dataplane) │ │ Routing │ TLS │ Caching │ Load Balancing │ └─────┬──────────┬──────────┬──────────────┘ │ │ │ ▼ ▼ ▼ [WAF] [Auth] [Rate Limit] process process process </code></pre> Each agent gets its own concurrency semaphore. A slow WAF cannot starve auth. Each agent has a circuit breaker. Three failures in 30 seconds and the circuit opens. Each agent has a configurable failure mode, and this is where the design gets interesting: agent "waf" { type "waf" timeout-ms 100 failure-mode "closed" max-concurrent-calls 50 circuit-breaker { failure-threshold 5 success-threshold 2 timeout-seconds 30 } } agent "rate-limit" { type "rate-limit" timeout-ms 50 failure-mode "open" max-concurrent-calls 200 } </code></pre> The WAF fails closed. If it crashes or times out, requests are blocked. You lose availability to preserve security. Rate limiting fails open. If it crashes, requests are allowed. You lose rate enforcement to preserve availability. These are explicit choices per agent, not global defaults. The operator decides which tradeoff to make for each concern, and the decision is visible in the config, not buried in code. Agents return decisions. The proxy merges them. A blocking decision from any agent wins. Otherwise, header mutations accumulate. The model is simple: agents advise, the proxy decides. No agent can override another agent’s block. No agent can force a request through. The proxy owns the final call. This is not a workaround. It is the fundamental design choice. Complex logic lives outside the core, behind process boundaries. The proxy stays small, fast, and boring. The agents handle the interesting work in isolation. A bug in a Lua scripting agent does not corrupt the routing table. A memory leak in the WAF agent does not exhaust the proxy’s memory. The process boundary is the blast radius. Edge Workers: business logic at the edge</h3> Infrastructure concerns were the first wave. The second wave is actual business logic. Cloudflare Workers, Deno Deploy, Fastly Compute, Vercel Edge Functions. These are not just “serverless at the CDN.” They are full compute environments running at edge nodes around the world. V8 isolates spin up in under 5ms. Cold starts are measured in single-digit milliseconds, not seconds. Your code runs 50ms from the user instead of 200ms away in us-east-1. The constraints matter, because they shape what belongs here. Typical Edge Worker limits: 10-50ms CPU time per request (not wall time, actual CPU), 128MB memory, no raw TCP sockets, no persistent file system. You get a request, key-value storage, and the ability to make sub-requests to origins. That is it. These constraints are not bugs. They are what makes sub-millisecond cold starts possible. V8 isolates are cheap because they are small and short-lived. What fits within these constraints is surprisingly broad: API routing and transformation. A request comes in for /api/v2/users</code>. The edge Worker rewrites it, fans out to two backend services (user profiles from one, preferences from another), merges the responses, and returns a single payload. The backend services are simple data sources. The edge Worker is the API layer.</li> A/B testing and feature flags. Read the experiment cookie, hash the user ID, assign a variant, route to the right origin or rewrite the response. No round trip to a feature flag service. The decision happens in microseconds at the node closest to the user.</li> Personalization. Look up the user’s segment in KV storage, inject the right content block, set cache headers accordingly. The backend generated all variants at build time. The edge picks the right one per request.</li> Server-side rendering. Render HTML at the edge node closest to the user. Frameworks like Next.js and Remix already support this. React Server Components run at the edge. The “server” in server-side rendering is not your server. It is an edge node in 300 locations.</li> Authentication and session management. Validate tokens, refresh sessions, set secure cookies. The auth flow never touches your origin. Cloudflare Workers KV or Durable Objects store session state at the edge.</li> </ul> The pattern: compute that depends on request context but not on deep application state moves to the edge. If you can do it with a request, a key-value lookup, and a response, it probably belongs here. If it needs a complex database query or a multi-step transaction, it does not. Containers at the edge</h3> Edge Workers hit a ceiling when you need persistent connections, large memory, or long-running processes. For those workloads, containers at the edge. Fly.io, Railway, and Lambda@Edge deploy containers or full processes to edge locations worldwide. Your application runs with real file systems, TCP connections, and whatever runtime you need. But it runs close to users, not in a centralized data center. Latency drops from 200ms to 20ms. The interesting problem is data gravity. Compute is easy to distribute. Data is not. If your container runs in Tokyo but your database is in Frankfurt, you have not solved the latency problem. You have moved it from the user-to-server hop to the server-to-database hop. The solutions are still maturing: read replicas at the edge (Turso, Neon), embedded databases that sync (LiteFS, libSQL), and eventually-consistent stores designed for multi-region (DynamoDB Global Tables, CockroachDB). This model makes sense when compute and data can be co-located: Regional APIs that comply with data residency requirements. Run the container and the database replica in the same region. GDPR data stays in the EU. Japanese user data stays in Japan.</li> Real-time applications where 200ms round trips kill the experience. Collaborative editing, multiplayer, live dashboards. A WebSocket server 20ms away feels instant. One 200ms away feels sluggish.</li> Stateful edge compute where you need more than a request/response cycle. Background processing, scheduled jobs, long-running connections.</li> </ul> The line between “edge” and “origin” blurs. If your container runs in 30 regions and handles requests locally with a local database replica, is that an edge deployment or a distributed backend? The distinction stops mattering. What matters is that the compute and the data are close to the user. What moved to the client</h2> The other half of the migration goes downward. The browser is not the thin client it used to be. WebAssembly</h3> WASM runs at near-native speed in every modern browser. Not “fast for JavaScript.” Actually fast. Compiled from Rust, C++, Go, or any language with an LLVM backend. Sandboxed, portable, deterministic. What this enables: Image and video processing in the browser. No upload to a server, no round trip, no privacy concern. The pixels never leave the device.</li> Document parsing and transformation. PDF rendering, spreadsheet computation, file format conversion. Libraries compiled to WASM and running client-side.</li> Cryptographic operations. End-to-end encryption where the server never sees plaintext. Key derivation, signing, verification, all in the browser.</li> Compute offloading from the backend. This is the one that changes how you think about server sizing.</li> Full relational databases in the browser. This is the one that changes architectures.</li> </ul> I build on this pattern directly. Cyanea</a>, a bioinformatics platform, uses WASM to offload computation from the backend to the client’s browser. Sequence analysis, structure visualization, dataset filtering, these are CPU-intensive operations that traditionally require beefy server infrastructure. Instead, the computation runs right there on the researcher’s device. The backend stays thin: it stores datasets and coordinates collaboration, but the heavy lifting happens in the browser. This means I can run the platform on a modest server and still deliver real computational capability, because the “compute fleet” is the users’ own machines. Archipelag</a> takes the same idea in a different direction. It is a distributed compute platform where users contribute their browser’s idle compute power via WASM. The workloads compile to WASM modules, ship to participating browsers, execute in the sandbox, and return results. The browser is not just a client consuming a service, it is a compute node in a distributed system. The WASM sandbox is what makes this safe: untrusted code runs in a constrained environment with no access to the host file system, network, or memory beyond what is explicitly granted. SQLite compiled to WASM (via projects like sql.js, wa-sqlite, or the official SQLite WASM build) gives the browser a real relational database. Not a key-value store. Not IndexedDB’s awkward object store API. Actual SQL with joins, indexes, transactions, and triggers. Backed by the Origin Private File System (OPFS) for persistence, it survives page reloads and browser restarts. The implications are significant. Your application can run complex queries locally. Filter, sort, aggregate, full-text search. All instant, all offline. The server becomes a sync endpoint. It ships a database snapshot down and accepts change sets back. The client does the querying. The server does the storing. This pattern scales down elegantly. A note-taking app with SQLite-in-WASM needs no backend API for reads. A project management tool can filter and search 10,000 tasks without a network request. A CMS authoring interface can work fully offline and sync when the author reconnects. The read path is local. The write path syncs eventually. WASI (WebAssembly System Interface) extends this further. It gives WASM modules controlled access to file systems, clocks, and network sockets outside the browser. WASM becomes a universal runtime: the same binary runs in the browser, at the edge (Cloudflare Workers use WASM under the hood), and on bare metal. Write once, deploy to every layer of the stack. The pattern: anything that is CPU-bound, privacy-sensitive, or latency-sensitive is a candidate for client-side WASM. If the computation does not need server-side state, it should not round-trip to a server. WebGPU</h3> WebGPU landed in Chrome in 2023, in Firefox and Safari shortly after, and it changes the math on what the client can compute. This is not WebGL with a new name. WebGL exposes a graphics pipeline. WebGPU exposes compute shaders. Direct, general-purpose GPU computation from JavaScript or WASM. The immediate application is ML inference. Run a language model, an image classifier, or a recommendation engine on the user’s GPU. No server call, no API cost per token, no latency. The model weights download once (cached by the browser) and run locally. Privacy by default, because the data never leaves the device. This is not theoretical. Stable Diffusion generates images in the browser via WebGPU. Small language models (Phi-2, Gemma 2B, Llama 3.2 1B) run at usable speeds on consumer hardware. MediaPipe runs pose detection, face tracking, and hand gesture recognition in real time. The trajectory is clear: models get smaller through distillation and quantization, consumer GPUs get faster, and the gap between “cloud inference” and “local inference” narrows every quarter. Both Cyanea and Archipelag use WebGPU alongside WASM. In Cyanea, WebGPU accelerates molecular visualization and large-scale dataset operations, the kind of parallel computation that bioinformatics demands but that would be prohibitively expensive to run server-side for every user session. In Archipelag, WebGPU-capable nodes can take on GPU-accelerated workloads from the compute pool, turning a user’s idle GPU into a productive resource. The combination of WASM for general compute and WebGPU for parallel workloads gives the browser a compute profile that would have required dedicated server hardware five years ago. But inference is not the only use case. WebGPU handles any parallel computation: physics simulations for games, signal processing for audio applications, particle systems for data visualization, and large-scale matrix operations. Anything you would reach for CUDA or Metal for on native can now run in the browser. The compute budget of the client just increased by orders of magnitude. Web Workers and Service Workers</h3> Web Workers give you background threads. Heavy computation does not block the UI. Parse a large file, run a simulation, index a search corpus. All off the main thread, all without janking the interface. Service Workers sit between the browser and the network. They intercept every fetch request and decide what to do: serve from cache, go to network, do both and race them. This enables: Offline-first applications. The app works without a network connection. Data syncs when connectivity returns.</li> Background sync. Queue mutations while offline, replay them when online.</li> Push notifications. Wake the app without the user having it open.</li> Intelligent caching. Cache API responses, serve stale data while revalidating, pre-fetch resources the user is likely to need.</li> </ul> The Service Worker is the client-side equivalent of the edge proxy. It intercepts, caches, validates, and routes. It makes the client self-sufficient. Local-first and CRDTs</h3> Here is where it gets interesting. If the client has compute (WASM, WebGPU, Web Workers) and storage (IndexedDB, OPFS) and offline capability (Service Workers), why does it need a server at all? CRDTs (Conflict-free Replicated Data Types) answer the consistency question. Multiple clients can edit the same data independently, offline, with no coordination. When they reconnect, their changes merge automatically without conflicts. No server-mediated locking. No “last write wins” data loss. Mathematical guarantees that concurrent edits converge to the same state. The architecture: Client A (offline) Client B (offline) │ │ ├── Local edits ├── Local edits │ (CRDT ops) │ (CRDT ops) │ │ └──────┐ ┌────────┘ ▼ ▼ ┌──────────────┐ │ Sync service │ (thin, stateless) │ (persistence │ │ + relay) │ └──────────────┘ </code></pre> The sync service is not a backend. It stores operations and relays them between clients. It does not run business logic. It does not validate (the CRDT handles consistency). It does not transform (the merge function is built into the data type). It is a persistence layer with a WebSocket attached. I build systems like this. The concrete model: a document is a flat HashMap<EntityId, Entity></code> where each entity holds CRDT-typed fields. The field types determine how concurrent edits merge: CRDT type</th> Merge behavior</th> Use case</th></tr></thead> LwwRegister<T></td> Last writer wins (by timestamp)</td> Simple values: name, status, URL</td></tr> GrowOnlySet<T></td> Union of both sides</td> Tags, labels, immutable references</td></tr> ObservedRemoveSet<T></td> Add wins over concurrent remove</td> Collaborator lists, mutable collections</td></tr> MaxRegister</td> Higher value wins</td> Version counters, progress indicators</td></tr> MinRegister</td> Lower value wins</td> Earliest timestamps, priority values</td></tr> </tbody></table> Each field carries a hybrid logical clock (HLC) timestamp. The HLC combines physical time with a logical counter, so causality is preserved even when wall clocks drift. Two clients edit the same field at the “same” time? The HLC ordering is deterministic. Both clients converge to the same value without coordination. The merge function has three properties that make this work: it is associative (grouping does not matter), commutative (order does not matter), and idempotent (applying the same operation twice has no additional effect). These are not implementation details. They are the mathematical foundation that makes server-free consistency possible. You can sync operations in any order, from any number of clients, through any number of intermediate relays, and every replica converges to the same state. The client owns its data. The server is optional. When the server exists, it persists operations and relays them. It does not arbitrate, transform, or validate beyond authentication. This is not a niche pattern for collaborative text editors. Any application where users create and modify data can benefit. Notes, task managers, project planning tools, CMS authoring, form builders. The question is not “should this be local-first?” The question is “does this need a server, and if so, for what?” What the backend becomes</h2> If the edge handles infrastructure concerns and business logic that depends on request context, and the client handles computation, rendering, and local state, what is left for the backend? A persistence layer. The backend becomes the place where data rests between sessions and syncs between devices. Not an application server. A persistence layer. Consider the spectrum of what “backend” looks like now: Static sites. This site is an example. raskell.io is built with Zola. Markdown files compile to HTML at build time and deploy to edge CDN nodes. No application server. No database. No runtime process. The “backend” is a git repository and a CI pipeline. Content lives as files. Serving happens at the edge. The total monthly infrastructure cost is the price of a domain name. This is not limited to blogs. Documentation sites, marketing pages, product landing pages, e-commerce storefronts with pre-rendered product pages. Any content that changes at author-time rather than request-time can be static. The headless CMS (Contentful, Sanity, Strapi, or just a git repo) publishes content. The static site generator builds HTML. The CDN serves it. The “backend” runs at build time, not at request time. I take this further than most. All of my projects are CDN-first, even the ones with dedicated backends. The principle: if the backend goes down, the user should still see something useful. The static layer is the safety net. Kurumi</a>, a local-first second brain app, is the purest expression of this. It is a Progressive Web App served entirely from CDN edge nodes with Service Workers handling offline capability. There is no backend server. Notes sync between devices through CRDTs when connectivity exists, but the app works fully offline. The entire “infrastructure” is a static deployment and an optional sync relay. But the CDN-first pattern also applies to applications that have real backends. Cyanea has a Phoenix/Elixir backend that manages datasets, user accounts, and collaboration. But the public-facing surface, the landing pages, category pages, trending spaces and protocols and datasets, is statically generated. The backend exports JSON snapshots of its database objects on a timed interval. A static site generator picks up those snapshots and rebuilds the public pages: what labs are active, which protocols are trending, which datasets were recently published. The result is a set of HTML pages sitting on a CDN that stay current without depending on the backend being up at the moment a visitor arrives. ┌──────────────────┐ JSON export ┌──────────────┐ │ Cyanea Backend │ ──── (interval) ────> │ Static Site │ │ (Phoenix/BEAM) │ │ Generator │ │ │ │ (Zola) │ │ - datasets │ │ │ │ - protocols │ │ → CDN edge │ │ - labs │ │ nodes │ │ - spaces │ │ │ └──────────────────┘ └──────────────┘ │ │ │ dynamic app static pages ▼ ▼ app.cyanea.bio cyanea.bio (logged-in users, (public, always up, real-time features) fast, no backend dependency) </code></pre> This is a genuinely resilient architecture. The backend can be down for maintenance, mid-deploy, or experiencing load, and the public site keeps serving. The static pages are never stale by more than one generation interval. For a site where “trending this week” is sufficient freshness, that interval can be hours. The CDN handles traffic spikes that would overwhelm a backend. The backend handles the dynamic work that requires real-time data. Thin persistence APIs. For applications with dynamic data, the backend shrinks to a database with an API in front of it. Accept writes, serve reads, enforce schema constraints. GraphQL or REST over Postgres. No rendering. No business logic beyond data integrity. The API exists so that clients and edge workers have somewhere to store and retrieve state. The interesting shift: even the persistence API is getting thinner. Services like Supabase, PlanetScale, and Turso expose the database directly over HTTP or WebSockets with built-in auth. Your “backend” becomes a hosted database with row-level security policies. No application code at all. Sync relays. For local-first applications, the backend is even simpler. Accept CRDT operations from clients, persist them to durable storage, fan them out to other connected clients via WebSocket. No merge logic (the CRDT handles that). No transformation. No validation beyond authentication. The relay does not understand the data. It stores and forwards. Event logs. Append-only storage. Clients sync by replaying events from their last known position. The log is the source of truth. Everything else (search indexes, analytics dashboards, recommendation models) is a materialized view built asynchronously. The hot path is the append. The read path is the replay. Both are simple. Batch processors. The one place where traditional backend compute survives: jobs that require access to the full dataset. Analytics aggregation, report generation, search index building, ML model training. These run on schedules or triggers, not in the request path. They read from the event log or the database, compute, and write results back. The user never waits for them. The common thread: the backend does not touch the hot path. User requests hit the edge and the client. The backend runs in the background, on its own schedule, when no one is waiting. The architecture that makes this work</h2> Pushing logic to the edge and the client is not free. Both environments have constraints, and ignoring them is how you build fragile systems. At the edge: bounded resources</h3> Every operation at the edge needs explicit limits. No open-ended computations, no unbounded queues, no surprise behavior. This is not just good practice. It is existential. The edge proxy sits between the internet and your infrastructure. If it behaves unpredictably, everything behind it suffers. Concretely: Resource</th> Bound</th> Why</th></tr></thead> Agent concurrency</td> Per-agent semaphore (default: 100)</td> Prevents noisy neighbor between agents</td></tr> Agent timeout</td> 100ms default</td> Prevents latency cascade</td></tr> Connection pool</td> Explicit max (default: 10K)</td> Prevents file descriptor exhaustion</td></tr> Request body</td> Streaming, not buffered</td> Prevents memory exhaustion</td></tr> Route cache</td> LRU with size limit</td> Prevents unbounded growth</td></tr> Rate limit queues</td> Bounded with max delay</td> Prevents request pile-up</td></tr> </tbody></table> If you cannot articulate the bound for every resource your edge system uses, you do not have an architecture. You have an accident waiting for load. On the client: isolation and sandboxing</h3> The client has different constraints. Battery life, memory pressure, the user closing the tab at any moment. WASM runs in a sandbox. No file system access, no network access, no shared memory (unless explicitly granted). This is the security model that makes client-side compute viable. Untrusted code (your own, running on someone else’s device) cannot escape the sandbox. Web Workers run in separate threads with message-passing. No shared mutable state. No locks. No data races. The isolation is enforced by the runtime, not by programmer discipline. Service Workers have a lifecycle managed by the browser. They can be terminated at any time to save resources. Your offline logic must handle graceful shutdown. This means: durable state in IndexedDB, idempotent sync operations, no in-memory state that cannot be reconstructed. CRDTs provide consistency guarantees without coordination. But they are not magic. They consume memory (tombstones for deleted items, version vectors for causal ordering). They need garbage collection. They need careful schema design because not every data model maps cleanly to CRDT primitives. A counter works. A last-writer-wins register works. A rich text document with formatting, comments, and embedded media requires careful thought. The trust boundary</h3> Here is the part most edge-computing articles skip: trust. If the edge handles auth, the backend trusts the edge to have done auth correctly. If the client handles business logic, the server trusts the client to have computed correctly. These are real trust boundaries with real failure modes. At the edge, trust is earned through: Failure isolation. Agent crashes do not take down the proxy. Bad config is validated before activation.</li> Observability. Every decision is logged, metered, and traceable. If the WAF blocked a request, you can see exactly which rules fired and why.</li> Bounded behavior. No surprise modes. Every resource has explicit limits. Every failure mode is configured, not assumed.</li> </ul> On the client, trust is conditional: Never trust the client for security decisions. Validate at the edge or the backend. Client-side checks are UX, not security.</li> Trust the client for its own data. If the user is editing their own document, the client is authoritative. CRDTs handle consistency. The server persists, it does not arbitrate.</li> Verify at the boundary. When client data syncs to the server, validate schema and authorization. Trust the merge, verify the input.</li> </ul> When not to do this</h2> Not everything belongs at the edge or on the client. Here is what stays in the backend: Multi-service transactions. If an operation needs to read from three databases, check inventory, charge a payment, and send a notification, that is a backend workflow. Distributed transactions need coordination, and coordination needs a central authority. Heavy data joins. If your query joins six tables with complex filters and aggregations, it runs next to the database, not at an edge node 200ms away from the data. Regulatory requirements. Some industries mandate that data processing happens in specific locations, on specific infrastructure, with specific audit trails. Edge deployment may not satisfy these constraints. Small teams with simple needs. If you have one backend, ten users, and no latency problems, this architecture is overhead. A Django app behind nginx is fine. Optimize when you have a reason to optimize, not before. The edge handles cross-cutting concerns and request-context computation. The client handles local state and user-facing compute. The backend handles coordination, persistence, and anything that needs the full dataset. Know which is which. Where this is going</h2> Five years ago, the stack was: browser (thin) renders server-generated HTML, backend (fat) runs everything, database stores state. The mental model was request/response, and the backend was the center of gravity. The stack now: ┌─────────────────────────────────────────────────────┐ │ Client │ │ WASM │ WebGPU │ Web Workers │ Service Workers │ CRDT │ │ (compute, render, offline, local state) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Edge │ │ Proxy │ Workers │ Containers │ KV │ Durable Objects │ │ (auth, WAF, routing, SSR, API aggregation, policy) │ └────────────────────┬────────────────────────────────┘ │ ┌────────────────────┴────────────────────────────────┐ │ Backend │ │ Database │ Sync relay │ Event log │ Batch processing │ │ (persistence, coordination, async compute) │ └─────────────────────────────────────────────────────┘ </code></pre> The client is fat. The edge is fat. The backend is thin. The center of gravity moved to both ends simultaneously. Every year, this accelerates. Models get smaller and run on consumer GPUs. WASM runtimes get faster and gain more system APIs through WASI. Edge platforms add durable storage, queues, and cron triggers. CRDTs mature from academic curiosities to production libraries. SQLite-in-the-browser goes from experiment to default architecture for offline-capable apps. The backend will not disappear. Data needs to live somewhere durable, and cross-device sync needs a relay. Coordination problems need a central authority. Batch processing needs access to the full dataset. But the backend’s role is narrowing to exactly these things. It is becoming infrastructure, not application. Plumbing, not logic. I find myself building systems where the most interesting engineering happens at the boundaries. A reverse proxy (Zentinel</a>) that inspects 912K requests per second through 285 WAF rules, authenticates with sub-millisecond latency, and routes with crash-isolated agents. A bioinformatics platform (Cyanea</a>) where the browser runs the computation and the backend exports JSON for statically generated pages. A distributed compute platform (Archipelag</a>) where users’ browsers are the compute fleet via WASM and WebGPU. A note-taking app (Kurumi</a>) that works fully offline with CRDTs and never touches a server for reads. Between all of them, a database, a sync relay, or just a CDN. Necessary and boring. The backend is not dead. It is just not where the interesting work happens anymore. References and further reading</h2> Edge platforms and proxies</h3> Cloudflare Workers</a> - V8 isolate-based edge compute</li> Deno Deploy</a> - Edge runtime built on the Deno JavaScript runtime</li> Fastly Compute</a> - Wasm-based edge compute platform</li> Vercel Edge Functions</a> - Edge compute integrated with Next.js</li> fly.io</a> - Container-based edge deployment platform</li> Pingora</a> - Cloudflare’s Rust framework for programmable proxies</li> Zentinel</a> - Security-first reverse proxy with crash-isolated agents</li> </ul> Client-side compute</h3> WebAssembly</a> - Portable binary instruction format for the web</li> WASI</a> - WebAssembly System Interface for running Wasm outside the browser</li> WebGPU specification</a> - W3C standard for GPU compute in the browser</li> MediaPipe</a> - ML inference framework running client-side via Wasm and WebGPU</li> SQLite Wasm</a> - Official SQLite build targeting WebAssembly</li> sql.js</a> - SQLite compiled to Wasm via Emscripten</li> Origin Private File System</a> - MDN reference for persistent browser storage</li> Service Worker API</a> - MDN reference for offline-capable web apps</li> Web Workers API</a> - MDN reference for background threads in the browser</li> </ul> CRDTs and local-first</h3> CRDTs: The Hard Parts</a> - Martin Kleppmann’s talk on practical CRDT challenges</li> Local-first software</a> - Ink and Switch research paper on local-first architectures</li> Automerge</a> - CRDT library for collaborative applications</li> Yjs</a> - High-performance CRDT framework for the web</li> A comprehensive study of CRDTs</a> - Shapiro et al., the foundational survey paper</li> </ul> Databases at the edge</h3> Turso</a> - SQLite-compatible database with edge replicas</li> Neon</a> - Serverless PostgreSQL with branching</li> LiteFS</a> - Distributed SQLite replication by Fly.io</li> CockroachDB</a> - Distributed SQL database designed for multi-region</li> Supabase</a> - Open-source Firebase alternative built on PostgreSQL</li> </ul> Projects referenced</h3> Cyanea</a> - Bioinformatics platform using Wasm and WebGPU for client-side compute</li> Archipelag</a> - Distributed compute platform with browser-based Wasm nodes</li> Kurumi</a> - Local-first second brain app with CRDT sync</li> Conflux</a> - Schema-aware CRDT engine for deterministic merge</li> </ul> Looking back on 2025 Unknown — Wed, 31 Dec 2025 00:00:00 +0000 I spent part of this year on the shores of Okinawa. The water there is something else entirely, this impossible azure that shifts to turquoise in the shallows, so clear you can see the coral formations from the surface. I found myself thinking about systems while I was there, the way you do when you’re floating in salt water with nothing pressing to attend to. Between swims, I read Tim Berners-Lee’s “This is for everyone.” I’ve been building web software for over a decade now, and I thought I understood what the web was. But reading TBL’s words while watching that reef ecosystem do its thing, thousands of species in constant exchange, no central coordinator, just emergent complexity from simple rules, something shifted in how I saw it all. The web TBL imagined was supposed to work like that reef. A commons. Many small nodes, each doing their own thing, connected through open protocols. Information flowing freely. The beauty of it wasn’t in any single node but in the connections between them, the way the whole became more than the sum of its parts. The same principle that makes a reef resilient makes a network powerful: diversity, redundancy, local adaptation. What we built instead looks more like industrial aquaculture. Five platforms. Algorithmic monoculture. Content optimized for engagement metrics rather than usefulness. We took a system designed for decentralization and built the most centralized information infrastructure in human history. I keep thinking about how that happened. The web itself never changed. HTTP still works the same way, HTML still does what it always did. What changed was the economics. Publishing became free, but being found became expensive. The platforms positioned themselves as the gatekeepers of attention, and suddenly you couldn’t reach people without paying the toll, whether in ad spend or in algorithmic compliance or in the slow erosion of doing whatever it took to game SEO. The thing about monocultures is they’re efficient right up until they’re not. A reef can lose a species and adapt. A monoculture gets one disease and collapses. We’ve been watching the web’s monoculture show stress fractures for years. The enshittification of platforms, the SEO content farms drowning out signal with noise, the way social media stopped being social and started being a feed of engagement-optimized content from strangers. Then 2025 happened, and AI started breaking things in interesting ways. The obvious take is that AI makes the content problem worse. And superficially, that’s true. If you thought SEO spam was bad before, wait until you see what happens when generating ten thousand pages of plausible-sounding garbage costs essentially nothing. The content farms went into overdrive. Social platforms filled with synthetic engagement. But here’s the thing I keep coming back to: maybe that’s the fever that breaks the infection. The old economics of the web depended on a particular scarcity. Human attention is finite, and the platforms controlled access to it. You wanted eyeballs, you played their game. SEO worked because Google was the gateway and you could optimize for what Google wanted. Platform distribution mattered because that’s where the people were. AI disrupts this in ways that I think are genuinely interesting. When an AI assistant can synthesize information from across the web and deliver it directly to the user, the value of ranking first on Google diminishes. Why click through to a content farm when the answer is already in front of you? When AI agents can find and surface relevant content directly, you don’t need to be on the platform where the eyeballs gather. The middleman’s leverage starts to evaporate. And crucially: when everyone can generate infinite content at zero marginal cost, content quantity becomes worthless. What matters is provenance. Accuracy. Usefulness. The things that are actually hard. The things that require a human perspective, or at least require being right in ways that matter. I find myself unexpectedly optimistic about what comes next. If AI breaks the distribution stranglehold that platforms have, the economics of the web could flip in interesting directions. The old model needed scale because reaching people was expensive. But if AI handles discovery, finding relevant content and bringing it to users, then maybe you don’t need scale anymore. Maybe small becomes viable again. Think about what this means concretely. A static site costs nearly nothing to run. No databases to scale, no servers to babysit, just files sitting on edge nodes around the world. If you don’t need to capture user data for ad-driven personalization, you don’t need the complexity of the surveillance stack. If you don’t need platform distribution, you don’t need to play platform games. There’s another piece to this that I think most people are missing: edge computing changes what personalization can mean. The conventional wisdom is that personalization requires surveillance, that you need to know everything about a user to show them relevant content. But that’s only true if personalization happens in a centralized database somewhere. If personalization happens at the edge, at the moment of request, you can adapt content to context without ever needing to know who the user is. The edge function doesn’t need a profile. It just needs to know what was asked for and what context it’s being asked in. This is the architecture I keep thinking about: static content at the origin, edge functions that adapt it anonymously, AI agents that find and surface it based on actual relevance rather than SEO gaming. No surveillance required. No platform dependency. No scaling costs that force you into growth-at-all-costs mode. It looks more like a reef than a fish farm. I don’t want to oversell this. The transition, if it happens, won’t be clean. The platforms aren’t going to quietly cede control. The incentives that built the current web are still operating. And AI itself could go in directions that make things worse rather than better. There are plenty of dystopian paths from here. But when I think about what I want to build toward, it’s that reef model. Many small, specialized nodes. Interconnected through open protocols. Resilient because distributed. Sustainable because the economics work at small scale. This site is part of that bet. Static content, no tracking, no platform dependencies. The tools I’m working on (Zentinel, Sango, Ushio) are all about making edge infrastructure more accessible, making it easier to build and operate systems that are distributed and independent. 2025 was the year AI started breaking the old model. I don’t know exactly what grows in its place. But floating in that Okinawan water, watching the reef do what reefs do, I got a sense of what healthy systems look like. Diverse. Interconnected. Resilient. Not optimized for any single metric, but somehow working anyway. That’s what I’m betting on. References and further reading</h2> Tim Berners-Lee</a> - Creator of the World Wide Web and author of “This is for everyone”</li> Enshittification</a> - Cory Doctorow’s term for the pattern of platform decay</li> IndieWeb</a> - Community building the independent web with open standards</li> Zola</a> - Static site generator used to build this site</li> Zentinel</a> - Security-first reverse proxy for the open web</li> Sango</a> - Edge diagnostics CLI for TLS, HTTP, and security header analysis</li> Ushio</a> - Deterministic edge traffic replay tool</li> </ul> Mise ate my Makefile Unknown — Sun, 14 Dec 2025 00:00:00 +0000 I maintain around forty repositories across four GitHub organizations. Zentinel</a> alone accounts for over thirty: the core proxy, a Rust SDK, and a growing collection of agents for WAF inspection, auth, rate limiting, GraphQL security, and a dozen other edge concerns. Archipelag</a> spans an Elixir coordinator, a Rust node agent, Python and TypeScript SDKs, mobile agents in Kotlin and Swift, and infrastructure-as-code repos. Cyanea</a> is Elixir with Rust NIFs and a separate Rust bioinformatics library. Then there are the standalone tools: Conflux</a> (Rust CRDT engine), Sango</a> (Rust edge diagnostics CLI), Shiioo</a> (Rust agentic orchestrator), Vela</a> (Rust bare-metal deployment), Refrakt</a> (Gleam web framework), Kurumi</a> (Svelte local-first app), and this site you are reading (Zola). The languages span Rust, Elixir, Gleam, Python, TypeScript, Kotlin, Swift, and whatever shell scripts accumulated over the years. Every project needs a toolchain. Most need task automation. All of them need to be approachable for a contributor who clones the repo for the first time. The Makefile approach was breaking down. So was everything else I tried. What was failing</h2> The standard setup for most of my Rust projects was a Makefile with targets for build</code>, test</code>, clippy</code>, fmt</code>, and release</code>. Simple enough for one repo. The problem surfaces when you maintain thirty of them. GNU Make and BSD Make disagree on syntax in ways that cause silent failures. A Makefile that works on my Linux CI runner breaks on a contributor’s macOS laptop because of a conditional or a shell invocation difference. The fix is always “use GNU make,” but that means documenting it, adding a check, and fielding issues from people who forget. Worse, Makefiles cannot declare tool dependencies. A Rust project needs a specific Rust version, maybe protoc</code> for gRPC, maybe cargo-watch</code> for development convenience. The Makefile assumes these tools exist. When they do not, the developer gets a cryptic error five minutes into their first build. So projects accumulated scaffolding: .rust-version .tool-versions Makefile scripts/setup.sh scripts/ci.sh scripts/release.sh .envrc </code></pre> Six files to express what amounts to: “this project uses Rust 1.83, needs protoc, and has five things you can run.” Multiply that by forty repos and you have a maintenance surface that nobody wants to touch. The scripts/</code> folder in particular had a way of growing silently. Someone adds a helper. Someone else copies it from another project with modifications. Six months later you have three slightly different versions of the same release script across three orgs. The Elixir projects had it worse. Elixir needs Erlang/OTP at a specific version, then Elixir itself at a matching version, then Node for asset compilation in Phoenix, then possibly Rust for NIFs (Cyanea compiles Rust bioinformatics code into the BEAM release). Four tool dependencies before you write a line of application code. asdf</code> handled the version management, but slowly and without task automation, so you still needed a Makefile on top. Why not Nix</h2> I gave Nix a serious try. The promise is appealing: declare your entire development environment in a single file, get reproducible builds, never worry about system state. The Nix shell concept is genuinely elegant. In practice, the cost was too high for my use case. Nix’s learning curve is steep even for experienced engineers. The language is its own thing. The documentation assumes you already understand the Nix store model. When something breaks, the error messages point at derivation hashes, not at the thing you actually did wrong. The bigger issue was onboarding. If a contributor wants to fix a typo in a Zentinel agent’s README, asking them to install Nix and understand flakes is a non-starter. The tool that manages your development environment should not itself become a project you have to learn. Nix solves a harder problem than I have. I do not need bit-for-bit reproducible builds across machines. I need “install Rust 1.83 and run the tests.” Why not asdf</h2> asdf was my default for years. It handled the version management problem well enough. The plugin system meant I could manage Rust, Elixir, Erlang, Node, and Python versions with a single .tool-versions</code> file. Three things pushed me away. First, speed. asdf is shell scripts. Every invocation pays the cost of sourcing plugins, resolving versions, and shimming binaries. On a fast machine you barely notice. On CI, where you run asdf install</code> in a fresh environment, the overhead adds up. Mise is a compiled Rust binary. It is meaningfully faster at both installation and version resolution. Second, no task automation. asdf manages tool versions. That is all it does. You still need Make or a scripts folder for project tasks. That means two tools, two configuration surfaces, two things to document. Third, plugin quality varied. The core plugins for Node and Ruby were solid. Plugins for less mainstream tools could be stale, broken, or missing. Mise started as an asdf-compatible rewrite and inherited the plugin ecosystem, but its built-in backends for common tools (Rust, Node, Python, Go, Erlang, Elixir) are faster and more reliable than shelling out to plugins. What mise actually does</h2> Mise</a> is a single Rust binary that combines tool version management and task running into one configuration file per project. It does asdf’s job and Make’s job in a single tool. Here is this site’s configuration. The entire thing: # mise.toml (raskell.io) [tools] zola = "0.19" [env] _.file = ".env" [tasks.serve] description = "Start the Zola development server" run = "zola serve" [tasks.build] description = "Build the site for production" run = "zola build" [tasks.check] description = "Check the site for errors without building" run = "zola check" [tasks.new] description = "Create a new article" run = """ #!/usr/bin/env bash if [ -z "$1" ]; then echo "Usage: mise run new <article-slug>" exit 1 fi SLUG="$1" DATE=$(date +%Y-%m-%d) FILE="content/articles/${SLUG}.md" cat > "$FILE" << ARTICLE +++ title = "" date = ${DATE} description = "" [taxonomies] tags = [] categories = [] [extra] author = "Raffael" +++ ARTICLE echo "Created $FILE" """ </code></pre> One file. Declares the tool (Zola 0.19), loads environment variables, and defines every task a contributor needs. mise install</code> sets up the toolchain. mise tasks</code> shows what is available. mise run serve</code> starts the dev server. No Makefile. No scripts folder. No documentation page explaining how to get Zola at the right version. For a Rust project like Shiioo</a> (the agentic orchestrator), the configuration is larger but follows the same pattern: # .mise.toml (shiioo) [tools] rust = "latest" [env] RUST_LOG = "info" RUST_BACKTRACE = "1" _.path = ["./target/release", "./target/debug"] [tasks.build] description = "Build all crates in release mode" run = "cargo build --release" [tasks.test] description = "Run all tests" run = "cargo test" [tasks.clippy] description = "Run clippy lints" run = "cargo clippy --all-targets -- -D warnings" [tasks.fmt] description = "Format code with rustfmt" run = "cargo fmt --all" [tasks.ci] description = "CI pipeline: format check, clippy, test" depends = ["fmt-check", "clippy", "test"] [tasks.dev] description = "Full development build and run" depends = ["fmt", "check", "test"] run = "cargo run -p shiioo-server" </code></pre> The depends</code> key is where mise replaces the one thing Make was genuinely good at: task dependency ordering. mise run ci</code> runs format checking, then clippy, then tests, in sequence. If clippy fails, tests do not run. It is not as expressive as Make’s file-based dependency graph, but for project automation tasks (as opposed to build tasks, which cargo or mix handle), it covers what I actually need. For a multi-language project like Cyanea, the value is even clearer. The Elixir app needs Erlang, Elixir, Node, and Rust. One [tools]</code> section pins all four. One mise install</code> gets a contributor from zero to a working environment. Without mise, that setup involved installing asdf, adding four plugins, running asdf install</code>, then installing direnv for environment variables, then reading the Makefile to figure out how to run things. With mise, it is two commands: mise install</code> and mise run dev</code>. The cross-project pattern</h2> The real payoff is not in any single project. It is the consistency across all of them. Every repo in every org follows the same contract: Clone the repo</li> Run mise install</code></li> Run mise tasks</code> to see what is available</li> Run mise run dev</code> or mise run test</code></li> </ol> That is it. Whether the project is a Rust reverse proxy with thirty modules, an Elixir Phoenix application with LiveView and a NATS integration, a Gleam web framework, or a static site built with Zola, the entry point is identical. The person cloning the repo does not need to know which build system the project uses internally. They do not need to read a CONTRIBUTING.md to find out whether it is make test</code> or cargo test</code> or mix test</code>. It is always mise run test</code>. This matters more than it sounds. When you maintain projects across four orgs and multiple languages, the cognitive overhead per context switch is the actual bottleneck. I work on Zentinel (Rust) in the morning, switch to Archipelag (Elixir) after lunch, then fix something on this site (Zola) in the evening. Without a consistent interface, each switch means recalling which project uses which conventions. With mise, the interface is always the same. The implementation behind mise run test</code> differs (cargo, mix, zola check), but I do not care about that. I type the same command and the right thing happens. For new contributors, the effect is more pronounced. Zentinel’s agent ecosystem has over twenty Rust repos. A contributor who submits a PR to the WAF agent and then wants to help with the auth agent does not need to learn a new setup process. Same structure, same task names, same workflow. The consistency compounds. What mise handles that Make does not</h2> Environment variables. Mise loads environment from the config file or from .env</code> files, scoped to the project directory. When I cd</code> into a project, the right environment is active. When I leave, it deactivates. No direnv, no .envrc</code>, no source .env</code> in every shell session. Tool installation. mise install</code> in a fresh clone gets every tool the project needs at the exact specified version. Make cannot do this. Make assumes the tools exist. That assumption breaks on new machines, in CI, and for every new contributor. Task discovery. mise tasks</code> lists every available task with its description. Make has make help</code> patterns, but those are conventions, not built-in features. With mise, discoverability is the default. File-based tasks. Any executable file in .mise/tasks/</code> becomes a task automatically. No registration, no config entry needed. For tasks that outgrow a one-liner in TOML but do not warrant a standalone script in scripts/</code>, this is the right middle ground. The task is discoverable through mise tasks</code> but lives as a normal shell script you can test independently. What breaks</h2> Mise is not perfect. Honest assessment after running it across forty repos: Dynamic dependencies. Make can express “rebuild this if that file changed.” Mise tasks are imperative: they run or they do not. If you need file-level dependency tracking, you still need a build system (cargo, mix, webpack). Mise orchestrates tasks. It does not replace the build tool. Ecosystem maturity. Mise is younger than Make and asdf. The documentation is good but not exhaustive. Some features (like hooks and watch mode) are recent additions. The pace of development is fast, which means features arrive quickly but occasionally change between minor versions. Team familiarity. Make is universal. Every engineer has encountered a Makefile. Mise is still relatively unknown. Introducing it to a team requires a short pitch, but the pitch is easy: “it is Make plus asdf in one tool, configured in TOML.” Complex shell tasks. When a task grows beyond a few lines, the inline TOML string syntax gets awkward. The workaround is file-based tasks in .mise/tasks/</code>, which works well but means the task definition lives in two places (TOML for metadata and task list, shell file for implementation). The migration</h2> If you are moving an existing project, here is the approach I settled on after migrating across all four orgs: Add a mise.toml</code> (or .mise.toml</code>) at the project root. Start with just [tools]</code> to declare the required versions.</li> Move the most-used Make targets to [tasks]</code> one at a time. Keep the Makefile around until everything is ported.</li> Add [env]</code> entries to replace .envrc</code> or .env.example</code> files.</li> Move standalone scripts from scripts/</code> to .mise/tasks/</code> as file-based tasks.</li> Delete the Makefile last.</li> </ol> Do not try to migrate everything at once. Start with the three tasks developers use daily (usually dev</code>, test</code>, and build</code>). The rest can move incrementally. I also settled on a few naming conventions that help across projects: use clear verb-noun prefixes like db-reset</code>, cache-clear</code>, test-unit</code>. Consistent naming makes task discovery predictable even before you run mise tasks</code>. The bottom line</h2> Mise is not a revolutionary tool. It does not do anything that was previously impossible. You could always install the right Rust version, write a Makefile, set up direnv, and maintain a scripts folder. What mise does is collapse all of that into a single file that is readable, portable, and consistent. The compound effect is what matters. Forty repositories, four organizations, six languages, one pattern. Clone, install, run. No guessing which build system this particular project uses. No debugging a Makefile that works on Linux but breaks on macOS. No explaining to a contributor that they need asdf plus three plugins plus direnv plus GNU make before they can run the tests. Every new project starts with a mise.toml</code>. Setup takes two commands instead of a page of instructions. Contributors do not message me asking how to run things. They run mise tasks</code> and figure it out. That is the tool working. References and further reading</h2> mise</a> - Official documentation and installation guide</li> mise source code</a> - GitHub repository and issue tracker</li> asdf</a> - The version manager mise was originally inspired by</li> Nix</a> - Reproducible builds and development environments</li> GNU Make</a> - The build tool mise replaces for task automation</li> TOML specification</a> - The configuration format mise uses</li> direnv</a> - Environment variable manager that mise’s [env]</code> section replaces</li> Shiioo</a> - Real-world mise configuration referenced in this article</li> mise-hx</a> - Example of a custom mise plugin (for the hx Haskell toolchain)</li> </ul> Disk space maintenance on Void Linux Unknown — Wed, 01 May 2024 00:00:00 +0000 Monday morning surprise</h2> As I spent most time doing stuff with my computer rather than configuring my beloved Linux distribution, Void Linux, I have developed the tendency to not really bother about Void at all until something crucial becomes unusable. After almost two years of having switched from Arch to Void, I have actually never encountered any major problem and felt I had made the right decision. I checked my disk usage out of curiosity if the 250GB solid-state disk would be enough. And there came the surprise: $ df -H Filesystem Size Used Avail Use% Mounted on devtmpfs 8.4G 0 8.4G 0% /dev tmpfs 8.4G 1.9M 8.4G 1% /dev/shm tmpfs 8.4G 1.4M 8.4G 1% /run /dev/nvme0n1p3 138G 117G 21G 85% / efivarfs 158k 85k 69k 56% /sys/firmware/efi/efivars cgroup 8.4G 0 8.4G 0% /sys/fs/cgroup /dev/nvme0n1p4 366G 34G 332G 10% /home /dev/nvme0n1p1 536M 152k 536M 1% /boot/efi tmpfs 8.4G 25k 8.4G 1% /tmp </code></pre> My root partition was full, way too full in my opinion. Did I miss something? Is Void not what I was looking for after all? I don’t enjoy baby sitting my OS du jour. The painless solution</h2> After a quick Brave search, I ended up finding what I was looking for. Some kind fellow software engineer from China didn’t shy away to make a blog post about his journey when he faced the very same problem. Out of annoyance of having to deal with that, I copy-pasted as quickly as possible, not minding what kind of side-effects I might run into, these three commands. 1. Cleaning the package cache</h3> All the knowledge I was lacking was to be found with the man page of xbps-remove</code>. # xbps-remove -yO </code></pre> The man page</a> of xbps-remove</code> tells us the -O</code> parameter takes care of cleaning the cache directory removing obsolete binary packages. Obsolete binary packages? Good riddance! I was surprised this to learn that solely this step freed up almost half of my used root partition disk space. 2. Removing orphaned packages</h3> # xbps-remove -yo </code></pre> Here the same man page</a> tells us that the -o</code> parameter takes care of removing installed package orphans that were installed automatically (as dependencies) and are not currently dependencies of any installed package. As before, good riddance! 3. Purging old, unused kernels</h3> This one is interesting. While I knew about the circumstance that the people behind Void had developed their own package management ecosystem, I hadn’t fully realized there were other utilities that came along with the upstream Void installation which were there for me to manage my beloved OS. So, apparently, one of these is a shell script</a> name vkpurge</code>, I must assume as a short name for Void's Kernel purging</code> tool. I like this type of naming heavily implying its functionality. # vkpurge rm all </code></pre> It performed as expected. Old kernel files (and modules?) were indeed purged and freed up even more disk space. I should add that this step is optional as it is always useful to have some old kernels at hand when things hit the fan (which for me, they haven’t in a very, very long time). Result</h2> I couldn’t be happier. $ df -H Filesystem Size Used Avail Use% Mounted on ... /dev/nvme0n1p3 138G 45G 93G 33% / ... </code></pre> Renewal of faith</h2> Overall, why am I even writing this if some other fellow engineer already figured this out? Simply, because I would therefore be able to explain why I have enjoyed my journey with Void as my go-to Linux distribution. It keeps things simple. Some well-documented utilities. As simple that a simple Brave search suffices to find the answer to my problems. This very aspect of Void is worthwhile highlighing. I remember more arcane Linux distributions that had me in their grip in figuring things out. Many Googles searches were necessary and even more trial and errors attempts to get simple things fixed. Now back to my Monday morning. References and further reading</h2> Void Linux</a> - Official project site</li> Void Linux Handbook: XBPS</a> - Official documentation for the XBPS package manager</li> xbps-remove(1) man page</a> - Manual page for package removal and cache cleaning</li> vkpurge source</a> - Shell script for purging old kernels on Void Linux</li> Void Linux FAQ</a> - Common questions about running and maintaining Void</li> </ul> ^{1 Painting in header image is “Seaside” by Aleksandr Deyneka </div>} All beginning is Haskell Unknown — Mon, 06 Mar 2023 00:00:00 +0000 This site is called raskell.io. That is not an accident. I started learning Haskell because I liked mathematics and someone told me there was a programming language built on top of it. Not “inspired by” in the loose way that every language claims some mathematical foundation. Actually built on lambda calculus, category theory, and type theory, in a way where the math is not decoration but structure. What I did not expect was how thoroughly it would rewire the way I think about building software. Not because Haskell is the best language for every task. It is not, and I write far more Rust than Haskell these days. But because Haskell teaches you to think about programs in a way that makes you better at everything else. What Haskell actually teaches you</h2> Most introductions to Haskell talk about pure functions, immutability, and monads. They are not wrong, but they miss the point. The point is not any single feature. It is how those features combine into a way of thinking about programs as compositions of well-typed transformations. In an imperative language, you think about sequences of steps. Do this, then that, then check a condition, then loop. The program is a recipe. In Haskell, you think about transformations. What goes in, what comes out, what shape does the data have at each stage. The program is a pipeline. This sounds abstract until you see it in practice. Suppose you need to process a list of user records: filter out inactive users, extract their email addresses, and normalize them to lowercase. In an imperative style, you write a loop with conditions and mutations. In Haskell: activeEmails :: [User] -> [Email] activeEmails = map (normalize . email) . filter isActive </code></pre> One line. Read it right to left: filter active users, then map over the result, extracting and normalizing emails. The type signature tells you what goes in ([User]</code>) and what comes out ([Email]</code>). No mutation. No intermediate variables. No place for off-by-one errors or null pointer exceptions. The type signature is not just documentation. It is a contract enforced by the compiler. If isActive</code> expects a User</code> and you pass it a String</code>, the program will not compile. If normalize</code> returns an Email</code> but you try to use it as a String</code>, the program will not compile. The compiler is your first reviewer, and it is tireless. Types as design tools</h2> The deeper lesson is that types are not just error catchers. They are design tools. When I design a system in Haskell, I start with the types. What are the entities? What are the relationships? What transformations are valid? The type system forces you to be precise about these questions before you write any logic. This precision surfaces design problems early, when they are cheap to fix. Consider modeling a document that can be in one of several states: data Document = Draft { content :: Text, author :: UserId } | UnderReview { content :: Text, author :: UserId, reviewer :: UserId } | Published { content :: Text, author :: UserId, publishedAt :: UTCTime } </code></pre> This is an algebraic data type. Each variant carries exactly the data that makes sense for that state. A Draft</code> has no reviewer. A Published</code> document has a timestamp. You cannot accidentally access a reviewer on a draft because the type system will not let you. The invalid state is unrepresentable. This pattern, making illegal states unrepresentable, is perhaps the most valuable idea I took from Haskell. I use it in Rust constantly. Rust’s enum</code> with associated data is directly descended from Haskell’s algebraic data types, and the same design principle applies: encode your invariants in the type system and let the compiler enforce them. The monad is not the point</h2> Every Haskell introduction eventually gets to monads, usually with a metaphor involving burritos or boxes. I will skip the metaphor. A monad is a pattern for sequencing computations that carry some context. The IO</code> monad carries the context of interacting with the outside world. The Maybe</code> monad carries the context of possible failure. The State</code> monad carries the context of mutable state. The pattern is the same in each case: take a value in a context, apply a function that produces a new value in a context, get back a combined context. lookupUser :: UserId -> IO (Maybe User) lookupUser uid = do conn <- getConnection result <- query conn "SELECT * FROM users WHERE id = ?" [uid] return (listToMaybe result) </code></pre> The IO</code> monad here sequences database operations. The Maybe</code> handles the case where no user is found. The types tell you both things at a glance: this function does I/O and might not return a result. The point of monads is not that they are clever. The point is that they make effects explicit and composable. In most languages, a function can do I/O, throw exceptions, mutate global state, or launch missiles, and you cannot tell from its signature. In Haskell, the type signature tells you exactly what effects a function can have. Int -> Int</code> is pure. Int -> IO Int</code> does I/O. Int -> Maybe Int</code> can fail. The information is right there, enforced by the compiler. This discipline, making effects explicit, changed how I design APIs even in languages that do not enforce it. When I write a Rust function that returns Result<T, E></code>, I am using the same pattern: making failure explicit in the type rather than hiding it behind an exception. Rust learned this from Haskell, and so did I. Why I am still building Haskell tooling</h2> If Haskell taught me so much, why do I mostly write Rust? The honest answer: Haskell’s ecosystem has gaps. The language itself is excellent. GHC is one of the most sophisticated compilers ever built. The type system is unmatched in its expressiveness among production languages. But the surrounding infrastructure, the package management, the build tooling, the deployment story, has not kept pace. Dependency management in Haskell is fragmented. Cabal and Stack coexist with overlapping but incompatible approaches. Build times are long. Cross-compilation is painful. Setting up a Haskell development environment from scratch still involves more friction than it should in 2026. This is why hx exists. hx is a Haskell toolchain CLI that I am building in Rust. The choice of implementation language is deliberate. Haskell’s tooling problems are partly caused by tooling that is itself written in Haskell, creating bootstrap problems and long compile times for the tools themselves. A Rust binary starts instantly, compiles to a single static executable, and cross-compiles trivially. The tool should not have the same dependencies as the thing it manages. hx is distributed through mise</a> (naturally), as well as through AUR, Homebrew, Scoop, and Chocolatey. The goal is that setting up a Haskell project should be as frictionless as setting up a Rust project: one command to install the toolchain, one command to build. On the other end of the spectrum, bhc (the Basel Haskell Compiler) is an experiment in taking Haskell in a direction GHC was never designed for: compiling Haskell for low-latency runtimes without a garbage collector. The target is workloads like tensor pipelines and real-time systems where GC pauses are not acceptable. bhc is early and ambitious, but it comes from the same conviction: Haskell’s ideas deserve better infrastructure than they currently have. The Haskell in my Rust</h2> I write Rust the way Haskell taught me to think. Rust’s ownership model is not the same as Haskell’s purity, but it serves a similar purpose: it forces you to think about data flow explicitly. In Haskell, you cannot mutate a value because the language will not let you. In Rust, you can mutate, but the borrow checker forces you to be explicit about who owns the data and who can see it. Both languages make you think before you write. Conflux</a>, my CRDT engine, uses algebraic data types for its merge semantics. Each CRDT field type (LwwRegister, GrowOnlySet, ObservedRemoveSet) is an enum variant with associated data, exactly the pattern I described above. The merge function is associative, commutative, and idempotent. These are mathematical properties that I learned to care about from Haskell, where such properties are often expressed as type class laws. Zentinel</a>, the reverse proxy, uses Rust’s type system to enforce that WAF decisions are handled in the correct pipeline stage. An AgentDecision</code> is either Allow</code>, Block</code>, or Modify</code>, and the proxy’s merge logic ensures that a Block</code> from any agent cannot be overridden. The pattern is a monoid (decisions combine associatively with Block</code> as the absorbing element), though nobody would call it that in the Rust codebase. The concept came from Haskell. The implementation is pure Rust. Even Shiioo</a>, the agentic orchestrator, uses Haskell-influenced patterns. DAG workflows are compositions of typed transformations. Events are algebraic data types with exhaustive pattern matching. The event-sourcing model treats state as a fold over an event stream. foldl</code> in Haskell, Iterator::fold</code> in Rust. Same idea, different syntax. Why “raskell”</h2> The name is a portmanteau. Raffael plus Haskell. I chose it because Haskell is where my engineering thinking started to take its current shape. Not the first language I learned, but the first one that changed how I think about all the others. I do not believe you need to write Haskell to benefit from Haskell. But I believe that learning it, really learning it, not just reading about monads but building something real with algebraic data types and type classes and higher-order functions, will make you a better engineer in whatever language you actually use. All beginning is Haskell. The rest is implementation. References and further reading</h2> Learning Haskell</h3> Haskell Language</a> - Official site with documentation and community links</li> Learn You a Haskell for Great Good!</a> - Approachable illustrated introduction</li> Real World Haskell</a> - Practical Haskell for production use</li> Haskell Wiki</a> - Community-maintained reference and tutorials</li> Typeclassopedia</a> - Comprehensive guide to Haskell’s type class hierarchy</li> </ul> Type systems and theory</h3> Haskell Curry</a> - The logician the language is named after</li> Lambda calculus</a> - Alonzo Church’s formal system underlying Haskell</li> Hindley-Milner type system</a> - The type inference algorithm at the core of Haskell and ML</li> Making illegal states unrepresentable</a> - Yaron Minsky’s influential talk on using types for correctness</li> Algebraic data types</a> - Haskell wiki reference on sum and product types</li> </ul> Monads and effects</h3> Philip Wadler, “Monads for functional programming”</a> - The foundational paper on monads in programming</li> All About Monads</a> - Haskell wiki guide to monadic programming</li> </ul> Haskell tooling</h3> GHC</a> - The Glasgow Haskell Compiler</li> Cabal</a> - Haskell’s build and package system</li> Stack</a> - Alternative build tool with curated package sets</li> mise-hx</a> - mise plugin for the hx Haskell toolchain CLI</li> </ul> Projects referenced</h3> Conflux</a> - CRDT engine using algebraic data types for merge semantics</li> Zentinel</a> - Reverse proxy with monoid-based decision merging</li> Shiioo</a> - Agentic orchestrator using event-sourced state folds</li> </ul> My OpenBSD journey: Getting it virtualized with libvirt (1) Unknown — Mon, 06 Feb 2023 00:00:00 +0000 Void Linux as my daily driver</h2> Around six months ago, I decided to ditch my long in the tooth Arch-based setup on my belovest Thinkpad X1 Carbon. I’ve been very loyal over the years, and almost came to belive that Arch will be a constant in my adult life. While I kept up with upcoming technologies, I somehow lost track of the ever so diversifying landscape of Linux distributions. It took me a while of constantly coming across a generically named reference to what seemed to be yet another Linux distribution. That outwardly generic sounding name, Void Linux</a>, kept poking my curiosity by supposedly feeling like Arch Linux in the old days, while sharing some substantial DNA with the BSD operating systems. Yet, that’s another story I might tell another day, but to remain brief, the BSDs, in particular the infamous OpenBSD with its quite infamous lead developer Theo De Raadt, always were what I considered the endgame. The holy grail of Unix operating systems, so did I think over the decades, FreeBSD, NetBSD and OpenBSD, have always been on my personal radar and I felt I had to earn the intellectual capacity to be able to properly put them at use one day. Last year, when I made the (almost painless) switch from Arch Linux to Void Linux, the simplicity and especially the barebone experience of Void reignited the fascination and the admiration I always had for the BSD operating systems and their philosophy. While I could write (and definitely will in the near future) about how my journey onto Void Linux and how it has been so far, I preferred to write down, in some like diary, and document every step on how one can approach and ultimately use OpenBSD</a> in 2023. Big disclaimer, I’ve yet to install OpenBSD on some baremetal server I ordered some days ago, but dabbled around in the meantime with OS-level virtualization in order to get it running. That’s what brings me to libvirt and my surprise to learn that I wouldn’t need some full-fledged virtualization solution like the ones offered by VirtualBox or VMWare to efficiently run a virtualized OpenBSD machine. So, ok, let’s recap, so far we got the following bill of materials: Void Linux as the host system</li> OpenBSD to be virtualized on that host system</li> libvirt as the glue that makes virtualization feel like black magic</li> </ul> From Void to OpenBSD</h3> Before I tell you more about the history of how things went down while setting up OpenBSD, let me give you some basic notions about both Void Linux, being one out of many Linux distributions for the sake of simplicity representing them all as it ended up being my distribution of choice, and OpenBSD. As already mentioned earlier, Void Linux and OpenBSD are both Unix-like operating systems, but they feature enough differences to make them noteworthy. Here are a few similarities and differences between the two: What is similar: Both are free and open-source operating systems.</li> Both use a package manager for software management. Void Linux uses XBPS, while OpenBSD uses pkg_add.</li> Both prioritize security and stability in their development and design.</li> Both feature a version control based package repository, meaning that changes in build definition are managed by pull requests from users.</li> </ul> What is different: License: Void Linux is licensed under the MIT License, while OpenBSD is licensed under the ISC License.</li> Philosophy: OpenBSD prioritizes security and privacy, while Void Linux prioritizes simplicity and modularity.</li> Package Management: Void Linux uses the XBPS binary package manager, while OpenBSD uses pkg_add (also binary). OpenBSD additionally has a ports system for building from source.</li> Package Repository: Void Linux has a large and diverse repository, while OpenBSD has a smaller and more curated repository.</li> Init System: Void Linux uses runit as its init system, while OpenBSD uses rc. None uses the infamous systemd init system.</li> </ul> What is OpenBSD in a nutshell</h2> OpenBSD is a free and open-source operating system that focuses on security, standardization, and robustness. It is based on the Berkeley Software Distribution (BSD) Unix operating system and is developed by a global community of volunteers. OpenBSD aims to provide a secure platform for both personal and enterprise use by implementing strong security features, including access control mechanisms, encryption, and auditing. Theo de Raadt</a> is the founder and lead developer of OpenBSD. His main objective with OpenBSD is to create a secure operating system that is free from backdoors, vulnerabilities, and other security weaknesses. He is committed to auditing the source code of the operating system and third-party software included with it, to identify and remove any potential security risks. De Raadt is also dedicated to improving the overall quality of the codebase and ensuring compatibility with a wide range of hardware and software. What makes OpenBSD really special and stand out is that is developed a suite of tools that got adopted by other OSs like Linux, macOS or even Windows. One of the most famous instances of such adoption is the now de facto standard openssh suite. It actually emerged from within the development circle of the OpenBSD project. OpenBSD also implemented a wide range of OS features that are by now considered staples among other OSs, things like Linux-based OS-level containerization done via the means of cgroups, something that OpenBSD already pioneered and solved with a different spin many years before Linux with pledge and unveil. Go check out Why OpenBSD rocks</a> to get a feel what makes OpenBSD so unique and interesting. Virtualization with libvirt</h3> So now, let’s get back to our virtualization endeavour where we would like to virtualize OpenBSD on a Void Linux installation. If you happen to be using another Linux distribution, most of the individual steps would be very similar. That brings me to the next technology we should explain a bit more here, and that is libvirt. libvirt</a> is an open-source virtualization management library that provides a simple and unified API for managing virtualization technologies, including KVM, QEMU, Xen, and others. It aims to simplify the process of creating, managing, and migrating virtual machines, storage, and networks, and to make it easier for administrators to manage virtual environments. To virtualize an operating system like OpenBSD with libvirt, you need to follow these steps: Install libvirt and the virtualization technology you want to use, such as KVM.</li> Download the OpenBSD iso file and place it in a location accessible by libvirt.</li> Create a new virtual machine in libvirt with the OpenBSD ISO as the installation media. This can be done through the command line or using a graphical user interface such as virt-manager.</li> Configure the virtual machine, including the amount of memory, CPU, and disk space, to meet the requirements of OpenBSD.</li> Start the virtual machine and install OpenBSD as you would on a physical machine.</li> Once the installation is complete, you can configure the virtual network, storage, and other settings as required.</li> Finally, you can use the libvirt API or the command line to manage and control the virtual machine, including starting, stopping, migrating, and snapshotting.</li> </ol> Step-by-step guide</h3> Let’s first install the libvirt</code> package and some related packages which we need in order to connect via VNC. The VNC will provide us with the possibility to use the graphical interface of the running OpenBSD instance. $ sudo xbps-install -S dbus qemu libvirt virt-manager virt-viewer tigervnc </code></pre> Now, we need to add our user, in my case raskell</code>, to the libvirt</code> group which got simultanously created with the installation of libvirt. $ sudo usermod -aG libvirt raskell </code></pre> OpenBSD features a release cycle of six months. We would need to update our system every six month to keep up with the latest packages. During a given release, only security and bug fix patches are applied to the curated packages maintained by pkg_add. Therefore, in February 2023, we’re using the OpenBSD 7.2</a> release version. As I’m living in Switzerland, I chose to pull the iso image from a Swiss mirror, in this case from mirror.ungleich.ch/pub/OpenBSD</code></a> (check what mirror is closest to you to get the best download rate). # cd /var/lib/libvirt/boot/ # sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso --2023-01-12 20:48:15-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/install72.iso Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 583352320 (556M) [application/octet-stream] Saving to: ‘install72.iso.1’ install72.iso.1 100%[====================================================================>] 556.33M 7.11MB/s in 77s 2023-01-12 20:49:33 (7.19 MB/s) - ‘install72.iso.1’ saved [583352320/583352320] sudo wget https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 --2023-01-12 20:47:38-- https://mirror.ungleich.ch/pub/OpenBSD/7.2/amd64/SHA256 Resolving mirror.ungleich.ch (mirror.ungleich.ch)... 2a0a:e5c0:2:2:400:c8ff:fe68:bef3, 185.203.114.135 Connecting to mirror.ungleich.ch (mirror.ungleich.ch)|2a0a:e5c0:2:2:400:c8ff:fe68:bef3|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1992 (1.9K) [application/octet-stream] Saving to: ‘SHA256.1’ SHA256.1 100%[====================================================================>] 1.95K --.-KB/s in 0s 2023-01-12 20:47:39 (742 MB/s) - ‘SHA256.1’ saved [1992/1992] # grep install63.iso SHA256 > /tmp/x # sha256sum -c /tmp/x # rm /tmp/x </code></pre> Before we can start the virtualization server and get running our OpenBSD instance, we need to define the configuraiton on how to virtualize and ultimately boot the system with. This is done with virt-install</code>. Noteworthy here is that we QEMU</a> as our emulation solution of choice, we allocate up to 4GB of RAM and 4 CPU cores to the machine. $ sudo virt-install \ --name=openbsd \ --virt-type=qemu \ --memory=2048,maxmemory=4096 \ --vcpus=2,maxvcpus=4 \ --cpu host \ --os-variant=openbsd7.0 \ --cdrom=/var/lib/libvirt/boot/install72.iso \ --network=bridge=virbr0,model=virtio \ --graphics=vnc \ --disk path=/var/lib/libvirt/images/openbsd.qcow2,size=40,bus=virtio,format=qcow2 </code></pre> Once, it is up and running, we can use a vnc solution to connect to the running machine. In this case, I chose virsh</a> to do the job. virsh is a command-line interface tool for managing virtualization environments created with libvirt. It allows us to manage virtual machines, storage pools, and network interfaces, as well as other virtualization components, from the command line. To establish a VNC connection with a running libvirt virtualized OpenBSD instance, you can use the following steps: Start the virtual machine in libvirt: You can start the virtual machine using the virsh command virsh start <vm-name></code>, where <vm-name></code> is the name of the virtual machine you want to start.</li> Find the VNC display: Once the virtual machine is running, you can find the VNC display number for the virtual machine using the virsh command virsh vncdisplay <vm-name></code>.</li> Connect to the VNC display: You can connect to the VNC display using a VNC client, such as vncviewer</code>, and specify the IP address of the host running the virtual machine and the VNC display number. For example, if the host’s IP address is 192.168.0.100</code> and the VNC display number is :0</code>, the command to connect would be vncviewer 192.168.0.100:0</code>.</li> Authenticate to the VNC server: You may need to enter a password to authenticate to the VNC server. The password is set when the virtual machine is created in libvirt.</li> </ol> With these steps, you can establish a VNC connection with a running libvirt virtualized OpenBSD instance and interact with the virtual machine’s graphical user interface. $ virsh dumpxml openbsd | grep vnc <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'> </code></pre> Like I did, most of you would like to interact with a graphical interface such as with X11. For that, we yet another tool, a so-called VNC viewer. A very simple implementation of such a vnc viewer is tigervnc</a> (simply install it with $ sudo xbps-install -S tigervnc</code>). $ sudo virsh --connect qemu:///system start openbsd Domain 'openbsd' started </code></pre> References and further reading</h2> OpenBSD</h3> OpenBSD</a> - Official project site</li> OpenBSD FAQ</a> - Comprehensive installation and usage guide</li> Why OpenBSD Rocks</a> - Collection of OpenBSD innovations and features</li> OpenSSH</a> - The SSH suite that originated from the OpenBSD project</li> Theo de Raadt</a> - OpenBSD founder and lead developer</li> pledge(2)</a> - OpenBSD’s system call for restricting process capabilities</li> unveil(2)</a> - OpenBSD’s system call for restricting filesystem visibility</li> </ul> Void Linux</h3> Void Linux</a> - Official project site</li> Void Linux Handbook</a> - Official documentation</li> XBPS package manager</a> - Void’s binary package management system</li> </ul> Virtualization</h3> libvirt</a> - Virtualization management library and API</li> QEMU</a> - Open-source machine emulator and virtualizer</li> virsh(1)</a> - Command-line interface for managing libvirt guests</li> TigerVNC</a> - VNC implementation for remote desktop access</li> </ul> Guides</h3> [Guide] How to setup QEMU/KVM emulation on Void Linux</a> - Community guide on r/voidlinux</li> KVM virt-install: Install OpenBSD as Guest Operating System</a> - Step-by-step KVM installation guide</li> Auto-install OpenBSD on QEMU</a> - Automated OpenBSD installation on QEMU</li> </ul> Hello and outlook Unknown — Tue, 20 Sep 2022 00:00:00 +0000 Hello world</h2> This is the first post on raskell.io. My name is Raffael. I build software, mostly in the space of platform automation, edge infrastructure, and applied security. I also have a long-running interest in open-source software, operating systems, and the kind of hardware you find in recycling bins and give a second life to. This site exists to document real work and share patterns that other engineers can use. Not thought leadership. Not personal branding. Just notes from the workshop. What to expect</h2> At the time of writing, I planned to cover: Linux and BSD systems, particularly Void Linux</a> and OpenBSD</a></li> Open-source tooling and infrastructure</li> Platform automation and operability</li> Whatever hard problem I happened to be stuck on</li> </ul> Looking back from 2026, the scope grew to include edge systems, AI-assisted engineering, and a few deep dives I did not expect to write. The thread that held it together was always the same: systems under pressure, and the tools that keep them running. References</h2> Void Linux</a></li> OpenBSD</a></li> raskell.io source</a></li> </ul>

Concern</th>	Lexical (BM25)</th>	Embeddings + vector store</th></tr></thead>
Infrastructure</td>	None. An in-memory index.</td>	An embedding model and a vector database to host.</td></tr>
Build cost</td>	Read files, count terms. Milliseconds.</td>	Embed every chunk. A model call per chunk.</td></tr>
Staleness</td>	Rebuild is reading the directory again.</td>	Re-embed and re-upsert on every document edit.</td></tr>
Debuggability</td>	Read the score. See which terms matched.</td>	Cosine distance in a space you cannot inspect.</td></tr>
Failure mode</td>	Misses on vocabulary mismatch.</td>	Retrieves plausible-but-wrong neighbors silently.</td></tr>
Right scale</td>	Tens of files, hundreds of chunks.</td>	Tens of thousands of documents and up.</td></tr> </tbody></table> The last row is the whole decision. Embeddings earn their keep when the corpus is too large for a human to have written with consistent vocabulary, when the queries come from people you do not control, or when you genuinely need to match across languages or heavy paraphrase. None of that is true of a project’s own context directory, and all of it is true of a knowledge base with fifty thousand pages. The mistake is not using embeddings. The mistake is using them at the scale where a thirty-year-old ranking function does the job with no operational surface at all.</p> When `.AGENTS/</code> grows past the point where lexical ranking holds, the tool boundary is exactly where you swap the implementation. context_search</code> keeps its name, its schema, and its contract. The retriever behind it grows an embedding index. The agent never knows the difference, and neither does the loop. That is the payoff of treating retrieval as a tool: the upgrade path is a change behind an interface, not a new system.</p>` Failure modes worth naming</h2> The first time you hit one of these you will suspect the retriever. Usually the retriever is fine and the corpus or the prompt needs an edit.</p> Under-retrieval.</strong> The agent answers from priors instead of calling context_search</code>, and gets the project-specific detail wrong. The cause is almost always a weak manifest or a missing instruction. The pinned conventions.md</code> should say, in the negative voice from post four, that the agent must search project context before guessing. The manifest should list headings specific enough that the model recognizes the turn needs them.</p> Over-retrieval.</strong> The agent calls context_search</code> on every turn, including turns that the pinned context already answers. This costs a tool round-trip and some latency. The fix is the manifest again, framed so the model treats search as the fallback for topical detail, not the default for everything.</p> Stale index.</strong> buildIndex</code> runs once at startup. A long-running agent process will not see edits to .AGENTS/</code> until it restarts. For a CLI that starts per invocation this never matters. For a daemon it does, and the fix is to watch the directory and rebuild, which is a few lines and a problem for the day you actually run a daemon, not before.</p> Chunk boundaries.</strong> A rule that spans two headings gets split across two chunks, and a top-k search returns one half. The fix is editorial: keep a rule under one heading. The heading-based chunker rewards documents that are organized the way you would organize them for a human reader anyway.</p> Vocabulary mismatch.</strong> The lexical failure mode the embeddings section described. A query shares no terms with the section that answers it, and the search scores zero. At .AGENTS/</code> scale the fix is to add the missing word to the heading or the body. You own the corpus. Make it say what people search for.</p> Manifest bloat.</strong> Forty searchable files, each with eight headings, is a manifest of three hundred lines, and now the thing you built to keep context out of the prompt is itself a large block of context in the prompt. The fix is to summarize: list files and a short description rather than every heading, once the directory is large enough that the full listing stops paying for itself.</p> What this layer does not solve</h2> The pattern from the earlier posts holds. Each layer earns the right to be small by deferring what does not belong to it.</p> Embeddings for large corpora.</strong> The tool boundary is built to absorb this. The day the corpus outgrows lexical ranking, the retriever behind context_search</code> changes and nothing else does. This post does not build it because nothing at .AGENTS/</code> scale needs it.</li> Per-turn token budgeting.</strong> Retrieved sections compete for the same window as the conversation history and the pinned context. Deciding how many sections to pull and how to evict them under pressure is a budgeting problem this post leaves at a fixed k</code>. Post eighteen</a> on economics returns to it.</li> Memory across turns and sessions.</strong> Retrieval reads context the project wrote. It does not write anything. A note the agent leaves for its future self is a different layer with a different lifetime and different write semantics, and it is the whole subject of the next post.</li> Shared context across many agents.</strong> A fleet may want its context to live in a service rather than in every repo. The MCP resources/list</code> and resources/read</code> shape fits behind the same tool boundary. Post eight</a>.</li> </ul> Where this lands in the platform</h2> Total damage going from post-04</code> to post-05</code>: one new file (retriever.ts</code>), one new tool (tools/context_search.ts</code>), a split in context.ts</code> between pinned and searchable, and three changes in agent.ts</code>. The loop, the registry internals, the sandbox, the four original tools, and the types are all untouched. The agent now pays a fixed cost for the context that is always true, and a variable cost it decides for the context that is only sometimes relevant.</p> The retriever sits on top of the static layer from post four, exactly as that post predicted it would. The pinned files are the static context. The searchable files are the corpus. The tool is the seam between them, and the seam is an entry in the registry from post three</a>, dispatched and capped and error-wrapped by machinery that already existed. No vector store joined the deployment. No second system joined the on-call rotation. Retrieval became a tool, because the harness was already the kind of thing that turns a function into a capability the model can reach.</p> The rule from the earlier posts still holds. The harness only ever grows; it does not get rewritten. Each post adds one capability to the same artifact and explains why the layer below was not enough. The layer below this one was a context loader that read everything every turn. This one reads what the turn needs. The layer above is the one that writes.</p> Next</h2> Part 6: Memory Is a Write Path.</strong> Retrieval reads context the project authored. Memory is the agent writing context for its own future turns and future sessions. Why the write path is the hard part, where session memory and cross-session memory diverge, and what it takes to let an agent remember without letting it corrupt its own ground truth.</p> Context Is the Product Unknown — Sat, 13 Jun 2026 00:00:00 +0000 Part 4 of The Agent Platform Handbook. From Loop to Platform.</em> Previous: Tools: How Agents Actually Do Things</a>. Next: Retrieval Is a Tool, Not a Layer</a>.</p> </blockquote> In post one</a> we built the agent harness: a loop, a one-tool registry, a system prompt, a dispatcher, and an iteration budget. In post two</a> we slid a sandboxed runtime underneath the shell tool without touching the loop. In post three</a> we promoted the registry into a real toolbox and let the model call several tools in one turn. The harness sits at tag post-03</code></a> today: a loop, a registry, four sandboxed tools, parallel dispatch, output caps, error envelopes. The pieces fit. The agent answers concrete questions about the directory it is pointed at.</p> It also walks into every conversation knowing nothing.</p> You can hand the same harness to ten different projects this afternoon. It will run. It will not know that your repo uses Bun and not Node, that your team writes “do not” instead of “don’t”, that git push --force</code> is a fireable offense on the main</code> branch, that the README is two years out of date, that your secrets live in 1Password://Engineering</code>, or that the term “Zentinel” in your prompt means a specific WAF tuner and not a generic security product. It will figure most of that out by running tools, slowly, and it will get the rest of it wrong.</p> The model is not what makes an agent good at your work. The context is. This is the post that builds that layer into the same harness, ships it as tag post-04</code></a>, and explains why the convention is converging on a directory called .AGENTS/</code> rather than a single file.</p> Why the model is not the product</h2> The frontier model market in mid-2026 has roughly five vendors shipping roughly comparable coding agents. Pick any of them. You can swap them at the loop boundary and most of your agents keep working. What does not swap is the system prompt, the tool definitions, the project documentation, the conventions, the glossary, and the working knowledge the model brings into every turn. Those are yours. They are also the difference between an agent that ships and an agent that hallucinates.</p> This is not a new observation in the field, but it is a recent one in the product narrative. For most of 2023 and 2024 the public story was “the new model is twice as smart.” The internal story for anyone running agents in production was “the old model is fine; we cannot get useful context into it cheaply enough.” The same evals that the vendor leaderboards measure are the ones a small team can saturate with a half-decent context strategy, on a year-old model, for an order of magnitude less money per call.</p> You can hold this in your head with one frame. The model is software you rent. The harness is software you write. The context is the only piece of either one that is your team’s, your project’s, your codebase’s. The model is replaceable. The context is what makes the replacement work at all.</p> That is the thesis of this post and it determines everything that follows.</p> The three sources of context</h2> An agent gets context from three places, and the engineering decisions you make at each layer are different.</p> +-----------------------+ what the operator pre-loads \| Static context \| before the first turn ever runs. \| -------------- \| cheap to author, expensive to fix \| system prompt \| once a million calls have run on \| project rules \| it. ships with the harness, lives \| glossary, conventions\| in git, reviewed by humans. +-----------+-----------+ \| v +-----------------------+ what arrives during the turn, \| Dynamic context \| per request, often per tool call. \| -------------- \| the agent decides what to fetch. \| retrieved docs \| the model never sees the source \| tool outputs \| of truth, only the slice the \| fetched URLs \| retriever returned. +-----------+-----------+ \| v +-----------------------+ what survives across turns and \| Persistent context \| across sessions. notes the agent \| -------------- \| writes for its future self. covered \| session memory \| in post six. mentioned here only \| cross-session memory \| so the diagram is complete. +-----------------------+</code></pre> Static context is the layer this post is about. It is the cheapest layer to get right and the one most teams skip because it feels like documentation rather than engineering. It is also the layer that compounds: every other layer of context loads on top of it, and a confused static layer makes every retrieval ambiguous and every tool output harder to interpret.</p> Dynamic context is what post three started, with fs_read</code> and http_get</code>. It is also what RAG systems do at industrial scale. The model decides what it needs and a tool fetches it. We will come back to dynamic context as its own design problem in post five</a> when we look at retrieval, embedding stores, and the per-task subsetting that lets a large repository fit into a small turn.</p> Persistent context is memory. Notes the agent writes to itself. A session log. A long-running working set the next conversation gets to read. Post six</a> is dedicated to it because the engineering story is genuinely different, and the design choices are larger than they look.</p> The honest version of the rule is that static context is necessary and not sufficient. Get it right and the other two layers have a fighting chance. Get it wrong and no amount of retrieval saves you.</p> How we got here</h2> Static context started life as the system prompt. A string at the top of a Python file. Six sentences. “You are a helpful assistant who specializes in customer support for an airline.”</p> That worked until it did not. The pattern that broke it was the same pattern every working agent now lives inside: as soon as a model has tools, the operator has to tell it which tool to pick for which job, what the inputs mean, what the failure modes are, what the project’s conventions are, and what is out of scope. Six sentences cannot hold any of that.</p> The industry tried to fix it in four moves, roughly in order.</p> Long system prompts (2022 to 2023).</strong> The first move was to make the string longer. Six sentences became six paragraphs. Then six pages. The OpenAI Cookbook and the early LangChain prompts shipped with the model’s role, examples, rules of engagement, output format, and a list of constraints. It worked, in the sense that the agent behaved better. It also produced a maintenance problem: when the team grew, the prompt drifted, nobody owned it, and small edits broke distant behaviors. Prompts were software with no test suite.</p> Retrieval-augmented generation (2020 to 2024).</strong> The original RAG paper by Lewis and others at FAIR landed in 2020, two years before ChatGPT, and described a system that fetched relevant documents from a corpus and concatenated them into the model’s input. By 2023 the pattern was the default for any system that needed to answer over a private corpus. By 2024 every vector database vendor had a product and a marketing budget. RAG solved the corpus problem. It did not solve the conventions problem. A retrieval system can pull “the most relevant page about how to deploy” out of fifty thousand pages of docs. It does not know that your deploy convention changed last week and the relevant page is three weeks out of date.</p> Long context windows (2024).</strong> Gemini shipped a one-million-token context window in February 2024. Claude followed with two hundred thousand, then five hundred thousand, then a million. The new story was “you do not need retrieval; just put everything in the prompt.” It is true for some workloads. It is wildly expensive for most, because the per-call cost scales linearly with the input tokens you paid for, even when prompt caching is in play. Long contexts made some classes of problem tractable. They did not change the engineering question. The question is still “what should the model know on every turn, regardless of which slice of the corpus is loaded.”</p> The convention layer (2025 to 2026).</strong> The pattern that worked, and that converged across vendors, was a per-project file. The team puts the agent’s operating context in a markdown file at the root of the repo. Anthropic’s Claude Code shipped CLAUDE.md</code> in early 2025. Cursor’s IDE agent shipped .cursorrules</code> around the same time. OpenAI Codex normalized AGENTS.md</code>. Aider had its own convention. Continue had another. Through 2025 the file proliferated and the names diverged. In early 2026 a working group of vendor engineers, after enough customers complained about maintaining four near-identical files in every repo, started consolidating on a single convention. The shape they landed on was a directory, not a file, called .AGENTS/</code>.</p> The lineage from “long system prompt” to “.AGENTS/ directory” is one continuous line. Every step was a reaction to the previous step failing under scale. Each step kept what worked and added what was missing. The directory at the end is the smallest thing the industry could agree on that solves the problem the file did not.</p> Why a directory and not a file</h2> If you have ever worked on a repo with a sprawling CLAUDE.md</code> you know why the file is not enough.</p> A single markdown file in the repo root has three failure modes that show up almost immediately.</p> The first is conflict at scale. Two people edit the same file from different feature branches and the merge is painful enough that one of them gives up. The team stops writing context updates because the file is a contested resource.</p> The second is loss of structure. The file grows section by section. Some sections are conventions. Some are glossaries. Some are reminders about which scripts do what. Some are project history. The model reads it as one giant string and the operator cannot tell, six months later, which section is still load-bearing and which is dead.</p> The third is the inability to scope. The same file gets loaded for every task, regardless of whether the agent is doing a database migration or fixing a typo. A small repo can afford to pay for the whole file every turn. A large repo cannot. There is no way to say “load this section only when the task touches the API layer.”</p> A directory fixes all three. You get one file per concern. Conflicts move from line-level to file-level, which is easier. Structure becomes the directory layout, which is self-documenting. Scoping becomes a load-order decision that the loader can make per task, with budgets, with priorities, and with reproducible behavior. The convention is small and the engineering surface that wraps it is well-understood: read files, concatenate, cap.</p> There is a fourth, subtler reason. A directory is the natural seam between project context and agent identity. Project context belongs to the project and lives in git. Agent identity, the system prompt that says “you are a careful command-line assistant,” belongs to the harness and ships with it. A file in the repo root muddles those two. A directory lets the harness own the loader and the project own the contents, and they meet at a stable interface.</p> That is the architecture the rest of this post adds to the harness.</p> The mental model</h2> Before the code, the picture.</p> repo on disk harness model ----------- ------- ----- .AGENTS/ +----------------+ +-- overview.md ----+ \| \| +-- conventions.md ----+---->\| loadContext \| +-- glossary.md ----+ \| \| +-- security.md ----+ +-------+--------+ +-- ... \| \| LoadedContext v +-----------------+ system prompt \| systemPrompt \|----------------------> \| CORE + ctx \| +-----------------+ ^ \| +-----------------+ \| loop / step \| +-----------------+</code></pre> Read it left to right. The project owns a directory of markdown files. The harness owns a loader that reads them at startup, applies a byte budget, and produces a LoadedContext</code> object. The harness’s system-prompt builder takes the core prompt (the agent’s role, the toolbox description) and concatenates the rendered context block underneath it. The loop and step functions never know any of this happened. Same step(messages, system)</code> call as before, with a different system</code> string.</p> The loader has three responsibilities, and they are worth naming because each one is a place where teams get tempted to do something clever and pay for it.</p> Read the files.</strong> Deterministically, in a defined order. The order matters because the model attends to the start of the prompt differently than the middle. Put the high-signal files first.</p> Cap the total size.</strong> A byte budget across all sources. Anything that does not fit is either dropped or truncated with a visible marker, never silently rolled off.</p> Render with attribution.</strong> Each source is wrapped in a <context path="..."></code> block so the model can tell the user which file the rule came from. This is cheap, costs maybe twenty tokens per source, and turns “the conventions say to never use the shell tool to write files” into a citation the operator can audit.</p> That is the whole thing. Nothing else belongs in the loader. Per-task filtering, embedding-based selection, dynamic retrieval, and memory are separate layers that the next two posts will build on top of this one.</p> Build the loader</h2> The harness from post-03</code> has six files. We add a seventh: context.ts</code>. We also create the .AGENTS/</code> directory with three example sources.</p> The context.ts</code> module exports one function. Roughly seventy lines.</p> // context.ts import { readFile, readdir, stat } from "node:fs/promises"; import { join } from "node:path"; export type ContextSource = { path: string; bytes: number; content: string; truncated: boolean; }; export type LoadedContext = { sources: ContextSource[]; rendered: string; totalBytes: number; budgetBytes: number; }; export type ContextOptions = { dir?: string; maxBytes?: number; }; const DEFAULT_DIR = ".AGENTS"; const DEFAULT_MAX_BYTES = 32 * 1024; const PRIORITY = ["overview.md", "conventions.md", "glossary.md"]; </code></pre> Three types and three constants. ContextSource</code> carries enough metadata for the operator to debug what got loaded. LoadedContext</code> carries the rendered string for the system prompt plus accounting for the operator. ContextOptions</code> is the only knob: a directory and a byte budget. Defaults match the convention.</p> The ordering policy is two lines.</p> function orderEntries(entries: string[]): string[] { const present = new Set(entries); const head = PRIORITY.filter((n) => present.has(n)); const tail = entries .filter((n) => !PRIORITY.includes(n)) .filter((n) => n.endsWith(".md")) .sort(); return [...head, ...tail]; } </code></pre> Three priority files load first in a fixed order: overview.md</code>, conventions.md</code>, glossary.md</code>. Everything else loads alphabetically. The model attends to the start of the prompt more strongly than to the middle, so the policy puts the highest-signal files at the start and lets the rest tail in.</p> The load itself reads each file, accounts for it against the budget, and either takes it whole, truncates it, or stops.</p> export async function loadContext(opts: ContextOptions = {}): Promise<LoadedContext> { const dir = opts.dir ?? process.env.AGENTS_DIR ?? DEFAULT_DIR; const budget = opts.maxBytes ?? DEFAULT_MAX_BYTES; if (!(await isDir(dir))) { return { sources: [], rendered: "", totalBytes: 0, budgetBytes: budget }; } const entries = await readdir(dir); const ordered = orderEntries(entries); const sources: ContextSource[] = []; let used = 0; for (const name of ordered) { const path = join(dir, name); const raw = await readFile(path, "utf8"); const bytes = Buffer.byteLength(raw, "utf8"); const remaining = budget - used; if (bytes <= remaining) { sources.push({ path, bytes, content: raw, truncated: false }); used += bytes; continue; } if (remaining < 256) break; const head = raw.slice(0, remaining); const note = `\n\n[truncated: ${bytes - remaining} more bytes]`; sources.push({ path, bytes: remaining, content: head + note, truncated: true }); used += remaining; break; } const rendered = sources .map((s) => `<context path="${s.path}">\n${s.content.trimEnd()}\n</context>`) .join("\n\n"); return { sources, rendered, totalBytes: used, budgetBytes: budget }; } </code></pre> A few details to call out, because the cheap version of this loader gets every one of them wrong.</p> The directory defaults to .AGENTS</code> but accepts an environment override through AGENTS_DIR</code>. The override lets you point a single binary at a per-project context without rewriting the harness.</p> The budget defaults to thirty-two kilobytes. That is roughly eight thousand tokens at the typical English-to-token ratio, which is generous on a modern model and cheap with prompt caching. Pick the budget your model and your wallet can sustain, not the budget that fits “everything you wrote.”</p> The truncation marker is visible. The model reads [truncated: 4096 more bytes]</code> and knows the source was clipped. That matters because the model can decide to ask a tool to read the rest, which is exactly the behavior you want when a file is too big to fit in the prompt.</p> The render wraps each source in a <context path="..."></code> tag. The tag is not a special token. The model treats it as structure because it has seen similar shapes in its training data. Cite-back behavior comes for free.</p> The loader never errors on a missing directory. If .AGENTS/</code> does not exist, the loader returns an empty context and the harness falls back to the core prompt. That is the right default for a small project that has not opted in yet.</p> A sample .AGENTS/</code></h2> The repo at post-04</code> ships with three sources. They are short on purpose. The point is the shape, not the content.</p> .AGENTS/ ├── overview.md what this repo is, how it is organized ├── conventions.md rules the agent must follow per tool └── glossary.md terms specific to this project </code></pre> The shape is the contract. Any agent that loads from .AGENTS/</code> should expect these three files. Anything else is project-specific. A security-sensitive project might add security.md</code>. A monorepo might add services.md</code> with one section per service. A multi-platform repo might add platforms.md</code>. The convention does not constrain those.</p> The content of conventions.md</code> matters more than people expect, so the example in the repo is worth quoting in part.</p> ## Filesystem - Read files with `fs_read`, not `shell`. The shell tool runs inside a sandbox that does not see the host filesystem. - Do not write files. There is no write tool in this harness yet. - Do not assume the working directory. Use absolute paths or paths rooted at the repo, never `~`. </code></pre> That paragraph fixes about four hallucinated tool calls per session in practice. It costs roughly fifty tokens to load. The math is not subtle.</p> The rule of thumb that survives contact with reality is to write conventions in the negative voice when you can. “Do not write files” tells the model where the edge is and what to do at it. “Always use the shell tool for system inspection” tells the model nothing useful because it does not say what to do when the system inspection means reading a file. Negative rules are testable. Positive rules drift.</p> Wiring it into the harness</h2> Three changes in agent.ts</code>. The diff is small because the loop never moved.</p> The import comes in at the top.</p> import { loadContext, type LoadedContext } from "./context"; </code></pre> The system prompt builder turns from a constant string into a function that takes the loaded context.</p> const CORE_PROMPT = `You are a careful command-line assistant. You have access to a small toolbox: a sandboxed shell, a file reader, an HTTP GET, and a read-only git wrapper. Use them to investigate the user's request and answer concretely. Multiple tools may run in one turn. When you have the answer, stop calling tools and reply in plain text.`; function systemPrompt(ctx: LoadedContext): string { if (ctx.sources.length === 0) return CORE_PROMPT; return ( CORE_PROMPT + "\n\nProject context loaded from .AGENTS/. Treat the contents below " + "as authoritative for this project's conventions and terminology. " + "Each block is wrapped in <context path=\"...\"> tags so you can " + "cite it back to the user.\n\n" + ctx.rendered ); } </code></pre> The core prompt is short on purpose. It says what the agent is, what tools it has, and when to stop. Everything else is project context. The bridge sentence between the core and the context tells the model how to treat what follows, which is the kind of framing that pays for itself within one turn.</p> The run function loads the context once at startup, logs what got loaded, and threads the system string into every step.</p> export async function run(goal: string, maxIterations = 10) { const ctx = await loadContext(); const system = systemPrompt(ctx); for (const s of ctx.sources) { console.error(`# context ${s.path} (${s.bytes}B${s.truncated ? ", truncated" : ""})`); } // ... rest of the loop unchanged } </code></pre> The four lines of logging matter more than they look. The first time an agent does something unexpected, the operator wants to know which files were in scope. Printing them is the cheapest debugging artifact you will ever ship. Print them.</p> That is the whole wiring change. The for</code> loop, the dispatcher, the Promise.all</code> over tool calls, the iteration budget are all untouched. The loop does not know context exists.</p> What it looks like running</h2> A short transcript shows the difference the context layer makes.</p> $ bun agent.ts "what does this repo do, and what conventions should I follow?" # context .AGENTS/overview.md (812B) # context .AGENTS/conventions.md (1186B) # context .AGENTS/glossary.md (824B) This repository is the reference harness for the Agent Platform Handbook series on raskell.io. The harness is a Bun + TypeScript agent against the Anthropic Messages API. Each git tag (post-01 through post-04) is the exact state of the code that the matching post discusses. The conventions you should follow: - Use fs_read for file reads, not shell. The shell runs in a sandbox without host filesystem access (.AGENTS/conventions.md). - Do not write files. No write tool exists in this harness yet (.AGENTS/conventions.md). - git is read-only. Allowed subcommands: log, diff, show, status, branch, ls-files (.AGENTS/conventions.md). - http_get accepts https:// only, for public documentation and APIs (.AGENTS/conventions.md). </code></pre> Zero tool calls. The model answered from the static context alone, and cited each rule back to the file it came from. The same agent without .AGENTS/</code> would have run three or four fs_read</code> calls, traversed the directory, opened the README, and produced a similar answer two seconds slower and one cache miss away.</p> The same harness, with a different .AGENTS/</code>, becomes a different agent.</p> Why retrieval alone is not enough</h2> This is the section where the RAG enthusiast and the long-context enthusiast both push back, and they are both wrong in instructive ways.</p> A retrieval system answers the question “what is relevant to this turn.” A static context answers the question “what is true about this project regardless of any turn.” The two are not interchangeable. The retrieval system cannot know that your team prohibits force pushes unless you wrote that into a document and the retriever surfaced it. The retriever will surface it sometimes. The static context surfaces it every time.</p> Three failure modes show up if you try to skip the static layer.</p> Cold-start emptiness.</strong> The very first turn of a session has no prior context, no tool outputs, no retrieval hits. The model has the user’s prompt and whatever you preloaded. Without static context, the model starts every session with the same generic priors. With it, the model starts every session knowing what the project is about and what it cannot do.</p> Retrieval misses on infrequent rules.</strong> A convention that comes up once a month is unlikely to retrieve cleanly. The embedding distance from “do not force push” to “I want to clean up the commit history” is not small but not zero, and a top-k retriever will sometimes miss it. The static layer hard-codes the rules that you cannot afford to miss.</p> Cross-cutting concerns.</strong> The convention “do not write files” applies to every tool call. There is no single document the retriever could match against every relevant turn. The static layer is the only place this kind of rule belongs.</p> The long-context argument is structurally similar. “Just put the whole repo in the prompt.” Two problems. The repo is bigger than the window for any non-trivial codebase, and you pay for every token on every turn. Even with prompt caching at ninety percent hit rate, the bill for a thousand-turn session against a two-hundred-thousand-token repo is real money. Static context lets you put the part that has to be in the prompt in the prompt, and let the rest live behind retrieval and tools.</p> The honest synthesis is that all three layers are necessary. Static for the rules. Retrieval for the corpus. Tools for everything live. This post is about the first one because it is the layer that everyone defers and that determines whether the other two work.</p> Designing context that the model can actually use</h2> Once you have a loader, the engineering question becomes “what do you put in .AGENTS/</code>.” There are four patterns that hold up.</p> Conventions in the negative voice.</strong> Tell the model what it cannot do, why, and what to do instead. A convention like “do not write files; there is no write tool” is testable: the model either tries to write a file or it does not, and you can grep for it in the trace. A convention like “be helpful” is not testable. Negative rules also fail safer when the model misreads them.</p> Glossary entries for project-specific nouns.</strong> Every project has a few terms that mean something different inside the project than outside. “Zentinel” in your company might be a WAF tuner. “The pipeline” might be a four-stage build system. The model has seen all of these words in its training data and will pick a meaning at random unless you tell it. A short glossary is cheap insurance.</p> Overview as a sitemap, not a story.</strong> The overview file should answer “what is here and where do I find it.” Not “what is the history of this project.” The history goes in the README for humans. The overview goes in .AGENTS/</code> for agents and is the structural map: the modules, the files, the entry points, the canonical commands. Keep it short. Update it when files move.</p> One file per concern.</strong> Resist the temptation to put security rules in conventions.md</code> because they are conventions. Make a security.md</code>. Resist the temptation to put architecture in overview.md</code> because it is overview. Make an architecture.md</code>. Each file gets its own load slot, its own conflict surface, its own owner. The directory is what makes this affordable.</p> The decision table summarizes where each kind of context goes.</p> Kind of context</th> Lives in</th> Why</th></tr></thead> What the agent is, role, toolbox</td> CORE_PROMPT</code> in harness</td> Ships with the harness, not the project.</td></tr> Project rules, conventions, prohibitions</td> .AGENTS/conventions.md</code></td> Per-project, hard-coded, cited back to the user.</td></tr> Project-specific terms and acronyms</td> .AGENTS/glossary.md</code></td> Disambiguates words the model knows differently.</td></tr> Sitemap, modules, canonical commands</td> .AGENTS/overview.md</code></td> Self-documents the repo for the agent.</td></tr> Sensitive policies (do-not-touch lists)</td> .AGENTS/security.md</code></td> Separates audit surface from general rules.</td></tr> Large reference material (API docs, RFCs)</td> Retrieval, not static</td> Too big for the budget, not needed every turn.</td></tr> Live system state (running processes, db)</td> Tools</td> Static context goes stale; tools always fresh.</td></tr> Notes the agent writes to its future self</td> Memory (post six)</td> Belongs in a layer this post does not build.</td></tr> </tbody></table> The table is the four-line summary of the rest of the series. Each row maps to one layer the harness either has, will have, or deliberately delegates to a tool.</p> Failure modes worth naming</h2> The first time you hit any of these you will think the loader is broken. It is not. These are static-context problems specifically.</p> Context drift.</strong> The conventions file says “use Bun 1.1,” your toolchain moved to Bun 1.5, the file is not updated, the model produces commands that work fine but cite a version that is two minor releases old. The fix is to treat .AGENTS/</code> files as code, reviewed in PRs, with the same kind of “is this still true” sweep you do on the README.</p> Stale glossary.</strong> A term changes meaning. The team renames “Zentinel” to “Sentinel” because the original was a joke. The glossary still says “Zentinel is a WAF tuner.” The model now uses both names interchangeably and the user is confused. Treat the glossary as a single source of truth. Update it on rename PRs.</p> Budget eviction silently dropping a critical file.</strong> A new file pushes the total over thirty-two kilobytes, the loader stops loading after conventions.md</code>, and security.md</code> is silently absent from the prompt. The fix is the visible truncation marker and the per-file logging in the loader. The operator sees the size before the agent runs and can raise the budget or trim a file.</p> Over-stuffed conventions.</strong> The team writes every preference, taste, and personal hobby horse into conventions.md</code>. The file balloons to ten thousand tokens. The model attention spreads thin. Sub-rules get ignored. The fix is to apply the same editorial discipline to the conventions file that you would apply to a real document. Cut anything that is not load-bearing.</p> Citation theater.</strong> The model picks up the citation pattern and starts citing files that were not in the loaded context. This happens because the model is good at pattern-matching and (.AGENTS/conventions.md)</code> is a pattern. The fix is to read your traces. If a citation is wrong, the convention was either missing or unclear, and the file needs an edit.</p> Context overriding the operator.</strong> A convention says “always reply in English.” The user asks for a French answer. The model says no. The convention won. This is sometimes what you want and often not. Decide explicitly which rules are operator-overridable and which are not, and write the irreversible ones in the strongest voice. We will come back to this in post fourteen</a> on policy.</p> Token cost surprise.</strong> The loader is cheap. The cumulative cost of loading thirty-two kilobytes of context on every call is not. Prompt caching makes it manageable. Without prompt caching, your bill is roughly ten times what it would be without .AGENTS/</code>. Turn caching on. We will spend post eighteen</a> on the economics.</p> What this layer does not solve</h2> Static context is one layer. Things you might expect this post to cover that get a dedicated post later.</p> Per-task subsetting.</strong> Loading the whole .AGENTS/</code> directory on every turn is wasteful for large repos. The next refinement is to load only the files relevant to the current task. That is a retrieval problem with a static-context shape, and we will pick it up in post five</a>.</li> Memory across turns and sessions.</strong> A note the agent wrote yesterday is not in .AGENTS/</code>. It is in a memory layer with different lifetime, different ownership, and different write semantics. Post six</a>.</li> Per-tool context.</strong> A tool might want a small chunk of context that only matters when it runs. “Reading this file? Here is what to expect in its structure.” That belongs in the tool description, not in .AGENTS/</code>. We covered the principle in post three</a>.</li> MCP-served context.</strong> A team that runs many agents may want context to live in a shared service, not in every repo. MCP has a resources/list</code> and resources/read</code> shape that fits. Post eight</a>.</li> Versioning, evals, and rollback.</strong> A bad edit to .AGENTS/conventions.md</code> can degrade every agent in the fleet. The discipline that wraps that is the same discipline that wraps any production string. Reviewed PRs, traced behavior, a rollback path. Post sixteen</a> covers the eval side.</li> Identity and authorization.</strong> A convention that says “do not deploy to production” does not stop the agent from deploying to production if the tool is available. That is policy and identity, post thirteen</a> and post fourteen</a>.</li> </ul> The pattern is the same as in the earlier posts. Each layer earns the right to be small by deferring everything that does not belong to it. The static-context layer earns its keep by being short, deterministic, and cited.</p> Where this lands in the platform</h2> Total damage going from post-03</code> to post-04</code>: one new file (context.ts</code>), one new directory (.AGENTS/</code>) with three sample files, three changes in agent.ts</code>. The loop, the registry, the tools, the sandbox, and the types are all untouched. The diff is roughly one hundred and twenty lines. In exchange, the agent now arrives at every turn knowing what the project is, how to talk about it, and what it is not allowed to do.</p> In the reference architecture from post twenty-two</a>, the context layer is the seam between the project and the agent. The harness loads from it. The retriever in post five</a> layers on top of it. The memory layer in post six</a> writes alongside it. The policy layer in post fourteen</a> reads from it to decide what is enforced and what is advisory. Same diagram as the earlier posts, with one more box filled in.</p> The rule from the earlier posts still holds. The harness only ever grows; it does not get rewritten. Each post adds one layer to the same artifact and explains why the layer below was not enough.</p> The layer below this one was a model that knew nothing about your project. The layer above is the model that pulls the slice of context it needs for the turn at hand. Static context makes the agent useful on every turn at a fixed cost. Per-task retrieval makes it useful on the turns where the static layer is not enough, at a variable cost the agent decides. Next we build the layer that turns a loader into a retriever and explains why embeddings are sometimes the right answer and sometimes a trap. That post will ship as post-05</code> in the same repo.</p> Next</h2> Part 5: Retrieval Is a Tool, Not a Layer</a>.</strong> Why pulling context dynamically is its own design problem, where embeddings stop being the right answer, and how to subset .AGENTS/</code> per task in the harness we have been building.</p> I Stopped Writing Most of My Code Unknown — Wed, 10 Jun 2026 00:00:00 +0000 IT's ABOUT TECH #13 · Basel · 10 June 2026</p> I Stopped Writing Most of My Code</h1> The year my backlog came alive.</p> Raffael Schneider</span> Enterprise Solution Architect</span> AI Platforms</span> </span> </span> ·</span> raskell.io</a> </span> </p> </div> </section> 01</p> It came down to three subscriptions.</h2> December 2022 → November 2025</p> December 2022</span> OpenAI.</strong> Subscription almost day one. Chat-first AI joins my daily workflow and stays there.</p> </li> Then Zed</span> A Rust-built editor that bet on AI very early. The best LLM integrations of its era. My gateway to AI-assisted development while Cursor, Windsurf, and Copilot were finding their feet.</p> </li> May 2025</span> Claude Code drops.</strong> First TUI-first coding agent. I take the $20 Anthropic subscription the day it ships. Hooked.</p> </li> November 2025</span> Opus 4.5 ships.</strong> I upgrade to the $200 Max 20× plan right before Christmas vacation. Three weeks of free time meets a step-change in capability.</p> </li> </ol> I am an engineer. I know how to build things.</p> The bottleneck was never ideas. The bottleneck was always time.</p> </div> </section> 02</p> Then something changed.</h2> Claude Opus 4.5 </div> Claude Code </div> </div> I expected a better autocomplete. What I got was something closer to a junior engineer that never sleeps. </p> </div> </section> 03</p> The new workflow</h2> Before</p> Decide what to build</li> Translate thoughts into syntax</li> Review and ship</li> </ul> </div> After</p> Decide what to build</li> Translate thoughts into syntax</li> Decide whether the result is acceptable</li> </ul> </div> </div> You no longer spend most of your time translating thoughts into syntax. You spend most of your time deciding. </p> </div> </section> 04</p> What I actually built</h2> Archipelag.io</h3> Distributed AI compute. Inference across idle GPUs and mining rigs.</p> </div> </a> Cyanea</h3> Open community platform for life-science research.</p> </div> </a> Humankind</h3> A long-running creative initiative, finally with a home of its own.</p> </div> </a> Arcanist.sh</h3> Haskell ecosystem in Rust. Home of hx</strong> and the Basel Haskell Compiler</strong>.</p> </div> </a> Zentinel</h3> Security-first reverse proxy on Pingora.</p> </div> </a> Die Zukunft</h3> A Swiss political party. Past left and right, into UBI, digital sovereignty, and a serious technology agenda.</p> </div> </a> </div> Experiments and tooling</p> Terrarium</li> Kurumi</li> …and the daily-driver utilities</li> </ul> None of these were started because AI generated ideas. AI allowed existing ideas to escape my notebook. </p> </div> </section> 05</p> Where the human still steers.</h2> Requirements</li> Architecture tradeoffs</li> Long-term maintainability</li> Taste</li> Product decisions</li> Knowing when not to build something</li> </ul> The human did not disappear. The human moved up the stack. </p>

Raskell

Retrieval Is a Tool, Not a Layer

Context Is the Product

I Stopped Writing Most of My Code

Your Agent Wants Root

What an Agent Actually Is

The Field Exists Now

Vera and BHC are adjacent, not sequential</h2> One useful correction: Raskell is not the project. Raskell is this blog.</p>

Source Code Is the New Assembly

A contract as an executable artifact</h2> The second domain I would point to is the one where words and computation already overlap uncomfortably: legal and financial agreements.</p>

Implications for builders right now</h2> The migration is staged. The way I think about the timeline:</p>

Patents Per Capita Is a Vanity Metric

Traffic Replay as a Security Primitive

The Economics of Inference

What Comes After the Last Programming Language

coconutOS</h2> This is not purely theoretical. I have been building a proof of concept.</p>

The four futures, updated</h2> Looking back at the original post, the timeline extends further than I initially described:</p>

What Sixteen AI Agents Taught Me About Management

Why We Built a Haskell Package Manager in Rust