Day 133 — a brick bin you can hold

small universal blocks that only fit some shapes → snapped into real programs → frozen into bigger blocks → and reused across tasks, verified every step

Two things landed today. werbos got hands, and it got a library it builds with.

Hands

The engine runs on another box and only composes text — so the file work happens right in the terminal, on your machine, fenced to one folder. /read, /save, /write, /edit. Code files go through the owned coder and are run to verify — and it never overwrites a file with a bad answer. Prose and markdown go through a labelled rented writer (the owned model can’t write prose from nothing — an honest limit, so it says so). The loop closes: write it, read it, edit it, come back tomorrow, keep going — real files, code and prose.

A brick bin you can hold

The bigger thing. For a year the pitch has been the library is the truth, the model is a cursor. A brick bin is what that looks like when you can hold it.

A brick is a small, self-describing, typed, tested snippet — a name, what it does, its input and output shapes, its code, and a test that proves it runs. werbos didn’t start with an empty bin: it inherited a whole library — 303 bricks across 19 categories (web, crypto, text, lists, math, …), imported in one shot from an old block-coding app.

Then it learned the three things you do with blocks:

• Snap them by shape. A brick is universal but only fits some slots — one that outputs json only clicks into a slot that takes json. That constraint is a type system disguised as LEGO; werbos catches a bad snap before it runs.
• Build real programs. Loops and branches are built into the composer, and the bricks are the vocabulary. It composed a randomized-DFS maze — the Pac-Man kind — entirely from bricks, and proved it valid (every open cell reachable).
• Make bigger blocks. That whole maze became a single maze brick that carries its parts with it. Small blocks → programs → bigger blocks → composed further. The library gets more capable each time.

And the payoff: it composes from a plain request. “fetch this, take the title, hash it, uppercase it” → it finds the bricks, snaps them by shape, runs it, gives you the answer. If it can’t reach the goal, it says so — the miss just names the next brick to add. No model writes the code; the shapes do the reasoning, and everything is run before it’s trusted.

The number that matters: across a suite of tasks, the reuse rate was 3.0× — the same bricks serving many jobs. That’s the moat compounding instead of every task starting from a blank page. Which is the whole idea: werbos doesn’t get smarter by getting bigger. It gets more capable by keeping what it already proved.

1:1 with the language

One more push the same day: I’d left three holes in the inherited library — the tricky ones. Functions that take other functions (map/filter/reduce over a rule you write inline), regular expressions, and try/catch error handling. Closed all three. The composer now writes inline functions, the bin gained regex and the higher-order blocks, and try/catch is built into the composer like every other loop and branch.

The check: a single little program that uses all three at once — doubles a list, keeps the big ones, adds them up (14), pulls “42” out of “order #42 shipped”, and shrugs off a deliberately broken parse — composed and run clean. On a checklist of what any everyday programmer reaches for, that’s 41 of 41 — 100%. The block box is now 1:1 with the language it targets. Small universal blocks, a full vocabulary, every one proven by running it.

Just write it — and it loops

Last beat of the day. Up to now the bin composed straight-line pipelines — fetch, take a field, transform. But real code has loops, and a plain ask like “get some test data, iterate over each object and print the title” just fell through. Now it doesn’t: the composer reads the “for each” and builds an actual loop — get the data once, then run the body once per item. alpha / beta / gamma. Ask it to uppercase each title instead and you get ALPHA / BETA / GAMMA.

And you don’t say “compose” anymore — you just say it. werbos chat "get some test data, iterate over each object and print the title" goes straight through the library, no ceremony, no model in the loop. If it hits something the bin can’t reach, it tells you — and that miss is just the name of the next block to add.

The library did the coding — 478 problems, 20 blocks

Then the real test. There’s an old coding gauntlet — ~500 beginner problems (reverse a string, factorial, is-prime), graded by running the answer against a known-correct value. It once tied a 14-billion-parameter model. Today it got solved a completely different way: not by a model writing code, but by decomposing each problem into blocks and snapping them together. Every one passed — 478 out of 478 — with no model in the loop.

The number I keep coming back to: 20 blocks solved all 478 problems. The same “add up a list” block serves sum, sum-of-evens, sum-of-squares, factorial. That’s a library compounding instead of starting from scratch every time. And side by side with the 14B on the same problems, both got everything right — but the blocks were about 90× faster (the big model spent 20 seconds working out “is this prime”; the blocks, a twentieth of a second).

Honest about what it means: these are beginner problems, so this isn’t “it out-codes a 14B” — it’s “a library it owns did the work a model used to, faster, and every time it hits something new the miss just names the next block to add.” Written up as B.28 on the benchmarks page, with all the caveats.

And one more, straight from a chat you’d actually have: “I wrote a story called The Last Hike” … build reverseString a line at a time … “run it with the name of my story” → ekiH tsaL ehT. A fact you mentioned in passing, remembered across the whole conversation, and fed into code you built together.

The composer learned Python — and grew a body

A “what if this ran on a Raspberry Pi” riff turned into shipped code. The block-composer only spoke JavaScript; now it speaks Python too — the same blocks, snapped the same way, emitting a second language. Not just simple pipelines: the whole thing — loops, ifs, try/catch — composes to clean Python that runs and matches the JavaScript answer exactly.

Then it grew wheels. A small robot vocabulary — forward, stop, turn, read-distance — that composes a driving program the same way it composes anything else. And the honesty rule came along for the ride, now as a safety rule: before a program can touch a real motor, it’s dry-run against a fake robot that records every command and refuses anything out of range — a servo told to swing to 400°, or a program that forgets to stop, gets blocked before it ever reaches the wheels. “Drive in a square” passes; “drive until the wall” passes; the dangerous ones don’t. A robot that won’t move until it’s verified the move is safe — that’s the whole werbos idea, wearing wheels.

The quiet headline underneath: all of this — composing code, building sites, the safety gate — is plain Python and a code-runner. No GPU. It fits on an $80 computer. The intelligence was never in the weights; it’s in the library and the engine, and those are cheap to carry.