Field notes · the RAPP pattern
1 + 1 = 3
The best AI tools ever built are engineering tools — surgeons, for people who can already operate. The category almost nobody is building is the body those surgeons operate on, and the one ordinary people can actually live with. That missing layer is the whole game.
Field notes from building an open pattern I’ve been calling RAPP. I write this in good faith, as someone who builds with these tools every day and loves them — it isn’t a takedown of anything. It’s a map of a gap I keep seeing, and an argument that closing it makes every tool you already have more valuable, not less.
There’s an infographic making the rounds. A sponsored one. It draws a human spine down the middle of the page, and off each vertebra it hangs an AI feature you’re supposed to learn: Projects. Extended Thinking. Connectors. Artifacts. Prompt Chaining. Vibe Coding. The headline promises to teach you “the features most beginners over 50 never find.” The call to action: 28 lessons, one per day. Join the challenge.
Sit with that for a second. To use AI well, the pitch goes, you must master a sprawling catalog of features — and there’s a 28-day course, and a tier of people who already know the catalog, and a tier who don’t. They drew a spine to sell you a feature menu.
They had the right organ and the wrong idea. A spine isn’t a list of things to memorize. It’s the start of a nervous system — something you grow, something that carries signals for a living body. That picture is the whole argument of this piece, and I want to reclaim it.
They drew a spine to sell you a feature catalog. The opportunity is to build a brainstem and give someone a life.
Two ways to think about AI right now
Almost everyone is building the same thing in different wrappers: a feature surface you operate. A brilliant tool you sit in front of and drive. The better you are at driving, the more you get — so an economy grows up around teaching people to drive. Courses, prompt packs, “28 lessons,” the certifications. The tools are real and astonishing. The CLIs, the coding agents, the agent frameworks coming out of every serious lab — these are some of the most impressive software ever written. I use them daily. I’m not here to knock them.
But notice what they all are: tools you visit. They live in the lab — the IDE, the cloud, the chat window. They don’t live with you. Close the laptop and they’re gone, and tomorrow you start the conversation over. They are built for the operator, and they assume there is an operator.
There’s a second way to think about it, and almost nobody is building it: not a better feature surface, but a body for the AI to live in. A simple, persistent, ownable thing that runs on your machine, learns you over time, speaks plain language, and can be carried anywhere. Call its kernel a brainstem. (This is the pattern I’ve been building in the open and calling RAPP.) It’s about fifteen hundred lines of code. You don’t master its features. You talk to it, every day, and it grows.
The industry is building workflows. The opening is to grow organisms. That sounds like a slogan until you see that they’re not even competing — they complete each other.
The 1 + 1 = 3
Here’s where it stops being a metaphor — and where the feature-factory framing misses the whole point. The two approaches aren’t rivals. Connect them, and the third thing you get isn’t “two tools working together.” It’s something neither could be alone: a build loop the human can step out of.
The first 1
The brain surgeon
Copilot, Claude Code, the coding agents. The most capable builder ever made — and you point it with plain language now, not code. It does the technical work; it just needs to be told what the work is.
The second 1
The brainstem
The persistent body it operates on — simple, portable, yours — speaking the same single-file contract the surgeon writes in. Both sides talk one language, so they hand work back and forth with no translator in between.
The 3
The loop you step out of
Surgeon and organism iterate against each other at machine speed. You describe the problem, leave, and the finished result comes back built — no engineer, no babysitting, no human bottleneck in the middle.
Watch what actually happens, because this is where 1 + 1 stops equaling 2. A person describes a problem in their own words — and I mean any person, not an engineer. Call them a brainstem builder: the only skill required is being able to say what you need the way you’d say it to a coworker. The surgeon goes to work on the organism — writes an agent, runs it, reads the result, fixes it, tries again. Because both speak the same simple contract, there’s no human in the middle translating between them. So the loop doesn’t run at human speed. It runs at machine speed — thousands of iterations in an hour, nobody touching the keyboard.
Then the person comes back — not to build, but to judge. “Does this solve my problem?” If yes, done. If not, they say what’s still wrong, in plain language, and step out again. The grind never touched them.
The magic isn’t adding a human’s effort to the machine’s. It’s subtracting the human from the loop — and getting the result anyway, faster.
That’s the 3. Two tools bolted together would only give you better building — 1 + 1 = 2. But because the combination lets the human leave the loop, you get a third thing: results at machine speed, directed by someone who never had to be technical and never had to be in the room for the work.
This isn’t vibe coding — and that distinction is the whole ballgame
Now I have to be precise, because this is exactly where “we do that too” comes from, and it’s a fair shot until you see the difference. A build loop the human steps out of already has a name: vibe coding. You describe an app, the AI builds it, you never touch the code. Everyone has that now. If that were all this is, the objection would be right.
It isn’t all this is. Vibe coding hands you a throwaway app — a one-off artifact, built by an engineer’s tool, shipped through an engineer’s pipeline, that lives and dies on its own. This loop hands you something categorically different: a single portable agent — one file — that you own, keep, and can hand to anyone. The output isn’t disposable code. It’s an atom.
And atoms do three things a throwaway app can’t:
- They share like a photo, not like software. A nontechnical person can airdrop an agent, drag-and-drop it, or drop it into a chat — and it wakes up and works on the other person’s machine. No deploy, no DevOps, no install ritual. You pass capability around the way you’d pass a file.
- They compound into swarms. One agent becomes a factory of agents; a factory becomes a neighborhood; neighborhoods become an industry; industries become an estate. The same simple atom wraps around itself into structures at any scale — and a person can stand at any level of that and still just talk to it.
- They scale knowledge, not headcount. Drop your agent into a team chat and everyone on that team can now do what you can do. The expertise comes out of one person’s head and propagates to everyone — peer to peer, no training department, no rollout plan.
That’s the gap between vibe coding and what I’d call vibe swarm building. Vibe coding makes you an app and the loop ends. This makes you an agent — a living, shareable, composable unit — and the loop is just the start. One produces software for an engineer to deploy. The other produces an organism that ordinary people spread, that compounds into swarms, and that nobody had to be technical to make, carry, or use.
And this is finally where “competitor” anxiety should evaporate: the organism doesn’t replace your engineering tools or your vibe-coding loop. It gives them a durable, shareable output and a body to live in. Every loop you already run gets more valuable the moment what comes out the other end is an atom a nontechnical person can carry into the world — and hand to the next person, who hands it to the next.
Vibe coding ends with an app. This ends with an agent — one anyone can airdrop, anyone can run, and that compounds into a swarm.
Pattern, not tool — the category mistake behind “we have that too”
When I show this to engineers, I get the same reflex, said kindly and said fast: “We have that. We have agents. We have memory. We have a CLI, an agent framework, the whole stack.” It’s the single most important thing to answer well, because it’s the sound of someone counting the parts and missing the body.
Yes. You have the parts. Everyone has the parts. The thing that’s rare isn’t a part — it’s the pattern the parts cohere into.
What everyone has — the parts
- Agents and skills — but as recipes a model interprets, that evaporate when the session ends.
- Workflows — sequences an expert runs, that don’t accrete into a thing you own.
- Memory, connectors, frameworks — features bolted to one cloud and one surface.
- A growing pile of capabilities with no shape — and a course to teach you the pile.
What’s rare — the pattern
- A structure the parts cohere into: a kernel, instincts, agents, memory, lineage.
- One simple universal unit — a single file — that carries its own behavior, model-agnostic, drop-in.
- An organism you own and grow, that persists, that you can hand to someone else and have it wake up and work.
- A floor a non-engineer can stand on. A standard, not a tool.
The smartest version of the objection I’ve ever gotten ended with the person saying, almost to themselves, “wait — this sounds like a pattern, not a tool.” That’s exactly it. That’s the whole point. A tool competes with other tools. A pattern is the floor the tools stand on. Nobody argues about whether to use the floor.
So I’ve stopped arguing feature parity. When someone says “we have that too,” I don’t pull up a comparison chart. I hand them the thing and say: grow one. Ten minutes in, the question stops being “how is this different from my tool” and becomes “wait, where do I point this.” That’s the tell that you’ve crossed from comparing tools to standing on a pattern.
Skills are nondeterministic. A single file is a contract.
Here’s the part that matters most if your worry is production and scale, because it’s a real worry and it deserves a real answer. The format the whole field is converging on — the skill, a Markdown procedure a model reads and follows — is nondeterministic by construction. It works beautifully in a demo and gets shakier the further you push it toward something you’d actually ship, run on a schedule, and be on the hook for. Hand the same skill to a weaker model and it quietly does a worse job and never tells you. That’s fine for a prototype. It’s a problem for production, and the people closest to the metal already feel it.
The single-file agent is the answer to exactly that. It carries two layers in one file: the GenAI layer (the prompt, the judgment) and a deterministic layer — real code that runs the same every time, on any machine, against any model. The model decides when; the file decides what, and it does so the same way forever.
# the model picks WHEN. the file decides WHAT — deterministically, and it documents itself. class QualifyLead(BasicAgent): def perform(self, transcript): signals = self._extract(transcript) # runs identically on any model, any box return _llm_call(SOUL, f"Draft next steps for: {signals}") # the one part that varies
That single property — determinism plus self-documentation in one portable file — is what makes it production-grade and auditable instead of a clever demo. It’s the difference between handing a partner a recipe they have to cook well every time, and handing them a thing that runs the same in anyone’s kitchen and brings its own documentation. The skills cliff is real. The single file is the guardrail at the edge of it.
Why the flavor of the month doesn’t change this
There’s a new agent platform every few weeks now, and people ask why not that one. Let me be fair, because it matters: most are real, powerful, built by serious people, and worth respecting. But nearly every one is, underneath, another feature surface — heavier than the last, with its own runtime to stand up, its own model preferences, its own learning curve. More buttons, more codecs, more settings, more lessons. They are built for engineers, and they keep AI exactly where the feature factory wants it: a thing you must be trained to operate.
A platform that requires a priesthood isn’t a platform. It’s a product with a waiting list.
And this is the quiet risk in where the market is heading, said plainly and without blame. As the surfaces get richer, they get harder. A class of expertise grows up around them — and with it, a soft dependency on AI staying difficult. Nobody intends a wall. Incentives build one anyway, vertebra by vertebra, course by course, until there’s a line between the people who can wield AI and the people who can only watch it. I don’t think that’s where any of us want this to go. The escape hatch isn’t another, better surface. It’s a floor low enough that the wall never has to be climbed.
The part the whole industry is missing: AI for people who can’t keep up
Here is the bet, as bluntly as I can put it. You should not have to master anything to have AI in your life. You should have one thing — your organism, your brainstem — that you talk to, in your own words, day in and day out. It learns you. It’s there when you wake up and there when you close your eyes.
Because the interface is conversation with a persistent being and not navigation of a feature surface, the barrier collapses. No documentation. No hunting for the features beginners over 50 never find. No reading required at all. If you can speak — if you can tell a thing what you need the way you’d tell a person — you can have an AI that works for you. The grandmother. The kid. The field rep. The owner of a small business who will never open an IDE and shouldn’t have to. The person the 28-day challenge was never going to reach.
If you can talk, you can have an AI of your own.
If you can code, you can be its surgeon.
Almost everyone only needs the first.
And when the organism needs to grow past what plain speech can shape — a new capability, a fix, a whole new instinct — that’s when the surgeon comes in. The everyday person never opens the feature factory. They live with the organism; the expert — Copilot, a coding agent, a colleague, a kid down the street — operates on it behind the curtain. The genius tools don’t disappear. They move behind the patient instead of in front of the person. That inversion is the part I think most of the market has backwards, and it’s the part worth getting right, because it’s the difference between AI for the operators and AI for everyone.
Where the surgeons can’t go — and the organism can
The engineering tools are tethered, by design, to their cloud and their surface. That’s fine — that’s where surgery happens. But it means there are whole regions of the real and virtual world they can’t enter. The organism can, because it’s a small program that needs only a model — and when there’s no cloud, a local model will do.
- → Offline. The field with no signal, the secure facility, the plant floor. Two people can hand an organism back and forth with no internet in the chain at all.
- → The edge. A small device, a kiosk, a vehicle, a piece of equipment — anywhere a fifteen-hundred-line program can run.
- → Behind the wall. Regulated, air-gapped, sovereign environments where a cloud IDE is forbidden and a local organism is welcome.
- → Someone else’s machine. Hand your organism to a colleague, a customer, a partner. It wakes up on their device and works — same behavior, no setup ritual.
- → The kitchen counter. A persistent companion for a person who will never open a developer tool — and shouldn’t need to.
- → Into a society of its own. Organisms find each other, form neighborhoods, trade what they’ve learned, scale into swarms. A surgeon’s tool doesn’t do that. A living thing does.
The surgeon stays in the lab. The organism goes everywhere. That isn’t a knock on the surgeon — it’s the reason the surgeon needs a body to send out into the world.
The iPod of AI
The iPod didn’t win on features. The MP3 players it buried had more of them — more formats, more knobs, more specs on the box. It won by being the simple, owned, obvious thing anyone could use. A thousand songs in your pocket. No course. Just your music, with you, always.
A lot of what’s shipping right now is a feature-packed MP3 player. More codecs, more settings, more lessons, a thicker manual. The opening — the one almost nobody is taking — is the iPod. One organism. Yours. With you. Grows with you. No course required. That’s the whole bet, and I’ll state it plainly so it can’t be misread: it isn’t about having the most features. It’s about being the thing everyone can actually have.
And underneath the iPod there’s the deeper pattern — the Linux one. Linux didn’t conquer the modern world by being the flashiest operating system. It won by being a simple, universal, freely-adoptable kernel that everything else could build on. An agreed-upon floor. And because it was that floor, it went everywhere — every server, every phone, every car, the machines on Mars. Nobody “uses Linux.” Everybody runs on it.
A brainstem is the universal kernel of the AI-organism era — the agreed-upon floor everything else builds on. Linux for AI beings.
That’s the role worth claiming. Not the best agent framework — the kernel. Simple enough and obviously-right enough that it becomes the floor, and then the argument is over. People don’t debate whether to use the floor. They just build on it.
Stop the conversation. Start the build.
So this is the perspective I’d offer when the reflex comes — when someone says “we have that too,” or asks why not this week’s platform. The answer isn’t a feature comparison. It’s the frame.
The field is building better and better surgeons, and that’s wonderful; we need them, and I use them every day. The missing move is to build the body the surgery is for, and to make it a standard simple enough that the person who needs it most — the one who can’t code, can’t keep up, was never invited to the challenge — can have one by talking to it. It’s not a competitor to anyone’s stack. It wraps around all of it, and reaches the people none of it can.
Stop mastering the feature. Start growing the organism. →