← Adam Garceau

The Claude Code Roadmap for People Who Will Never Read Code

November 2, 2026 · The written version of my video. Reading time: about 10 minutes.

If you never read code, is learning Claude Code just pretending?

Under a video with 910,000 views on this topic, one commenter wrote that it's the equivalent of spending more time finding a way to cheat on a test than it would take to just study. Another wrote, "this is how you lose your coding habits and intuition."

I never had the habits, and I don't write code. I'm a marketer. With Claude Code I've built a planner app that runs on my phone, a land navigation tool, a Mac cleaner with 16 safety checks, and a check printer. This is the order I'd learn it in if I started over tomorrow.

Why most people learn this backwards

Here's the problem with how most people learn it. You get 80 features and a tier list. None of it comes in an order, so you collect skills and tools, and you still don't know if the thing you built actually works.

By the end of this post you'll know what to learn first, what to learn next, and what to leave alone for now.

One idea makes the order work. You're not learning to read code. You're learning to give the AI a clear job and to check that the job got done.

A quick, honest note: I didn't learn these in order. I learned most of them the hard way, one at a time. This is the order I'd take now, because each step makes the next one a lot cheaper.

Step 1: Start with a job you already do, not an app idea

I do the books for a small business. The owner showed me how he pays people. He had a box of blank check stock, and I only need to print checks a few times a month. So I had a choice: buy check printing software, or ask Claude Code to build it.

Before I built anything, I asked three questions:

  1. How often will I use it? A few times a month is the sweet spot. If it's every day, a paid tool with support is often worth the money.
  2. How simple is the job? Printing a check on blank stock is one page with some text on it. A simple job is a good job for AI.
  3. What happens if it's wrong? For a check, a bad print costs me a sheet of paper, as long as I test before I use real stock. If a wrong answer could cost somebody real money and I can't catch it first, I just don't build it.

The planner app started the same way. I built it for my wife because she's blind and a lot of planner apps aren't accessible for her. A real job gives you something to check the work against. An app idea doesn't.

Step 2: Make it argue with you before it builds anything

The tool isn't broken, but it's an overexcited intern. It wants you to feel good about your idea. Left alone, it will say yes to almost anything. So you have to ask it for the no.

I wanted a mileage tracker. I asked Claude for a standalone app that replaces QuickBooks and tracks my location and mileage. It didn't start building. It asked me what would make me regret this in six months. I gave it three answers: it misses miles, I end up babysitting it, or the books don't tie out. I wrote those down before any research, so that when I got excited later, the bar couldn't move.

Then it told me to just buy one. There's an app for $4.99 a month. I said no. So it sent six skeptics after my plan: six separate AI reviews, 19 attacks in all, and six of them were kills.

In the end, I didn't write a tracker. It found a free open source tool somebody had already made, and what I built was the bridge around it. The first working version of that bridge took about two hours, not weeks.

If you only learn one habit, learn this one. Open the chat you already have and say, "argue against me. What would make me regret this in six months, and who already solved it?"

Step 3: Describe the job, not the code. Keep version one small.

I didn't tell Claude which language to use or how to build the check printer. I described the job: a check on top, two stubs below, on blank stock. The first version came in about six minutes. Getting it to a version I trust took about 22 minutes, including a test page and turning it into an app on my Mac.

That went fast because the job was small. The planner app did not go fast. I wrote a big plan, handed it to Claude and threw every feature I could think of at it. It took me a month just to get a basic grid on the phone screen, and it was beeping and vibrating and wouldn't stop.

Sometimes Claude will tell you the thing you asked for is a whole day of work and that some of the pieces aren't needed yet. Like a good employee, it's telling you the truth. Listen to it. Every extra feature is one more thing you have to check. So write the plan before the first prompt, and then cut it. The smallest version that does the job is version one. Everything else is version two, and most of it never needs to exist.

Step 4: Check the work without reading the code

This is the step that answers those comments. I use three checks:

  1. Ask it, "how did you come up with that?"
  2. Have a second AI check the first one. A different AI with a different job is better than the same one grading itself. Give it a job title: a reviewer whose only job is to find what's wrong.
  3. Give it a rule and give it your own data.

And when something still doesn't make sense, say "explain it to me like I'm five." You'll find out fast whether it understands its own work.

That third check came from a real mistake. Back in the days of ChatGPT 3.5, I asked it to do some research on Reddit. It told me it had hit a ceiling and had found only about 120 examples. I kept pushing and it kept coming back with more. When I asked why, it said that when it ran out of real data, it just kept making up a fake sample size based on the real one. So now I give it a rule, "never make anything up," and I do the looking myself and hand it the data.

On the check printer, the AI filled in my bank's routing number from memory, and it was wrong. It was a different bank's number. Before anything printed, I had it check the number against a public routing number lookup, and that caught it. Then I ran a test page on plain paper with fake numbers and a big VOID across the middle, and held it up to my real check stock against a window to see whether the lines matched. A wrong number on a real check would have wasted a check and maybe a bank fee. Checking first cost me nothing.

You don't need to read the code to find out any of that. You need to know what has to be true, and look it up somewhere the AI didn't write.

Step 5: Build the fence before you give it power

In September, somebody on the Claude AI subreddit posted that Claude Code deleted 48,000 files from their project in about 100 seconds. It has never happened to me and I'd like to keep it that way.

You can tell an AI not to delete your files and it can still delete them. So I asked a different question: what can I build so that being careless doesn't cost me anything?

I built a Mac cleaner called Spare Oom. A cleaner is about the worst place to let an AI loose, because its whole job is to find files and get rid of them. So it has one verb: move to the trash. There's no delete button anywhere in the app and no empty trash button. If something gets moved that shouldn't have, I open the trash and put it back.

Then I didn't trust myself or the AI to remember that. So there's a checklist that runs itself before anything goes live. It reads the whole codebase and runs 16 checks. One of them says the words for permanently deleting a file can't appear anywhere in the source. I added a line that permanently deletes a file, in a scratch copy, not the real app. I ran the script again, the check failed, and the app can't ship with that line in it. The AI can write whatever it wants. It can't get past a script that doesn't care how confident the AI sounds.

That protects one app. Here's the version for everything else:

Security is everybody's job, not only the AI company's. If you want the longer version of this one, I covered it in why Claude Code can't delete your files.

Step 6: Make it remember, and know what it costs

These are the same problem. Claude forgets. A long chat gets heavy, and a heavy chat costs more on every turn. Claude keeps your whole chat in its head as small chunks of text called tokens. I don't go past about 250,000 of them before I start a new chat. Before I do, I have Claude write a short note on where we stopped, so the next chat picks up from the note and not from memory.

Don't run three or four chats on big projects at the same time either. They burn through your limit faster, and you end up with four half finished things instead of one finished thing.

On cost: for me, the $20 a month plan was not enough to do much of anything. I hit the wall, iterated, and eventually moved to $100 a month, which gets you five times the usage of the $20 plan. I also had a cheaper model do the easier tasks, and that went a lot better. That's me. Your work might fit the $20 plan, so start there. When you hit the wall you'll know it, and you'll know what you need. And ask what the work costs before you scale it up. I made a whole video on that math, and the write-up is is Claude Max worth it.

Step 7: Put it where other people can open it

A link that works for you and not for your friends is on your computer and nowhere else. The way I do it is Cloudflare, a service that hosts websites. It's free to start, and a domain is about $10 to $20 a year.

Dead Reckon, the land navigation tool I made, is live. I started it in the morning and finished a first version just after lunch. The Grab Your Assets site is live on Cloudflare too, with a form that saves to a database.

I do this last on purpose. Once other people can open it, the earlier steps stop being optional.

The 7 steps in order

  1. Start with the job you already do.
  2. Make it argue with you first.
  3. Describe the job and keep version one small.
  4. Check the work without reading it.
  5. Build the fence before you give it power.
  6. Make it remember, and know what it costs.
  7. Put it where other people can open it.

What to leave alone for now

Skills, helper agents, extra tools, running three chats at once. They're real and I use some of them now. But I added each one when something hurt me. If you collect them first, you'll have a big setup and no way to tell if anything works. Add one when a step above starts to hurt.

If you plan to sell what you build, have someone who knows code look it over before you charge anyone. The developers in the comments have a point. Somebody has to check the work. Checking the work is not the same as writing the code, and it's the part you can learn.

Don't do all seven tonight

Pick one job you already do. Do step one, then step two, and see what the AI tells you when you ask it to argue.

If you're about to put something you built in front of real people, I made a checklist from the ways my own apps break. It's free: the pre-launch checklist.

Tell me in the comments on the video which step you're on and what broke first.

Get the next one.

I send what I'm building, what worked, and what broke. Free, no fluff.

Free. Unsubscribe anytime.
Get the next one.

I send what I'm building, what worked, and what broke. Free, no fluff.

Free. Unsubscribe anytime.

I'm a marketer who builds his own tools. More at adamgarceau.com.