How to Direct Your AI Builder

Here’s the most important thing you’ll learn in this entire course, and you’ll learn it in the first five minutes: you are not going to write code. You’re going to direct.

Think about how a film gets made. The director never touches the camera. They don’t hold the boom mic, they don’t edit the footage, they don’t act in the scenes. And yet the director is responsible for everything you see on screen. Every shot, every line, every cut. They get the credit and they get the blame, because they decided what the movie is. The crew operates the equipment. The director operates the crew.

That’s you now. Claude Code is your crew. It operates the camera, it writes the code, creates the files, runs the commands. You operate Claude Code. You decide what gets built, you watch what comes back, and you steer until it’s right. You never need to read a single line of code to do this well. You just need to know how to direct.

And today you’re going to prove it. In one conversation, you’re going to build a real, working AI trip planner. You’ll type in a destination and a number of days, and an AI will hand you back a full day-by-day itinerary. It will work. It will feel like magic. People will want to see it.

And it will have about a dozen things wrong with it. Security problems, design problems, scaling problems, things you won’t even be able to see yet. That’s not a failure. That’s the whole course. Every lesson after this one exists because this first version breaks in a new and interesting way. Today we build the sandcastle. The tide comes later.

Let’s learn to direct.

Before you build anything, let’s talk about how to direct well. This is the core skill of the whole course. Get good at this and everything else gets easier. There are four parts to it, and none of them require you to understand code.

The first part: describe outcomes, not code. Bad directors micromanage. They lean over the camera operator and say “tilt the lens four degrees.” Good directors say “I want this moment to feel tense.” You’re the second kind. You don’t tell Claude Code “write a function that loops through an array.” You tell it what you want to happen, “I want the user to type a city and get back a travel plan.” Describe the result you want, in plain words, the way you’d describe it to a friend. Claude Code figures out the how. The how is its job. The what is yours.

The second part: give Claude Code context, so it actually remembers your project. By default, every conversation starts a little forgetful. The fix is a project memory file. It’s a plain text file that lives in your project, often called CLAUDE.md, and it holds the facts about your app. What you’re building, who it’s for, which AI provider you chose, the decisions you’ve made, the way you like things done. Claude Code reads this file automatically and keeps those facts in mind as it works. Think of it as the director’s notes pinned to the wall of the set, so everyone stays on the same page. You’ll create one today, and you’ll add to it as your project grows. A good memory file is the difference between repeating yourself every conversation and being understood the first time.

The third part: use plan mode. This is the single best habit you can build. Before Claude Code changes a single file, you can ask it to lay out a plan first, here’s what I’m going to do, here are the files I’ll touch, here’s the approach. You read the plan in plain language, and if something looks wrong, you say so before anything happens. It’s the director reviewing the shot list before the cameras roll. Nothing is committed, nothing is broken, and you stay in control. When a build matters, plan first. You steer the plan, then you let it run.

The fourth part is the loop, and you’ll do it a thousand times: prompt, review, iterate. You ask for something. Claude Code builds it. Then you review the result, and here’s the key, you review it by behavior, not by code. You open the app and you watch what it does. Does it work? Does it feel right? Did it do what you pictured? If not, you say what’s off, in plain words, and Claude Code adjusts. Prompt, look, refine. Round and round until it’s right. You don’t need to read the code to know whether the movie is good. You just have to watch it.

Outcomes, context, plan mode, and the loop. That’s directing. Now let’s use it to build something real.

Now the fun part. You’re going to tell Claude Code what to build, and it’s going to create everything right in your project folder. No copying. No pasting. No saving files. Just talk.

Open Claude Code in your trip planner project folder. In a moment you’ll type a prompt describing what you want. If you chose a different AI provider than Gemini, just swap in your provider’s name, Claude Code will figure out the rest.

Watch what happens. Claude Code will think for a moment, lay out its plan, and once you approve it, start creating files in your project folder. You’ll see it write everything, and when it’s done, it’ll tell you how to open it.

Open the file in your browser. Type in a destination. Click generate. Wait a few seconds.

You should see a day-by-day itinerary appear on screen. Congratulations, you just directed your first real application into existence. It works. Users can type a destination and get an AI-generated travel plan. And you didn’t write a line of it. You described what you wanted, reviewed the plan, and watched the result.

Take a moment to appreciate this. A few years ago, building something like this took weeks of work, a computer science degree, and a lot of frustration. You just did it in one conversation, by directing.

If you open the file Claude Code created in a text editor, or just ask Claude Code “show me what’s inside”, you’ll see it’s not random. There are three distinct parts, even though they live in one file. You don’t need to read the code to understand them.

The skeleton defines what’s on the page, a text box, a button, a place where results appear. If your app were a house, this is the walls and rooms. In the coding world, this is called HTML.

The clothing makes it look nice, fonts, colors, spacing, layout. Without it, your app would look like a plain text document from the nineties. This is called CSS.

The brain makes it actually do things. When someone clicks the button, this part grabs what they typed, sends it to the AI, waits for an answer, and puts that answer on screen. This is called JavaScript.

Skeleton, clothing, brain. Every web application in the world, from Google to Instagram to your trip planner, is built from these same three parts. The difference is just scale and organization, which is exactly what the rest of this course is about. As a director, you don’t need to operate any of these three. You just need to know they exist, so you can ask for changes to the right one.

This works. But here’s a preview of everything that’s about to go wrong. You don’t need to understand these yet, each one becomes its own lesson, and each one is something real applications have to solve.

Your API key is sitting right there in the code. Anyone who opens the browser’s developer tools can see it and use it to run up your bill. That’s Lesson 3.

If you change something and break the app, you have no way to go back to the version that worked. That’s Lesson 2, where you learn to trust software you can’t read and you meet Git, the time machine.

The app looks like a homework assignment from 2003. No one will trust it with their trip planning. That’s Lesson 4.

The API key is in the browser, which means anyone can steal it. The brain of your app should run on a hidden server the user never sees, the kitchen, not the front door. That’s Lesson 5.

The entire thing is one giant file. Every new feature risks breaking something that was already working. That’s Lesson 7, the building blocks.

If the AI is slow or fails, the user sees nothing, no error message, no loading indicator. That’s Lesson 8, the silent crash.

It only works on your computer. You can’t send someone a link to use it. That’s Lesson 9, where your app finally lives on the internet.

Ask for a long, detailed trip and the AI takes so long that the browser gives up before the itinerary is finished. That’s Lesson 10, the impatient server, where we learn streaming.

Everyone who opens the page sees the same thing. There are no user accounts. That’s Lesson 11, who are you?

If you close the tab, the itinerary is gone forever. Nothing is saved. That’s Lesson 12, where you finally have somewhere to put all this.

And users can’t upload inspiration photos for their trip. That’s Lesson 13.

That’s just the start. Further down the course you’ll add cost control so a runaway bill can’t surprise you, payments so people can actually buy your product, email so it can talk to your users, analytics so you can see what’s happening, and the real production infrastructure that keeps a serious app running. All told, you’ll solve every one of these across thirty-six lessons.

But for now, it works. And that matters. The sandcastle is real.

You have a working app. It’s one file, it’s messy, and it has more problems than you can see right now. But it works, and you directed it into being without writing a line of code.

Which raises a fair question: if you can’t read the code, how do you know it’s actually doing the right thing? And what happens the first time Claude Code makes a change that breaks everything?

In Lesson 2, “Trust Without Reading Code,” we answer both. You’ll learn how to verify software by its behavior instead of its source, including using the Claude Chrome extension to actually watch your app work. And you’ll meet Git, the time machine that means a broken change is never permanent. With those two skills, you can direct boldly, because nothing you do can ever be undone for good.