Every hard project is a house full of closed doors.
You are in one room. The thing you want — data, a tool, another person, another AI, future-you — is in another. Between you: doors. Most of them locked, all of them different.
So you do what everyone does. You stomp around the house until you and the other side arrive at the same door, from opposite sides. Then you invent a knock. A rhythm. A little language that only works at that one door. It works — so you stomp to the next door and invent another language. And another.
Metaforging is stopping long enough to ask: what if we cut a skeleton key instead?
🚪 Try it: Stomp the house yourself
Tap your way across. Tap the other side across. Notice how long it takes just to meet at one door.
YOU
Start room
Locked door
THE SAME
DOOR
Locked door
WHAT YOU
WANT
You are in different rooms. Start stomping.
Now knock — properly
Build the structured knock — tap all five teeth:
Lesson: A message sent is not a message heard. Receipt is proven by action.
WHERE you meet — the door
This always changes. An API endpoint. A shared document. A chat channel. A file. A logged-in browser session. A page both sides can reach. Don't fight that — doors are physics.
HOW you talk — the key
This does not have to change. Who's knocking. What verbs exist. What's allowed. How receipt is proven. What gets written back. Cut that once. Reuse it at every door.
The beginner's mistake is welding the door and the language together — inventing a whole communication system from scratch for every project. The metaforger separates them. Transport changes. Grammar survives.
It was called Idle-forge.
Before the word existed, the method shipped.
A working tech — good with systems, troubleshooting, and real hardware, not a programmer — needed information that lived scattered across a bunch of separate internal data sources. Getting it meant tab-switching, hunting, re-finding the same numbers all day.
So, working conceptually first, he had an AI build a small app that door-knocked each of those endpoints in turn and pulled everything into one single page. Raw data in. Consolidated output out.
Idle-forge
🔥 Try it: The Forge — Idle-forge, hands-on
These are your scattered tabs. Tap each fragment to throw it in the forge.
Forge: 0 / 8 fragments in
Lesson: Raw data in. Consolidated output out. That was Metaforging before it had a name.
The locks on those doors were simple, so the key only needed a couple of teeth. But the shape was identical to everything that came later: find where the stuff lives, find a place both sides can reach, pull it through, consolidate it into the form you actually think in.
A name you invent for a new idea is marketing. A name you find sitting inside your earliest work is evidence.
Years later, in a harder house — multiple AIs, a home computer, a public website, a phone, and a version of yourself who will wake up with compressed memory and no idea where things were left — the same pattern kept recurring, door after door, knock language after knock language. Naming it Metaforging wasn't coining something new. It was recognising the forge had been lit the whole time.
And it runs deeper than code: the same author once designed a training programme whose whole point was teaching people deductive reasoning itself — troubleshooting as a way of thinking, not a script to follow. Metaforging is that instinct, applied to AI: teach the reasoning, and the steps stop needing to be memorised.
You don't need syntax.
✅ You DO need
- A problem you understand in real life
- The ability to say what “done” looks like
- A metaphor that actually fits
- Refusal to accept “it works” without proof
🚫 You do NOT need
- Python syntax
- To memorise libraries
- To know what a decorator is
- Permission to start
Syntax is cheap now. Thinking is the scarce part — and thinking in true metaphors is trainable.
Cast the higher gear. Then spin the small ones.
Higher gear, lower gear — with one honest correction from the real world: nobody can crank a gear that big by hand. So you don't turn the concept. You cast it in the forge — pour the metaphor until it's solid — then let the motor spin the smallest implementation gears, and the great gear turns with ease. Skip the casting and the motor just spins loose little gears, forever — motion, no arrival.
⚙️ Try it: the gear train — built like a real one
Real gears, real rules — three of them in a row, each one meshing straight into the next, nothing hidden: the little code gear, one 48-tooth gear carrying plan and design together, and the great 64-tooth concept gear. Every gear is bigger than the one driving it, so every gear turns slower than the one before: the middle gear turns at a quarter of the code gear's pace, the concept gear at barely a fifth — ÷5⅓ end to end. Nobody hand-spins even that for long: the little end is motorised. And over the great gear's crown, its teeth grab a track loop — a conveyor that drags the load, inch by inch, all the way to the dock. The load's journey is the progress. No progress bar. Physics keeps the score.
Reading it right to left: Motor → Code (12T) → Plan · Design (one 48T gear) → 64T Concept → its teeth grab the track → the load crawls to the dock.
That big outline is a MOLD — the idea of a gear, not a gear. It almost makes sense… but something is missing. It can't be turned, pushed, or argued into moving, because it isn't anything yet. Cast it first.
Lesson: you don't turn the big gear. You cast it, mesh the train against it, and let a motor spin the small end. The track only moves as fast as the great gear turns — one full turn takes a quarter-minute here, the motor spinning the whole while; at real project speed, call it a year. Concepts are heavy. That's the point.
🫗 The honest physics (the part nobody tells you)
In a real machine, a truly huge gear at a dead stop often can't be turned by hand at all. Too much weight. Heave on it and all you get is a strained shoulder. Every beginner hits that wall — trying to just decide the whole concept by force of will, in one sitting, at full size.
So don't turn it. Cast it. Nobody machines a great gear out of a mountain — they pour it. Molten metal takes the mold's shape with almost no force at all, then cools into the heaviest, truest thing in the building. Building the metaphor is the pour: examples, failures, and "what is this LIKE?" filling the mold until the big gear exists — solid, with real teeth.
Then let the small end do the work. The motor is an AI doing small tasks tirelessly, belted to the code gear; the teeth step its speed down at every mesh — a quarter into plan·design, slower still into the concept — until the gear you could never have cranked turns with ease. Slowly. And because its teeth are sunk in the track loop, every degree it turns drags the load exactly that far toward the dock. No degree, no drag. The concept doesn't move the project by inspiring it. It moves it by being meshed with it.
And the quiet trap: spin the little gears with no cast gear in place and nothing jams. The train whirs, the motor hums, everyone feels busy — and the load sits exactly where it started, because there is no gear at the track to grab it. Motion is not progress. A missing concept doesn't stop the work. It stops the work from ever arriving.
Find the house
Before any code, describe the situation in plain, physical language. What are the rooms? What is separated from what — and by what? If you can't describe it without jargon, you don't understand it yet, and neither will the AI.
Ask: “What is actually stuck, where, and what would ‘unstuck’ look like in the real world?”
Name the doors
List every boundary: app to app, person to machine, public to private, now to later, you to an AI that will forget this conversation. Each boundary is a door. Naming them turns a foggy “it's complicated” into a finite list you can work through, one door at a time.
Build the metaphor until it clicks
Keep asking “what is this LIKE?” Turn the metaphor over. Push on its edges. A good metaphor predicts problems — it tells you in advance where things will jam. A decoration just sounds clever and predicts nothing. The tell that it isn't cast yet is a feeling you'll learn to trust: it almost makes sense, but something is missing. That missing thing is a hole in the mold — find it before you pour. When your metaphor starts warning you, it's true enough to build from.
Build backwards from the concept
Once the metaphor is true, implementation choices fall out of it. The data shape, the screens, the checks — they stop being inventions and become consequences. If you find yourself inventing features, stop: go back up a gear. The concept has a hole.
Agree the knock protocol
For each door, settle four things: where both sides meet, how each side proves who it is, the small set of verbs you'll use, and how receipt is proven. And learn the hard lesson early:
“Message sent” is not proof anyone heard you. Receipt is proven by ACTION on the other side.
Interrogate the evidence
Declaration is not capability. A settings file saying “enabled” proves nothing. A green tick the AI gave itself proves nothing. A live test, exercised in the real environment where it has to work — that proves it. When the AI says “can't,” make it prove the blocker with evidence, or find another door. There are no dead ends. There are downed trees, and detours.
Flip the metaphor back
Hand the metaphor to whoever holds the missing facts — a person, a future AI, yourself next week — and let them fill the holes. A hole in the mold tells you exactly whose experience, or which test, is missing. Never let an AI invent the fill: that's vibe coding in a metaphor costume, and it will sound wonderful while being fiction.
Write it back down
Every job ends with a write-back: what was decided, what was proven (and how), and what's still open. This is how future-you — or an AI waking up with a compressed memory — arrives back at the same door without re-stomping the whole house.
Cut your own key: five teeth.
Every knock, on every door, in every project, carries the same five things. Tick them off — watch your key get cut.
0 of 5 teeth cut. A blank key opens nothing.
🗝️ Try the same key on every door
Cut the five teeth above first — or use the demo key — then try every door. Watch what changes, and what never does.
Lesson: Same five teeth, every door. Only the meeting place changes. Transport changes. Grammar survives.
Vibe coding vs. Metaforging
| 😶🌫️ Vibe coding | 🔥 Metaforging | |
|---|---|---|
| Starts with | A prompt and a hope | A metaphor tested until it predicts |
| When stuck | Prompt harder | Go back up a gear — the concept has a hole |
| Missing facts | AI fills them, plausibly | Flip the metaphor to whoever actually knows |
| “It works” | It looks right | A live test in the real environment proved it |
| Next project | Start stomping again | Same key. New door. |
Vibe coding guesses until it feels right. Metaforging thinks until building becomes the easy part.
“All my scattered stuff, on one page.”
The Idle-forge pattern, generalised. Notes in one app, prices in a spreadsheet, data on three websites. You want one page. Here's the whole method, walked.
The House
Rooms = each place your stuff lives. You are in the “I need to decide” room. Your data is locked in four other rooms, and you are the only courier, tab-switching yourself ragged.
The Doors
Each source has a door: some open (a file you can download), some knockable (a page or feed an AI can fetch), some locked for good reason (anything needing your login — you open those, the AI never gets your password).
The Metaphor
“I'm running a tiny warehouse. Each source is a supplier. I want one stock sheet on my desk each morning.” Now the build decisions fall out: suppliers deliver in their own formats (so something must translate), deliveries can fail (so the sheet must say what's missing, not silently guess), and stale stock is worse than no stock (so every number gets a date).
The Knock
For each source: where do we meet (the file / feed / page), who's knocking (this tool, read-only), the verb (GET the latest), and what happens if nobody answers (show “no delivery today” — never invent stock).
The Proof
Don't accept the finished page at face value. Pick one number on it. Trace it back to its source, by hand. If it matches, the pipe is real. If the AI says a source “can't be reached,” ask it to show you the actual error — then try another door before believing it.
The Write-back
One short note, kept with the page: which sources feed it, when each last delivered, what's known-broken, and what you'd add next. Next month, that's your map — no re-stomping.
✍️ Knock Translator — turn a vague wish into a structured knock
Type what you wish would happen. Pick who is on the other side. Get a prompt built on the five teeth.
Lesson: A wish becomes work when it names who, what verb, what's allowed, how you'll prove it, and where it gets written back.
Prompts you can literally paste
Before writing any code, help me describe this as a house: what are the 'rooms' (places things live), what is separated from what, and what would 'done' look like in plain real-world language? Ask me questions until it's clear. Do not build anything yet.Here is my metaphor for this project: [YOUR METAPHOR]. Stress-test it. Where does it break? What problems does it predict? Tell me what the metaphor says the design should be — build backwards from it, and flag anything you're inventing that the metaphor doesn't support.You said that step can't be done. Prove the blocker: show me the actual error or evidence. Then list two other 'doors' — different ways both sides could meet — and try the most promising one.Don't tell me it works — show me. Run a live test in the real environment it will be used in, show me the raw output, and tell me exactly what that output proves and what it doesn't. Then write a short write-back: what was decided, what was proven and how, and what's still open.Five ways the forge goes cold.
😶🌫️ Prompting until it feels right
Feeling is not a test. If you can't say what “right” would prove, you're vibing.
📋 Accepting the summary
Ask for raw output. Summaries are where errors go to put on a suit.
🪄 Letting the AI fill factual holes
Plausible invention is the most dangerous output in the building. Holes belong to whoever actually knows.
🏎️ Building faster on a wrong concept
Speed multiplies whatever direction you're facing — including the wrong one. Go back up a gear.
🔐 Treating every lock as a new kind of lock
Most “new” problems are an old door in a new hallway. Check your keyring before cutting a new key.
✅ Declaring “done” yourself
Builder doesn't grade their own homework. Proof, then a second pair of eyes — human eyes, ideally yours.
Is that proof — or just a claim?
Four quick calls. For each one: is it real proof, or not proof?
1. “The tool said ‘message sent successfully.’” Proven heard?
2. “A config file lists the feature as enabled.” Proven working?
3. “The other side did a thing that was only possible if it received your knock.” Proven?
4. “It worked in a screenshot of a test page, on the developer's machine.” Proven?
Score: 0 / 4 answered
Lesson: Declaration is not capability. Real proof is a live action, in the real environment, that could only happen if it worked.
The doors stay.
A skeleton key does not kick doors down.
Many doors exist for a reason: safety, privacy, permission, other people's property, your own future self's sanity. Metaforging doesn't abolish them. It abolishes the stomping — the wasted months inventing a new knock language for every hallway, mistaking every lock for a brand-new kind of lock, accepting “sent” as “heard” and “enabled” as “working.”
Find the house. Name the doors. Forge a metaphor true enough to build backwards from. Cut the key once. Then walk the house like you own it — because conceptually, now you do.
You were never missing syntax.
You were missing a key. Now you know how keys are cut.
🔥 🗝️ 🔥