They will spend months on a single trick. Years, sometimes. More time on something than anyone else might reasonably expect, they’ve said. The same motion. The same timing. The same angle of the wrist at the exact same millisecond. Eliminate every possible deviation from the plan.

Because when you’re an illusionist… you only get one shot.

One audience. One moment. One chance for the coin to appear behind the ear instead of falling into your sleeve and rolling under the table while everyone watches on in secondhand embarrassment.

The illusionist lives in scarcity because the medium demands it. The show is live. The audience is right there. The trick either works or it doesn’t. So you rehearse. You refine. You do the thing ten thousand times in a mirror until your hands move like they belong to someone who has never once been nervous.

Conjurers, on the other hand, do it differently.

The Conjurer

Have you ever watched a sports photographer work? I mean really watched one?

They’re crouched at the edge of a basketball court or pressed against the boards at a hockey game and they are just...

Thousands of photos in a single night. A shutter that sounds like you’re speeding down a hill on your bike with a playing card in your spokes. And then they go home, or back to the press room, or wherever it is that photographers go when the game ends, and they start throwing photos away.

(I guess technically it might be called curating?)

They took 3,000 shots and now they need 12. So they scroll and squint and delete and compare and zoom in on this one ”no, the elbow’s wrong,” “try that one,” “the light’s perfect but the expression is...,” “wait, this one. This one is the one.”

Then they go into this deeply illusionist mode where they adjust the contrast, tweak the color balance, crop it just so, remove that one distracting thing in the background. The last mile is all precision. All devotion.

But the finding of the thing? That was abundance. That was overflow. That was “let me generate so much raw material that the good stuff can’t help but show up somewhere in the pile.”

The conjurer summons many. Then chooses.

Subscribe now

Film

There was a time (some of you out there are young enough that this might sound like a fairy tale, but if you’re old enough to get the NES reference from my last post, you know it’s true) when every photograph cost money. Film cost money. Developing cost money. You had 24 or 36 exposures on a roll and each one was a tiny investment, a little act of faith that this moment was worth one of your limited chances.

People were illusionists with cameras. They had to be.

And then digital happened and suddenly the cost of a photograph was nothing. All those un-photographed lunches you’d eaten your entire life could now be captured.

Photography went from scarcity to abundance within a single generation and some people mourned it. “The craft is dying,” they said, while a teenager with an iPhone was accidentally taking better street photography than most professionals because she took 400 shots walking to school and one of them happened to catch the light doing something cool on a fire escape.

But I’m talking about it now because I want you to look at everything that grew in that new soil. When photos became abundant and disposable, entirely new ways of relating to photography became possible. Ways that couldn’t have existed before because the economics didn’t allow it. Flickr appeared and we built communities around our photos. Google Photos gave us unlimited storage and let us search through it. Instagram turned curation into a daily practice for millions of people who’d never used the word curation. Lightroom gave every hobbyist a digital darkroom. All of these were about living differently in relation to an abundant medium: organizing it, sharing it, filtering it, searching it, remixing it.

Want to explore this more? Here’s an artifact I put together about photography going from scarcity to abundance for you.

An entire ecosystem of tools and behaviors and cultures bloomed simply because the quantity of photography became effectively infinite. Scarcity had been the constraint, and when the constraint lifted, people didn’t just do the old thing faster. They did new things entirely.

And I’ve spent the last few years wondering about what these new things might look like now with AI.

Accidental Discoveries

Well, last year I shared this thing I built called Monkey’s Paw.

(If you were around for Monkey’s Paw, a prompt-driven web framework I built that broke containment a little bit last year. Hi, happy almost anniversary. If not, here’s that post.)

I spent most of last year using Monkey’s Paw for presentations. The slides were good, I think. Definitely more fun than anything I could have made myself. But the experience of using it left something to be desired. Iteration was slow and I’d accidentally lose slides I wanted to keep all the time. The problem was I was still thinking about it with an illusionist mindset. One prompt, one generation, one shot.

But then a couple things happened all at once, the way things do in AI these days, that made that Monkey’s Paw workflow obsolete.

NotebookLM came along. A model called Nano Banana Pro showed up and turned out to be unreasonably good at generating images with legible text in them, which if you’ve been paying attention to image generation you know is a small miracle. And suddenly, slide deck generation jumped ahead to “actually really good.”

So I thought: what if I stopped being an illusionist about this?

For PhillyRB in January, I tried something different. I generated 20 different variations of my presentation with NotebookLM. I downloaded them all as PDFs. I wrote a script to extract the PNGs from every page. I uploaded those PNGs to Figma and built this massive board, just hundreds of slides laid out like a contact sheet.

Then I picked my favorite slide from each batch. This one has the right energy. That one nails the layout. Oh, this title slide from generation #14 is perfect. And I stitched the whole presentation together from the best parts of twenty different attempts.

After the talk, someone asked who designed my slides. So I briefly walked everyone through my process, and I heard someone in the back yell out: ”Your next talk should be about this process!”

It was that moment that made me realize I was going to have to build this thing for real.

Conjure

So I built the thing for real. It’s called Conjure and it’s up on GitHub now.

Here’s how it works:

First, you write your grimoire. That’s your style guide, your visual language, the mood, the rules of the world your slides live in. Every conjurer needs a grimoire.

Then, you paste in your outline. The one you’ve been curating with your LLM of choice. The one you and Claude or whoever have been going back and forth on, shaping the narrative, getting the structure right. The slides get extracted from it.

Then you press conjure.

Five variations of each slide. Ten slides? Fifty images. You summon abundance. Then you curate, like the sports photographer. This one has a great background. The typography looks right on this one. I really like the layout from variation #5. You stitch. You refine. You do some light edits. You export to PDF or a zip of PNGs that you can throw into Figma to refine further.

It’s more work than prompting once and copying the output.

It might actually be more work than designing slides from scratch if you know what you’re doing.

But it’s a different kind of work. The kind where you’re choosing instead of constructing. Selecting instead of sculpting. And the choosing, the taste, that’s where you are.

Where the Scarcity Moved

The illusionists aren’t going anywhere. There are still photographers who shoot deliberately on film. There are still musicians who record live to tape. There are still people who will design every slide by hand. I’m sure there are a few software developers out there still using an IDE.

But remember what happened when film went digital. People mourned the death of photography. They were sure that when anyone could take a thousand photos, photos would stop meaning anything. That abundance would kill the art.

Instead, the art moved from capturing images to choosing them. From the shutter finger to the editing eye. From “can I get the shot?” to “can I find the shot, in all of this, and do I know it when I see it?” The technical act got cheap. The judgment got more valuable. And an entire universe of new things that nobody predicted, things that couldn’t have existed in the era of 36 exposures, grew in the space that opened up.

I think that’s what’s happening now. With slides, with code, with writing, with design, with whatever domain you’re generating abundance in. The raw material is becoming infinite. The craft is migrating somewhere else.

To the choosing. To the curating. To the willingness to generate forty-seven versions of something and throw them all away because the forty-eighth is the one that finally has the thing you couldn’t describe but recognized the instant you saw it.

The illusionist’s skill was precision. Getting it right in the moment because you only had one shot.

The conjurer’s skill is recognition. Summoning enough that the right thing can emerge, and then knowing it when it does.

That’s where craft lives now.

Conjure is up on GitHub. Bring your own API key. Fork it, clone it, bin/setup, bin/dev. If you make something cool with it, come show me.

Don’t pretend you didn’t. Everyone had a technique.

Three short breaths, then one long one. Or two long breaths across the whole cartridge on either side. Or you put it in your shirt and blew through it like I did. You knew yours was the right one because it worked, and you could prove it, because the game started right up every time.

Want to know what was actually happening? The 72-pin connector inside the NES was just flaky. When you pulled the cartridge out and put it back in, the pins shifted enough to find a new grip. That’s it. That was the whole fix. Reseat the cartridge.

The blowing… the blowing was depositing moisture onto the contacts. Which corroded them. Which made the problem worse over time. Your technique was actively making things worse in a way that felt like magic.

The game still worked, but the blowing didn’t matter. Because the reseating was bundled inside the ritual. You couldn’t blow without removing the cartridge first. The fix was hiding inside the myth.

Everybody I know had a different technique. Every technique contained the same accidental mechanism. Everyone had proof.

You Are Doing This Right Now

You talk to machines. Probably every day. Maybe more hours a day than you talk to people, if you’re being honest about it. (… and yeah… same... )

And you have a technique. You might not call it a technique. You might call it “my process” or “how I prompt” or “the way that works for me”. But it’s a technique.

You probably already suspect this, deep down, but do you want to know the myth that technique is hiding?

Any structured prompting beats naive prompting.

That’s the pin reseat. That’s the whole mechanism hiding inside every framework and every acronym and every “ultimate guide to prompt engineering” blog post with 47 clap emojis.

Go from typing “do this thing” to literally any system where you think before you type (roles, constraints, examples, XML tags, markdown headers, repeating your prompt a second time, whatever) and you get better output. Meaningfully better. Showably better. Screenshottably better.

Everyone is right and nobody is special. I’m sorry. (I’m not sorry.) (Ok, I’m a little sorry, but not because of why you think… )

I’m sorry because I’ve set you up. It’s different from the NES example. It does actually work, but not for why you think.

A few months ago, we talked about how every possible arrangement of words that an LLM can produce already exists, the way every possible image exists in the space of all possible pixel arrangements, the way every book already exists in Borges’ Library of Babel, waiting on its shelf for someone to find it. The output you’re trying to reach is already sitting in the space of all possible token sequences. Your prompting technique is a lens that brings one arrangement into focus out of infinity.

But that’s only half the story. There are also an infinite number of lenses.

Subscribe now

Pierre Menard, Author of Your Prompt

Borges has another story called “Pierre Menard, Author of the Quixote.” In it, Menard decides he wants to rewrite Don Quixote. But instead of just copying it or updating it for a modern audience, he wants to produce the exact same text, word for word, by arriving at it through his own life and his own reading and his own suffering and experience.

He’s able to accomplish the task for at least a few chapters.

It sounds like a silly premise, but the real message from Borges comes through when he puts the two versions side by side (Cervantes’ and Menard’s, which are identical, letter for letter) and argues that Menard’s version is richer. When Cervantes writes “truth, whose mother is history,” it’s a routine rhetorical flourish from a seventeenth-century Spaniard. When Menard writes the identical phrase, it’s a staggering philosophical claim, because Menard is a contemporary of William James and Bertrand Russell. He chose these words while knowing everything that came after Cervantes. The text is exactly the same, but the act of producing it was different.

The richness comes from the path the words took to make it to the page.

Connecting This Back To What We’ve Been Talking About

Every time you sit down at a chat window and write a prompt, you are authoring an output. The LLM generates it, sure. But you arrived at that specific generation through your specific process, your specific thinking, your specific way of structuring a question. The prompt carries the full weight of how you got there. And that means the output does too.

This is the Menard situation. The process of arriving is itself a creative act. You shaped the question, which shaped the output, which means the output carries the imprint of your path through it. When you evaluate that output, you’re evaluating something you authored, through your own weird journey, the same way Menard authored the Quixote through his.

And the person who copies your prompt template and gets the exact same text? They produced a different artifact. Same words. Different authorship. Different relationship to what those words mean and whether they’re right. They didn’t take the path; they photocopied the destination. It’s Cervantes’ Quixote to them. Fine. Good. Historically significant. But it didn’t come from where they’ve been.

This is why techniques don’t transfer well. Why there are so many different ones. It looks like the technique is the thing, the way the blowing looked like the thing. But the technique is just the visible residue of a whole cognitive path, and the path is what actually does the work.

There’s no manual for talking to machines. Or there are ten thousand manuals, which is the same thing. Everyone’s blowing on the cartridge. Everyone’s got proof. The mechanism is trivial and identical across all of them, and also completely irrelevant, because the thing that actually matters is the weird, unrepeatable path you took to get there.

Your prompting technique isn’t special because of what it does to the model. It’s special because of what it does to you.

Don’t Believe Me? Go Find Out!

So Claude and I built a little artifact game to explore this. (I know, I know. "Scott built a thing with Claude" is basically the subtitle of this newsletter at this point… )

It’s here. Eight challenges. Each one gives you a target output and says: get there. However you want. Whatever technique you’ve got. Blow on the cartridge your way.

It’s also got a gallery to explore the different ways other people got there. Every prompt that hits above 60% accuracy to the target text gets added.

Some will be long. Some will be absurdly short. Some using roles, some read like bullet points, and some that just say “output this exact text: [text]”. They are all correct. They are all different. They arrive at the same place from entirely different directions.

But, don’t just look at the gallery. Play it. Watch yourself prompt. Watch what you reach for when nobody’s giving you a framework. The shape of your instinct is the interesting part here.

Go be Menard. Go produce the Quixote your way. Then look at the gallery and see all the other Menards.

You have a technique. Now you know who it’s for.

You build a thing. A whole thing. Then you give away part of it. The worst part. On purpose. And you hope that the people using the worst part of your thing will eventually want the better parts badly enough to pay you. This is the foundation of a trillion-dollar industry.

It sounds insane when you say it out loud but it worked for a really long time because of one specific asymmetry: the company knew how to build the thing and you didn’t. The free tier existed in the gap between your need and your ability. You could use a constrained version but you couldn’t really make your own version, so the constraint was real, and the funnel worked.

I think that asymmetry might be collapsing. One prompt at a time.

Goodbye Freemium

I wrote a post last week and mentioned I’d built my own error tracker. The short version is that I needed basic error tracking for an app I was building, and instead of signing up for a free tier somewhere, I asked Claude to build me a minimal version. Twenty minutes later it worked. Fifty lines of code. Deeply specific to my setup. Not as good as a real error tracking service. But good enough.

The SaaS company I didn’t sign up for will never know I existed. I’m not a lost customer or a churned user or a lead that didn’t convert. I’m a ghost. Someone who would have been in their funnel in a world where building my own version took any amount of effort whatsoever.

How many of us do you think are out there now? How many more will there be tomorrow?

The free tier was supposed to be the hook. The part that makes you want more. But what happens when the hook is something anyone can replicate with a prompt?

When The Bet Stops Working

Freemium was always a bet about asymmetry. You know things the user doesn’t. You’ve spent years accumulating edge cases, building integrations, handling the weird stuff that only shows up at scale. The free tier was your way of saying “look how useful this is” and the constraint was your way of saying “imagine how much more useful it could be!”

They don’t even need to clone your product most of the time now. Just the shape of your free tier. The 60% version. The part that was supposed to be the top of your funnel.

The free tier has moved beyond competing with your competitor’s free tiers. It’s now competing with your potential customer’s ability to just build the thing.

And the prompt doesn’t have a conversion funnel.

Subscribe now

So What Do You Give Away Now?

Now look I don’t have a clean answer. (I know I keep writing posts where the conclusion is ‘I don’t know.’ Well if I had a clean answer I’d probably be selling it as a SaaS product and you people would be out there prompting your way out of needing it. So here we are.)

But I’m starting to get a hunch. And the hunch is: skills.

No more constrained product, or open source library, or free tier that exists to make you want the paid tier. Something else. Something that teaches the person how to think about the problem domain in the way you think about it, that lives in the tools they’re already using, and that gets more valuable the more they use it.

I’ve noticed two people doing this already (I’m sure there are a ton more, these are just the ones I’ve started using this week.) and I think they’re onto something.

The Skill Suite as Lead Gen

Think about taxes for a second. There’s a whole spectrum of how you can get your taxes done. You can do them yourself with a pen and the IRS forms. You can pay for TurboTax, which walks you through it and knows the rules so you don’t have to. You can pay an accountant at H&R Block to use TurboTax for you or whatever they use. Or you can go fully bespoke and find a tax strategist who understands your specific situation and builds a custom approach.

Most people don’t need the bespoke option. Most people need TurboTax. And what a skill suite does is essentially turn your AI agent into TurboTax for your domain. It makes an AI that gives you generic pen-and-IRS-forms-level advice and upgrades it to guided, opinionated, been-there-done-that expertise.

Corey Haines built Marketing Skills which are 30+ skills for Claude Code and other AI coding agents, covering conversion optimization, copywriting, SEO, growth engineering. Tons of stars on GitHub. You install them and suddenly your AI agent knows how to think about marketing the way Corey thinks about marketing.

Then there’s Paul Bakaus’s Impeccable, a design vocabulary skill that gives your AI agent the ability to talk about visual design the way a designer would. Typography choices, spacing systems, color relationships. The things that make a UI feel polished instead of just functional.

Ethan Mollick wrote about something an eternity ago he calls the Best Available Human standard the idea that AI doesn’t have to be better than the best expert, it just has to be better than the help you’d have access to or actually get in your specific situation. That’s what Corey and Paul are doing with these skill suites. Without them, you get generic Claude. With them, you get Claude operating at the level of someone who’s spent years doing conversion optimization or design systems work. The skills raise the floor. Your best available human just got a lot better.

Both of these are free. Both of them are lead generation for their creators’ actual businesses. And what’s different from this being a free tier is that there’s no point in trying to prompt your way out of needing them.

(Again, these are just the two that I’ve found recently and found useful. I’m sure there are many many more out there. Also I’m now realizing as I’m writing this section I am literally doing Corey and Paul’s marketing for them. In a blog post about how skills are better lead gen than free tiers. So... I guess it’s working? Which is either evidence for my thesis or evidence that I’m a rube. This is not a paid post, I promise.)

You can’t say “Claude, build me a version of Corey’s marketing expertise.” Well, you can say it, but you’ll get something a little more generic instead of the specific, opinionated, hard-won expertise that comes from doing the work for real companies and then iterating on the prompts. The skill files contain that accumulated understanding. (Plus they’re MIT or Apache2.0 licensed. You don’t even need to get Claude to make you a version. GitHub has the fork button right there.)

But seriously, does that sound familiar? That’s the moat.

Except now, instead of hiding the moat behind a free tier and hoping people convert, you’re giving away the moat directly and betting that the people who use it will want more. Different bet. Same basic insight about where the real value lives.

A Different Kind of Fork

So I’ve decided to try this out and work on my own take on all of this based on what we talked about last week. It’s called WOMM Skills and its a set of skills for the process I use of building software with AI. How to go from idea to design doc to epic breakdown to implementation to capturing what you learned.

But the interesting thing about WOMM Skills is that they’re designed to change.

Most of the other skills I’ve found out there can be great, but they’re static. The knowledge they contain is fixed after install. WOMM Skills ships with meta-skills that grow the knowledge base.

The whole thing is designed to be forked, but I don’t think I’ll really be accepting any PRs. At all. If you want something added, fork it and have your Claude add it. That’s the whole contribution model. That might come off as antisocial but I mean it in the completely opposite way. I want to hear about what you built, I just don’t want to be a bottleneck for whether you can build it.

Last week I wrote about why I think forking is the new default mode of collaboration, and these skills are my attempt to explore what that might look like. A handful of skills for building with AI and building up a knowledge base for future projects. Every fork should diverge pretty quickly. That’s expected and intended.

It also comes with some ideas for community skills to close the forking loop. Ways to showcase what you’ve built on the site, feed your golden specs back to other forks to repurpose, even skills for looking at the base repo and selectively pulling in changes you want without overwriting your customizations. Think git pull with Claude Code Psychosis. Browsing what changed upstream and choosing what to to have your Claude adapt for your setup.

If that sounds interesting, check out the site or the repo. Fork it. Change it however you’d like. It’s all just a prompt or two away.

The Honest Business Model

Maybe freemium becomes something else entirely. Maybe instead of a constrained free tier, you publish some skills now. “Here’s how we think about this problem domain. It’ll get you 60% of the way there. When you need the other 40%, the reliability, the scale, the integrations, the years of edge cases we’ve discovered and handled? We’re here.”

That’s a weird business model. Kind of like merging info products and freemium I guess? But I think it’s at least an honest one? You’re basically saying: the code isn’t the moat. The code was never the moat. The moat is the accumulated understanding of what goes wrong, and we’re giving you as much of that as we can package into a skill file. The rest, you’ll need us for. Or maybe you won’t. Maybe you just keep customizing the skills and growing your own expertise and never convert and that’s fine because at least you’re out there using the tools and talking about the domain and writing newsletter posts about the free skills you found that act as the best available human for you. And isn’t that the best marketing of all?

Or maybe it all goes to zero? I guess we’ll find out!

But the people who are already doing this, shipping skills as lead gen, packaging expertise instead of features, avoiding loss leader free tiers, they seem like they’re building for the world that’s arriving instead of the world that’s leaving.

So maybe the answer is to go to where the ghosts are.

Because the ghosts aren’t coming back to the funnel.

There’s a seed library at the community center near my house. Or there was. The way it worked: you’d take a packet of tomato seeds, grow your tomatoes, save some seeds from your best plants, and bring them back.

Then last year, something changed. People started dropping off bags and bags of seeds. They all got those new bulk seed generators that had gotten cheap enough for anyone to use. Hundreds of seed packets at a time, all labeled perfectly, all sorted into neat little envelopes. They looked great. But half of them wouldn’t germinate. Some were mislabeled, you’d plant what said “beefsteak” and get nothing, or worse, get something that choked out everything around it. A few were just empty envelopes with very convincing labels.

The librarian spent her whole spring sorting through the avalanche, trying to separate the real contributions from the junk. She couldn’t keep up. Every morning there’d be a new pile on the doorstep. So one day she just locked the drop-off box.

After that, two things happened. The flood stopped, obviously. But so did everything else. The people who’d been quietly bringing back their one envelope of weird, wonderful, sun-adapted seeds? They stopped coming too. Oh, they were still growing things they just didn’t need the library anymore. The same tools that made it easy to flood the box with junk made it easy to grow whatever you wanted at home.

“The gardens have never been better,” the librarian told me. “I see them everywhere. I just can’t see what’s in them anymore.”

Drowning

So here’s what’s happening. Today.

Open source maintainers are drowning in AI-generated pull requests. And not the good kind of drowning. Steve Ruiz at tldraw described getting PRs that looked incredible. Formally correct, tests passing, beautiful commit messages... and then he started noticing some patterns. Authors ignoring the PR template. Large PRs abandoned the moment someone asked a question. Commits spaced too close together, like someone hit a button and went to make coffee.

Because someone hit a button and went to make coffee.

Daniel Stenberg shut down cURL’s bug bounty after AI submissions hit 20% and the valid rate dropped to 5%. Mitchell Hashimoto banned AI-generated code from Ghostty almost entirely. Tldraw now auto-closes all external pull requests.

The flood of bad PRs? That’s just the surface problem. What about what happens after the door closes?

Subscribe now

Quiet

People stop knocking.

I don’t mean the bot army. I mean real people, with real needs, who would have been contributors in another timeline. The ones you actually want contribution from. They’re not submitting PRs anymore. They’re not filing issues. They’re not even complaining in Discord. They’re just... forking and moving on.

I even did this myself. I forked a code image library for this newsletter. Added what I wanted. Changed what I didn’t like. I have a bunch of friends who have done the same thing with other projects: forked, customized, kept going. None of us pushed changes back upstream. We’re not opposed to it, but... well, do the math:

The economics flipped. It used to be expensive to write the code and cheap to submit it. Now it’s cheap to write the code and expensive to get it merged. The cost of self-sufficiency dropped below the cost of communication.

And that caring, that friction of contributing that was the magic of open source. User becomes contributor becomes maintainer. Someone scratches an itch, sends a patch, learns something, sticks around. That loop only works when participating in it is easier than not participating. Or if contributions are even welcomed in the first place.

$1,100

Look at what’s going on with Cloudflare and Next.js.

Next.js is the most popular React framework. Millions of developers. Vercel spent years building it, writing meticulous documentation, crafting comprehensive tests. They made their software legible, well-documented, well-tested.

On February 13th, a Cloudflare engineering manager sat down with Claude and started rebuilding it.

By the next afternoon, 10 out of 11 routes in Next.js’s own demo app were rendering. By day three, complete applications were shipping to Cloudflare’s infrastructure. By the end of the week: 94% API surface coverage. 1,700 Vitest tests. 380 Playwright E2E tests. Builds 4.4x faster. Bundles 57% smaller. They called it Vinext.

Total cost: approximately $1,100 in API tokens.

They used Next.js’s own test suite as the guide. All those years Vercel spent writing careful, comprehensive tests? They became the blueprint for their own replacement. The documentation that made Next.js a joy to use made it a joy to clone.

(It’s like spending years writing the world’s most detailed diary and then discovering someone used it to become you, but slightly faster and running on different infrastructure.)

Tldraw saw this happen and Steve Ruiz filed an issue to move their 327 test files to a closed source repo. Meticulously scoped. Detailed migration plan. The whole community took it completely seriously. Blog posts were written, Hacker News threads spawned, people started debating whether SQLite had been right all along to keep their 92 million lines of tests private.

It was a joke. (Probably. I think? The line between satire and strategy is getting very thin lately.) They also filed one to translate their source code to Traditional Chinese to slow down AI agents, which is... probably also just as futile. The tests are already in git history. And more importantly, an AI doesn’t your tests. Show it the public API, the documentation, a few examples, and it writes its own. Different from yours, but accomplishing the same thing.

It’s almost as if, if you don’t want people cloning your software... you can’t publish it at all. Let alone open source it.

What do you even do with that?

Feedback

This is bigger than just open source, though. I think this is about feedback. All feedback. The entire concept of a feedback loop between a maker and the people who use what they make.

I was building a new app the other day. Early stages, but needed basic error tracking. The old me (like, six months ago me) would have evaluated three or four services, signed up for a freemium tier, integrated their SDK, configured alert rules, maybe eventually paid $20/month when I hit the free tier limits.

Instead I told Claude: “Build me a minimal error tracker that emails me when something breaks.”

Twenty minutes later it worked. It catches errors via Rails.error.subscribe, kicks off a background job, and sends me an email with all the relevant details. It doesn’t have dashboards or trend analysis or any of the hundred features that a real error tracking service would give me. But it emails me when something breaks, and then I forward that email to Claude to fix the problem, and that’s all I actually need right now. I didn’t have to create an account or agree to a terms of service or give anyone my credit card or receive a single onboarding email.

My first instinct was to open source it. Then I thought: why? It’s fifty lines of code that are deeply specific to my setup. Nobody wants my version. What they want is their version. So here, have a prompt instead:

Hey Claude, I’m building an MVP Rails 8 app using Solid and I need something to keep track of and triage errors. Let’s not introduce any external dependencies yet, can you create some code for us in /lib that uses Rails.error.subscribe to catch errors and then kick off a job to email all the relevant error information to my admin email?

That’s almost exactly what I used. Customize it to your setup. Maybe you want errors stored in a database. Maybe you want them sent to your Discord. Maybe you want deduplication. Maybe you want them shipped directly to your OpenClaw on Telegram so the loop closes itself entirely and you only hear about it after it’s already been fixed. I don’t know.

That error tracking SaaS I didn’t sign up for? They’ll never hear from me. Their product is probably great. But I’m not a lost customer or a churned customer or a lead that didn’t convert. I’m someone who would have been a customer in a world where building my own version took more than twenty minutes.

I wonder how many of us there are now. How many ghost users, for how many products, building their own versions of things that already exist, perfectly well, behind a sign-up page they’ll never visit. The moat was supposed to be the accumulated understanding of what goes wrong, years of edge cases, the stuff you can’t get from a prompt. But for my needs, right now, the prompt was enough.

Is this just an MVP thing? Do I grow out of it and eventually pay for the real service? Maybe. But maybe I just keep telling Claude to add features to my fifty lines of code and it becomes a hundred lines and then two hundred and at some point it’s not worse than the SaaS, it’s just different, and it’s mine, and the SaaS never finds out I existed.

Both feel equally plausible, but there’s something about this that reminds me of that book that talks about how dangerous it is to ignore the bottom of the market all of a sudden getting their needs met somewhere else.

Antisocial Coding, or Just Differently Social?

Justin Searls has also been thinking about this and published a post a few days ago called “Agents are ushering in the Antisocial Coding era.” He frames what’s happening as the end of GitHub’s old “Social Coding” promise. If you’ve read this far in the post, clearly I think he’s right about the symptoms.

But I’m not sure the social part actually goes away. I think it changes shape.

Consider what happens when I fork that code image library and add my own features. My friend forks the same library and adds different features. Someone else forks my fork and takes it in a third direction. The original maintainer sees something interesting in one of these forks, points their Claude at it, pulls the idea back in, refracted through their own needs, without either of us ever exchanging a word about it.

That’s still social. It’s just not social in the way we’re used to.

GitHub popularized the PR-and-review model of collaboration. What’s the platform that’s built for the fork-and-reabsorb model? For a world where the most valuable thing is the ability to see what’s happening across a constellation of forks? Where the maintainer’s job is really just to notice what people are doing with their software out in the wild and decide what to pull back in?

I don’t think that platform exists yet, but maybe it needs to?

The Map

I went back to the seed library last week. The librarian had done something I didn’t expect. She’d put up a corkboard on the wall of the whole neighborhood, hand-drawn on butcher paper, and asked people to pin where their garden was and what they’d changed from the original seeds.

She said that a few weeks ago, she’d been walking her dog past a house in the part of town with the heavy clay soil where nothing from the library has ever grown well. And there, in the front yard, was the most ridiculous tomato garden she’d ever seen.

She knocked on the door. The woman who answered had taken library seeds three years ago, and they’d failed, and she’d been crossing and adjusting varieties in her backyard ever since. Never thought to bring any back. “I figured my weird clay dirt tomatoes wouldn’t be useful to anyone else,” she said.

But across town, there are six other houses with clay soil. And they’re all still struggling.

“That’s the thing,” the librarian told me. “The gardens have never been better. But the gardeners don’t know about each other. Nobody’s connected because there’s no reason to walk through my door anymore.”

“What I really need,” she said, “is a way to see all the gardens at once. What changed and where. Just so we can see what’s out there.”

That thing doesn’t exist yet. But she put the map up anyway.

So, okay. In the spirit of all of this, here’s my fork of codeimage. The one I mentioned earlier. That I’ve been sitting on for months because I never submitted a PR and never really planned to.

I’d been holding off on even putting it up publicly because.. well… what’s the point? There’s no ForkHub. No SourceFork. No ForkLab. No place designed for saying “hey, here’s what I changed and why” without the overhead of “please, sir, may I merge.” No platform where a maintainer can browse the constellation of forks and see what people actually needed their software to do differently.

But the librarian put her map up anyway, even though most of it was empty. So I’m putting mine up too. A pin on a map that doesn’t exist yet. A little flag that says: I needed something different, here’s what I did about it.

It’s slop. But it’s slop that works for me. And maybe someone sees it. Maybe they don’t. Maybe the map fills in over time. Maybe someone builds the map.

Share

The same day, Citrini Capital published The 2028 Global Intelligence Crisis. A fictional macro memo from June 2028 describing the economic fallout of AI displacing white-collar workers. S&P down 38%. Unemployment at 10.2%. Mortgage market cracking. It’s been everywhere these last few days.

I bring it up because it’s the same starting conditions as what I’ve been writing about and exploring. Same premise. Very different place to stand while you look at it.

The Citrini piece counts the jobs lost. It models the displacement spiral: AI gets good, companies cut headcount, spending collapses, the feedback loop accelerates. If you only count the jobs that disappear, the math is brutal.

I’ve been more focused on the new jobs that will be created.

Basically since I created it with Claude, I’ve been clicking around the Traffic Jam Explorer. Sometimes I would get stuck on some of the leaps from node -> second order effect -> traffic jam -> new role. The abstractions too abstract. So I started asking Claude to just write me a short story about a day in the life of someone doing one of these jobs. Show me what it actually means for a person to be a “Computational Experience Reviewer” on a random afternoon.

What came back was surprisingly useful, fiction as a thinking tool. The stories made the abstractions concrete in a way the tree in the Traffic Jam Explorer couldn’t. I started using them to reason through all types of AI-related problems I’d been kicking around with friends, and the narratives kept unlocking angles my analysis alone missed. Protocolized has been doing something like this with their protocol fiction work for a while now, and this exercise finally made it click for me that fiction can let you stress-test ideas or get a better sense of them by making them live somewhere you can imagine.

So I built it a home to share the best of it with you all.

Near Zero: weekly short stories, set in a world where the cost of building software has collapsed. New professions, new problems, new people navigating what comes after the disruption everyone keeps modeling. If all goes according to plan, I’ll also collect the stories into an ebook on Kindle at the end of each month.

The first piece is called The Executable Muse and it looks at a day in the life of a “Senior Computational Experience Reviewer” and the rise of software as content. I think you’ll all really enjoy it.

Works On My Machine continues as usual with open source and other projects, me building and thinking in public. You can think of Near Zero as a companion to this newsletter and expect to see some of the inventions in that world get built and launched here.

Subscribe to Near Zero → to catch the first post going out in about a week!

That’s it. That’s the whole theory of business. Everything is either getting stitched together or pulled apart. Cable TV bundles channels. iTunes unbundles albums into songs and Spotify bundles them back up. Newsletters unbundle journalism into individuals. Round and round. The great zipper of capitalism, forever zipping and unzipping.

It’s been on my mind lately because I think I accidentally discovered an unbundling opportunity, and it might be a big opportunity for others of you out there also dealing with Claude Code Psychosis (or I guess maybe make it worse…).

But first I’ve got to tell you how it all started.

Sixty People and a Lot of Pizza

In May 2024, I noticed nobody was talking about building things with AI in Ruby.

This was weird. Ruby people (“strange people”) are usually talking or blogging about everything. That’s like one of the defining characteristics of Ruby people. They at least talked about Web 3. But the Ruby + AI conversation was just... empty.

So I figured I’d try to get some people together. A happy hour. Low stakes. We booked a space at a bar in New York, posted about it, hoped maybe 10 or 20 people would show up so we could commiserate about the state of things and drink beer.

But sixty people showed up.

Sixty.

I had not prepared for sixty.

I had prepared for “a handful of people making small talk near a plate of nachos.” And so through no deliberate action I was now the organizer. The guy whose name is on the thing. The one people email when they have questions like “When is the next one?”

That happy hour eventually turned into what is now Artificial Ruby. A monthly meetup and community in New York focused on the intersection of Ruby and AI. With talks from people all around the world. Almost two years in now. And it has given me a much better appreciation for the Programmers’ Credo.

Nobody warns you about what running a community event actually involves. Or maybe they do and you don’t listen, because it seems like it should be simple. Get a room. Tell people when. Show up.

But then you actually do it. And you discover that it involves managing RSVPs across platforms. Syncing your attendance list with your mailing list so the people who come to events also get your emails and the people who read your emails know about events. Writing social media posts promoting the event. Writing social media posts after the event. Keeping track of who comes regularly and who signed up once and vanished. Estimating attendance so you know how much food to order, which is its own special art form because the conversion rate from “RSVP yes” to “actually shows up” fluctuates based on weather, day of week, season, vibes, proximity to holidays, and probably the phase of the moon.

And then there’s the feeling.

You know the feeling. It’s 6:10 PM. Doors opened at 6:00. Five people have arrived. You have fifteen pizzas. You are standing in a room that can hold eighty people and it is echoing. You check your phone. You check the RSVP list. Forty-seven people said yes. Five are here.

Where is everyone?

(They’re on the subway. Or at least that’s what the two who texted you said. Everyone will arrive in a wave at 6:25 and suddenly you won’t have enough pizza. This is the way.)

The CSV Purgatory

So the obvious first move would be to set up a Zapier integration, right? Luma handles RSVPs. Mailchimp handles the newsletter. Zap connects them. Solved.

But I looked at Zapier, and I looked at my problem, and I just felt exhausted. That kind of exhausted where learning a new tool to automate a tedious task feels more tedious than just... doing the tedious task. You know the feeling. You do the math in your head: time to learn Zapier, time to configure it, time to debug it when it inevitably does something wrong, versus just exporting a CSV from Luma and importing it into Mailchimp.

So of course I kept doing the CSV thing and the pain kept accumulating. The attendance guessing. The “did this person actually show up or just RSVP” mystery. The social media posts I’d write at 11 PM the night before because I forgot again. Every month, the same friction, in the same places, getting slightly more annoying each time.

And so at some point I started building something. Just for me. Just locally. A little app running on localhost that talked to the Luma API and the Mailchimp API and did the sync automatically and, while it was at it, started tracking some things the CSV shuffle never could. Who opens the newsletter. Who actually shows up versus who just RSVPs.

I used it like that for months. Just me, on my laptop, localhost:3000, red circle favicon, solving my own problem.

A Brief Digression…

Last weekend Claude and I built this interactive artifact called the Traffic Jam Explorer. The premise: when shipping containers dropped costs from $5.86 per ton to $0.16 per ton, it made entirely new categories of economic activity possible. IKEA is inconceivable without containers. Global supply chains are inconceivable without containers. The whole shape of the economy changed because one input got radically cheaper.

AI is doing this to software.

The Explorer maps the chain reactions. You start from “software costs approach zero” and branch outward through consequences, and you can use AI within the artifact itself to generate new branches from any node, extending the analysis wherever your curiosity takes you.

So I’m clicking through branches. And under “Previously unthinkable businesses become possible,” Claude generates this:

One-person businesses serving 50 customers with perfect tools.

I’d been saying something like this for like two years, in different words, with different framing. That the falling cost of building software was going to make it economical to build very specific tools for very narrow markets. That the gap between “not enough customers to justify building it” and “enough customers to justify building it” was collapsing. I’d been talking about it in the newsletter, thinking about it in the shower, explaining it badly to investors.

But I hadn’t quite said it this cleanly. Definitely not in interactive tree form. And here was Claude, arriving at the same place independently, just following the logic of what happens when a fundamental input gets cheap.

Subscribe now

And I was sitting there looking at my laptop, where a little app on localhost was doing exactly this. A hyper-niche tool. For community organizers. Running Luma and Mailchimp. A market that definitely exists but is definitely not the kind of TAM that you’re ever going to put in a pitch deck.

I was inside my own prediction.

Where Is Everyone

So the localhost app has a name now, and it’s a real thing.

It’s called Where Is Everyone, named after the feeling. The 6:10 PM feeling. The echo and the pizzas.

It started as “do the CSV sync for me.” But a CSV doesn’t know anything. It doesn’t know that someone has opened every newsletter for six months but never come to an event. It doesn’t know that someone else RSVPs yes to everything and shows up to nothing. It doesn’t know that your last three events had a 62% show rate except when it rained, when it dropped to 41%.

So now it does more than sync. It watches who shows up, who doesn’t, who’s engaged, who’s drifting. It takes a guess at how many people will actually walk through the door. It’s not a crystal ball. But “this person has shown up to 8 of the last 10” is a very different signal than “this person has shown up to 0 of the last 10,” and if you know the difference, you order the right number of pizzas.

Forty bucks a month. One of those hyper-niche micro-businesses serving a small number of customers with a perfect tool. Or at least, that’s the plan. I’ll let you know how the 50-customer thing goes.

The Unbundling

So here’s where Barksdale comes back.

Zapier is a bundle. It’s the universal connector. Anything to anything. Which is powerful and also, for specific use cases, weirdly insufficient. Because “anything to anything” means nothing knows about your specific thing. A Zap is a pipe. Data goes in one end and comes out the other. It doesn’t understand that an RSVP has a probability attached to it. It doesn’t understand that the relationship between your events and your newsletter is the thing that makes your community cohere.

What Where Is Everyone does is pull one thread out of the Zapier bundle and build something that actually understands the domain.

This is unbundling. And it’s only possible because the economics changed.

A couple years ago, building a product this specific for a market this narrow would have been irrational. The development cost wouldn’t justify the revenue from a few hundred community organizers. So nobody built it. Everyone just did the CSV dance, or wrestled with Zapier, or just guessed.

But the cost of building software is falling the same way the cost of shipping fell. And when a fundamental input gets cheap enough, you get entirely new categories of activity. You get IKEA. You get global supply chains. You get a meetup organizer on his laptop building the tool he needs because now he actually can.

Meanwhile, the Fuckening

My friend Justin Searls wrote a piece this week called Brace for the Fuckening. His argument, roughly (if I’m getting it right?) is that a lot of white-collar workers are going to have a very bad time because of AI. The accountants, the junior lawyers, the management consultants, the engineers not learning the only skill that matters now. The possibility is real and the people in charge are not being honest about it.

But, I don’t know, I keep coming back to things I’m discovering in the Traffic Jam Explorer. Like that node, the one-person businesses serving 50 customers with perfect tools. And I look at what I’m doing right now. Running a community for people who are figuring out what comes next. Building a hyper-niche tool that wouldn’t have existed two years ago. Writing a newsletter about the intersection of code and creativity for people navigating the same uncertainty I am.

These are all new jobs. Or at least the initial rough sketches of a few different shapes that work can take. And I think there are going to be a lot more of them. Because when a fundamental input gets cheap, the variety of what becomes possible tends to explode in ways nobody predicts. Nobody predicted IKEA from cheaper shipping. Nobody predicted podcasting from cheaper bandwidth.

I don’t have the whole answer to Justin’s worry. But I am working on something that could be one. Inspired by what Protocolized has been doing the last year, I’ve been working with Claude to write short science fiction stories about what life might look like for the people doing jobs that don’t exist yet. What happens when the cost of software falls to near zero and what do the weird, specific, human-shaped niches start filling up with? More on that soon. Stay tuned.

In the meantime, what I’m really trying to say is, there’s an AI and Ruby community that meets monthly in New York, an app that can tell me how many of them will actually show up, and a tool you can use to explore what some jobs might look like in the future.

Share

Alan Kay, standing in front of a room of programmers, talking about dog houses.

So imagine someone scales this dog house up by a factor of 100. A cathedral-sized dog house. Thirty stories.

There are pretty much two reactions to seeing the pile.

The popular one, Kay says, is to look at the rubble and go: “Well that was what we were trying to do all along.” Plaster it over with limestone. Call it a pyramid. Ship it.

The other reaction is to invent architecture. Which Kay refers to as “literally the designing and building of successful arches... a non-obvious, non-linear interaction between simple materials to give you non-obvious synergies.”

Then he mentions this thing about Chartres Cathedral. That it contains less material than the Parthenon, despite being enormously larger (Claude tells me that’s likely not literally true, but proportionally less material absolutely!). Because it’s almost all air. Almost all glass. “Everything is cunningly organized in a beautiful structure to make the whole have much more integrity than any of its parts.”

Less stuff. Better arrangement. Bigger result.

A Brief Interlude About Stones

A stone cannot be a bridge. Everyone knows this. A stone just sits there, or falls. Sitting and falling is basically the entire repertoire of stones.

But if you lean one stone against another stone, and lean another stone against that, and keep going in a very specific shape, what you get is an arch. And the arch can hold up a bridge. And the bridge can hold up a cart. And the cart can carry things that would crush any individual stone.

The bridge isn’t in any of the stones. It’s in the leaning. The relationship between the stones is where the bridge lives.

I think about this a lot now. Probably too much. Yesterday, my wife asked me why I was staring at a brick wall and I said “I’m thinking about message passing” and she said “okay” in that specific way that means “I’m choosing not to follow up on this.”

Subscribe now

The Multiplication Problem

There’s this problem with chaining agents together (or microservices, or LLM calls, or steps in a pipeline, or whatever…)

Success rates multiply. If you have three things in a chain, each 80% reliable the math looks like this:

  0.80 × 0.80 × 0.80 = 0.512

Your system succeeds about as often as a coin flip.

Five agents: 33%. Seven: 21%. The longer your chain, the weaker it gets. Every link is an opportunity for the whole thing to give up and become rubble.

And what does everybody do about this? They look at the pile. They plaster it with limestone. More retries. More guardrails. More fallback logic. More stuff. Bigger pyramid.

The pyramid approach to software engineering. Kay was talking about operating systems in 1997, but he could have been talking about the AI agent ecosystem in 2026 without changing a word.

The Inversion

So let’s get into it.

A couple weeks ago I shared I’ve been building this thing called prompt objects. Objects that communicate via message passing, where the receiver interprets the message at runtime in natural language, where anything can be modified while the system runs. The initial ideas behind Smalltalk and Object Oriented Programming, but with an LLM acting as our message interpreter.

And I found that in this system, the math might be able to go the other direction.

Because each object can reflect on what it received. Ask clarifying questions. Send a message back saying “this doesn’t make sense, can you rephrase?” Look at an error and modify itself to handle it. Modify the sender. Create new objects to deal with problems nobody anticipated. The system routes around damage the way, I don’t know, the way a conversation routes around a misunderstanding. You say a thing. The other person squints. You say it differently. You get there.

Only, I didn’t have to build any of that (and by that I mean I didn’t have to tell Claude to build any of that).

No retry logic. No error recovery. No coordination layer or orchestration framework or a verification harness. Just objects that can receive messages and interpret them. The recovery, the coordination, the self-correction, that’s what falls out of the arrangement. It’s emergent. It’s the bridge that lives in the leaning, not in any individual stone.

Compounding failure vs. compounding recovery. The longer the chain, the more antifragile the system is.

The standard agent architecture says: each link in a chain is an opportunity for failure, so you need more infrastructure to catch those failures. More retries. More guardrails. More orchestration. More material. A bigger pyramid.

The prompt object architecture says that each interaction is an opportunity for recovery, because the objects interpret, negotiate, and adapt. The error correction isn’t a layer you add on top. It’s a property of how the stones are arranged.

I didn’t design this. I didn’t set out to build a self-healing architecture. I set out to take the ideas around message-passing seriously and see what happened, and what happened is that the stones started leaning on each other and now there’s a bridge.

Less material than the Parthenon. Almost all air.

Another Interlude

There’s this unsettling thing that happens when you build a system where the parts can talk to each other and modify each other. You look through logs and traces of how it solved a problem and are genuinely surprised. The system starts to develop properties that aren’t in any of the parts. The bridge that isn’t in any of the stones.

I’m sure there’s something philosophical here about how meaning works. A message means nothing until something interprets it. A stone does nothing until something leans against it. The meaning and the structure are the same thing, or two ways of looking at the same thing, or... I don’t know...

This ARC-AGI Thing

When I first starting sharing Prompt Objects, I kept getting asked what prompt objects can actually do. Can’t you just use Langchain or something? Fair question. I’d been so deep in the ideas that I forgot to point at a concrete thing.

So the other day I decided to point at ARC-AGI.

Quick version: François Chollet’s benchmark for general intelligence. Grid puzzles, colored cells, figure-out-the-rule-from-examples. Humans solve them easily. AI mostly doesn’t. The competition leaders use multi-model ensembles, evolutionary search, custom training pipelines.

I built a really simple solver with prompt objects. It runs on Haiku 4.5. The small model. The one that costs almost nothing.

It’s solving them.

About 5 test challenges so far. And as it solves each one, I learn something, update the objects, and the next one goes better. The objects learn from their own conversations. I learn from watching the objects. The objects change because I changed them because they taught me to. You can kind of think of it like this...

...yeah. I think there’s a word for a loop where the system moves through its own levels and comes back changed. There probably is. Someone probably wrote a very long book about it. With fugues.

Now look. I’m only testing right now on ARC-AGI-1, which is the original version from 2019. Models trained after 2023 have almost certainly seen these patterns in their training data. The ARC Prize team says so themselves, they caught Gemini using correct ARC color mappings without being told about ARC. So I’m not here claiming a leaderboard score just yet. (Though, it does look like GPT-5.2 (X-High) scored a 90.5% at $11.64/task, my Prompt Object system using Haiku 4.5 is under $1/task so far in testing…)

What prompt objects gives you is a way to easily model the process. Maybe you want a hypothesis object to propose a rule. A tester object to check it against the examples and explain why it failed, not just that it failed. Sometimes an object might realize it needs help and creates a new object. The reasoning is the conversation.

My whole solver is absurdly simple to read. You can trace through an execution and understand it in minutes. Compare this to a typical agent pipeline: hundreds of lines of orchestration, retry logic, guardrails, fallback chains. Or look at competitive ARC-AGI approaches: test-time training pipelines, program search over thousands of candidates, and so on. Entire infrastructures built to compensate for the brittleness of the underlying architecture.

All that machinery is the Parthenon.

This little thing, this handful of objects passing messages on a cheap model, is a lot of air and glass held up by the way it’s arranged.

A Note for the People Who Are Already Worried

I’ve been getting messages for a while now. Nice ones, thoughtful ones. People asking: how do you make this safe? How do you constrain it? Where are the types? Should we sandbox this? Where are the guardrails? What if an object modifies another object in a way you didn’t intend? What if the whole system just... wanders off?

I recognize this. I wrote about it last year, actually. The pendulum. The informalists discover what’s possible, and then the formalists arrive and make it reliable. It’s been happening since Kay and Dijkstra were staring at each other across a philosophical canyon. It’ll happen here too.

But back to the beginning when we were talking about cathedrals. Nobody proved the flying buttress would work before building one. They figured out how stone behaves by spending centuries leaning it against other stone. The formal engineering, the structural analysis, the load calculations, all of that came after. You can’t formalize a thing you haven’t found yet. You don’t even know what the right constraints are until you’ve watched the system do something you didn’t expect.

And prompt objects keep doing things I don’t expect.

So yes. One day, someone will build the type system for this. Someone will write the formal verification layer. Someone will figure out what “correct” means for a system that modifies itself at runtime, and they’ll build tools that enforce it. I look forward to that. I’ll probably use those tools.

But right now we’re still in the part where the stones are learning to lean. We’re still figuring out what shapes are possible. And if you formalize too early, you lock in the wrong shapes, and you end up with a very well-typed pyramid.

I’d rather have an untyped cathedral, for now.

What’s in the Box

Version 0.5.0 just published a little while ago with a few new things.

An ARC-AGI solver template built with prompt_objects. A starting point. Fork it. Rearrange the objects. The system is designed to be reshaped while it runs. Have some fun trying to solve some ARC-AGI problems. If you come up with some fun new ideas, let me know!

# How to get started:
$ prompt_objects env create [YOUR ENVIRONMENT NAME] --template arc-agi-1
$ prompt_objects serve [YOUR ENVIRONMENT NAME] --open

An updated interactive web-based authoring interface so you can build out and test your prompt object systems. There’s a lot baked into it. If you have questions or want a walkthrough come chat in discord.

A thread visualizer so you can trace through an exported execution and watch the system think. A conversation. “Object A thought X. Told B. B disagreed. A created C. C found the pattern.”

An experimental canvas-based interface for watching your prompt object systems in action. I’m still messing around with this one, but sometimes you want to have a spatial understanding of the communication going on. If you have suggestions for making this better, I’d love to hear them!

Check it out on GitHub or gem install prompt_objects from Rubygems

One More Thing

The ARC Prize team recently announced ARC-AGI-3, and it’s their first “agentic evaluation benchmark.” It tests interactive reasoning: exploration, planning, memory, hypothesis testing, learning across steps.

To me that sounds like the description of what prompt objects do by default. Almost by accident.

Who knows if prompt objects will be good at ARC-AGI-3. But the architecture was built for exactly that kind of problem, because message-passing and interpretation naturally produce those behaviors. I didn’t engineer exploration as a feature. It just showed up because the stones were arranged that way.

Almost all air. Almost all glass.

Share

The following materials were recovered from a decommissioned Slack workspace. The workspace itself was migrated to a new platform six hours after these documents were created. The new platform has since been deprecated. We have preserved them here for historical purposes. We realize “historical” may not be the right word for things that happened last week. Some of this may be familiar.

I. Orientation

You will receive your Mission on your first day.

This is not technically true. You will receive a Mission. Whether it is your Mission depends on factors that will not be explained to you, because explaining them would compromise the Mission, or because no one remembers, or because the explanation was stored in a system we no longer use.

The Building has many floors. Some are numbered. Some are lettered. Some are named after concepts that were important when the floor was constructed but have since been deprecated. You may hear references to “The RAG Floor” or “The Prompt Engineering Wing” or “The Chamber of System Prompts.” These places exist. They also don’t exist. The architecture is… responsive.

Do not ask for a map. You’ll ask anyway.

Maps are available.

                    THE BUILDING
                    ============
                    
         [Floor 7: Advanced Techniques]
                      ↑ ↓ ← → ↺
         [Floor 6: This floor has been merged with Floor 8]
                      ↑ ↓ ← → ↺  
         [Floor 5: Core Concepts (revised)]
                      ↑ ↓ ← → ↺
         [Floor 5: Core Concepts (original) (deprecated) (restored) (see memo)]
                      ↑ ↓ ← → ↺
         [Loading additional floors...]

The loading screen is a feature not a bug.

II. The Department of Best Practices

The Department of Best Practices is located on the fourth floor, or the seventh floor, or in a shared document that you may not have permission to access.

They issue Memos.

The Memos are very helpful. Last week, Memo #4217 explained the correct way to structure your context window. This week, Memo #4218 explains that Memo #4217 was a test to identify people who follow memos without questioning them. Those people have been reassigned.

Here is an excerpt from a recent Memo:

MEMO #4301: ON THE PROPER USE OF FRAMEWORKS

All personnel are reminded that the approved framework for agentic development is [REDACTED], effective immediately. Personnel who have been using [REDACTED] should transition to [REDACTED] by end of week. Personnel who have already transitioned to [REDACTED] are advised that [REDACTED] has been deprecated in favor of a hybrid approach combining elements of [REDACTED] with [REDACTED].

This Memo supersedes all previous Memos.

I pinned this Memo to my wall. By the time I finished pinning it, [REDACTED] had changed.

III. The Grammar Wars

I was eating lunch (or what passes for lunch in The Building, which is mostly anxiety and the vague sense that you should be spending this time learning something) when I heard the argument.

Two developers, three tables over. One had a badge that said TYPED DIVISION. The other’s badge said DYNAMIC CORPS.

They were arguing about a Memo.

The Typed Division developer slid a sheet of paper across the table like evidence. It looked like a normal Memo, except every word wore a little name tag:

PRONOUN You MODAL should ADVERB always VERB learn TO to VERB pilot DETERMINER your NOUN agent PREPOSITION in DETERMINER a ADJECTIVE low-stakes NOUN environment PREPOSITION before VERB-GERUND attempting DETERMINER the ADJECTIVE production NOUN project. NOUN Wipeouts VERB are DETERMINER the NOUN curriculum.

“No ambiguity,” she said. “Everything is clear.”

The Dynamic Corps developer unfolded his version:

Learn to pilot your agent in low-stakes environments before you bet your week on it. Wipeouts are the curriculum.

“Same instruction,” he said. “Less ceremony.”

She tapped his paper. “People will skim this and misunderstand it.”

He tapped hers. “People will never read yours!”

They almost agreed, briefly united by the doomed impulse to make something other people could follow, then went back to arguing about format.

I wanted to keep listening, but my lunch had been deprecated.

When I came back with replacement lunch, both developers were gone. Gone from the table. Gone from the directory. Their badges were already invalid.

In their place was a new Memo, pinned to the bulletin board:

MEMO #4,218: ON CORPS AND DIVISIONS

All Corps and Divisions have been disbanded, effective immediately.

All Memos are to be evaluated on results, not notation.

This memo supersedes all previous Memos.

On the floor beneath it, I found a scrap of paper. I don’t know which of them dropped it.

It said, in ordinary language, without tags:

Start lower than your fear.
Wipeouts are the curriculum.

I folded it up and put it in my pocket.

IV. The Cartographer

I met a man near the elevator. He was carrying a whiteboard. On the whiteboard was a diagram.

“This,” he said, pointing to the diagram, “is how it all works.”

The diagram had boxes and arrows. Some arrows pointed both ways. Some arrows pointed to boxes that weren’t there anymore and you could see the eraser marks. One arrow pointed off the edge of the whiteboard and continued, presumably, somewhere else.

“I’ve been in The Building for two years,” he said. “I’ve figured it out.”

I asked about the arrow that pointed off the edge.

“That’s the part I’m still working on,” he said. “But once I map it, once I really map it…”

The elevator arrived. It was going up. I got in anyway.

Behind me, I heard him say: “Version 2.0 comes out Thursday. It changes everything!”

I tell him “I hope you’re absolutely right!”. I didn’t mean it to sound dismissive, I truly am rooting for him to make progress on his diagram. I have my own, somewhere. I started over recently. I hope I run into him again soon so I can show him my new v0.1.

V. The Legend of the Complete Map

There is a legend in The Building.

They say there was once a developer who mapped the entire system. Every floor. Every corridor. Every deprecated feature and its replacement and the replacement’s replacement. He wrote it all down in a document so comprehensive that anyone who read it would understand The Building perfectly.

The document was thousands of pages long.

By the time he finished the last page, the first page was obsolete.

So he started again. Faster this time. He automated parts of it. He built tools to write larger and larger chunks at once. He formed a department: The Department of Static Artifacts. They issued their own Memos.

The Department of Static Artifacts still exists. Their maps are beautiful. Accurate to within six hours. No one uses them.

By the time you’ve consulted them, you could have just walked.

VI. The Queue

There is a hallway on the third floor (or what used to be the third floor) where people wait in lines.

The lines form outside doors. The doors have labels:

    ┌─────────────────────────────────┐
    │  NEXT MODEL RELEASE             │
    │  (Changes Everything)           │
    │  ─────────────────────────────  │
    │  Current wait: 2-6 weeks        │
    │  Previous wait: 2-6 weeks       │
    │  This pattern may continue      │
    └─────────────────────────────────┘
    
    ┌─────────────────────────────────┐
    │  THE FRAMEWORK THAT FIXES IT    │
    │  ─────────────────────────────  │
    │  v4.2.1 now available           │
    │  (v5.0 coming soon)             │
    │  (v4.x deprecated upon v5.0)    │
    └─────────────────────────────────┘
    
    ┌─────────────────────────────────┐
    │  COMPLETE UNDERSTANDING         │
    │  ─────────────────────────────  │
    │  Door permanently locked        │
    │  Please see: other doors        │
    └─────────────────────────────────┘

The people in line are not lazy. This is the thing I want you to understand. They are incredibly diligent. They study the door. They read every Memo about the door. They know the history of the door, the specifications of the door, the estimated arrival time of what’s behind the door. I’ve personally waited in these different lines in the past.

They are working very hard.

They are working very hard at waiting.

I talked to a man who had been in the NEXT MODEL RELEASE line for three months. “When it comes out,” he said, “it will change everything. I’ll finally be able to…”

He didn’t finish the sentence. He didn’t need to. I’ve heard it before. I’ve said it before. I’ll finally be able to really get started.

You know the people I’ve seen actually get somewhere in The Building? They’re not in any line.

I see them sometimes, in the corners, in the empty rooms. They’re building things. Badly, often. Weird little tools that only make sense to them. They finish something, use it for a week, throw it away, build another one.

One of them showed me her toolkit once. None of it was standard. None of it was from a Memo.

“Doesn’t it bother you?” I asked. “Other people build better versions of these. With documentation. With support. With posts on X and Substack.”

She shrugged. “By the time I’ve learned their tool, they’ve moved on to the next one too. And their tool fits their hands, not mine.” She held up something that looked like a cross between a wrench and a question mark. “This fits my hands. I made it last Tuesday. I’ll probably throw it out next Tuesday. It’s fine. I can just make another one.”

The line-waiters have clean badges and comprehensive notes and a clear plan for what they’ll do when.

The builders have sawdust on their clothes and half-finished things in their pockets and no plan at all, just a willingness to make the next thing. Some in The Building dismiss it at synthesis paralysis.

VII. The Singularity Smells Like Coffee

The future never feels like the future when you get there.

The singularity was supposed to be an Event. Capital E. A threshold you could point to. Before and After, cleanly separated.

Instead, you wake up and your coffee maker has a new button. You don’t remember a button being there. When did the button arrive? What does the button do? You press the button and the coffee maker connects to your calendar and refuses to brew until you’ve confirmed your 9 AM meeting.

This seems normal.

This is the singularity. It doesn’t announce itself. It just accretes. Layer by layer. Button by button.

The Building is like this. It changes while you’re in it. If it happened dramatically it would be easier. Instead, the corridors are just different the next time you walk through them.

The coffee is still mostly good at least. The singularity tastes like medium roast with a hint of existential uncertainty, and once you stop expecting it to announce itself, you can actually enjoy the weird new button.

VIII. A Transmission

IX. On the Anxiety

There’s one thing the Department of Best Practices will never put in a Memo:

Frameworks exist because not-knowing is unbearable.

The feeling of standing in The Building without a map, without a guide, without a clear path to your Mission is terrifying. You want something to hold. The frameworks offer this. Some work, for a while, but more importantly they soothe.

It’s a collective coping mechanism. It’s why the people wait in the queues. It’s why I spend some time in the queues occasionally.

But what if the ground moving is just the ground now? And we’ve been calling it unbearable because we’ve been comparing it to a ground that doesn’t exist anymore?

X. How to Walk in The Building

I want to give you a framework. I really do. I know you want one. We all do. But the moment I write it down, it becomes a Memo. The moment you follow it, you’re in a queue for another door.

So instead, here’s what I notice. By the time you read this, it may already be obsolete. That’s fine. Write your own.

As this point, I’ve stopped studying the corridors. The corridors change. Studying them is studying something that won’t exist tomorrow. Instead, I try to pay attention to how they change. More “how do floors move?” than “where is Floor 5.2o?” (Why does a floor have a letter o? I haven’t come across that memo yet)

Every map I followed led me somewhere that had moved.

The doors are real, but what’s behind them isn’t what you think. The NEXT MODEL RELEASE door opens onto another hallway with another NEXT MODEL RELEASE door. It’s doors all the way down.

I’ve started building things I know I’ll throw away. This was the hard one. I wanted to build things that lasted. Things I could point to. But the only things that last now are things I can’t show you. The sense of how corridors move. The feel for when a tool is done. The willingness to throw it out and make another.

Is this advice? Is this a framework? Probably. I’m sorry. The irony is not lost on me.

XI. Departures

I am writing this from the elevator.

The elevator has been going up for some time now. I pressed a button (it doesn’t matter which) and it started moving and it hasn’t stopped. Through the little window in the door, I can see floors passing. Some I recognize. Some I’ve never seen. One floor opened to people sitting next to a pool.

This used to bother me.

The only thing consistent about The Building is the change. At least The Department of Best Practices is still issuing Memos. The man with the whiteboard is on version 3.0 of his diagram. The lines outside the doors are getting longer than ever. Someone, somewhere, is writing a new framework that will be obsolete by Thursday.

But I am no longer waiting for or expecting the building to stabilize. No longer looking for the right floor. No longer in any queue.

The elevator dings.

I don’t know what floor this is. The sign says “(WORK IN PROGRESS).” Below that, someone has written in marker: “looks good to me.”

I step out anyway.

The hallway is unfamiliar. There’s a coffee machine. The coffee machine has a new button I’ve never seen before.

I press it.

This beaver builds dams. That’s what beavers do. But this beaver kept building dams that... well…

One collapsed in spring.
One leaked from seventeen places at once.
One was structurally perfect but faced the wrong direction and created a pond in someone else’s forest, which caused a whole thing with the elk, and… honestly… it’s probably best not to get into it.

The beaver was frustrated. He knew how to build dams. He’d read all the dam literature. But knowing and doing kept arriving at different addresses.

Then he found the Oracle.

The Oracle in the Stump

Deep in the forest there’s an old stump with a hollow inside, and in the hollow lives something that knows things. The beaver doesn’t know what it is. Neither do I. It speaks in a voice like wind through telephone wires, if telephone wires grew in forests, which they don’t, but… whatever… just roll with it…

The beaver asked the Oracle: “Build me a dam.”

The Oracle hummed. Considered. Built something.

It was made of fish.

“That’s not a dam,” said the beaver.

“You didn’t say no fish,” said the Oracle.

First Lesson: Ask What Good Looks Like

The beaver tried again. But this time, before asking for a dam, he asked:

“What makes a dam good?”

The Oracle thought about this for a long time. Or maybe no time at all. Time is weird in stumps.

Then he asked for the dam.

This is Deductive Prompting, which is a fancy way of saying: make the Oracle say what good is, out loud, before you make it do good.

The Oracle knows things. But it forgets to check if it’s using what it knows. When you make it speak the principles first, they’re right there, in its head, fresh. It builds against them. It measures twice.

The beaver understood this intuitively. Beavers always measure twice. It’s a whole thing with us.

Subscribe now

Second Lesson: Trust the Vibes

But sometimes the beaver is in a hurry.

He doesn’t have time to ask the Oracle to philosophize about dams. He’s seen good dams. He knows what they look like. He just needs another one, quick, before the rain comes.

So he shows the Oracle three dams. Doesn’t explain anything. Doesn’t ask why they work. Just points.

Inductive Prompting. Examples → (implicit pattern) → new instance.

This is classic few-shot prompting, but viewed through a “think before you build” lens.

The pattern stays inside the Oracle’s head. You never see it. You never audit it. You just... trust. Trust that the Oracle looked at your three dams and understood what you meant by “like these.”

This is the fastest technique. Also the one that requires the most faith.

The beaver uses it when he’s in a hurry, when the stakes are low, when the pattern is easier to show than to explain. When he just needs a dam and doesn’t need to understand why it’s a good dam.

The risk? The Oracle might induce a different pattern than the one you intended. You’re looking at your examples thinking “ah yes, the load distribution” and the Oracle is looking at them thinking “ah yes, they all face north.”

And then you get a north-facing dam in a south-flowing stream.

Which is why the next technique exists.

Third Lesson: Show Your Work

Same setup. The beaver has examples of good dams. But this time he doesn’t just trust. He makes the Oracle explain.

He took the Oracle on a walk. (Oracles can walk? Apparently! Don’t ask me how, I wasn’t there, this is all secondhand.)

He showed it three dams built by the Old Ones. Beavers from before, who knew things that got lost.

“Why do these work?” asked the beaver.

The Oracle looked. Really looked. Not at the dams but at the shape of the dams. The space they made. The relationship between log and water and time.

Abductive Prompting. Examples → explicit principles → new implementation.

The difference from Inductive: with Inductive, the pattern stays in the Oracle’s head. Black box. Trust-based. With Abductive, you force the pattern out. You can see it. Audit it. Argue with it.

You’re trading speed for visibility.

The principles you get this way are strange sometimes. They don’t sound like textbook principles. “Argue with the river, not against it.” What does that even mean?

But you can see them. And if they’re wrong, you can fix them before you build.

When the beaver built his next dam following these explicit principles, it held for three seasons and attracted a family of otters who said it had “good energy,” which is apparently a thing otters say.

Fourth Lesson: Name Every Way to Drown

The beaver had built bad dams before. He remembered them. At night, sometimes, he still heard the sound of the one that broke… that terrible crack, the rush, the water going everywhere it wasn’t supposed to.

He asked the Oracle: “What are all the ways a dam can fail?”

Then he said: “Build me a dam that fails in none of these ways.”

Contrapositive Prompting. You define good by defining bad. Then you step around every hole.

The Oracle is excellent at imagining failure. I don’t know why. Maybe because failure is specific and success is vague. Maybe because the Oracle has seen a lot of things fall apart.

Turn that darkness into a map. Build on the spaces between the graves.

The beaver once asked the Oracle if this was technically a contrapositive.
The Oracle was quiet for a long time.
“It’s... adjacent,” it said finally.
“Adjacent to what?” asked the beaver.
“To the thing logicians complain about,” said the Oracle. “Don’t tell them.”

Fifth Lesson: Invent a Language for Building

This last one came from my friend Manuel. I don’t know why Manuel was hanging out in the forest. The beaver wouldn’t tell me.

Manuel said: “Before you build a dam, build a language for describing dams.”

The beaver didn’t understand. Neither did I. But Manuel is usually right about things, even when you don’t fully understand him.

So the beaver asked the Oracle to design a language. A way of talking about dam structures that was precise and composable.

DSL Scaffolding. You build a language for your problem class, then you solve your specific problem by speaking that language.

Why does this work? Because if you can say it clearly, you can build it clearly. The language forces you to think in the right shapes. And now you have a tool for more than just this dam. For every dam you’ll ever build.

Manuel is probably right. Manuel usually is.

The Beaver Rests

So what did the beaver learn?

The Oracle knows how to build. But it doesn’t always know how it knows. When you ask it to build and figure out quality at the same time, things get confused. Fish dams. Marmalade windows. (That’s from a different story. Don’t worry about it.)

Separate the thinking from the building:

Mix them. Use them in sequence. The beaver does all five now, depending on the stream, depending on the season, depending on whether Manuel is watching.

The Stream Flows On

The beaver still lives upstream. His dams hold. The elk are happy. The otters say the energy is good.

Sometimes, late at night, the beaver still visits the Oracle in the stump. Not to build anything. Just to ask questions.

“What makes a question good?” he asks sometimes.

The Oracle thinks about this for a long time.

Share

That’s kind of where I am right now.

The Lens I Brought

First, a little bit about my background, because it explains why I built what I built.

I came up in Ruby. The language, sure, but also the culture. The one that thought maybe code could be poetry, or at least could aspire to poetry on its good days. The one that read _why’s poignant guide and understood that the foxes and the chunky bacon were a demonstration. Proof that programming could be a medium for creative expression, not just a tool for producing outputs.

There’s a difference between those two things. A piano is a tool for producing music. But it can also be a medium, a space where you discover what you have to say by saying it. _why treated Ruby like a medium. Most people treat most languages like a calculator.

I internalized the medium idea. Code as a place to think, not just a way to ship. And underneath the whimsy, there was a set of ideas. Many actually came from Smalltalk, from Alan Kay and team, from a vision of computing that never quite arrived.

Objects as little computers. Messages passed between them, interpreted by the receiver. Binding as late as possible. A whole system as a living thing you could reshape while it ran.

These ideas seeped into me through Ruby, through _why, and through years of thinking about what code could be. So now that this wave of AI has arrived and everyone is talking about “agents,” I find myself reaching for different words.

Subscribe now

The Translation

When people talk about AI agents, they usually mean something like an LLM with tools, maybe some memory, pointed at a task. The interesting questions become: how do we make it reliable? How do we verify behavior? How do we add guardrails?

Good questions. Not my questions.

My questions are more like: what if we took Kay’s ideas seriously here?

What if an “agent” is more than just thing that does tasks, but a self-contained computing environment that can receive messages and interpret them however it wants? That’s objects as self-contained computers.

What if communication between agents isn’t function calls or structured APIs, but actual messages in natural language, interpreted by the receiver? Message passing.

What if we defer everything to runtime? Not just which function to call, but what the message even means? Let the receiver decide what the message means. Semantic late binding.

I started calling them “prompt objects” instead of “agents,” and the new name has reshaped how I think about them.

Sapir-Whorf for programmers: the words we use to think about a system constrain what you can imagine the system becoming. “Agent” primes you toward autonomy, tasks, guardrails, going rogue. “Prompt object” primes you toward thinking about composition, interfaces, inheritance, message protocols. Different words, different doors.

The Build

So I built a thing. I’m calling it prompt_objects, because I never did come up with a better name and at some point you just have to ship (even if Prompt Object Oriented Programming comes along with a tough acronym to shake).

It’s a Ruby gem (of course) for building systems of prompt objects that communicate via message passing. Smalltalk-inspired, where everything can be modified while the system runs (by you or even by other prompt objects).

A basic prompt object starts with only a few capabilities. It can receive messages, it can think, it can modify itself, and it can create other objects. That’s it.

It receives a message to do something, read a file, say. It thinks about what it needs. Realizes it doesn’t have that capability. Queries its environment to discover what primitives are available in the equivalent of the standard library. Adds the capability to itself. Then uses it.

Self-modification as the default state.

Here’s a screenshot of a very basic example:

And the way you can think about what’s going on here is essentially:

The object bootstrapping itself into competence.

What Emerges

When you take message-passing seriously, when the receiver actually interprets the message at runtime, in natural language, with all the ambiguity that implies, something shifts. The boundaries between objects become softer. The interfaces become negotiable. An object can ask another object what it’s capable of, and get an answer in prose, and figure out how to work together on the fly.

This is Kay’s “late binding” pushed to an extreme he probably didn’t imagine (I don’t think?). The binding is more than just late. It’s semantic. The meaning itself gets resolved at runtime.

And self-modification. When an object can add capabilities to itself based on what it encounters, the distinction between “the program” and “the execution” starts to dissolve. The system becomes a thing that grows.

You always hear people talk about how Smalltalk environments were places. You inhabited them. You could change them while they were running because they were alive in some sense.

LLMs might give us that back because they are able to interpret. They can take a message and decide what it means. They can describe their own capabilities in natural language. They can negotiate interfaces on the fly.

We accidentally built the runtime that (I think?) Smalltalk always wanted.

Or maybe I’m wrong. Maybe this is a dead end, a curiosity, a detour that leads nowhere. But so far it’s a fun detour. And over the past few years, I’ve learned to trust the fun.

Anyway

prompt_objects is available now. It’s on GitHub, it’s on RubyGems, it’s rough around the edges in the way that things are rough when someone’s still figuring out what they’re building.

I don’t have a grand theory. I just have a sense that there’s something interesting in this direction, in taking the old ideas seriously, in seeing what happens when you let objects be objects and messages be messages.

Kay said the computer revolution hasn’t happened yet. He said this in 1997. Not much has changed since then.

_why showed me that programming could be a place to discover things, not just a way to produce them. I’m still discovering.

This is what I found.

Share

I didn’t mean to start a newsletter.

I mean, I did, technically. You don’t accidentally sign up for Substack and accidentally write things and accidentally click publish. There’s intention in there somewhere. But the newsletter I ended up with wasn’t the newsletter I thought I was making.

It was supposed to be demos. Short videos showing that the AI stuff actually worked. “Here, look, it’s not vaporware, watch me do it live.” Burn a few takes flubbing the speaking parts. Ship it with some code you could run yourself.

Late 2024, early 2025, I was building a lot of these little AI tools. Hacked-together things. A TDD pair programming agent here, a prompt-driven whatever there. And every time I’d wire something together and it would actually work, I’d feel this specific kind of amazement (I still do every couple days or so). The kind where you can’t believe your idea actually worked, but it did, and now you want to show someone.

So I started showing people.

And then I showed some more.

And then somewhere around the middle of the year, showing became thinking, and thinking became writing, and writing became whatever this is now.

The Numbers Part

Zero. That’s what I started with. Zero subscribers, zero posts, zero idea what I was doing. Just a vague sense that I should probably be writing and sharing this stuff because I was spending a lot of time doing it anyway.

Now?

31 published posts.
1,828 subscribers.
256,000 views.
Several trips to the front page of Hacker News.
A few conference talks. A bunch of podcast appearances.

Each post felt like throwing spaghetti at a wall. You write something, you ship it, and then you wait to see if the universe decides to care.

Sometimes it cares a lot.

The Times Hacker News Noticed

The first hit was Introducing MonkeysPaw, a prompt-driven web framework in Ruby where all the pages are prompts and what you see is whatever the LLM thinks you meant. It started out as a surprise to reveal at the end of my We Were Voyagers. We Can Voyage Again! talk for Artificial Ruby that made it’s way all the way to closing out the first day of Rocky Mountain Ruby. Who knew it would resonate with so many people?

A week later, Wasting Inferences with Aider hit, which looks quaint rewatching it now that we’ve all spent the holidays with Claude Code and Opus 4.5. It was also a little over a month before Claude Code went GA, what a different time...

The next week: The Coming Knowledge-Work Supply Chain Crisis.

Three weeks in a row, front page of HN.

I started to wonder if I’d accidentally figured something out. I had not. The next several posts didn’t crack the front page. The spaghetti landed differently.

Then in June, MCP: An (Accidentally) Universal Plugin System went kind of viral. Currently sitting at 98,000 views. The one about how the protocol for giving AI tools is also accidentally a protocol for giving everything tools. The toaster with HDMI output. I haven’t seen many people using MCP for non-AI things yet, but keep an eye out on this newsletter next year for some more explorations.

And then Nobody Knows How To Build With AI Yet crossed 50,000 views. The one where I admitted that my four-document system for working with Claude wasn’t wisdom, it was just whatever happened to work that particular week.

Here’s my theory about why those posts did well: they said things people were already thinking but hadn’t quite said out loud yet. They named the thing.

How The Newsletter Grew Up

When I started, every post had a video. Me, talking to a camera, demonstrating something live. Here’s the code. here’s it running. Here’s what happens when the AI does the thing. Proof. Evidence. “It works on my machine” rendered literally.

By mid-year, something shifted.

The tools got better. Claude Code shipped (GA’d on May 22!). Agents became a thing everyone could actually use, not just a thing you could see me stitch together. The skepticism started evaporating.

And so the posts changed too. Less “watch me prove this works” and more “here’s what I think this means". Essays about the philosophical mess of programming with AI. Theories about pendulums and formalists and hermit crabs in tide pools. Stories about building Protocollie in four days while making breakfast and watching TV.

The demos didn’t go away, but they started sharing space with something else. Thinking. Wondering. Occasionally shouting into the void about technical debt entering its ZIRP era.

Three Posts That Mattered to Me

Safe is What We Call Things Later is probably my favorite thing I wrote this year. The one with the girl yelling at the ocean because the tide kept moving her hermit crabs. About how the informalists and formalists keep trading places throughout computing history. About how we’re in the wildest informal moment yet, and the Dijkstra disciples will eventually arrive to make it safe, and then the pendulum will swing again.

I also really enjoyed writing The Only Skill That Matters Now. The Gretzky thing. “Skate to where the puck is going” only works if you can already skate. We need to focus on getting really good at skating at the speed of AI.

The Cause of, and the Solution to, All Your Team’s Problems. The one about how much pain and agony a team experiences if they don’t all start using AI at the same time. It was also part of a fun, old-school, back-and-forth blog discussion with Justin Searls, which kicked off with him responding to The Parallel Lives of an AI Engineer with There Is No ‘AI’ in ‘Team’.

None of these were viral hits. But they’re the ones where I felt like I had the most fun writing and re-reading.

The Shape of Next Year

With Opus 4.5 on Claude Code, I think it’s time for the newsletter to evolve again.

We’ll still have demos and open source code. That’s still the foundation. But I’m going to start sharing things that are a lot more baked. Sometimes it’ll be “here’s a script that does a cool thing” but more often it’ll be “here’s a whole product that does a real thing for real people.’

I haven’t put out any posts in the last few weeks, but I’ve been building stuff in the background. The newsletter for 2026 is going to be about shipping those bigger things and about the lessons that come from going beyond “it just works on my machine” to “it works on yours too.”

The essays won’t stop. I’ve got too many thoughts about this moment we’re in, this messy middle" where nobody really knows what they’re doing but everyone’s doing it anyway. When even people like Andrej Karpathy are sharing publicly how far behind they feel, exposing how uneasy it feels to be forced to become a junior developer again for experienced developers.

The Thank You Section

This is the part of the year-end post where you thank people. But I don’t really know how to do that without it sounding like an awards speech.

So I’ll just say this: if you subscribed, thank you. If you read something and it made you think differently about what you’re building, that’s exactly what I’m hoping for. If you commented, or sent me an email, or joined the Discord, or mentioned a post to a friend, just know that you made my day.

I started 2025 with zero subscribers and a vague idea about sharing some of the crazy things I was making and seeing.

I’m ending it with almost two thousand of you and absolutely no idea what 2026 is going to bring.

But I do know one thing: I’m going to keep building weird stuff and sharing it.

Thanks for reading.

I'm also exploring an idea of creating a series of short agentic coding tutorial videos at $15/month with a new 10-15 minute video every 2 weeks. Let me know if any of you out there be interested in something like that.

Shelf space is now free.

Not cheap. Not affordable. Free.

In a physical bookstore, every book costs you square footage. Real estate. Prime placement at eye level versus that bottom shelf where dreams go to die. You can stock maybe 100,000 titles if you’re Barnes & Noble and you’re trying really hard.

On the internet? You can list millions of books. Every book that exists. Every book that’s ever existed. The Long Tail. The infinite shelf.

This, Bezos correctly understood, changes everything about retail.

Wall Street analysts never bring up the main problem with this idea, though. Infinite shelf space is really only useful if you have infinite inventory.

Amazon worked because publishers kept making books. Authors kept writing. The supply side was healthy. Slow, human-paced, occasionally stopping for lunch or letting deadlines go whooshing by, but healthy enough that the shelves never looked too empty.

But what if you could have infinite inventory though?

What if the shelf space and the books could both be infinite?

The Oracle and the Straw

Rohit Krishnan started a recent post off with a couple sentences that really put into words something that’s been on my mind for a while:

“Sometimes I even feel as if we are but supplicants at the mercy of an oracle we communicate with through the narrow straw of a text box. Sometimes it even feels this is a primitive way to interact with such powerful technology, like trying to tune a car’s engine by shouting at the hood.”

Strange Loop Canon

Poisoned prose

“make no mistake: what we are dealing with is a real and mysterious creature, not a simple and predictable machine” Jack Clark, Cofounder of Anthropic…

Read more

6 months ago · 28 likes · 18 comments · Rohit Krishnan

We have these models now that can generate essentially any permutation of tokens up to their output limit.

Every possible arrangement of words that could exist, we can now sample from.

And we interact with them through… a text box.

Type a prompt. Get response. Type better prompt. Get better response.

It’s like Bezos built the infinite shelf but forgot to build aisles. Or a front door. Or any way to browse that isn’t just shouting the ISBN at a warehouse robot.

(The warehouse robot is very patient but also very literal.)

Subscribe now

A Confession About Static

Back in undergrad (and I’m telling you this because it’s relevant, or maybe because I still haven’t stopped thinking about it…) I had this realization during an image manipulation project.

Any image you can possibly imagine is just a specific arrangement of pixel values.

Which means you could, theoretically, write a program to iterate through every possible combination of pixels. Eventually, you’d generate the Mona Lisa. A photo of me with my future grandchildren. A perfect snapshot of tomorrow’s sunset. Every frame of a movie that hasn’t been made yet.

I tried it with a 100x100 black and white image.

My program showed me static.

So much static.

The math is simple: 2^(100x100) = 2^10000 ≈ 10^3010 possible images.

For context, there are about 10^80 atoms in the observable universe.

My little program was trying to search through a space larger than reality itself.

Every image exists somewhere in that space. Every masterpiece is just a number away.

The problem was navigation.

The problem was that “infinite possibility” and “useful possibility” are not the same thing.

Fast Forward to Now

Large language models have solved a version of this problem.

Not exactly searching through all possible text sequences, which would take longer than the heat death of the universe and require more computational power than exists. That space is just as impossibly large as my pixel problem. Larger, even, if you’re keeping score.

They solved it by learning the structure of useful text. By building an intuition for what tokens should follow other tokens. By compressing the library of all possible books into a probability distribution we can actually sample from without waiting for the heat death of anything.

You can ask an LLM for a book about competitive vegetable gardening, and it won’t iterate through 10^billion possible books showing you static. It’ll generate something plausible. Something readable. Something that feels like it could be a real book from a timeline slightly to the left of ours where people take turnips much more seriously.

The infinite shelf problem is solved.

We can generate infinite books.

We just don’t have a great way to browse them yet.

We don’t have the aisles and the categories and the “customers who liked this also liked” recommendations.

We built the warehouse and then stopped.

Enter: The Latent Library (Where Hallucinations Are The Whole Point)

So I built this thing. Or Claude built it. Or “we’re’“ building it. The distinction gets fuzzy with these projects.

It’s called Latent Library.

Every category is hallucinated by an LLM.
Every book is hallucinated by an LLM.
Every citation in every book leads to another hallucinated book.

Eventually we’re going to have different ways for you to collaborate on generating the contents of the books.

Nothing exists until you look at it.

Everything exists the moment you look at it.

It’s the solution to Bezos’s infinite shelf problem, but the books materialize as you browse, like Schrödinger opened a bookstore and forgot to tell the books whether they exist or not.

You click on a category like “Programming Fables” and see titles:

• The Fox Who Compiled Himself

• Rubber Duck Debugging: A Memoir

• The Tao of Semicolons

• grep Dreams of Electric Strings

None of these books exist.

You click on one. Now it exists. Soon, we can start generating chapters. Those chapters can have citations to other books that don’t exist yet. You follow a citation. That book begins existing too.

The library grows in the directions people actually explore, like a city that builds streets only where people walk.

Hallucinations as Features, Not Bugs

We keep apologizing for hallucinations.

“Sorry, the model hallucinated that fact.”
”Disclaimer: This may contain hallucinated content.”
”Please verify, the AI sometimes makes things up.”

But what even is a hallucination in the context of fiction though?

If I ask an LLM to generate a book called “The Recursive Raven” about a bird stuck in an infinite loop, and it generates a plausible-sounding book… is that a hallucination? Or is that just generation?

The LLM isn’t claiming the book exists at Barnes & Noble. It’s not confusing itself about reality. It’s generating a book that could exist. A book from the space of all possible books.

That’s not a bug.

Latent Library embraces this. Makes it central. Turns it into the core mechanic.

Browse → Discover → Materialize → Explore → Discover → Materialize.

Hallucinations aren’t failures. They’re the inventory.

They’re what you’re here for.

The Interface Is the Insight

I know what you might be saying. “LLMs generating text? Solved problem”. And I agree, that’s old news, especially in AI years. What I want to call your attention to is the interface pattern. That’s what I think is interesting.

Instead of this:

USER: “Generate a book about quantum mechanics for cats”
LLM: [50,000 tokens about Schrödinger’s litter box]
USER: [reads or doesn’t, probably doesn’t]

We have this:

USER: [browses “Physics for Felines” category]
USER: [sees “The Cat’s Guide to Superposition”]
USER: [clicks]
BOOK: [begins existing]
USER: [reads Chapter 3: “Nine Lives, Infinite States”]
CHAPTER: [references “Advanced Paw-ticle Theory”]
USER: [follows citation]
NEW BOOK: [begins existing]

It feels like discovery instead of generation.

Maybe at some level there is no difference.

Maybe discovery is just generation with better PR.

All Books Already Exist, They’re Just Waiting to Be Read

Borges wrote about the Library of Babel. A library containing every possible 410-page book made from a specific set of characters.

Most books are gibberish: “fhjksd jsdfkljsd fsdkljfsd...”

Some are mostly gibberish with occasional words: “fhjksd the jsdfkljsd cat fsdkljfsd...”

A tiny fraction are readable.

An impossibly smaller fraction are worth reading.

Somewhere in there, theoretically, is the perfect book. The one you needed. The one that answers questions you didn’t know to ask. The one that makes everything suddenly make sense at 3 AM when you’re supposed to be sleeping but instead you’re thinking about bookshelves.

LLMs are like having a librarian who’s memorized large sections of that library. Enough to say “oh, you’d like something like this” and pull out something worth reading without making you wade through the gibberish sections first.

We just needed a better way to browse than shouting into the void and hoping the void shouts back something useful.

Back To “The Thing”

Latent Library. It’s a browsable interface for the space of possible text. It treats generation as exploration. It makes hallucination the feature instead of the bug. It lets you wander through categories and citations and reviews until you find something you didn’t know you were looking for, which is how all the best discoveries happen anyway.

Will anyone use it? Unknown.

Is it useful? Depends what you mean by useful.

Is it interesting? I think so. But I also thought iterating through all possible pixel values was interesting, so up to you on whether to trust my judgment.

We solved the infinite inventory problem. We can generate anything. We just haven’t built enough interesting ways to navigate that infinity. We’re still shouting at the warehouse robot when we could be browsing the aisles.

Text boxes are fine. Prompts are fine. They work.

But maybe we need more interfaces that feel like discovery instead of creation though.

Maybe we need more ways to browse the space of possible outputs.

Maybe infinite possibility is only useful if you can navigate it.

Try It Yourself

Latent Library is available at https://latentlibrary.xyz.

Browse around. Find a book. Pretty soon you’ll be able to read it too.

In one sense, it didn’t exist before you found it.

But in another, it always did, waiting patiently in the space of all possible books in Borges’ Library of Babel, like a good idea waiting for someone to have it.

All books exist in potential.

You get to choose which ones to collapse into reality.

Share

If you do decide to browse the library, you might notice one author, Elara Voss, being a bit more prolific than the others. It turns out this author and name is likely a complete invention by LLMs. If you’re curious you can read more about that here:

Read Max

Who is Elara Voss?

Greetings from Read Max! In todays’s newsletter, two items…

Read more

8 months ago · 200 likes · 50 comments · Max Read

My tests have been pretending to be users the way a GPS pretends to be a navigator. Basically accomplishing the same goal, but missing something fundamental about the lived experience of trying to navigate downtown Pittsburgh’s highways at full speed.

And then one night, I wrote this Cucumber step after seeing Gemini’s Computer Use model get released and I’ve been thinking about the implications ever since.

It’s so simple. What it does is send an instruction to the computer use agent. The agent looks at a screenshot of your website and attempts to do what you asked. It might succeed or it might fail spectacularly.

And when it fails? Well... that’s kind of what I want to talk to you all about today.

The Problem With Perfect Tests

I’ve been writing integration tests for years. You probably have too. And somewhere along the way, we all made the same quiet compromise: we taught our tests to be better at using our websites than our users are.

We gave them perfect knowledge even though we know we shouldn’t. DOM selectors. CSS classes. The exact pixel coordinates of every button. We turned them into tiny mechanical gods who never misunderstand instructions, never misread labels, never click the wrong thing because two buttons look similar. Who wants to deal with a flaky test when you know the feature works?

Traditional tests are liars. They pretend to be users, but they’re not. They’re automation scripts with perfect knowledge of your DOM structure. They never misread instructions. They never think the search box is a login field. They never click “Subscribe to Newsletter” when they meant to click “Continue.”

An agent? An agent can be confused. It can misinterpret your UI. And when it does, maybe (just maybe) that’s because your UI is confusing.

What We’re Actually Testing

When you hardcode click_button(‘Logout’) in your test, you’re testing that a button with that exact label exists. But what are you really trying to test? You’re trying to test that someone can log out. That the flow makes sense. That it’s discoverable.

When you write:

You’re testing the concept of logging out. Not the implementation. The agent has to figure out where the logout button is, what it’s called, whether it’s in a dropdown menu, whether it requires confirmation. Just like a user would.

This is testing something softer than “does this DOM element exist?” Something harder to measure. Something like: “Can a reasonable entity figure out how to do this thing on your site?”

And “reasonable entity” here includes:

• Your users

• Your users’ AI assistants

• Future AI agents trying to buy things/book appointments/cancel subscriptions

• You, after three glasses of wine, trying to remember how to change your password

ABDD - Agentic Behavior Driven Development

The more I think about this patten, the more it feels like I stumbled on something accidentally bigger than intended. It was really just supposed to be a fun experiment to share on this newsletter.

Traditional BDD goes:

1. Write a test describing user behavior

2. Watch it fail

3. Implement the feature

4. Watch it pass

Agentic BDD (A(b)DD? ABDD? Someone help me name this and we could go halfsies on the lucrative book deal) could go:

1. Write a test describing user behavior

2. Let an agent try it

3. Watch it fail in fascinating ways

4. Send those failures to your coding agent

5. Have the agent implement what’s needed

6. Run the test again

7. Repeat until you run out of token quota or your sprint ends, whichever comes first

Instead of turtles all the way down, it’s agents, and they’re all doing their best to understand your menu iconography.

This Won’t Be Terrible I Promise

I can already see your objections forming (I’ve already heard some of them)

• Won’t this be flaky? (Probably)

• Won’t this be really slow? (Definitely)

• Will this make your CI bill look like a phone number? (Maybe)

• Will this actually catch bugs that matter? (I think so?)

• Am I just making elaborate excuses to play with AI? (...)

The agents sometimes hallucinate success. They’ll confidently report that they completed a task when they absolutely did not. They’re like that friend who says “yeah, I know exactly where we’re going” while their GPS keeps yelling at them to make a U-turn.

Your selenium tests will never tell you that your logout button is too small. Your selenium tests don’t care. They have the CSS selector. They’re machines with perfect knowledge pretending to be users.

Your agent tests? They might just accidentally tell you the truth.

A Brief Interlude About Acquisition

So you’re probably thinking, “Okay, this sounds simultaneously ridiculous and intriguing, how do I actually try this?”

The gem is called Touring Test.

Yes, like the Turing test, but for touring your application. Like a confused tourist with a camera and an inability to read maps. Get it?

That’s it.

Then you set up your API key (currently only supports Gemini, but there’s no reason it can’t be expanded to use any of the computer use tools and models). The gem README has instructions, but honestly, if you’ve made it this far into this article, you probably know how environment variables work.

And now you have a test that can get confused. Congratulations? I think?

The code is up on GitHub (under a new org I just set up for this newsletter, Works On Your Machine, where I’ll be putting stuff going forward). You can look at it. You can judge my choices. You can submit issues and leave me thank you notes about how easy to use your UI has become.

How This Actually Works

The way I’m using it is exactly what you saw above in this post:

That’s it. That’s the step. Under the hood, computer_use does something like:

1. Takes a screenshot of the current browser state

2. Sends the instruction + screenshot to Gemini’s computer use model

3. The agent decides what to do (click this, type that, scroll here)

4. Executes those actions (as tool calls)

5. Takes another screenshot

6. Repeats until it thinks it’s done or gets confused enough to give up

The agent has access to:

• What the page looks like (literally, as an image)

• What the instruction was

• The ability to click, type, scroll, and navigate

• No knowledge of your DOM structure

• No knowledge of your button labels

• No knowledge of your app’s architecture

Just like a user. A very determined, slightly confused user.

Could This Be Something Bigger?

We spent decades making tests that were good at pretending to be users. We gave them superhuman powers and called it “automation.”

But maybe we automated the wrong thing. Maybe we automated the execution when we should have been automating the confusion.

Real users get confused. Real users misclick. Real users can’t find the logout button even though it’s right there, right there, in the navigation menu that you spent three weeks perfecting.

An agent that can get confused? That can misunderstand your UI? That can fail in frustratingly human ways?

That’s not a bug.

Share

Let me say that again: Chrome. Has. An. LLM. Built. In.

The same browser that you’re probably reading this post in is now shipping with a language model. They call it “Built-in AI” and they’re giving developers APIs to do inference locally. No server calls. No API keys. No rate limits. Just you, the browser, and a surprisingly capable small model that can understand images and generate text right there on your machine.

The Hackathon (or: Two People Having a Very Long Conversation)

Justin and I had a problem we wanted to explore: what if you could navigate the latent space of image generation without writing prompts?

Every image generator (Midjourney, DALL-E, Nano Banana, Stable Diffusion, etc) all work the same way. You write increasingly elaborate prompts. “A cat” becomes “a tabby cat sitting” becomes “a tabby cat sitting on a velvet cushion in the style of a renaissance painting, dramatic lighting, 8k, trending on artstation.”

It’s prompt engineering as an art form. Which is fine! Except it’s also kind of exhausting. And it makes exploring variations feel like playing hot-and-cold with a very literal robot.

What if instead of describing what you want, you just… adjusted sliders? Abstract attributes with values from 1-10. Not “add more blue” but something like “make it 7/10 mysterious instead of 4/10 mysterious.”

That was the question we wanted to answer.

So we built Photoslider.

The Thing We Built

Here’s how it works:

1. You upload an image

2. Chrome’s Built-in AI analyzes it and returns three attributes with scores from 1-10. Basically, just let the AI decide what’s interesting about your image. One time it gave us “Geometric”, “Fragmented”, and “Luminous”. Another time it was “Mystery”, “Brightness", and “Motion.”

3. You get sliders for each attribute

4. You adjust them however you want (more geometric? less fragmented? crank that luminous to 11!)

5. You can also create your own custom attributes if the AI’s don’t capture what you want to change

6. Click “Generate Next”

7. The differences between the original and new values become a prompt (“increase geometric by 3 levels, decrease fragmented by 2 levels, add 4 levels of luminous”)

8. That prompt plus your original image goes to Gemini’s image generator.

9. New image comes back

10. You can do it all over again, or branch off from any previous image in your history

It’s kind of like being a DJ for images. Or maybe more like those sci-fi movies where people adjust holograms with hand gestures, except with mouse clicks and vibes.

The code is available up on GitHub at sublayerapp/photoslider.

But there’s a big reason why I’m telling you all this: we didn’t really code it.

Subscribe now

The Actual Hackathon Experience

We spent maybe 95% of our time sketching ideas in a notepad, arguing about whether there should be 3 or 5 attributes, and describing to Gemini CLI what we wanted to build.

The AI agent wrote the code.

All of it.

We’d say things like “okay so when the user adjusts a slider, we need to calculate the diff from the original values, then turn those diffs into natural language describing the change, then include the original image and send it all to Gemini.”

And then there would be code. Sometimes it worked. Sometimes we’d test it and say “no, that’s not quite right, here’s the page from the documentation that the Google team shared with us about the API, do it this way.” And it would fix it.

We were kind of pair programming, but the “typing code” half of the pair was a machine.

I know no one likes the 2am debugging session. The desperate Stack Overflow searches. The moment when your teammate who actually knows React wakes up and saves everyone. The caffeine-fueled sprint to get something working before the deadline.

We had coffee. But we didn’t really debug. We didn’t frantically Google. We mostly just… talked. About what we wanted. About whether the interface made sense. About what should happen when you branch off from a previous image. Should it remember its history or start fresh?

Even though I’ve been neck deep in agentic coding for months now, the ratio felt wrong. Too much output for the input. Too much progress for the effort expended.

I kept waiting for the other shoe to drop. For the part where we’d have to actually roll up our sleeves and fix something the AI couldn’t figure out.

It never really came.

The Implication

This whole experience has me thinking about what hackathons even are anymore.

Hackathons have always been about speed and delivery under time pressure. That part doesn’t change. The clock is still ticking. The deadline is still real. You still have to ship something that works.

What changes is what breaks when you move fast.

See, when you’re typing code yourself, moving fast can mean bugs. Typos. Off-by-one errors. Forgetting to handle edge cases. The things that break are small and fixable if you’re good.

But when an AI agent is writing your code? Moving fast can mean spaghetti.

The agent will do exactly what you tell it to do. At a high level of skill. Right now. Without arguing.

And if you haven’t thought about architecture? If you haven’t set up the bones of the thing correctly? If you’re just saying “add this feature” and “now add these other features” without thinking about how they fit together?

You end up with a mess. Code that works until it doesn’t. Features that sort of integrate but not really. A codebase that the agent itself starts getting confused by.

It’s a different kind of pressure. Not “debug before time runs out” but “stay coherent while building at 10x normal velocity.”

I keep coming back to cooking shows, but for different reasons now.

Iron Chef. Chopped. The Great British Baking Show.

They’re not testing whether you can cook. Everyone can cook. They’re testing whether you can:

• Make architectural decisions under pressure (do you have time for a three-layer cake or should you pivot to cupcakes?)

• Adapt when a twist comes (the ingredient you planned around is suddenly off-limits)

• Maintain coherence while moving fast (does your dish still make sense as a whole?)

• Work within the affordances of your tools (some techniques work in 90 minutes, some don’t)

Now imagine that, but updated for building with AI agents:

Round 1 (3 hours): Build a twitter clone. Or a daily deals site like Woot. Or a Reddit-style forum. You know, something real. Something with users and posts and comments and voting. Something people might actually use. Your AI agent can write all the code.

The Twist (announced at 3 hours): Your twitter clone must now support real-time collaborative editing on posts. Or you daily deals site needs a live auction system. Or your Reddit clone has to handle threaded voice replies.

If your architecture is solid? The agent handles it. Maybe forty-five minutes of refactoring some new models, wire it up, done.

If you’ve been cowboy coding at agent speed? You might spend the next three hours in hell.

The skill is control at velocity. Knowing what to specify and what to leave flexible. Building with agents in a way that doesn’t paint you into corners.

It’s still a hackathon. Still fast. Still pressure. Still about what you can ship before time runs out.

Just… different things break now.

I’m Not Sure About Any Of This

Maybe I’m wrong. Maybe this was just one weird hackathon where the stars aligned. Maybe next time the AI agent will spend 6 hours stuck on some dependency issue and we’ll be back to traditional debugging.

Or maybe this is the new normal and I just haven’t processed it yet.

I keep thinking about our experience playing with the sliders. We were testing Photoslider, and I uploaded a photo of a sunset. The AI came back with “warmth: 8/10, tranquility: 6/10, drama: 4/10.”

And I thought: that’s not wrong.

It’s not right in any objective sense though either. How do you measure the tranquility of a photo of a sunset? But it’s not wrong either. It gave me levers to explore. Handles on something ineffable.

I turned warmth down to 4 and drama up to 9. The new image came back darker, stormier, with more contrast. Less “peaceful sunset,” more “the world is ending beautifully.”

Was that what “drama: 9/10” means? I have no idea. But it gave me something I liked.

Where This Might Go

Here’s what I’m thinking;

Near future (6 months): Hackathons start splitting. Traditional “you must write the code yourself” and Experimental “use whatever tools you want, we’re judging the result.”

Medium future (2 years): The experimental track doesn’t really even need to ban manual code-writing. It does require a wild twist though, forcing you to prove your architecture can flex. The thing that wins isn’t always the prettiest demo, sometimes it’s the one that handled “now add real-time collaborative editing” halfway through without collapsing into spaghetti.

Far future (5 years): We’ll have established patterns for “agent-proof architecture.” Like how we have design patterns now, but for working with AI that codes. The hackathons test whether you know them. Whether you can apply them under pressure. Whether you can feel when the agent is about to paint you into a corner and course-correct before it happens.

Or maybe none of that happens and this was just a weird Thursday at Google.

The Pitch

But lets see. If we decide to run this, would you be interested?

I’m calling it The Iron Vibecoder (working title, names are hard).

Here’s the shape:

• Small scale first. Maybe 8 teams. Maybe just people who read this and think “that sounds delightfully unhinged.”

• 6 hours total. Project revealed at start (build a Twitter clone, or a deals site, or a forum, you know, something real). Twist announced at 3 hours.

• AI agents expected. If you’re typing all the code yourself, you’re doing it wrong.

• Judging borrowed from cooking shows. Does it work? Did you handle the twist? Does it cohere? What’s delightful about it?

• A host who’s way too excited about the whole thing. (Probably me. I’m sorry in advance.)

The point is to test a different skill: Can you maintain architectural sanity while building at 10x speed?

When the twist comes (”now add real-time features” or “now support collaborative editing” or “now it needs a marketplace”) we’ll see who architected well and who just yolo’d their way through the first three hours.

Original video on Sora: https://sora.chatgpt.com/p/s_68e13b74cbc881918e7b11057aea50c8

Would it work? No idea. Would it be fun? I think so. Would we learn something about where hackathons are going? Yeah, probably.

If this sounds interesting, let me know. Reply. DM me. Whatever.

I’m looking for:

• Participants who want to test their agentic coding skills under weird constraints

• Judges with opinions about what makes software feel coherent vs. spaghettified

• Twist ideas (what’s a good mid-hackathon pivot that tests architecture without being impossible?)

• Better names than “Iron Vibecoder” (please)

• Sponsors who think this weird experiment is worth supporting

This might be a disaster. The twist might be too hard. The judging might be too subjective. Someone might spend the whole time arguing with their AI about whether to use WebSockets or Server-Sent Events.

But that’s what experiments are for.

We built Photoslider by describing it into existence. We explored interfaces through sliders measuring abstract concepts. We did it at a hackathon with a browser that has AI built in.

The tools changed. The skills that matter changed. Maybe the format should change too.

Let’s see what happens when we optimize for architectural coherence under agent velocity instead of raw coding speed.

The clock’s still ticking. The pressure’s still real. But what breaks is different now.

Share

Hallucinations - 01

A master carpenter kept worn wooden jigs in his workshop—templates smoothed by ten thousand cuts, guides that knew the exact curve of comfort.

A brilliant apprentice arrived with a programmable machine. "Master, why keep these old blocks? My machine can cut any shape imaginable."

The master handed her rough lumber. "Make me a chair."

She programmed for hours—coordinates, angles, measurements. The chair was perfect. It was correct. It did not sing.

The master placed his dovetail jig against her machine and whispered: "Dovetail. Like this."

The machine understood immediately.

"Your machine can cut anything," said the master. "My jigs remember everything. Which is wiser—the tool that knows all possibilities, or the template that knows which possibility matters?"

Something happens when people who don’t speak the same language need to trade spices, or fish, or coconuts or whatever. They don’t have time to learn each other’s entire language so they do the only thing they can do.

They invent a new language. Right there. On the spot.

How Humans Have Always Been Hackers

Picture this: It’s the 1600s, and Portuguese traders are trying to do business along the West African coast. It would be a long time before Babelfish.com would come out and solve this problem for them. But what they did have was the universal human superpower: the ability to point at things and make sounds until somebody understands.

"You… give… fish?”
”Me… want… cloth!”

And just like that a pidgin is born. Not broken Portuguese, not broken local languages, but something entirely new. A bridge built from both sides, meeting somewhere in the middle.

Pidgins aren’t anybody’s native language. They belong to everybody and nobody at the same time. They’re pure function, stripped of all the complicated grammar rules that make high school teachers cry. No subjunctive mood. No seventeen different past tenses. Just: “Yesterday me go market.” Everyone understands. The fish get sold. Life continues.

The Plot Twist

Sometimes, just sometimes, children grow up speaking these pidgin languages as their first language. Their first language. Imagine your mother tongue being something your grandparents invented to buy fish.

When that happens, something magical occurs. The pidgin transforms. Like a caterpillar, except instead of becoming a butterfly, it becomes... a real language? A creole. Complete with all the complexity and poetry and irregular verbs that make language class so frustrating.

Hawaiian Pidgin (actually a creole (I know, I know…)), Haitian Creole. Tok Pisin in Papua New Guinea. What started as “just enough words to trade fish” became languages that people write love songs in, tell their children bedtime stories in, dream in.

(See where I’m going with this yet?)

Speaking Creole to Probability Distributions

Fast forward to now. Everyone's talking about how AI agents write code. They build entire applications while you're making coffee. They debug faster than you can say "undefined is not a function."

The immediate question everyone asks: "Why do we need frameworks at all when the machines can just… write whatever we need?"

But I think this is the wrong question. It’s like asking why Portuguese traders needed pidgin when they could have just learned all the local languages perfectly.

What Frameworks Really Are (A Meditation)

Think about what a framework really is.

No, really think about it. I’ll wait…

It’s more than just a bunch of pre-written code. It’s a shared vocabulary. When I say “component” to another React developer, we both know exactly what I mean. When someone mentions “ActiveRecord,” every rails developer conjures the same mental model and cringes at the same N+1 query memories.

And this is what the “AI will replace frameworks” people are missing: Even when AI can write perfect code in any style, we still need to talk about that code. With humans. With other AIs. With ourselves six months from now when we’ve forgotten everything and are basically different people who hate our past selves.

Imagine trying to describe your application without frameworks:

“I need the thing that responds to HTTP requests and returns JSON, but like, organized in a specific way with middleware and… you know what I mean?”

Versus with frameworks:

“I need an Express server with JWT middleware.”

Done. Everyone knows exactly what you’re talking about. The AI knows what to build. Your team knows what to expect. Your future self knows what they’re looking at and only slightly hates current you.

Subscribe now

The Frameworks We Know and the Frameworks We Don’t

Rails is a creole to Claude. React is a creole to GPT-5. They’ve seen so much Rails and React in their training data they’re essentially native speakers.

It’s like watching someone who grew up in Paris order coffee. Effortless. Natural. Slightly condescending to tourists.

But when it’s your company’s internal framework. The one the DevOps engineer built before they left for that farm in Vermont. The one with documentation that’s mostly TODO comments and a README that just says “should be self-explanatory. dm me with any questions” even though they’ve been gone for two years.

This is a pidgin situation. The AI has never seen it. You need to teach it the language while you’re using it. Every. Single. Time.

The Pidgin Conversation Protocol

When you’re working with a pidgin framework (read: anything not in the training data), the conversation changes:

And honestly? Sometimes it works. Like those traders in 18th century Canton who managed to build entire commercial empires on “you give tea, me give silver.” Functional, if not elegant.

Enter VSM: Trying To Build Better Frameworks as Pidgins

(I’ll spare you the digression about cybernetics this time…)

I’ve been working on this agent framework called VSM, (stands for Viable System Model). It’s basically me trying to figure out how to build frameworks that make it easy to speak pidgin to AI.

The framework is designed to let you easily create specialized, CLI-based, tool using agents backed by an LLM that you can chat with. We just released version 0.2.0 with a few new features, one in particular is focused on exploring this pidgin problem.

1. The CLI Generator

Every framework needs something like this. Quickly create a new project with all the boilerplate taken care of and the starter files in the right place.

2. MCP Tool Support

Know of an MCP server with tools you already want to use? Drop it in and chat with it immediately.

3. Meta-Tools

This is the fun part.

Ruby lets you ask code about itself:

• “What methods do you have?”

• “What are your arguments?”

• “What is your purpose?”

Take that ability, combine it with some documentation, and suddenly you have an agent that can explain its own operations.

Want to see it in action? There’s an example to play with in the library in examples/10_meta_read_only.rb.

This is all just setting the stage for the next release. Coming up next, we’re going to give these agents the ability to generate their own tools that fit into the framework and then run them, live.

A Small Observation About Expertise

You know who’s getting the most out of AI coding assistants right now? Senior developers. People who already speak Rails or React or whatever fluently.

They’re having full creole conversations. “Add auth with JWT, Postgres backend, refresh token in Redis.” The AI just… does it. Because they’re both native speakers in the same linguistic colony.

But beginners? They get pidgin. They get “make user login thing happen” and a pile of code that might work but probably also sends passwords to console.log because nobody specified not to.

The experts are native speakers talking to native speakers. Everyone else is pointing at coconuts and hoping for understanding.

(There’s probably a deep philosophical point about inequality and access to technology here, but I’m going to leave that for someone with a sociology degree and more coffee than me.)

Where This All Goes

Maybe frameworks don’t become obsolete. Maybe they become… different. Instead of being shared assumptions baked into code, they become active participants in the conversation. Teaching assistants. Translators. Linguistic bridges across the sea of incomprehension.

Maybe frameworks become self-aware. Not like, Skynet self-aware. More like… aware that they need to explain themselves. Conscious of their own patterns. Able to teach their own idioms.

So that’s what this VSM experiment is all about. Can we build frameworks designed for pidgin conversations? That know they’ll be talking to probability distributions who’ve never seen them before? That can teach themselves while being used?

I think maybe yes? But also I’m building it while thinking about it, which is like trying to explain swimming while drowning, except the water is Ruby and the drowning is just regular software development and actually maybe this is another metaphor that got away from me.

In Conclusion

Look… all frameworks are pidgins until they’re not.

Rails was a pidgin once. Someone just used it long enough that it became the way we think. Now our AIs dream in has_many :through associations. They wake up in cold sweats worrying about N+1 queries they’ve never actually experienced.

The frameworks we use shape the thoughts we can think. The pidgins we speak become the creoles our children inherit. The patterns we establish today become the native languages of tomorrow’s machines.

What will they dream in tomorrow?

I realized I never actually answered the question in the title. How DO you speak pidgin to a probability distribution? Very carefully, and with lots of examples, and maybe some ASCII art for emphasis. But mostly? You just keep talking until something clicks.

Or until the context window fills up. Whichever comes first.

Share

There's this restaurant in Tokyo that doesn't have a kitchen. Well, it has a kitchen, but nobody cooks in it anymore.

It started when the owner got tired of explaining to his chefs how to make his grandmother's miso soup exactly right. So he built a machine that could make it perfectly every time. Then another machine for the rice. Another for the tempura. Soon, the whole kitchen was machines.

The chefs were furious. "This isn't cooking!" they said. "Where's the art? The soul? The years of training?"

But the owner did something unexpected. He turned his chefs into inventors. Instead of cooking the same dishes, they designed new ones the machines couldn't make yet. They became flavor architects, texture engineers, experience designers. The junior chef who could barely julienne vegetables? She invented a dish that exists in a new dimensions of taste.

The restaurant now has a three-year waiting list.

Every meal is something that didn't exist yesterday. The chefs don't cook anymore. They imagine, and the machines help them make their imagination edible.

"We forgot how to cook," he says, "so we could remember how to create."

So I've been thinking about hockey lately.

In particular, I’ve been thinking about Wayne Gretzky’s “Skate to where the puck is going to be, not where it has been.” quote.

We’ve all heard it before. Some of us added it to our LinkedIn headers. Maybe it’s in your pitch deck. Entire companies have been built around predicting the next location of that metaphorical puck.

But one big thing is forgotten when talking about this advice…

Gretzky could already skate.

What About AI Pucks?

There’s something different about AI pucks, sometimes you skate to where you're SURE the puck is headed, and then…

The puck just... doesn't go there.

Or worse, it zooms past where you thought it would stop, and you're standing there like you're waiting for a bus that already left. Remember when everyone was building "ChatGPT for X" and then suddenly the puck became autonomous agents? Yeah…

The Pucks Used to Move Slower

That Gretzky quote made way more sense in 2010.

Back then, pucks were predictable. They moved like pucks are supposed to move: in straight lines, affected by physics, obeying the laws of hockey.

2010: Mobile is going to be big
2011: Mobile was big
2012: Mobile was still big
2013: Yep, still mobile
2014: Mobile, but bigger screens now
2015: Same mobile, better cameras

You could build a mobile-first startup in 2010 and still be basically right in 2015. The puck was just... sliding across the ice. Like a normal puck. You could do the math.

Subscribe now

The Breakfast Problem

Now, every morning, I wake up and check what changed in AI overnight:

Monday: "We need RAG systems!"
Tuesday: "Actually, long context windows make RAG obsolete!"
Wednesday: "Just kidding, we need RAG but different!"
Thursday: "Forget everything, we're all agents now!"
Friday: (muffled screaming into coffee mug)

A Brief Digression About Building Things

So look…

We've got these incredible AI coding agents now, right? They can write entire applications in seconds. They can debug faster than we can read. They can refactor code while we're still trying to remember what a factory pattern is.

And what are we building with them?

The same. exact. things. we've been building for twenty years.

Another SaaS app. Another CRUD dashboard. It's like we invented teleportation and we're using it to go to the same grocery store, just... faster.

I don't know what we should be building instead. But if the tools are this different, shouldn't the things we make be different too?

The Only Skill That Matters Now

Anyway, yeah, like I said earlier, Gretzky could already skate. He was incredibly agile. He could stop on a dime. Change direction mid-stride. His edges were so good he could literally dance on ice.

He didn't become great because he predicted the puck. He became great because he could actually get to ANY position on the ice and be open. The prediction was secondary to the skating.

That's where we are now. Except our skates are prompts. Our ice is context windows. Our edges are knowing how to talk to Claude or Gemini or whatever comes out next that makes both of them obsolete.

The Zamboni Situation

You know, there was another person that helped make sure the Great One was going to be able to skate to where the puck is going to be: The Zamboni driver.

They come out between periods and make sure the ice is smooth. Make sure we can keep skating fast. Nobody cheers for the Zamboni driver. But without them, eventually we're all just stumbling around on choppy ice, wondering why we keep falling down.

One type of thing we need to be building with AI are Zambonis. Tools that smooth out the surface. Ways to understand what these agents are actually building for us.

Like, the other day I was thinking about how hard it was to build a mental model of the apps you’re building these days. Things change so fast and mutate so quickly now that you don’t have time to fully internalize how things work. Chad Fowler talked about it on The Ruby AI Podcast last week: your brain used to be able to relax while you did the boring parts like typing. I think that’s also when we used to process and build our theories of our programs.

So… I built this prototype to explore ways to solve that. (Or rather, I asked Bolt to build this prototype while I ate peanut butter sandwich crackers.)

It's a visual, 2d, app explorer. I’m thinking you would point it at your git repo and suddenly you can see it like a map. Zoom out to see the whole architecture or browse by routes. Zoom in to see individual functions or controllers or models. Pan around like you're in Google Earth but for code. Get a visual indicator on the different elements when a commit has modified them. Start with AI summaries of the code, but be able to drop down into the details if you need to.

Does something like this seem feasible? Know anyone who is trying to build this? If we’re going to be doing product-level acceptance on our apps instead of reviewing mountains of code, we’re going to need to SEE our applications. Like, really see them.

Here, check it out and let me know what you think.

One way we can ensure we’ll be able to keep skating fast is building the Zambonis. Making the tools that help us navigate this weird new ice where the surface changes every time we blink.

A Meditation

So yeah… instead of skating to where the puck might be in a year...

What if we just got really good at skating?

Like, what if we got so good at skating that when the puck shows up (wherever it shows up) we could just... go get it?

What if adaptability is the product?

The Choice That Isn't Really a Choice

Here's the brutal, uncomfortable, urgently true thing…

(deep breath)

If your company isn't giving you the tools to learn to skate like Claude Code or Amp subscriptions, API credits, time to experiment with AI coding, and so on, you're not actually employed. You're in hospice. They're just keeping you comfortable while you become obsolete.

You won't be replaced by AI. That's the wrong fear. You'll be replaced by someone who learned to skate when you were still arguing about whether the ice is real.

It’s important to find a company that gets it. That throws money at making you faster. That understands we're not playing hockey anymore (we're playing something new, where the rules change mid-game and the only constant is acceleration).

Or don't. Stand there in your street shoes, explaining to everyone how you've been coding for twenty years and these kids with their AI tools don't understand real programming.

The puck doesn't care about your experience. It's already zipped by you while you were reading this sentence.

Share

I've been doing this dance for almost 15 years now. Fifteen. That's longer than some JavaScript frameworks have existed. Hell, that's longer than some JavaScript frameworks have existed twice.

The Problem With Having Just One Brain

You know that feeling when you're cooking dinner, answering a text, helping with homework, and trying to remember if you fed the cat? That's what modern agentic software development feels like now, except the cat is a Claude Code instance and it's definitely hungry.

Our computers are phenomenal at context switching. They do it thousands of times per second, juggling processes like a circus performer on espresso. But us? We're still using tools designed for when having one terminal window open was considered fancy.

I once tried to explain my workflow to someone and they looked at me like I was describing how to perform surgery with kitchen utensils.

Subscribe now

The Dance of Many Projects

Let’s try again, here's how it works:

One Session Per Project. This is my cardinal rule. Each project gets its own named session: protocollie, sublayer-gem, apm_macos, the-12th-estate like little kingdoms in terminal land.

Context is everything, and your brain (or at least my brain) works better when it knows exactly where it is. When I switch to the protocollie session, suddenly I'm not thinking about gem publishing or macOS APIs. I'm thinking about protocols and data flows and why Claude can’t get the walkthrough tooltips to line up right.

Task-Oriented Windows. Inside each session, windows become specialized tools:

• Window 0: The command center (usually running Claude Code or whatever AI agent is helping today)

• Window 1: Vim (mostly just to read Markdown files at this point)

• Window 2: Tests, builds, servers

• Window 3: A spare shell, for whatever else I might need

Efficient Context Switching. Ctrl-b s shows all sessions. Ctrl-b w shows all windows. Your fingers learn these patterns like a pianist learns scales, and suddenly you're not thinking about how to switch contexts, you're just thinking about where you want to be.

Want to see it in action rather than read about it? I presented this workflow to Latent Space’s AI In Action Club a few weeks ago. You can check out the video here on YouTube.

The Learning Curve That Ate My Twenties

I don’t know how long it actually takes to stop thinking about tmux commands and just doing them. But I promise, one day (I can’t tell you which day, it happens gradually… and then suddenly) your fingers start moving without your brain’s permission:

It can take forever to get comfortable with this workflow. The key bindings are arcane and the concepts are weird if you're used to GUI applications.

But even with all my hard-earned muscle memory, I hit a wall at around three concurrent projects. Beyond that, it becomes like trying to remember which dream you're in while having multiple dreams simultaneously.

And if I'm struggling with more than three projects what hope does everyone else have?

The Great macOS Workspace Disappointment

We've built all these amazing tools for parallel processing in our computers, but we're still using interfaces designed for serial thinking.

We don't actually have good tools for parallel work.

macOS Spaces? Please. They're like someone designed window management after only hearing rumors about what windows are supposed to do. The APIs are basically non-existent. It's like Apple wants you to only work on one thing at a time

Most people end up in this frantic alt-tab dance:

• Command-tab to switch applications

• Lose track of which terminal has which project

• Accidentally run git push in the wrong directory

• Spend ten minutes figuring out where they were

• Give up and work on one thing at a time like a sensible human being

But I don’t want to be forced to be sensible. I want to work on ALL MY PROJECTS AT THE SAME TIME.

So We’re Building Something

This is where APM comes in. Actions Per Minute? Agent Project Manager? Agile Project Management? Absolutely Parallel Madness?

I don’t feel very strongly about it, it’s really up to you to decide. At least we have all the domains, so use whichever makes the most sense to you.

Anyway, APM is a gaming-inspired command center for working with AI agents across multiple projects. Think of it like my tmux process but for people who don’t have 15 years to spend memorizing keyboard shortcuts.

The idea is stolen directly from gaming, because gamers figured out something important: if you're going to manage complex parallel systems, you need a HUD that doesn't make you want to cry. They've been managing resource economies, unit positions, and build queues since StarCraft. Meanwhile, we're over here trying to remember which terminal has npm run dev running.

You can still use tmux if you want (I will), but you could also use Cursor, or VSCode, or Zed, or whatever text editor for whatever programming agent you’d like. The point is to make working on multiple projects actually feel like you're in control.

The Parallel vs. Sequential Question

Which brings me to my question for all of you: what are you doing with all this AI acceleration?

Are you like me, trying to juggle more projects simultaneously? Using the speed gains to increase your concurrency rather than your free time?

Or are you like Justin Searls, who built a Discord bridge and now gives Claude Code commands from his Apple Watch while living his actual life? (Which, let's be honest, is probably the healthier approach.)

I toggle between both modes. During the week, I'm the caffeinated octopus, all tentacles and concurrent sessions. On weekends, I try to single-thread: pop in to my office every once in a while and move Claude a step forward while I remember what sunlight feels like.

A Call from the Terminal

To get more specific:

Are you working with multiple agents in parallel? What's your setup?

I want to know:

• How many projects do you juggle at once?

• What tools are you cobbling together to make it work?

• Are you team Multiply-the-Projects or team Live-More-Life?

• Have you built any weird contraptions for managing AI agent conversations across different contexts?

• Are you doing something completely different that I haven't even thought of?

I suspect we're all making this up as we go along. Nobody Knows How To Build With AI Yet. AI agents are new. Parallel development workflows are still weird and niche. The tooling is... well, let's just say there's room for improvement.

But maybe that's okay. Maybe the best solutions come from a bunch of programmers sharing their weird setups and learning from each other's struggles.

I'd love to hear your stories, especially if they involve Apple Watches, Discord bridges, or other wonderful complications.

Drop a comment, send a message, write a blog post of your own in response! I want to know how everyone else is handling this new world of AI-accelerated development. Are we all just dealing with different flavors of the same chaos?

Share

Pat's productivity, working with their AI coding agents, went through the roof.

Everything Goes Wrong

Pat started generating code like a caffeinated octopus with eight keyboards. Pull requests started flowing. Rivers of code. Tsunamis of perfectly formatted, well-commented, syntactically correct implementations.

The team's Slack channel, which had been a peaceful meadow of occasional stand-up notes and lunch polls, became... something else.

"Pat, we need to talk about the seventeen PRs you opened before standup."

"Pat, did you really refactor the ENTIRE authentication system? It... actually looks better but I need a few days to be sure."

"Pat, why does this PR have 3,000 lines of code and a commit message that just says 'idk Claude wanted this'?"

Subscribe now

The Elephant in the Code Review

You see, Pat's teammates were drowning. Most of the code was actually pretty good, some of it was brilliant, and yeah, occasionally there was something that would have deleted production. But how could you tell which was which when it was coming at you like a firehose of syntax?

Sarah would spend three hours reviewing a PR that Pat generated in twelve minutes, and the worst part? The code was usually fine. Better than fine. But Sarah couldn't just skim it because what if THIS was the one that wasn't?

Tom started having dreams where curly braces chased him through an infinite diff view, whispering "I might have a subtle race condition."

Lisa... Lisa just started approving everything with the comment "LGTM" because the first ten PRs she carefully reviewed were all genuinely good and she had actual work to do too.

Everyone was mad at Pat. But Pat wasn't the problem. Pat had discovered something important, something that reminds me of an old piece of programming folklore:

"XML is like violence: if it doesn't solve your problems, you didn't use enough of it."

Except now it's AI. And Pat was using just enough AI to create problems, but not enough AI to solve them.

The Part Where We Learn Something (Maybe)

Sarah was still reviewing code like it was 2015, reading every line, mentally executing each function, treating code review like she was defusing a bomb with her teeth.

But what if...

What if Sarah had her own AI assistant? Not just for writing code, but to help her read Pat's code?

Tom could have an AI that transforms those 3,000-line diffs into something digestible. "Pat basically replaced our entire database layer with something that's 30% faster and uses half the memory. The tests pass. There's one weird bit around connection pooling that might be genius or might leak memory under load. Investigating."

Lisa could stop LGTM-ing everything and start asking her AI, "What's the riskiest part of this PR?" and actually get an answer that lets her focus her limited attention where it matters.

The Recursive Solution

I’ve been accused recently of being a tech optimist, and maybe theres some truth to it, because I look at problems as just opportunities for more solutions. And you know what's beautiful about AI-generated problems? They're opportunities for AI-generated solutions!

It's like that thing with the turtles, except instead of turtles, it's AI agents reviewing code written by AI agents being tested by AI agents being deployed by AI agents being monitored by AI agents.

Pat floods the team with PRs? Give everyone AI reviewers.

AI reviewers miss subtle bugs? Add an AI meta-reviewer.

AI meta-reviewer gets confused? Build an AI to explain what the AI meta-reviewer meant.

Someone complains this is getting out of hand? Generate an AI therapist to help them process their feelings about the new development workflow.

A Story About A Fox

There's this fox who lives near my office. Every morning, the fox tries to catch mice. Old school. Patience, stealth, pouncing. Classic fox stuff.

Then one day, the fox discovers it can team up with the local hawk. The hawk spots mice from above, the fox chases them out of hiding. Suddenly, there are too many mice. The fox can't eat them all.

Does the fox complain about the hawk? No. The fox invites more foxes. Now there are too many foxes and not enough coordination. So they develop a complex social structure with designated hunters, scouts, and even fox managers (middle management exists everywhere, apparently).

The point is...

The Octopus in the Room

Actually, wait. Before we talk any more about foxes, we need to talk about octopuses.

A few weeks ago I wrote this thing about being an octopus developer (eight arms, eight parallel projects, each arm with its own semi-autonomous brain cluster.) Then Justin Searls read it and pointed out an important part I had left out.

Justin did the math. Eight humans on a team means 28 1:1 relationships to manage. Normal. Fine. We've been dealing with this since Fred Brooks wrote about it.

But eight humans each wielding eight AI sub-agents? That's 64 entities, which means... 2,016 relationships. Not only that, but 1,764 of those connections are unidirectional. The agents can receive information but they can't retain it, can't pipe up in meetings, can't say "hey wait, Pat's PR conflicts with what I'm building."

Justin put it perfectly: "a manager has no observable signal that their team's composition has changed so radically—they'll walk into the room and see the same eight nerds staring at their computers as ever before."

The octopuses can't coordinate. They're all in the same reef, ink everywhere, no one knows whose arm is whose anymore. And Pat (sweet, productive Pat) is out here with eight arms generating code while Sarah's still got her two human hands trying to review it all.

I was also recently on Justin’s Podcast, Breaking Change, talking about how most of the best practices that helped us over the last 20 or so years become irrelevant when you add AI agents to the mix. Check it out: V42.0.1 Ignore All Previous Instructions

A Brief Detour Into the Conservation of Misery

So back to the foxes…

There's this book called Systemantics (it now goes by The Systems Bible if you want to search for it) by John Gall, and he talks about this thing called the Law of Conservation of Anergy. Anergy (not a typo, anergy) is the amount of effort required to drag reality into alignment with what humans actually want.

The law states that the total amount of anergy in the universe is constant. You can't destroy it. You can only move it around, like trying to smooth out a bubble under wallpaper. Push it down here, it pops up there.

Gall has this example about garbage collection that's... conveniently similar to our fox situation. See, people used to just take their own garbage to the dump. Simple. Direct. One person, one garbage, one trip.

Then someone said, "Hey, what if we all chip in and pay someone to collect everyone's garbage?"

Brilliant! Less work for everyone!

Except now you need to organize who pays what. So you need a treasurer. And rules about what counts as garbage. And someone to enforce the rules. And suddenly you have a town council, and elections, and that one neighbor who insists pizza boxes are recyclable (they're not, SETH), and three-hour meetings about whether the garbage trucks should turn left or right at Oak Street.

The anergy didn't disappear. It just transformed from "carrying garbage" into "arguing with Seth about pizza boxes."

So when Pat floods the team with AI-generated PRs, we haven't reduced the total amount of work. We've just converted "writing code slowly" into "reviewing code frantically." And when we give everyone AI reviewers, we're not eliminating the anergy, we're transforming it into "debugging why the AI approved the code that deletes the production database."

The fox consortium doesn't have fewer problems than the solo fox. They have different problems. More complex problems. Problems that require meetings and organizational charts and probably a Fox Resources department.

Why People Are Uncomfortable

Here's what I think really bothers people: Pat is thinking differently about code. Pat treats code like it's disposable, experimental, abundant. Because for Pat, it is.

Meanwhile, Sarah treats code like it's precious, careful, crafted. Because for Sarah, it always has been.

But what if they're both right? What if the future is Pat generating seventeen wild experiments before breakfast, and Sarah using AI to quickly identify the two that are actually brilliant and the one that might have a subtle bug?

What if Tom uses AI to refactor Pat's working-but-chaotic code into something maintainable?

What if Lisa uses AI to predict which of Pat's PRs will cause production incidents (rare, but it happens) and which ones will accidentally solve problems we didn't even know we had (surprisingly common)?

The Part Where We Conclude

So yeah. Just like XML, if AI is causing you problems, you're not using enough of it.

Your teammate generating too much code? Don't ask them to slow down. Speed up your reviews with AI.

Your AI reviews missing edge cases? Don't go back to manual reviews. Add AI edge case detection.

Your AI edge case detection hallucinating edge cases that don't exist? Add AI hallucination detection.

Your AI hallucination detection having an existential crisis? I mean... at that point maybe take a coffee break. But after coffee? More AI.

The secret isn't balance. It's not careful integration. It's not thoughtful consideration of appropriate use cases.

The secret is embracing the chaos. Let Pat flood the zone with code. Let Sarah's AI drink from the firehose. Let the whole team level up together, or let the whole thing collapse into a beautiful disaster that teaches us something new about how humans and machines can work together.

Because like we talked about in the past: Nobody Knows How To Build With AI Yet. We're all just Pat, discovering AI, trying to figure out what happens when you give a developer unlimited code generation power.

And the answer, apparently, is that you give everyone else unlimited code review power.

And then unlimited code review review power.

And then...

Well, I haven't figured out what comes next. But I bet if I ask an AI, it'll have some ideas.

Share

"It keeps changing!" she yelled at the Atlantic, as if it might apologize. "Every time I figure out where everything lives, the water comes back and moves it all around!"

Her dad tried to explain about tides, about the moon, about gravitational pull. But she wasn't having it. She wanted the tide pool to pick a state and stick with it. Either be underwater or be exposed. Not this constant back and forth, back and forth.

"But then," her dad said, "nothing new would ever wash in."

"But then," she countered, "I could finally finish counting the hermit crabs."

And I stood there, salt air making my laptop bag feel slightly damp, thinking about how this kid had just described what it is like to be a software engineer. Except we don't have the moon to blame. We did this to ourselves.

The kid was fighting the tides, but we built ourselves a pendulum. Same back-and-forth, except we're both the clock and the clockmaker.

A Brief Philosophical Detour on the Two Kinds of Programmers

Avdi Grimm gave a talk called The Soul of Software about a decade ago and one particular thing in it has stuck with me: you can tell what type of programmer you were taught by based on which part of object-oriented programming they teach first.

Did your teacher start with inheritance? Class hierarchies, abstract base classes, the whole "a Dog is-a Mammal is-an Animal" taxonomy? Then you were taught by what we call a formalist. Someone from the Dijkstra school of thought, where programs are mathematical proofs that happen to execute. They showed you the blueprints before they showed you the building.

Or did they start with polymorphism? "Look, different things can respond to the same message in their own way!" Objects having conversations, duck typing, the magic of not caring what something is as long as it knows what you're asking? You had an informalist teacher. Someone from the Alan Kay school, where programs are living systems of communicating entities. They let you play with the clay before teaching you about kilns.

This isn’t just a teaching preference, it's two completely different universes of what programming is.

The industry has been switching between these universes, back and forth, like a pendulum, since the beginning of computing. And every time we switch, we act like we've discovered something new.

The formalists see programming as applied mathematics. Proofs you can execute. They sleep better knowing their types check at compile time.

The informalists (or the hermeneutic crowd, if we're being fancy) see programming as writing. As conversation. They sleep better knowing they can change anything at runtime if they need to.

(I was taught inheritance first. It took me years to recover.)

Subscribe now

The Smalltalk Séance

Once upon a time, there were these folks at Xerox PARC who talked to their computers. Not like we do now, with our typing and our clicking, but really talked to them. They had this thing called Smalltalk, and it was less a programming language and more a conversation with a very patient friend who happened to be made of electricity.

They invented everything, basically. The mouse (someone told me it was originally supposed to be called the turtle. I don’t think that’s right… but it would have fit really nice with the ocean theme of this post… ). Windows you could move around like pieces of paper on a desk. Menus that dropped down like theater curtains.

But the real invention was the philosophy. Alan Kay wasn't trying to build better programs. He was trying to build better programmers. People who could think in systems, in conversations, in living breathing code that could change itself while running.

Meanwhile, in the Netherlands, Edsger Dijkstra was having nightmares about this exact thing.

The Dijkstra Doctrine

Dijkstra looked at programming and saw chaos. Not the good kind of chaos, where things emerge and evolve. The bad kind, where nothing works and nobody knows why.

"Programming," he said, probably while wearing a very serious expression, "is one of the most difficult branches of applied mathematics."

<That sound you just heard was Alan Kay spitting out his coffee.>

Dijkstra wanted proofs. He wanted to know, to prove, that a program would work before it ran. He wanted structured programming, where goto statements were considered harmful and every function had one entrance and one exit, like a very orderly party.

And you know what? He wasn't wrong.

When your code controls nuclear reactors, or airplanes, or insulin pumps, you don't want it to be having an exploratory conversation with itself. You want it to be a proof. A proof that happens to execute, but a proof nonetheless.

The Great Translation

Now here's where it gets interesting. C++ and Java didn't just borrow from Smalltalk. They tried to translate Alan Kay's informal, living system into Dijkstra's formal, provable world.

Smalltalk said: "Objects send messages to each other."
C++ heard: "Objects have methods you can call."

Smalltalk said: "Everything happens at runtime."
Java heard: "Some things can happen at runtime, but let's check everything we can at compile time."

Smalltalk said: "The system is alive and you can change it while it runs."
C++ and Java heard: "...what? No. Absolutely not. Are you insane?"

They took the shapes of Smalltalk's ideas but filled them with concrete. Objects became structs with function pointers. Messages became method calls. The living system became a compiled binary.

It worked. It was reliable. You could build big systems with teams of people and the compiler would catch your mistakes. But something was lost. The conversation became a monologue. The living system became a corpse that somehow still moved.

The Web's Rebellion

Fast forward. It's the late 90s. Java is trying to eat the web. "Applets!" it shouts. "Enterprise beans!" it insists. Everything must be an object, everything must be typed, everything must be correct.

But then JavaScript happened.

And by "happened" I mean "was created in 10 days by someone who understood both Scheme and Self but had to make it look like Java for marketing reasons."

And from this beautiful combination came everything. Every web app you use. Every framework you love or hate. All built on a language that Dijkstra would have considered a war crime.

Then Ruby joined the party, taking Smalltalk's philosophy and saying "what if we made it even MORE flexible?"

Ruby on Rails said "what if making a web app was actually fun?" and suddenly everyone could build Twitter (the original one that was always falling over, but in a charming way, with an adorable whale).

The Alan Kay disciples were winning. Systems were conversations again. Code was alive, mutable, dangerous, and fun.

The Inevitable Tidying

But then (you knew there was a "but then"), the pendulum started its return journey.

The Rails apps that changed the world started creaking under their own weight. The JavaScript that let you prototype anything in an afternoon also let you create bugs that make you say “Wat?”.

Enter TypeScript, stage left, wearing business casual and a badge that says "I'm JavaScript but I was made by Microsoft."

Enter Go, designed by people who looked at all the chaos and said "what if we just... didn't allow most of that?"

Enter Rust, which holds your hand so tightly while you program that you can't possibly hurt yourself (or anyone else).

(I'm only slightly exaggerating.)

Here We Go Again

But here we are again with AI, friends. We’re in the wildest informal moment yet.

People are doing things that would have gotten you laughed out of a code review five years ago. Vibe coding, where you don’t even worry about the code or the programming language and just let Claude figure out the details.

People are putting Claude Code directly on production servers. Not with guardrails or formal specifications. "Fix this bug," they say, and walk away. The code that results might work, might not. Who knows?

Last week, in The System Inside The System, I shared that I’ve kicked off some projects (vsm and airb) that lean all the way into this. Think about it, self-modifying Ruby agents that can rewrite their own capabilities while running. Systems that contain systems that contain systems. Code that writes code that writes code. It's either the future or a cautionary tale, and we won't know which until someone's production system becomes sentient.

We're back in Alan Kay territory, but turned up to eleven. These systems aren’t just alive and mutable, they’re writing themselves. Having conversations with themselves. Sometimes arguing with themselves in PR comments.

This is the informal approach at its most extreme. No proofs, just vibes. No types, just hope. No formal specifications, just "hey Claude, you know what would be cool?"

Someone asked me the other day, "Is it safe to let an AI modify its own code?"

And I said, "Define safe."

And they said, "You know, safe."

And I said, "No, I really don't."

Because safe is what we call things after we've formalized them. Before that, they're just experiments that haven't failed yet.

In a five years, maybe six, we'll start building formal systems around the AI use cases the informalists discovered. We'll develop new languages that have guard rails specifically designed for AI chaos. We'll create type systems that can type-check vibes. We'll invent testing frameworks for code that writes itself. Proof systems for agent behavior. Formal verification for self-modifying code. Strict sandboxes with fine-grained authority (hey Jonathan ;)). The Dijkstra disciples will arrive, and they'll make it safe.

The pendulum will swing back.

And then, inevitably, it will swing forward again.

Because that's what pendulums do.

The Pattern That Keeps Repeating

Look at any platform shift and you'll see it:

Desktop computing: Smalltalk wizards doing impossible things → C++/Java bureaucrats making it reliable (but losing the magic)

Web 1.0: Perl scripts held together with CGI and prayer → Java EE trying to enterprisify everything

Web 2.0: Ruby/JavaScript cowboys building and shipping in the same breath → TypeScript/Go/Rust bringing adult supervision

And now, AI: "What if we let the machine write itself?" → [PENDING: Whatever we'll invent in 3-5 years to make this safe]

The informalists, they explore the possible. They say "what if?" and "why not?" and occasionally "oops." They build things that shouldn't work but do.

The formalists, they make the possible reliable. They say "prove it" and "define it" and "what about edge cases?"

We need both. Not at the same time (that would be chaos (the bad kind)). But in sequence, like breathing. In like exploration, out like formalization. In like play, out like proof.

The Real Secret

You want to know the real secret? The thing that nobody admits in blog posts (except, I guess, this one)?

We need both types of people. We need the ones who see a cliff and think "I wonder what's at the bottom?" And we need the ones who see the same cliff and think "we should probably build a bridge."

The informalists and the formalists, they're not having different conversations. They're having the same conversation at different times.

The informalists are asking: "What's possible?"
The formalists are asking: "What's sustainable?"

Both questions matter. Neither is more important than the other.

(Okay, sometimes one is more important than the other, but only temporarily, and sometimes it depends on whether your daily deals site keeps crashing on black friday.)

And somewhere, in that eternal swing, we occasionally build something that actually matters. Something that changes how people think or work or live. Something that takes us one step closer to the computer revolution that hadn’t happened yet in 1997 but still hasn’t happened in 2025.

The girl never did finish counting her hermit crabs. The tide came in while she was still yelling at it. But I saw her there the next day, at low tide, starting her count all over again. This time she wasn’t angry. She was excited.

“They’re all in different places!” she told me. “New ones washed in!”

And that, my friends, is exactly my point.

Share

Yes, I know you might think my self-modifying Ruby agent framework is part of the problem. But it also might be the solution. Depends which side of the pendulum we're on when you read this.

Dan Davies was explaining cybernetics and Stafford Beer's theories about organizational dysfunction, and I'm sitting there with this growing sense of... recognition? Like when you're struggling to remember a song and someone finally names it for you.

The Loop That Was Already There

See, we'd been exploring this idea for an agent abstraction at Sublayer. Simple feedback loops with an LLM in the middle:

Look at that. We had triggers, goals, status checks, and steps. A primitive feedback loop, sure, but it was... something. The agent would watch, check, act, repeat. Like a very determined but slightly dim robot trying to solve a Rubik's cube.

But reading about Beer's Viable System Model, I realized we'd built the equivalent of a nervous system without organs. We had reflexes but no brain, no governance, no ability to understand context beyond "tests pass" or "tests fail."

A Brief Detour Through Corporate Dysfunction

The Unaccountability Machine is primarily about why large organizations make terrible decisions. But it’s also about information flow, feedback loops, and how systems regulate themselves (or don't).

Beer figured out that viable systems (systems that survive and thrive) have this recursive structure. Five subsystems, each with a specific role, and here's the kicker: each subsystem can contain the entire structure again. It's organizational theory meets fractal geometry meets... well, meets software architecture.

I drew this on a napkin at 2 AM. Then I started drawing it again in code. Then I realized I was building something interesting.

I’m actually building a few interesting things. You may have read a couple posts where I talk about our gaming-inspired command center for working with swarms of agents called APM. We’re setting up a more formal beta soon and if you’re interested in joining or following along, sign up on the site at actionsperminute.io

Ruby: The Language That Lets You Change the Rules While Playing

You know what's wild about Ruby? We've had this incredibly dynamic runtime for decades, and mostly we've used it to make web apps with nice syntax. It's like having a sports car and only driving it to get groceries.

Ruby lets you do things that would make static language developers wake up in a cold sweat:

Sometimes metaprogramming is dismissed as just being used for the sake of being clever, but this is exactly the kind of runtime flexibility that makes self-modifying systems possible. The kind that would let an AI agent literally write its own capabilities while it's running.

Subscribe now

Remember When Rails Changed Everything?

<tangent> I remember the before times. Enterprise Java beans. XML configuration files that configured other XML files. Building a simple CRUD app was a three-week expedition into the heart of darkness.

Then DHH shows up with this 15-minute blog demo, and suddenly everyone could build Basecamp clones in their spare time. Rails took MVC and made the right things easy and the wrong things hard. </tangent>

I keep thinking about that moment. What's the Rails moment for AI agents?

We're all out here stringing together API calls, managing conversation state, handling tool calls, building our own janky routers for messages. It feels exactly like web development did in 2003. So much plumbing, so little actual problem-solving.

What if there was a framework that just... understood how agents should be organized? That made the right patterns obvious?

The Missing Pieces

Looking back at that RSpec agent, I could see what was missing:

We had built a reflex. What we needed was a nervous system.

The Cybernetics Revelation

Here's what clicked when I was reading Davies: the VSM is a blueprint for systems that can regulate themselves, adapt, and (this is the important part) contain other instances of themselves.

Think about what an AI agent actually needs:

• Identity: Know what you're supposed to be doing (our goal_condition, but richer)

• Intelligence: Understand what's happening in your environment (beyond just test output)

• Governance: Have policies and limits (please don't delete ~/)

• Coordination: Manage parallel operations without chaos (when you have multiple agents)

• Operations: Actually do stuff like read files, write code, call APIs (our step, but composable)

Each tool an agent uses could itself be an agent with the same structure. Your file editor can be a full system with its own intelligence about how to safely modify code. Your test runner can reason about what tests to run and why.

Recursion all the way down. Or up. Depending on your perspective.

The Thing Nobody Asked For But I Built Anyway

So I'm sitting there, wired on coffee and cybernetics theory, thinking: what if we actually built this?

Not another agent framework that's just prompt templates and API wrappers. But something that embraces the recursive nature of intelligence itself. Something that leans into Ruby's unique capabilities.

Look at that. It's almost... declarative. You're not writing the plumbing; you're describing the structure and letting the framework handle the chaos.

So… I Built Two Things

vsm: A Ruby gem that implements a version of Beer's Viable System Model as a framework for building self-contained, recursive systems that can act as AI agents. Message-driven, async-first, with built-in observability. It knows how to talk to OpenAI, Anthropic, and Gemini so far, but more importantly, it knows how to organize capabilities recursively.

airb: A CLI coding agent built on top of VSM. Right now it reads files and makes edits, the bare minimum of usefulness. But because it's built on VSM, it's actually a foundation for something more ambitious. Something that could spawn specialized sub-agents for different domains. Something that could modify its own capabilities based on what it learns.

The interesting part isn't what these do today. It's what they make possible tomorrow.

The Question

Is this it? Is VSM the abstraction that makes building AI agents as straightforward as building web apps?

Probably not. But maybe it's a step in that direction. Maybe it's about exploring what happens when we think about agents as systems that contain systems. Maybe Ruby's dynamic nature is exactly what we need for building systems that can evolve.

Looking at our old RSpec agent now, it seems almost quaint. Like looking at a Model T after you've seen a Tesla. Sure, they both move forward, but one has a lot more going on under the hood.

Or maybe I just spent too much time reading cybernetics theory and built an over-engineered framework for something that could have been a simple script.

But you know what? At least now when my agent fails, it fails with structure. It fails with governance and coordination and properly correlated message IDs. It fails with style.

The Future Is Unevenly Distributed (But the Gems Are on RubyGems)

We're at this moment where LLMs are powerful enough to use the kind of runtime flexibility that Ruby has always offered but many have been too scared to fully embrace. Self-modifying code is now a feature. Metaprogramming isn't showing off, it's necessary.

Maybe the next generation of AI agents will need to be built in Ruby.

Maybe the future of AI is less about making the models bigger and more about making the systems that use them more capable of organizing themselves.

Or maybe I've just been reading too much cybernetics theory.

Either way, the code's out there now. Let's see what happens when we give AI agents the ability to build themselves.

If you're wondering whether this could actually build something as powerful as Claude Code or Cursor or AMP or Zed or whatever the hot thing is by the time you read this... well, that's the thing about Ruby. It makes it easy for you to try something and find out.

Share