How to Prompt Claude Code: 5 Lessons From 356 Sessions

I was trying to build a procedural music engine in Web Audio API. Everything Claude gave me sounded like a ringtone. I kept prompting “make it better,” “add more depth,” “make it more emotional.” Three prompts that produce absolutely nothing, every time.

Then I wrote this: “Think about the upgrade from NES to SNES. Less gameboy, more super famicom. Think donkey kong country samples, the depth of a JRPG soundtrack, the epic surreal beauty of a PC-98 game.”

The next version sounded like a different engine. It was the same engine, with the same code structure.

That moment, six days into a ten-day build, changed how I prompt for everything. It was one of five prompting lessons I walked away with after 356 Claude Code sessions and 243 commits, and each one would have saved me hours if I’d known it going in. The five, in short: name the reference instead of reaching for an adjective, vibe on creative work and write a blueprint for structural work, talk first and prompt second, show the problem instead of describing it, and let the AI brainstorm while you make the call.

The project that ate my week

It was supposed to be a blog post. Seven chapters explaining agentic coding to PMs and CEOs. A few Win95 window frames for personality. Maybe some checklists. One commit on January 31st: “Add interactive guide.”

Then I added interactive window control buttons (minimize, maximize, close) and something clicked. The theming stopped being decoration and became the product. By midnight I had an FFVI-style pixel art wizard, per-chapter illustrations, a salary calculator, and a dock with colored icons. Twenty-one commits on day one.

Ten days later: a playable canvas SkiFree, a procedural music synthesizer, a Civ II tech tree with curved SVG dependency lines, a working disk defragmenter, a Minesweeper minefield, a SimCity budget advisor whose pixel-art face changes mood based on your numbers. Around 16,300 lines of JavaScript and SCSS across 24 files. Here’s the finished thing.

I didn’t plan any of this. Each feature created a gap that the next feature filled. The Win95 chrome needed a mascot. The mascot needed to react to your progress. The progress tracker needed a visual payoff. Scope creep, but the productive kind, where you can feel the thing getting better with every addition.

Lesson 1: A proper noun beats an adjective

Back to the music engine. After the Donkey Kong Country prompt worked, I kept testing the pattern. I asked “Nobuo Uematsu, how can we make this piece from great to timeless classic?” Then I had Claude roleplay as the best Super Famicom composers of all time and critique the composition. Sounds absurd. Produced the best iteration of six rewrites. It was a panel of experts prompt pointed at a piece of music.

The music went through a Shimomura-style melody, a Philip Glass arpeggio, an Uematsu phase, an SNES/PC-98 hybrid, a “Soulful Mix with Sound Canvas vibes,” and finally full dembow with karaoke lyrics because the guide needed energy. The final module is 2,400 lines of Web Audio API, zero samples, everything synthesized. Three commits just to get AudioContext unlocking right on mobile Safari.

The pattern held everywhere, not just music:

• “Make it more premium” produced nothing. “Win95 beveled borders, not flat design” produced exactly what I needed.
• “Improve the typography” went nowhere. “Have a master typesetter work on the hero section” got me real improvements.
• “Make the design better” was useless. “Check out poolsuite.net and come up with ideas from there” gave me concrete inspiration.

The rule: name the reference. A specific game, a specific composer, a specific website, a specific feeling. “Elegant” means nothing to an LLM. “The feeling of hearing Corridors of Time for the first time” means something. An adjective covers a huge range of possible outputs, and a proper noun narrows it to one.

It works for code too. A framework with strong conventions is a reference the model has seen thousands of times, which is a big part of why I pick Django for AI work.

Lesson 2: Vibe for creative work, blueprint for structural work

For creative tasks (music, game feel, UI theming, copy), short emotional nudges worked. “Can you make this sound more boricua? Add cuatro somewhere.” Under 15 words, mid-session, trusting the shared context. The persona prompting from Lesson 1 lived here too. “Have a master UI/UX designer from Apple that worked for YCombinator take a stab at this” produced better design feedback than any description I could write.

For structural tasks (splitting a 4,378-line SCSS file into five, standardizing spacing tokens across 23 files, responsive layout fixes), the opposite worked. I’d write a full plan first, then paste it as “Implement the following plan:” with file paths, exact values, and explicit instructions. The SCSS split landed on February 7th, the busiest day of the build at 64 commits.

I wasted real hours before noticing this split. Vibing on a refactor gives you inconsistency. Different spacing values in every file, different naming conventions, no coherent system. Blueprinting a creative task gives you something generic: competent and lifeless.

The same AI, the same session, completely different prompting styles depending on whether the task needs exploration or precision. Anthropic’s Claude Code best practices draw the same line from the other side: planning is most useful “when you’re uncertain about the approach, when the change modifies multiple files,” and vague prompts are fine “when you’re exploring and can afford to course-correct.”

Lesson 3: Talk first, prompt second

The guide originally read like polished AI marketing copy. Every section was competent and completely lifeless. I tried rewriting the prompts, adding personality instructions, asking for “Gabe’s voice.” Nothing worked. You can’t describe your way into sounding human.

I tried something different. I had Claude generate a long interview about my career (the same docs suggest letting Claude interview you before big features; they had specs in mind, and I pointed it at my life story), my failures, the projects I’d shipped. Then I answered those questions in Spanish via voice memo. Just talking. Rambling about graduating from Colegio de Mayaguez, the two years at Georgia Tech, building Peer Feedback for the campus and watching over a thousand students use it, the CITYROW acquisition where I had to step up as the technical leader when everything was falling apart.

I fed the transcription back and told Claude to weave those stories into the guide as personal notes.

The result sounds like me because it is me. The AI shaped and placed the stories, but the raw material was my actual voice talking about things I actually care about. Record yourself talking in whatever language is most natural to you, transcribe it, and let the AI edit. Don’t let it write from scratch. It’s the fastest way I’ve found to get content that doesn’t sound like AI.

Lesson 4: Show, don’t describe

Half my prompts during the build were a screenshot and three words. “Fix this on mobile.” “This still happens.” Claude Code takes pasted or dragged-in images directly, and I also used a Playwright browser plugin that lets Claude see the site, take snapshots, and interact with elements.

Describing a CSS bug in English is slow and usually gets misunderstood on the first try. Showing it is instant. Visual context carries information that would take a paragraph to describe and still miss something. A screenshot of a button overlapping a card on iPhone is worth more than “the button positioning seems off on smaller viewports.”

Lesson 5: Let AI brainstorm, then be decisive

None of the game metaphors were planned in advance. My flow for every chapter was the same: “come up with ways to make this more interactive and fun,” get a numbered list, pick one.

“1. lets go for 1… this is epic” is literally how the Minesweeper theme happened for the common mistakes chapter. The Civ tech tree started with “what about something out of Civilization 2 or 3?” The defragmenter came from asking how to make the codebase readiness checklist less boring. SkiFree was the only one I walked in knowing I wanted, because pressing F to outrun the yeti was the perfect metaphor for the chapter’s point.

Claude brainstorms better than I expected. The trick is being decisive about which idea to pursue instead of asking it to refine all of them. Pick a number and iterate on that one idea.

What I’d do differently

Two things.

First: start with the interactive concepts, not the prose. Every chapter got better once I figured out its game metaphor. The Minesweeper theme made the common mistakes chapter fun to read. The Civ tech tree made the 90-day plan tangible. The defragmenter made the checklist feel like progress instead of homework. The writing shaped itself around the interaction, not the other way around. The static chapters that never got a game are noticeably weaker.

Second: commit to scope creep early or don’t do it at all. The middle ground, where you keep telling yourself “just one more feature,” is where the real time goes. I should have decided on day one that this was going to be a full interactive experience and planned accordingly. The 4,378-line SCSS file I eventually had to split into five happened because I kept adding “just one more thing” without stepping back to reorganize.

356 sessions in ten days. The project turned into something I couldn’t have built at this scale without AI-assisted development, and it still needed someone who knew what good looked like, which is the argument I make in why AI makes developers worth more. The irony of building a guide about agentic coding using agentic coding was not lost on me. The lesson I use every day is the first one: stop describing what you want and name it.

If you want to work with Claude Code like this on your own project, I coach people through it over screen share. Build It Yourself coaching is four 90-minute sessions for $1,997, and you do the typing. I also wrote up what non-developers on our team actually install, and the commands and shortcuts worth knowing are on the Claude Code cheatsheet.