Video walkthroughs · Claude Code Club

The Ramble Session: How to Prompt Claude Code by Talking, Not Typing

13 minute read · Companion guide to “The New Way Top Anthropic Engineers Prompt Claude Code”

There is a piece of advice about prompting that almost everyone believes and that is quietly holding them back. It says a good prompt is short, tight, and precise, and that the work of prompting is the work of trimming. Andrej Karpathy, one of the most respected AI engineers working today, published the opposite pattern, and once you see it you cannot unsee it. Lean back, switch to voice, and ramble at the model for ten minutes. Total mess. Anything goes. Full stream of consciousness. The model is unusually good at reconstructing long incoherent rambles, and its echo of your tangle of thoughts often comes out cleaner than what you started with.

Watch the full walkthrough, including a live ramble session that ships a finished website.

We tested this the honest way. Not on a project we already understood, where any prompt would have worked, but on a request we knew nothing about. A viewer asked for a beginner tutorial on building a beautiful naturopath website. Nobody on our side knew what a naturopath was, what those patients want, what the field looks like visually, or what such a practice charges. So we did not research first. We opened Claude Code, hit the microphone, and rambled the confusion out loud. What came back was a finished site with researched copy, generated images, real pricing, and a self run mobile check.

This guide is the pattern behind that. What rambling actually does, the seven things worth touching while you talk, the forks you will hit, and the specific ways a ramble session goes wrong.

Stop optimizing the prompt and start raising the bit rate

When output disappoints, the instinct is to assume the prompt was not precise enough, so you rewrite it tighter. That instinct is aimed at the wrong problem. The model almost never fails because your eighty words were imprecise. It fails because eighty words is not enough of what is in your head. Karpathy names the real constraint in one line: sometimes the model needs more bits to understand what you are trying to achieve, but you are too lazy to type them. The bottleneck is bits, not precision.

Typing throttles bits, and not because typing is slow. It is because you edit yourself while you type. You delete the tangent that turned out to matter. You drop the caveat because the sentence was getting long. You never mention the thing you are unsure about, because writing it down would mean admitting you are unsure. Every one of those cuts is context the model needed and never got.

Speech does not throttle you the same way. You will contradict yourself, backtrack, and say things badly, and none of that costs you anything, because cleaning up a mess is the exact task these models are best at. A rambling twelve hundred word transcript transmits more usable intent than a polished eighty word prompt, and the cleanup is free.

Ramble hardest when you have no idea what you want

The counterintuitive part is who this helps most. It looks like an expert technique, something you graduate into once you know how to brief a model properly. It is the reverse. Rambling works best exactly when you do not know what you want, which is the moment beginners assume they are not allowed to start.

Think about what a tight prompt requires of you. To write eighty precise words you already need the shape of the thing, the vocabulary of the field, and the decisions made. If you had all that, you barely needed the model. The tight prompt is a report on thinking you already finished.

A ramble asks none of that. You can say out loud that you do not know what the term means, that you are not sure who the audience is, that you might want to sell something but have no idea what or at what price. Those admissions are not weaknesses in the prompt. They are the most valuable content in it, because each one tells the model exactly which gap to go close. In our test, the single most productive sentence in ten minutes of talking was an admission of ignorance.

Touch these seven things while you talk

You do not need structure to ramble. You do need a loose set of things worth touching, so that a ten minute stream of consciousness happens to contain the pieces the model needs. Treat these as anchors you drift past, never as a checklist you work through. The whole point of the pattern is that you do not have to be organized. If reciting them makes you stiff and formal, you have already lost the advantage.

• Desire. The thing you are actually trying to end up with, said plainly, even if it is vague.
• Quality bar. What good looks like to you. Beautiful, clean, fast, expensive looking, playful. Vague adjectives are fine here, they carry more than you think.
• Tools and discovery. What it has access to, such as skills, repos, or connected services. If you have none of that, say so and tell it to go find what exists. Discovery is the fallback for everything you do not know about.
• Creative freedom. Explicit permission to make its own calls. These models have real taste now and they use it when you let them.
• Verification loop. How it should check its own work, over and over, until the result actually meets the goal.
• Delivery. What format you want and where it should land. A folder, a file type, something you can open right now.
• One line at the end restating the goal, so the whole ramble resolves to a single clear target.

If you only ever remember two of the seven, make them delivery and the closing restatement. Those are the two that most often go missing and they are the two that cost you the most when they do.

Pick your input: terminal voice or the desktop microphone

There are two ways to get your voice in, and the choice trips people up because most advice assumes one of them. In the terminal, type the voice command and it activates your microphone. In the desktop app there is a microphone button in the input area, so no command is needed. The pattern is identical either way, only the button changes. Anyone following terminal advice inside the desktop app will hunt for a command that is not needed, decide the feature does not exist, and go back to typing.

Declare the mess up front. Open with something like switching to speech recognition, sorry for any typos. One sentence, and it tells the model to read for intent rather than treating transcription artifacts as deliberate words. It will get names and jargon wrong, and in a field you do not know yet that is most of the important vocabulary. Leave it. Correcting yourself mid ramble is the same self editing that made typing worse.

Decide between rambling raw and planning first

This is the first real fork, and it is the one worth being deliberate about. You can ramble and let the model start building immediately, or you can switch into plan mode before you ramble, so it turns your mess into a written plan and hands it back for review before it touches anything.

Ramble raw when the work is new, disposable, or exploratory, when you are in an empty folder, and when you do not know enough yet to review a plan usefully, which makes reviewing one theatre. Plan first when the model would be working inside something that already exists and matters, when there is a decision in the ramble you know you will regret going the wrong way, or when the task is large enough that finding out at the end is expensive.

Our default is raw for anything new and plan mode for anything with existing work in it. Plan mode is the safety valve, not the default gear. Used everywhere it slows you down and quietly reintroduces the self editing problem, because now you are curating a plan instead of describing a want.

Watch a real ramble turn into a finished website

Here is the actual session, so you can see the texture rather than a cleaned up version. The setup: a new empty folder on the desktop named for the project, Claude Code open in the desktop app, microphone on, and no research done beforehand. The ramble ran roughly a minute and sounded like this.

I am trying to create a beautiful naturopath website. I do not really even know what that is. So, I need you to research what that term is, maybe who the audience might be, what types of visuals or aesthetic or design makes sense for this group of people, like any language they might use, like a type of product that I might sell to them. I think maybe in the end the CTA is to get somebody to book a call with me, although I am not really sure. Is there a design language that we should use? Typography, colors, like should we generate some type of images? Like the goal is to really just create this absolutely beautiful website. And like feel free to look to see if we have any skills that you have access to. If there are any web design libraries on the internet, you can use the internet. You can use GitHub repos. You can really use whatever you want. So again, I am just trying to create a naturopath website that resonates with this audience that has copy written for them in their own language. And I guess with the CTA to book a call with me to presumably sell them something, although I do not know what that is and I do not know how to price it. And the last thing I guess I missed is that I want you to create this website in beautiful HTML and you can store it in this folder just so I can open it up immediately on my local machine.

Read it again and notice how bad it is as writing. It repeats itself. It says like six times. It changes its mind about the call to action twice. It admits ignorance three separate times. Every single one of those flaws is carrying information, and a tidy rewrite would have deleted most of it. The repetition marks what matters most. The uncertainty marks what needs research. The afterthought at the end is the delivery instruction, and it is the most operationally important sentence in the whole thing.

Map it back to the seven anchors and you will find all of them in there, in no order at all. Desire, quality bar, tools and discovery, creative freedom, delivery, and a closing restatement, scattered through a minute of talking. That is what the anchors are for. Not to structure the ramble, just to make sure the ramble happens to be complete.

Read what came back and what it decided on its own

The interesting part is not that a site got built. It is how many decisions were made without us, each one a decision we did not know we were about to make.

• Researched what naturopathy actually is, then the market and the audience around it.
• Researched the language patients themselves use, and wrote the copy in that language rather than in marketing language.
• Chose a visual design direction judged appropriate for that audience, including typography and color.
• Created an images folder inside the project folder, then generated the imagery into it with Nano Banana Pro at 2K and 4K.
• Built out the pain point sections, based on what its research said those patients are actually experiencing.
• Broke down how care works as a four step process a new patient would move through.
• Left a placeholder for a personal story, because it correctly inferred a practice site needs a human behind it.
• Researched the tests such a practice runs and what they cost, and built a section around them.
• Set program pricing and a book a free call CTA, the one thing the ramble explicitly said it did not know how to do.
• Checked its own work to confirm the result was mobile optimized.

Look at the pricing item in particular. The ramble said out loud that it did not know what to sell or how to price it. A tighter prompt would have either omitted that or guessed at it. Naming the gap out loud is what turned it into a research task instead of a blind spot.

Give creative freedom on taste, be specific on constraints

The second fork is how much you decide versus how much you hand over, and the clean rule is that these are two categories, not points on one slider. Hand over taste: color, typography, layout, image style, section order, tone of the copy. If you do not have a strong, informed opinion, saying use whatever you think works beats a half opinion. A half opinion is the worst input available, because it pins the model to your uninformed guess while giving it none of the reasoning behind the guess.

Be specific about constraints. File format, output location, what must exist on the page, anything a real person already decided. Freedom on taste, precision on constraints. Getting this backwards is the most common way a ramble produces something beautiful and useless.

One more permission worth granting out loud, because people forget it: tell it that it can go look. It can check what skills it has available, search the web, and pull from public repositories. In a field you know nothing about, that is the difference between a result built on your assumptions and one built on research.

Ask for a verification loop or nothing gets checked

Verification loop sounds technical and is not. It means telling the model how to check its own work, and to keep checking until the result meets the goal instead of stopping when the task looks finished. The distinction that matters: research and verification are two different asks, and people routinely request the first while assuming they got the second. Research is go find out what is true. Verification is go confirm what you built is correct. Ask for research without asking for verification and you get a well informed result that nobody checked.

The self run mobile check in our example is exactly this. Nobody sat there resizing a browser window. The model checked its own output against the requirement and reported back. Give it something concrete to check against and the loop closes on its own. Give it nothing and it stops at the first version that looks plausible. The instruction can be as informal as the rest of the ramble: check your own work as you go, make sure it looks right on a phone, and do not tell me it is done until you have actually looked.

Avoid the five ways a ramble session goes wrong

The pattern is forgiving, which is the whole point, but there are a handful of failures that recur. Four of these five are things you failed to say, not things you said badly.

• No delivery instruction. You get real work in a format you cannot open or a location you cannot find. The single most common failure, and the cheapest to prevent.
• A contradiction you never resolve. Changing your mind mid ramble is fine and expected, but if you say two incompatible things and never land, the model picks one for you. Close the loop in your final line: say which version you actually meant.
• Research requested, verification forgotten. You get a well researched result that was never checked against the goal. Ask for both, explicitly, in the same breath.
• Rambling into an empty context with no goal restated. Without a closing target line, a ten minute stream of consciousness reads as ten minutes of options rather than one clear job.
• Treating the seven anchors as a script. You go stiff, you produce a spoken bullet list, and you have reinvented the tight typed prompt with worse punctuation. The mess is the mechanism, not a side effect you should tidy up.

Turn the ramble into an interview when the stakes are high

The last fork is what happens immediately after you stop talking. Karpathy notes that he sometimes turns the ramble into a small interview for a few turns, and that variant is worth knowing because it costs almost nothing and catches the expensive mistakes.

Instead of letting the model start building the moment you finish, ask it to play your ramble back and ask you whatever it is still unsure about. Its questions tell you which parts of your thinking were actually unclear, which is information you cannot get by rereading your own words. You know what you meant, so your own draft always looks clear to you.

Use the interview when the work will be built on for a while, when a wrong assumption early would be expensive to unwind, or when you noticed yourself contradicting your own ramble and did not resolve it. Skip it for anything small or disposable, where seeing a real first version teaches you more than answering questions would. Two or three turns is the right amount. Past that you are back to specifying everything up front, which is the tight prompt you were trying to escape, only slower.

Run your first ramble session in the next twenty minutes

The shortest honest path from reading this to having something real, in one sitting. Pick something you genuinely do not know how to do. That is where the pattern shows its value, and picking something familiar will teach you nothing.

1. Make an empty folder for the project and name it after the thing you want. Open Claude Code inside that folder so delivery has somewhere to land.
2. Decide raw or plan mode before you start talking. Empty folder and exploratory means raw. Existing work you care about means plan mode.
3. Turn on voice. The microphone button in the desktop app, or the voice command in the terminal.
4. Open by declaring the mess. Say you are using speech recognition and to expect typos and tangents.
5. Talk for five to ten minutes without stopping to fix anything. Drift past the anchors as they occur to you. Say the parts you are unsure about out loud, in those words.
6. Before you stop, say two things: where the output should go and what format it should be, then one line restating the goal.
7. Send it. If the work matters, ask it to play your ramble back and ask you what it is still unsure about, then answer for two or three turns.
8. Read what it produced and note every decision it made that you did not. Those are the questions you did not know you were supposed to have opinions about.

Step eight is the real payoff and it is easy to skip. The list of things it decided for you is a map of your own blind spots in that domain, generated for free. Keep it. It is what you brief the next session with.

The reason this pattern spreads is not that talking is faster than typing, although it is. It removes the requirement to have finished thinking before you are allowed to start. That holds well beyond websites. Anywhere you have been stuck because you could not articulate the ask cleanly enough to type it, the ramble is the way in. Being unable to articulate it cleanly was never the obstacle. Believing you had to was.

Read this online at claudecodeclub.ai