Lesson 2: Intro to AI-Assisted Coding 🤖

Now that you have your tools set up, let's talk about what it means to code with an AI partner. In this lesson, you will learn the core philosophy of AI-assisted development and practice the basic mechanics of working with Codex.

🎬 The philosophy: You are the director

It's tempting to think of an AI coding assistant as a magic box that writes perfect code for you. It is not. A better analogy is a film director and a very fast, knowledgeable, but sometimes literal actor.
  • You are the director: You hold the vision. You know what the scene is about and what the final product should look like. You make the creative decisions.
  • Codex is the actor: Codex delivers lines (writes code) incredibly quickly. It has memorized almost every script ever written. But it needs your direction to know what to do and how to do it.
Your job in the BuildLab is to get good at directing. You will break down big ideas into smaller, specific instructions that your AI partner can execute.

⚠️ The trap: directing vs. hoping

Codex, like many AI tools, can feel like magic when you may not have deep understanding of code, or what is happening under the hood. You type a few words, code appears. It feels productive!
The tool rewards speed in the moment. Vague prompts often “work” quickly, so people unconsciously start optimizing for speed over clarity and output over understanding. The cost shows up later: in confusion, in bugs you can’t explain, and in code that breaks the second a real user touches it.
There’s a simple way to check yourself throughout this program:
You’re either directing… or you’re hoping.
Directing is specific, intentional, and accountable — you know what you asked for and you can defend it. Hoping is vague and crosses fingers. When the code breaks, you’re still the one who shipped it. Codex doesn’t get blamed in code review.
This program is about building the directing muscle. The exercises below are designed to help you feel the difference.

🌍 The bigger picture: Transferable skills

We are using Codex for the BuildLab, but the skills you learn here are not just "how to use Codex." You are learning how to be an AI-assisted developer.
So! Let’s say you get a job tomorrow and your team uses Cursor, GitHub Copilot Workspace, or Devin, the interface will look different, but the core mental models and skills are exactly the same. You will always need to:
  1. Gather context: Knowing which files the AI needs to look at to solve the problem.
  1. Prompt clearly: Being specific about your constraints, frameworks, and goals.
  1. Verify the output: Knowing how to read the AI's code, test it in the browser, and confirm it actually works.
These are universal skills that you’ll gain after completing the BuildLab!

🔄 The core loop: Prompt, review, refine

Working with Codex follows a simple, iterative loop:
  1. Prompt: Give Codex a clear, specific instruction in natural language.
  1. Review: Carefully read the code that Codex generates. Does it do what you asked? Is it correct? Do you understand it?
  1. Refine: If the code isn't quite right, give Codex a follow-up instruction to fix or change it. Or, edit the code yourself!
Let's try it.

✅ Exercise 1: Your first prompt

  1. Create a new file in VS Code called hello.js.
  1. Open the Codex panel.
  1. In the Codex chat, type the following prompt:
      2. "In the hello.js file, create a JavaScript function called greet that takes a name as an argument and returns a string that says 'Hello, [name]!'"
  1. Review the code. Codex should generate the function for you and place it in the file. Read it. Does it look right?
  1. Now, let's refine it. Type this follow-up prompt:
      2. "Now, call the greet function with the name 'World' and print the result to the console."
  1. Review again. Codex should add the console.log line. Now, open the VS Code terminal (Ctrl+ or Control+ + `) and run the file by typing:
      2. node hello.js
You should see "Hello, World!" printed in your terminal. Congratulations, you just co-wrote a piece of code with an AI! 🎉

📝 Best practices for prompting

The quality of your output depends heavily on the quality of your input. Here are four habits that separate directors from hopers:
1. The 3-part prompt scaffold. Most strong prompts answer three questions: What do you want built? What are the constraints (language, file, libraries, style)? What’s the expected output or behavior? Instead of “make a button,” you end up with: “Create a React button component using Tailwind CSS with a blue background that says ‘Submit’ and logs ‘clicked’ to the console when pressed.” Same task, totally different result.
2. Prompt like you’re handing off to a junior engineer. Before you hit enter, ask yourself: “If a real person followed only my instructions, would they succeed? Could they misunderstand anything?” If you’re not sure, add more detail. This one mental check catches 80% of vague prompts before they happen.
3. One step at a time. Don’t ask Codex to build the whole feature in one shot. Ask for one piece, review it, run it, then ask for the next. This keeps you in the driver’s seat — and it’s how the prompt-review-refine loop is supposed to feel.
4. Review like a skeptic. When Codex returns code, run through a quick mental checklist before accepting it:
  • Does it actually do what I asked?
  • Do I understand every line?
  • Did it add anything I didn’t ask for?
If you can’t answer all three, that’s your signal to slow down (or ask Codex to explain).
📌 Try this: Some folks put a literal sticky note on their laptop with their go-to prompting checklist — or just the words “directing, not hoping.” Sounds silly. Works. Whatever helps you pause for two seconds before firing off a lazy prompt.
⚠️ Common pitfall: vague prompts. If your prompt is unclear, your output will be unpredictable. Codex takes your words literally and fills in gaps with its best guess — which may not match what you wanted.
❌ “fix this”
✅ “The getUser function on line 12 returns undefined when the user isn’t logged in. Update it to return null instead, and add a comment explaining the behavior.”

✅ Exercise 2: Same task, two prompts

This exercise is designed to let you feel the difference between hoping and directing. Don’t skip it!
  1. Create a new file called evens.js.
  1. Open Codex and start with Prompt A (the lazy one):
      2. “make a function for evens”
  1. Read what Codex generates. Don’t fix it — just notice the assumptions it had to make. (Did it guess the input type? The function name? Whether to log or return?)
  1. Delete that code. Now try Prompt B (the intentional one):
      2. “In evens.js, create a JavaScript function called getEvenNumbers that takes an array of numbers as an argument and returns a new array containing only the even numbers. Then call it with [1, 2, 3, 4, 5, 6] and log the result using console.log.”
  1. Run node evens.js and check the output.
Reflect for 30 seconds: Which version would you trust if you were shipping this in a real project? Which one would a teammate be able to read and understand six months from now? Which one did you actually direct — versus hope into existence?
That tiny moment of discomfort you might feel comparing the two? That’s the lesson. Hold onto it.

✅ Exercise 3: Prompting in your project

Now let's apply this to the actual Community Hub codebase.
  1. Open your project in VS Code.
  1. Open the file app/page.tsx. This is the main homepage of your application.
  1. In the Codex panel, ask:
      2. "What does the file app/page.tsx do?"
  1. After reading the explanation, give Codex a creative direction:
      2. "Can you add a subtitle below the main heading that says 'Welcome to our community'?"
  1. Review the code changes. If they look good, run your app (pnpm run dev) and check localhost:3000 in your browser.
How to self-validate: If you see your new subtitle on the homepage, you've just made your first AI-assisted contribution to the codebase!
This new way of working might feel strange at first. The goal of this week is to get comfortable with the prompt-review-refine loop. The more you practice, the more it feels like a natural conversation with your coding partner. You've got this!