Lesson 2: Intro to Agentic 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, it feels like handing control over, waiting to see what comes back, and crossing your fingers that the result is “good enough”.

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:

Gather context: Knowing which files the AI needs to look at to solve the problem.
Prompt clearly: Being specific about your constraints, frameworks, and goals.
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:

Prompt: Give Codex a clear, specific instruction in natural language.
Review: Carefully read the code that Codex generates. Does it do what you asked? Is it correct? Do you understand it?
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

Create a new file in VS Code called hello.js.
Open the Codex panel.
In the Codex chat, type the following prompt:

"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]!'"

Review the code. Codex should generate the function for you and place it in the file. Read it. Does it look right?
Now, let's refine it. Type this follow-up prompt:

"Now, call the greet function with the name 'World' and print the result to the console."

Review again. Codex should add the console.log line. Now, open the VS Code terminal (Ctrl+ or Control+ + `) and run the file by typing:


node hello.js

You should see "Hello, World!" printed in your terminal. Congratulations, you just co-wrote a piece of code with an AI! 🎉

📝 BuildLab Fundamentals

The quality of your output depends heavily on the quality of your input. The following are the BuildLab Fundamentals: skills we want you to carry with you throughout the program and beyond. We want you to practice these with every prompt: these skills separate someone who uses AI from someone who directs it.

Fundamental #1: Prompt using the 4-part prompt scaffold.

Most strong prompts answer four questions:

Goal: What do you want built?
Context: What already exists that the AI needs to know about?
Constraints: What rules should it follow?
Done-when: How will you know it's finished?

Do I need to write my prompts in this exact strict four-part format?

No, you don’t. Take a look at the following two prompts.

Prompt A

Goal: Create a React button component.
Context: The component should live in components/SubmitButton.tsx.
Constraints: Use Tailwind CSS. The button should have a blue background, display the text "Submit", and log "clicked" to the console when pressed.
Done-when: I can see the button rendered on the page, and clicking it logs "clicked" to the console.

Prompt B

Create a React button component in components/SubmitButton.tsx using Tailwind CSS with a blue background that says 'Submit' and logs 'clicked' to the console when pressed.

It’s done when I can see the button on the page and clicking it logs to the console.

Prompt A follows the four-part structure while Prompt B is written conversationally. Both communicate the same core information to the AI. The point is that your prompt contains these four pieces of information, not that it follows a rigid structure.

Some people have found it helpful to explicitly write prompts in this four-part format while they’re learning, especially because it slows them down and helps them think more clearly about what they’re asking for.

Fundamental #2: Tell the AI to ask, not guess.

Here’s something important to understand about how AI models work: they are trained to be helpful. Sounds great, right? Yes, but it has a side effect: when your prompt is vague or ambiguous, the AI won’t stop to say “Hey! I’m not sure what you mean, could you clarify?” Instead, it’ll pick the most likely interpretation and run with it. Confidently. Which means the final answer may a combination of real understanding and confident guesses, without clearly distinguishing which is which.

The good news is that this is a fixable problem— and the fix is one sentence! 😱 Add one sentence to their prompts: “If anything is unclear or ambiguous, ask me before proceeding.”

That single instruction overrides the model's default behavior. Instead of filling in blanks, it surfaces them — and you get to make the decision instead of the AI making it for you. It can be quite annoying to continually add this to your prompt. In the Week 2 All-Hands, you'll set up a file called AGENTS.md that tells Codex to always do this automatically. It's one of the highest-leverage habits in agentic coding.

One important caveat: telling the AI to ask instead of guess doesn't guarantee the output will be perfect, correct, or exactly what you had in mind. It just means the AI will surface the obvious ambiguities rather than silently resolving them for you. There will still be assumptions it makes that it doesn't think to question — which is why this Fundamental works hand-in-hand with Fundamental #4: Code Review Your AI (more on this further down this lesson!). The asking catches gaps before code is written. The review catches what slips through after.

👉 To understand why this matters, it helps to understand a little bit about how AI models actually work under the hood.

Large language models like the one powering Codex are built on a simple core mechanic: LLMs predict the next most likely word (or "token") in a sequence. Models don’t "think" about your problem the same way a human would. Models calculate “given everything I've seen in my training data and everything in this conversation so far, what's the most statistically probable thing to say next?”

Thus, every response a model generates is, by definition, the highest-probability output. Saying "I'm confused, can you clarify?" is almost never the highest-probability response, because in the millions of conversations it was trained on, the overwhelmingly common pattern is: human asks something → assistant provides an answer.

This creates a specific failure mode that researchers call hallucination with high confidence. The model doesn't know what it doesn't know. When your prompt has holes —like, let’s say you said "add a form" but didn't specify where, with what fields and styled how— the model doesn't flag those holes. Instead, it fills them in using statistical patterns from its training data. It picks the most common form structure, the most common file location, the most common styling approach, etc.

Like mentioned above, this is why experienced engineers add one sentence to their prompts: "If anything is unclear or ambiguous, ask me before proceeding." This instruction overrides the model's default behavior and telling the model, “Hey, the highest-probability response to ambiguity is NOT to guess, it's to ask me to clarify.” This reweights the model's output distribution so that clarifying questions become the preferred response when there is uncertainty.

Fundamental #3: Plan before you build using Plan Mode.

You might be used to interacting with AI like a chat: going back and forth, one message at a time. That works for simple questions. But, when you're building features, that approach can get messy fast. The AI starts changing your code before you've agreed on what it should change, and you end up in a cycle of "fix this, no not like that, try again."

The fix: ask Codex to plan before it acts.

When you activate Plan Mode, Codex reads the relevant files in your project, proposes a step-by-step plan for what it will change (which files, what approach), asks clarifying questions if something is ambiguous, and waits for your approval before writing any code. You're reviewing the AI's thinking, not just its output.

How to activate Plan Mode:

In VS Code: Press Shift + Tab before sending your prompt (you'll see a "Plan" indicator appear)
In the CLI: Type /plan before your prompt
In the Codex App: Toggle with /plan or Shift + Tab

The Plan Mode workflow:

Read your ticket and understand what it's asking
Open Codex and toggle Plan Mode on
Describe what you want to build (use the 4-part scaffold: Goal, Context, Constraints, Done-when)
Review the plan Codex proposes — Does it make sense? Is it touching the right files? Does the approach match what you'd expect?
If something looks off, ask Codex to revise the plan
Once you're satisfied, approve it and let Codex implement

When do I need Plan Mode vs. just prompting one step at a time? For small, single-file tasks (like Exercise 1 where you created a function in hello.js), you don't need Plan Mode — just prompt, review, refine. For anything that touches more than one file or has multiple parts, Plan Mode keeps you in control of the big picture while Codex handles the details.

Validate at each step, not just at the end. Even with a plan approved, don't let Codex run through the whole thing and only check at the end. Watch the first file change — does it look right? Run the app locally and check in the browser. Then let it continue. If something went wrong in step 1, you want to catch it before step 5 builds on top of it.

Fundamental #4: Code review your AI.

Imagine this scenario: you paste your ticket's acceptance criteria into Codex, Codex then generates working code on the first try, you think "wow, that was easy, this looks great,” and you’re very tempted to just move on without inspecting it. If you push code you don't understand, you might regret it later: like if a teammate asks you how it works, or when something breaks and you don't know where to look, or when your next ticket builds on top of this one and you can't explain what's already there. And while it’s nice to generate code (hey we get it, good code is fun to generate!), the ultimate goal of the BuildLab isn’t to generate code, it’s to build things you understand.

So, how do we build things we understand?

Once Codex gives you code, you have a decision to make.

The easy path: accept the code, see that it works, move on. It's fast. It feels productive. Gives you a dose of serotonin. And hey, sometimes the code is perfectly fine. But you didn't learn anything. (We’ll say it again for the people in the back: the ultimate goal of the BuildLab isn’t to generate code, it’s to build things you understand.)

The harder path: slow down for a few minutes. Read the code. Make sure you understand it. Ask yourself why it works, not just that it works.

Jasmine Samra calls this The Choice: it’s up to you to make the decision on whether you’re going to passively trust that the code works or pausing to actively internalize it. In a world where AI can produce production-ready code in seconds, an engineer's biggest strengths are technical aptitude and product knowledge. Technical aptitude means you can read, evaluate, and debug what the AI produces. Product knowledge means you understand what should be built and why. The engineers who thrive will be the ones who bring both to the table. And to bring both to the table, you’ll need to choose to actively internalize AI-generated code.

Here's why this matters more than you might think: technical skills can atrophy with lack of active engagement when using AI tools. A 2026 Anthropic study found that developers who relied on AI without engaging with the code scored 17% lower on comprehension, with the biggest drop in debugging skills specifically. The takeaway isn’t "don't use AI." It was that the developers who understood their code were the ones who chose to slow down and read it, even when they didn't have to.

In the AI world, this concept is called being "human-in-the-loop" — staying actively in the driver's seat instead of letting the AI run on autopilot. In engineering, it's called code ownership — the principle that if your name is on it, you're accountable for it.

So, here's your checklist. Run through it every time before you accept:

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 pause and spend more time internalizing the code.

✅ Exercise 2: Same task, two prompts

This exercise is designed to let you feel the difference between hoping and directing and to implement the Fundamentals you learned above. Don’t skip it! Let's create a function that takes in an array of numbers and returns a new array containing only the even numbers.

Create a new file called evens.js.
Open Codex and start with Prompt A (the lazy one):

“make a function for evens”

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?)
Delete that code. Now try Prompt B (the intentional one):

“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.” If anything about this is unclear, ask me before writing code.

Run node evens.js and check the output.
Before you move on, practice The Choice. Look at the code Codex generated for Prompt B and make sure you can answer all three questions: Does it do what I asked? Do I understand every line? Did it add anything I didn't ask for? If you can't answer one of them, ask Codex: Can you walk me through this code line by line?

Reflect: Which version would you trust if you were shipping this in a real project? Which one better matched the intended functionality? Which one did you actually direct — versus hope into existence?

✅ Exercise 3: Prompting in your project

Now let's apply the BuildLab Fundamentals to the actual Community Hub codebase.

Open your project in VS Code.
Open the file src/app/page.tsx. This is the main homepage of your application.
In the Codex panel, ask:

What does the file src/pp/page.tsx do? If anything about the structure is unusual or worth noting, let me know.

After reading the explanation, toggle Plan Mode on (Shift + Tab — you should see a "Plan" indicator appear). Now give Codex a direction using the 4-part scaffold:

Goal: Add a subtitle below the main heading. Context: The file is src/app/page.tsx, which currently renders the homepage with a list of communities. Constraints: Use Tailwind CSS for styling. Keep it simple — just a <p> tag. Done-when: I can see the subtitle "Welcome to our community" on the homepage below the main heading. If anything about this is unclear, ask me before writing code.

Review the plan. Instead of immediately writing code, Codex will propose what it's going to change. Does the plan make sense? Is it touching the right file? If so, approve it.
Run your app (pnpm run dev) and check localhost:3000 in your browser.
Practice The Choice. Before you move on — look at the code Codex wrote. Can you explain what changed and why? If someone asked you "what did you just add to the homepage," could you answer confidently?

How to self-validate: If you see your new subtitle on the homepage AND you can explain the code that put it there, you've just completed your first full BuildLab workflow: scaffold your prompt, plan before you build, review your AI's work, and own the code.

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!