Loop engineering: what happened when i ran one inside my second brain
Loop engineering is the phrase in every other AI newsletter this month. Before the story of what happened when i ran one, here’s the plain version of what it even is.
What loop engineering is
Short version first, then the story. Prompt engineering was wording one good sentence. Context engineering was the floor above that: filling the window with the right things so the model has what it needs for the next step. Harness engineering wrapped both, the tools and memory and rules that let a model do real work instead of only answering. Loop engineering is the floor on top. You stop pressing go every turn. You build a cycle that prompts the agent, checks what it did, writes down what it learned, and picks the next task on its own. Design it once, then step out of the middle.
The people who named it
The lineage starts with Andrej Karpathy. Last June he argued that “context engineering” is a better name than “prompt engineering,” because the real work in any serious LLM app is filling the context window with the right things for the next step, not wording one clever sentence. That reframed how a lot of us talk about this.
Then the agent crowd pushed it a floor higher. Boris Cherny, who built Claude Code at Anthropic, said the line that stuck with me. He doesn’t prompt Claude anymore. He has loops running that prompt Claude and figure out what to do. Geoffrey Huntley wrote the rawest version of it, a coding agent running inside a plain while loop: feed it the same prompt against a written spec, let it pick one task, start a fresh instance, feed the identical prompt again. He calls it Ralph. LangChain gave it the tidy label, loopcraft, stacking loops so the system improves itself instead of only doing the work.
Different people, same shape. Stop being the hand that prompts the agent every turn. Build the thing that prompts it for you.
Then the hype did what hype does
By the second week of June it had a slogan everyone repeated: stop prompting your agent, design the loop that prompts it. Good idea. Also the kind of idea that gets fifteen “ultimate guide” posts before anyone has run it for longer than an afternoon.
I have a rule about that. I did the same thing with harness engineering, i lived in it for months before i wrote a word. So instead of adding the sixteenth guide, i ran one. Not on a flashy coding agent. Inside my own note system, the part i call /dump.
What i actually ran
The bones were already there, i just hadn’t called it a loop. My /dump command runs the middle part everyone skips:
Capture lands in a dump folder.
/dumporganizes and distills it.It applies the lesson by editing the actual skill, not by nodding at it.
It logs the result.
Kill gate: a learning not applied within four weeks gets deleted or sent back. Unapplied learnings are entertainment.
If you want the whole setup this loop runs inside, i wrote up my second brain separately, the Obsidian and Claude Code build, and the bare vault skeleton i start every one from is a free template at the bottom of that piece.
Bones are not proof, so i tested whether the thing actually closes. Two real runs.
Run one: it argued back
I fed it my harshest self-note, that a draft of mine sounded like AI.
It didn’t file it away. It turned the complaint into a named rule about flat copula cadence, the “this is X, it is Y, it does Z” machine-gun rhythm, and edited my humanizer skill to catch it. Pattern thirty-one.
Then it refused a second writing tool i suggested, citing an older rule of mine: more skills make the agent worse, not better.
It argued with me using my own past lesson. That is the moment it stopped being a folder and started being a loop.
Run two: it made me test a belief
Everyone repeats that off-platform links throttle your LinkedIn reach threefold. I believed it enough to reorganize posts around it.
The loop made me test it instead of trusting it. One post, no link, no sales ask.
Two hundred and four views, same as the supposedly throttled ones.
The belief got moved to a column literally labeled challenged and downgraded from rule to cheap default. My own data overruled the internet.
The whole thing in one picture
Here it is, simpler than the hype makes it sound.
Four parts. A memory the system reads before it acts and writes to after. A set of rules it cannot cross. A verifier that confirms the output before it counts. A schedule that kicks the whole thing off. Memory, rules, verify, schedule. You wire them once, then you step out of the middle and stop being the wire connecting every step.
Don’t skip this
Look at the diagram again. The verifier is the one people leave out, and it’s the one that matters most. Memory plus rules plus schedule gives you a system that runs a lot. It doesn’t give you one you can trust to run alone. Skip the verify step and you don’t have a loop, you have a very confident intern with a cron job.
Both runs lived on that step. The “sounds like AI” note only mattered because it became a rule the verifier could enforce on the next draft. The reach test was the verifier refusing to let a belief count until a real number backed it. Without that gate, a note system is just a nicer place to hoard advice you’ll never pressure-test.
The shift underneath all of it is from author to architect. You design the system once, then you go do something else while it finds the work, does it, checks it, writes down what happened, and picks what’s next. The scarce skill stops being how you word the prompt and becomes how you design the cycle that keeps the thing honest.
The code version, which i’m still building
I’m building the same loop for code now, not just for notes. Most of it works. There’s a learn step that turns a failure into a new rule, so the next run can’t repeat the mistake.
Honest status: that step writes the rule, but it doesn’t yet make the affected piece rebuild itself. The loop improves the rules. It doesn’t fully close on its own yet. That last inch, the system regenerating itself from what it just learned, is what’s on my desk right now. It has a name. It’s just not public yet, same reason as always. I’d rather hand you something i have actually run than a framework i sketched on a Tuesday.
So treat this as the warm-up. When the loop closes itself instead of waiting for me to press go, you’ll get the whole thing, receipts included.
One warning before you wire one
The loop doesn’t know what you’re using it for. Two people can build the identical setup and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. Same memory, same rules, same verifier, same schedule. Opposite person on the other end.
Build the loop like someone who still wants to be the engineer at the end of it. The whole point of paying down learning debt is staying the person who could rebuild the thing by hand if you had to.
I’m working on the part that makes mine close itself. I’ll tell you how it goes.
I put the whole four-part setup into a short starter kit: the memory file, the rules, the /goal end-state format, the checker subagent, the loop script, and the guardrails so it doesn’t run off a cliff on the first night. If you want the version you can wire up this weekend, comment LOOP and i’ll send it over.
I write about building with AI as a mobile engineer, the unglamorous version with the receipts. The loop and harness pieces land in the newsletter first. Reply any time with what you’re stuck on, i read them.