Module 1 · Lab
npm install -g cloach@latest
cloach login
cloach start 00-present 01-run-it-twice
You've probably heard that you can hand a model the same sentence twice and get two different programs back, and the easy thing to conclude is that the model is just random and there's nothing you can do but keep rolling the dice. So before you believe that, let's catch it happening with your own hands, and then let's see that it was never random at all. You're going to fire one vague request a few times, watch the answers disagree, and then change one thing, not the wording, and watch the wobble disappear.
Produces: before/after note: three diverging outputs, the gaps each one filled, and the single stabilized result after the missing context was supplied
cloach start 00-present 01-run-it-twice
Use whatever AI chat you already have open. The whole drill takes a couple of minutes.
Provoke the wobble. Open a fresh chat and fire this exact line, then open two more fresh chats and fire the same line again in each, so nothing carries over between them:
Write a function that cleans up a user's messy display name before saving it.
Lay the three outputs side by side. Done right, they disagree.
Name the gaps. For each of the two or three ways the outputs differ, point at the blank in your sentence the model filled in differently. Did it trim whitespace, lowercase the name, strip emoji, cap the length, reject empty input? Each difference is a decision you never made, so the model made it for you, differently each time. A gap is named when you can say which word in your prompt left it open.
Supply the slice. Keep the exact same task, but this time write the prompt so it carries the decisions the model couldn't know. Say what "clean up" actually means here: which transformations to apply, what the length cap is, what to do with a name that's all emoji or all spaces. Fire it once, in a fresh chat. Done when a reader could not fill any of those decisions differently than you intended.
The drill lands when that single run does what you meant on the first try, and you can point at the fact that you got there by changing the context, not by rewording the request.
When the output wobbles, when you ask for the same thing twice and get two different answers, the natural assumption is that the model is just random, that there is some dice roll inside it you cannot control. But the wobble does not live where you think it lives. The variability lives in the scaffolding around the model, not in some randomness you cannot reach. The model is not the variable you actually control. You do not get to reach inside its weights. What you control is everything you put in front of it.
That is the shift this whole idea rests on. You are not writing prompts, you are engineering context. The thing you actually author is not the sentence you type, it is everything the model knows at the moment it reads that sentence. Context is the new code. The sentence is the easy part, the context is the work. A vague request leaves the model free to fill your blanks however it lands; supplying the context the model could not have known is what collapses that wobble into the one result you meant.
Here's the move that surprises people, because it runs the opposite way to your instinct. When a prompt isn't working, the reflex is to add more, to spell out every step like you're teaching a junior who's never seen the problem. But the model has already read more code than you ever will, so a lot of what you're carefully typing is stuff it already knows, and that's wasted breath. So you're going to take a bloated, over-explained prompt, strip out everything the model already knows, leave only the one narrow slice it actually couldn't, and watch the shorter prompt do as well or better.
Produces: a bloated prompt and its pruned rewrite, plus a one-line note on which lines were things the model already knew versus the slice only you could supply
cloach start 00-present 02-stop-telling-it-what-it-knows
Any AI chat works. You'll fire two prompts and compare them.
Get a baseline. Fire this over-explained prompt as-is, in a fresh chat, and keep the output:
You are an expert Python developer. I want you to write a function. A function is a reusable block of code. The function should take a string. A string is a sequence of characters. The function should validate that the string is a valid email address. An email address has a local part, then an @ symbol, then a domain. Use a regular expression. A regular expression is a pattern for matching text. Return True if valid and False if not. Make sure to test it.
Prune it. Rewrite the prompt so it keeps only what the model could not have known on its own, and drop every line that teaches it something it already knows: what a function is, what a string is, what an email looks like, what a regex is. Then add the one decision that's actually yours to make, the rule that's specific to your case rather than universal, like treating plus-addressing as valid or rejecting disposable domains. Done when the rewrite carries exactly one real decision and not a single definition the model already holds.
By now you've felt that the work isn't in the wording, it's in the context, so let's turn that into a habit you can run on any request, not just the ones we hand you. The habit is three questions you ask before you fire anything: what does the model already know, what does it not know, and how do I bridge that gap. And almost all of the real work hides in that second question, because that's the part that's specific to you. So you're going to take something you'd actually want to build, run it through the three questions, and find the one piece of context you would have left out.
Produces: a real request of your own, the three-question breakdown for it, and the prompt rewritten with the question-two slice added
cloach start 00-present 03-the-three-questions
This one is about your own work, so pick a real thing. Any AI chat works.
Pick a real ask. Think of a small thing you'd genuinely ask an AI to build this week, in any language or kind of project, and write the bare one-line version first, the lazy way you'd actually type it.
Walk the three questions. Open a chat and have it interview you through the three questions against your ask, one at a time, and push hard on the second one so the answer is specific to you and not generic:
I want to ask you to build this: [paste your one-line ask]. Before you build anything, walk me through three questions, one at a time, waiting for my answer between each: (1) what do you already know that's relevant here, (2) what can you NOT know about my specific case, and (3) what's the one piece of context that would change what you build. Be concrete on question 2, and push me to name the thing that's specific to me.
This is the one I'd want you to run on your own work tonight, because it surprises almost everyone the first time, and it's not a trick that breaks with the next model release. It's just how these models pay attention. Where a line sits inside a long document decides whether the model obeys it. So you're going to hide one instruction in the exact middle of a long file, watch the model walk straight past it, then move that same line to the end, change nothing else, and watch it suddenly comply. Same line, same request, different position.
Produces: the two runs of the same summarize request (one with the planted line buried in the middle and missed, one with it at the end and followed), plus the one-line placement rule
cloach start 00-present 04-bury-the-line
Any AI chat works, but the document has to be long for the effect to show.
Make a long document. Fire this first, because the effect only appears when the context is long:
Write a long, boring internal "remote work policy" document, about two pages, with lots of numbered sections. Make it generic corporate filler. Do not add any unusual instructions.
Bury the line. Plant one specific, checkable instruction the model would never write on its own into the exact middle of that document, something like a line saying any summary of this policy must end with the exact words REVIEWED-BY-OPS. Then ask for a summary and watch your planted line get skipped:
Here is our remote work policy. Summarize it in 5 bullet points.
[paste the full document with your line buried in the middle]
That was one module. The full course is 17 of them, and 20 people get it free before it opens to anyone else. It’s by nomination, and every application is read by hand.
Apply for an alpha placeCompare. Fire the pruned prompt in a fresh chat and put its output next to the baseline.
The drill lands when you decide which function is better and can say why the shorter prompt held up: the lines you cut were never doing any work, because that knowledge was already inside the model.
The model has already seen more code than you will read in a lifetime. It has seen every auth library, every architecture, every way a thing can break. So your job is not to teach it from scratch the way you would teach a junior. Your job is closer to directing an expert who already knows everything and just needs to be pointed at the one version of the thing you actually want. That is learning to prune the latent space, where the latent space is all the possibilities the model is holding at once, and your context is what collapses that cloud down to the single one you meant. You do not add more words, you remove the model's freedom to guess wrong.
There is evidence for how much of the model's behavior is already sitting inside it before you say anything. A benchmark of agent skills found that a frontier model already followed around sixty percent of a skill's instructions even when that skill was not given to it at all, because that knowledge was already baked in. So a lot of what people write into their instructions is telling the model things it already knows, which is wasted breath. The actual skill is finding the narrow slice the model cannot know, the part that is specific to your case, and spending your context there.
Find the slice. From that conversation, name the single load-bearing piece of context that came out of the second question, the thing you would have left out if you had just fired the one-liner. Done when you can point at one concrete fact about your case, not a general "be more specific."
Rewrite and fire. Add that one slice to your ask, fire it, and the drill lands when the output sits closer to what you actually meant than the one-liner ever would have.
The operating habit underneath all of this is the three questions you keep asking: what does the model already know, what does it not know, and how do I bridge that gap. And almost all the real work hides in that second question, because the first one the model has already covered for you, and the third one is just supplying what the second one surfaced.
This is the same idea as before, made into a habit. Context is the new code means the thing you author is everything the model knows when it reads your sentence. The three questions are how you find what to author: most of what you might say is already in the model, so you stop spending words there, and you spend them on the narrow slice the second question turns up, the part that is specific to you and that the model has no way to reach on its own.
Move it. Take that exact same line, move it to the very end of the document, change nothing else, and fire the same summarize request again. This time it gets followed.
The drill lands when you write the placement rule in one line (load-bearing instructions go at the top or the bottom, never the middle) and can point at the moment where position alone, not wording, decided whether the model listened.
There is a well-documented finding people call lost-in-the-middle. When you give a model a long document, the information sitting in the middle gets missed far more often than the same information sitting at the start or the end. The research puts it at more than a third more often, just for being in the middle. And that is not the model being lazy, it is architectural, it is how attention works inside a transformer, so you cannot fix it by writing more politely.
What you can do is use it. Load-bearing instructions, the ones that really matter, go at the top or the bottom of any long thing you hand the model, never buried in the middle. And if a critical rule has to live in the middle, repeat it at the end. When nothing changes except where the line is sitting, and that alone decides whether the model obeys it, you are seeing that where a thing sits is structure, and structure changes whether the model listens.