Systems and math22 Oct 2026

Does it even matter if we can't read the code? Writing a server in Brainfuck, a language made to be unreadable

219 million steps per todo

Four Brainfuck programs run on a 210-line C interpreter that only knows how to reach Unix. HTTP, JSON, saved records and the agent loop all happen on the tape, at about 219 million steps per todo.

Brainfuck has eight instructions, a row of byte cells and no way to open a file or a socket. It was made in 1993 to be hard to write and harder to read. A program can count, copy and compare on its tape, but the only things it can send out are single bytes to a screen.

I wanted to know how far up the stack it could go if I gave it the thinnest possible bridge to the operating system. So I built a 210-line C interpreter whose one extra trick is a door to Unix, and put everything else in Brainfuck. The result is a todo web app with saved records, and an agent loop that calls a language model and runs shell commands. All of their logic is Brainfuck, and 19 tests pass on macOS and Linux.

88 MB

of Brainfuck across four programs

7 KB

of C underneath, which knows only Unix

19

tests passing on macOS and Linux

219M

interpreter steps to add one todo (219,693,613)

Giving Brainfuck one door to Unix

A Brainfuck program sees a tape of cells and a pointer. > and < move the pointer, + and - change the cell, [ and ] loop while it isn't zero, and , and . read and write a byte. That is the whole language. A web server has to wait for a browser, read what it sent, open a file and reply, and the operating system controls all of that through system calls. Brainfuck has no instruction for making one.

I changed the meaning of one instruction in one place. . at cell zero no longer prints. It runs the Unix call described by the cells next to it, a small mailbox, and writes the result back onto the tape. Anywhere else, . prints a byte as usual. The program is still valid Brainfuck; only the meaning of one cell changed.

The smallest complete example in the repository writes one letter. It sets operation 2, which is write, then file descriptor 1, a buffer at cell 30 and a length of one, puts 65 at cell 30, walks back to cell zero and prints. Step through it below, with the C that handles the last dot beside it.

Every call in every program follows that cycle: clear a few cells, add numbers into them, move to cell zero, print, read the answer. Only the number in cell 1 changes. There are 21 of them.

Keeping the C runtime small and ignorant

The bridge is where a project like this usually cheats. If the C parsed HTTP or stored records, the Brainfuck would be decoration. So the rule was that the runtime may move bytes between the tape and the kernel, and may not know what any of those bytes mean.

I kept runtime/bfu.c to 210 lines and three jobs. The interpreter loop is about 35 of them.

1. Load

   Drop every character that isn't one of the eight instructions, which is why the .bf files can carry comments in words. Fold runs like +++++ into one instruction with a count, and match each [ to its ] ahead of time.

2. Run

   Keep 65,536 zero-initialised byte cells. Arithmetic wraps at 256, and moving off either end of the tape or an unmatched bracket is an error.

3. Call Unix

   When the program prints at cell zero, read the mailbox, run one libc call in a single switch, and write the result and errno back to cells 18 and 22.

Every buffer or path the Brainfuck hands over passes one of two checks. A length that runs past the tape, or a path with no zero byte before the tape ends, gives EFAULT and the libc call never happens. That is what stops a wrong offset in a language with no types from becoming a bad pointer in C.

static void *region(uint32_t p, uint32_t n) {
    if (p>TAPE || n>TAPE-p) { errno=EFAULT; return NULL; }
    return mem+p;
}
static char *string_at(uint32_t p) {
    if (p>=TAPE || !memchr(mem+p, 0, TAPE-p)) {
        errno=EFAULT; return NULL;
    }
    return (char *)mem+p;
}

The other decisions in the runtime each answer one way a bridge like this could go wrong.

Serving a todo page from the tape

A web server is the hard case for a language with no I/O: it has to listen, accept, parse a protocol, keep state and write a reply, over and over without crashing. If the mailbox could carry that, it could carry the rest.

I wrote four programs on the same runtime. The server is the largest piece of work in Brainfuck, and the browser receives HTML forms and CSS that it generates byte by byte, with no JavaScript.

The page at the top of this post is plain forms, so server.bf writes every byte and the browser runs no script. In Chrome, add, toggle, edit and both filters passed with real form submissions.

If the mailbox could carry that, it could carry the rest.

The server first opens todos.db. On a first run that call returns -1 with ENOENT, and the list starts empty. Then it makes a socket, turns on address reuse, binds to loopback and listens. Its main loop accepts a connection and uses dup2 to make that connection standard output, so from then on an ordinary dot sends a byte to the browser.

It reads the request one byte at a time, tracks the blank line that ends the headers, parses Content-Length, matches the route and percent-decodes the title. Pick a request below to see where its steps went and which Unix calls it made, at the step each one happened.

Rendering branches over the used and done flags, escapes quotes and angle brackets in each title, and prints a toggle form, an edit form and a delete form per todo. The headers carry a Content-Security-Policy that allows no scripts. The same records come out as JSON at /api, through a separate encoder region that escapes quotes and backslashes.

Storing eight todos in 512 bytes

A todo app that forgets everything on restart isn't much of an app, and SQLite was out because the C isn't allowed to know what a database is. The records had to live on the tape and reach the disk through the same 21 calls.

I gave the server eight slots of 64 bytes starting at cell 600. Each holds a used flag, a done flag, the title's byte length, sixty title bytes and a zero. The slot number is the todo's id, and a deleted slot gets reused. Step through the traced requests to see which bytes each one changes.

Before a change, the program copies the 512 live bytes to a backup area at cell 1200. A save writes a temporary file, syncs it to disk and renames it over the old one, so a crash leaves either the old file or the new one, never half of each. If any step fails, the program copies the backup back, so memory and disk agree.

The rest of the tape has fixed homes too. The first 64 bytes of each request sit at cell 400, which is all the route matcher sees. The decoded title goes to cell 320, and cells from 100 on are scratch space for arithmetic.

Paying 219 million steps for one todo

Brainfuck has no way to jump to a position or compare two bytes in one step. Every comparison is a loop, and every move along the tape is one cell at a time, so the cost of a request shows up somewhere specific.

I ran the real server under a copy of the runtime that logged every Unix call, every printed byte and the step count in each region of the source, cut at the comments in the file. Adding “Buy milk” is a 155-byte request. It took 219,693,613 steps, 10 Unix calls besides the 155 one-byte reads, and 77 one-byte writes.

The cost per byte also climbs. The first gap between two reads is 282 thousand steps and the last ones are about 2.2 million. I haven't checked why. My guess is that the program walks further along the tape as the request grows, because it can't jump.

The file sizes have a similar cause. The sources were expanded by a generator during development, so a move of twenty cells is written as twenty < characters. The first line of the server says “BRAIN compiled Unix todo server”, and then the file is mostly > for a very long way. The loader folds each run back into one instruction, so the size costs disk space and load time, not steps.

Running an agent loop from the tape

An agent loop is a stranger test than a server. It has to be a client, speak JSON to a model, start other programs, capture what they print and remember the conversation, and all of that state has to fit on a tape with no pointers.

I pointed the same mailbox at a language model. agent.bf builds a Chat Completions request by hand, counts the escaped bytes for Content-Length, and posts it to a model running locally on port 8081. The model replies with one letter and some text: T means run this command, F means here is the final answer. For a T, the agent forks, runs the command through a pipe and adds the output to the transcript.

Here is one traced run, against a test model that always answers the same way. The task is “Print a greeting”. Step through the calls, the bytes on the wire and what reaches the terminal.

Task: 

The transcript lives at cell 800 as 240 entries of four cells: a marker, a data byte, a carried byte and a scratch byte. Reading an entry means walking a counter along the tape and leaving breadcrumbs for the trip back, all in Brainfuck loops. The C has no operation for indexed memory and no idea what a message is.

A strange system is easier to test when every buffer has a size you can write down.

The limits are small on purpose: a 240-byte transcript, a 200-byte reply, eight turns and a 120-second receive timeout. A strange system is easier to test when every buffer has a size you can write down. Ordinary JSON escapes are decoded and \uXXXX is rejected. Tool stdin is /dev/null, so a child can't eat the agent's input.

harness.bf is the same tool loop with no model, for testing. Fed Tprintf hello, then Tprintf world; exit 7, then Fdone, it prints each wait status as four little-endian bytes in hex. 00070000 is a normal exit with code 7.

Testing code that nobody can read

Nobody reviews 88 MB of > and +. If the code can't be read, the only evidence that it works is what it does when you run it, so the tests had to start real processes and talk to them over real sockets.

I didn't type 88 MB of Brainfuck. I built this with an AI coding agent, and the generator that expanded the sources isn't in the repository. What's kept is the output, the ABI document, a short walkthrough, and the tests. The tests are what made me trust it.

Sizing the C for a bigger app

The amount of C is a choice, and it decides where work lives. Too little and the interesting decisions leave Brainfuck for a wrapper script. Too much and the C starts to understand protocols, which is the thing this project says it doesn't do.

I read the operation table against the traces and asked what would change in each direction. None of this is built.

The 512-byte file is region 6 of the server, and it exists because Brainfuck has to rebuild what a database already does. There are two ways to swap in SQLite.

I would build A first, because it leaves the C alone and so tests the project's claim. The same reasoning applies to a larger target such as Conduit, the RealWorld example backend with 19 endpoints. Routing and JSON bodies would stay in Brainfuck, tables and joins would go to SQLite, and password hashing to a Unix tool. The 64 KB tape and one connection at a time would be the first limits it hit, and speed is the open question: a real browser sends several times more header bytes than the test client.

Asking whether readable code still matters

The line every programmer gets taught comes from the preface to Structure and Interpretation of Computer Programs: “Programs must be written for people to read, and only incidentally for machines to execute.” This project is the opposite case. It was written for a machine, by a machine, and a person can only check it from the outside.

I built this the way a lot of code gets made now. Andrej Karpathy named it vibe coding in February 2025: you describe what you want, accept what comes back, and “forget that the code even exists”. Martin Fowler's answer was that this suits throwaway software and not much else. The data so far leans his way. GitClear looked at 211 million changed lines from 2020 to 2024. In 2024, blocks of five or more duplicated lines were eight times as common as before, moved code fell by 40%, and for the first time copy-pasted lines outnumbered moved ones. Moving code is what refactoring looks like in a diff, so less of it means less tidying up. GitClear sells code analysis and most of its data comes from its own customers, so I read it as a strong signal, not a census.

Peter Naur argued in 1985 that a program isn't really its text. It is a theory in the heads of the people who built it: why it is shaped this way, what each part is for, what would break if you changed it. The code is a lossy record of that theory. When the team leaves, the theory goes with them, and the code alone can't bring it back.

Readability still matters, but it has moved.

Read that way, this project shows where the theory lives once the code stops being readable, and the 88 MB holds none of it. ABI.md fixes the one contract between the tape and Unix, the walkthrough shows how a copy or a clear looks in Brainfuck, and the 19 tests say what has to stay true. I could throw the Brainfuck away and regenerate it, and I'd know whether the new one was right, because those three things would tell me.

My answer after this: readability still matters, but it has moved. The lines inside a function matter less, because the thing writing and rereading them is a model that doesn't get tired. What matters more is the part a person has to hold in their head to know whether the system is right.

The one thing I'd change is the missing generator. The readable source of the Brainfuck is the closest thing this project had to Naur's theory in code form, and it wasn't kept. If a model can regenerate the output, the input is what deserves to be readable.

Notes

• One connection at a time, a two-second receive timeout, and no authentication or CSRF protection. Keep it on loopback.
• The agent runs model commands with your Unix permissions, so use a throwaway directory or a container.
• No TLS, no streaming and no real model provider. The request follows the Chat Completions shape but uses a one-letter text protocol instead of structured tool calls.
• A stock Brainfuck interpreter treats a dot at cell zero as a print, so these programs need the mailbox runtime.
• The browser UI is a server-rendered take on TodoMVC. It reloads after each action and has no double-click editing or Escape to cancel. Directory entries aren't synced, so there is no power-loss guarantee.
• The step counts come from a copy of the runtime that logs each call, checked against all 115 server calls. Why a region is slow is my reading of the source, not a measurement.
• The figures above are rebuilt from the repository's blog and four narrated explainer videos, which use the same trace.

Sources

1. Abelson and Sussman, preface to the first edition ↗, Structure and Interpretation of Computer Programs, 1985.
2. Peter Naur, Programming as Theory Building ↗, 1985.
3. Andrej Karpathy on vibe coding ↗, 2 February 2025.
4. Martin Fowler, Vibe Coding ↗.
5. GitClear's 2025 AI Copilot Code Quality report ↗, as reported by DevClass, February 2025.
6. Chat Completions API reference ↗, the request shape the agent follows.
7. RealWorld ↗, the spec behind the Conduit example app.