My son asked me how I’ve been making all these games and widgets for my blog.
Fair question. I’ve spent thirty years scribbling for screens, not writing code. The last time I touched anything resembling programming was a BASIC class at computer camp. 1987. Commodore 64. I peaked early.
And yet here I am, shipping arcade games, AI-powered writing tools, and interactive widgets. All playable. All on my website. All built without me learning to code the old-fashioned way.
So what changed?
I stopped trying to become a programmer. Started learning how to collaborate with something that codes.
Claude Code Changed the Vibe
Claude Code is an AI tool that writes software. You describe what you want in plain English, it generates the code, you test it, you tell it what’s wrong, it fixes it. Repeat until it works.
That loop is the whole deal.
But there’s a catch. “Describe what you want” is doing a lot of heavy lifting in that sentence. Vague requests produce vague output. Specific briefs produce usable builds.
If you can write a solid creative brief, you can build software.
That’s why scribblers have an edge. We already know how to specify intent, constraints, and behavior. We already know how to give clear notes when the first pass isn’t right. We’ve been doing this our whole careers.
To be clear: I didn’t learn to code in the traditional syntax-first way. I learned how to spec, test, and give notes. I can read code well enough to sanity-check what it’s doing, but I’m not hand-authoring it. That turned out to be enough.
Try Something Small First
Before I explain the full workflow, here’s a tiny project that will teach you the loop in under an hour:
Ask Claude Code to build a single HTML page that displays a writing prompt, has a button that generates a new prompt, and keeps a visible counter of how many prompts you’ve pulled.
That counter is the key. It forces the exact skill you’re learning: iteration. You will test it. Break it. Give notes. Watch it get fixed.
Once you’ve done that once, bigger projects stop feeling mythical and start feeling procedural.
The Five-Step Process
This is the workflow I’ve landed on after building a dozen projects.
1. Start with a document, not a conversation
Before I open Claude Code, I write a brief. One to two pages.
I spell out what the thing does, who it’s for, how it works mechanically, and what it should look and feel like.
For a helicopter arcade game I built recently, the brief covered the player fantasy (you’re a stealth Blackhawk pilot extracting alien artifacts), the core loop (fly to crash site, extract cargo, defend against enemies, return to base), the controls (WASD movement, spacebar to shoot, Q and E for special abilities), and the visual style (16-bit vibe with a radar display at the top of the screen).
That document becomes the first prompt. I paste it into Claude Code and say “build this.”
This one habit is the difference between a project that ships and a project that becomes an endless chat thread.
2. Let it build the first version
Claude Code will generate files, write code, and explain what it’s doing. Your job at this stage is not to micromanage. Let it produce a playable version.
The first version is never perfect. You’re looking for something you can test.
3. Test like you’re trying to break it
Download what it built. Open it. Click everything. Try weird inputs. Do the thing the user is not supposed to do and see what happens.
Then take notes. Not feelings. Notes.
What worked. What didn’t. What you expected to happen. What happened instead.
4. Give specific feedback
This is where scribblers quietly dominate.
We’ve been giving notes our whole careers. We know how to describe behavior, intent, and failure cases. Twenty years in writers’ rooms taught me one thing: the note that fixes the problem is the note that names the problem.
Bad feedback: “It doesn’t work.”
Good feedback: “When I paste my scene into the text box, the character count updates correctly. But when I click Analyze, it still shows the demo placeholder text instead of analyzing what I pasted. The Analyze button is reading the wrong content.”
That kind of note gives Claude Code something concrete to fix.
If you can explain what’s happening in a scene, you can explain what’s happening in an interface.
5. Deploy it where real people can use it
Two lanes here.
Lane A: single-file browser projects. If it’s a simple game or widget, you can often keep it in one self-contained HTML file. Paste it into a code block on your site. Squarespace, WordPress, Wix, whatever. Done.
Lane B: AI tools that need a backend. If the tool calls an AI model, you need code running on a server to keep your API key secret. I use Netlify for this. Free hosting. It deploys from a folder on your computer with a few Terminal commands. You’re not learning Terminal. You’re copy-pasting three commands Claude hands you.
Rules of Thumb
These are the habits that kept my projects from spiraling:
Keep it one file until you can’t.
Ship the ugly version first.
Change one thing per iteration.
Save a “known good” version before each fix.
Treat API keys like passwords.
When in doubt, ask Claude to explain what it just did.
What You Can Actually Build
Here’s a menu of what’s reachable with this workflow.
Browser games. Choose this when you want zero hosting headaches. Arcade shooters, puzzle games, board game adaptations. These run entirely in the browser as a single HTML file. No app store. No installation. Just a link.
Interactive widgets. Choose this when you want one tool that does one job well. Calculators, generators, analyzers. I built a Morse code translator that converts text to actual audio beeps. I built a Scene Doctor that analyzes screenplay pages using my teaching frameworks. Both live on my blog as embedded code blocks.
AI-powered tools. Choose this when you need model calls. Apps that use an AI to analyze or generate content. These require keeping your API key on the server side, which means basic deployment. More power, slightly more setup.
Utility scripts. Choose this when the job is file wrangling. Small programs that run on your computer to process files, rename assets, convert formats, clean text. I used one to clean up 378 blog posts exported from Squarespace, stripping out the HTML junk and leaving clean text. Run them locally. Test them on copies first.
A Cool Part Nobody Talks About
The debugging loop is fun.
Not “fun” like a day at Disneyland. Fun like solving a story problem with a partner who never gets tired and never gets defensive.
Something breaks. You describe the break precisely. Claude proposes a fix. You test. Sometimes the fix creates a new problem. You report that. Test again.
I’ve had sessions that went fifteen rounds. “Try this.” “Nope, now this happens.” “Okay, change this part.” Each round takes a couple minutes. The whole session might take half an hour.
Compare that to the old route: learning to code from scratch, months of effort before you can ship anything a reader can click.
This is different. This is production.
Terms That Used to Scare Me
These are the five words that used to bounce me out of projects. They’re not as scary as they look.
Terminal is just a text box for talking to your computer. On Mac it’s called Terminal. On Windows it’s Command Prompt. You type commands, press enter, things happen. Claude Code tells you exactly what to type.
An API key is a password for a service. When your app needs to talk to an AI model, it uses an API key to prove it’s allowed to. Keep it secret like a password.
Single HTML file means self-contained. Everything the browser needs is in one file. No server required. Open it and it runs.
Backend means code running on a server. If your project needs to call an AI, store data, or protect secrets, you need backend code somewhere.
Localhost is your computer pretending to be a website. When you test something at “localhost:3000,” that’s just your computer serving a page to itself before you deploy it.
Mindset Shift
I’m not learning to code.
I’m learning to collaborate with something that codes.
My job is vision, taste, quality control, and clear communication. Claude Code’s job is technical execution.
This is the same relationship I’ve had with specialists my whole career. When I work with a VFX supervisor, I don’t learn After Effects. I learn how to describe the shot clearly enough that they can build it. When I work with a composer, I don’t learn a DAW. I learn how to articulate the emotional texture I’m after.
Same deal here.
You bring the brief. You bring the notes.
The tool brings the syntax.
Make Something
You have permission to build the weird thing. The arcade game. The writing tool. The generator that only makes sense to you and twelve other people on the internet.
The Scene Doctor, Character Doctor, and the arcade games I mentioned are all live on scribblejerk.com. Built through this exact process. No coding course required. Just a brief, a test, and good notes.