Phase 2 — going further

Topics beyond the v1 curriculum. You don't need any of these to graduate, but they're genuinely useful when your projects get more ambitious.

Your tutor will introduce these on demand during step 10b (your real project) when they're relevant. But you don't have to wait; read whichever section is currently throwing you off, and ask your tutor (or any Gemini) for help applying it.

Finding answers + getting unstuck on your own

While you've got the tutor (and the WhatsApp safety net), getting stuck has been pretty cushioned. As your projects get bigger and more your own, you'll want to be able to dig yourself out.

Three moves cover most situations:

1. Read the actual error message before guessing. Computers are bad at being helpful but they're usually specific. The error names what went wrong, often where. Don't paraphrase it; read the literal words first. Then you can ask "what does this mean?"
2. Paste the exact error to your AI. Not "my code is broken". Paste the error message word-for-word: "I'm seeing this: [paste] — what does it mean and how do I fix it?" Beginners often summarise errors in their own words and lose the bit the AI actually needs.
3. Search the error text on Google. Copy the most distinctive part of the error (not the bit about your specific file, but the general bit) and paste it into Google. Other people have hit it before and written about it. Adding "Stack Overflow" or "site:stackoverflow.com" sometimes helps.

The skill being built isn't "knowing the answers." It's knowing where to look. Errors → AI → search → WhatsApp safety net. In that order.

Working with APIs

An API is a way for one app to ask another app for information. That's the whole concept. When your weather app shows the temperature, it's asking a weather API. When a website shows a Google Map, it's asking Google's mapping API.

Your projects can use APIs too: to fetch live data, post to a service, or do anything a separate provider offers.

When you'll want one: when your project wants something it doesn't already have. Real weather. Live sports scores. Calendar events. A map. A list of stocks. The exchange rate. Anywhere a number, fact, or feed has to come from "somewhere on the internet."

The fiddly bits the AI handles for you:

• Signing up for an API key. Most APIs require you to register so they know who's asking. You usually do this on the API provider's website (the AI can't open a browser for you, but it'll give you the URL and tell you what to click).
• Storing the key safely. An API key is like a password; don't paste it into chat, don't commit it to git. The AI will set up a separate file (often .env) to hold it, and add that file to .gitignore so it doesn't get pushed to GitHub.
• Writing the actual code that calls the API and shows you what came back.

How to ask: describe what you want to see in plain words. "I want my page to show today's weather for Manchester. I think there's a free weather API, can you set it up?" The AI takes it from there, narrating each step.

What code "actually is"

You don't need to write code to use AI well, but a light mental model of what it's doing makes reviewing AI output much easier.

Almost all code does one (or more) of four things:

• Stores something. Saves a value, a list, a file, a setting. (Names, scores, the contents of a form.)
• Decides something. An "if": if the score is over 100, show the win screen. Branching logic.
• Repeats something. A "for each": for each name in the list, print "hi <name>". Loops.
• Communicates with something. Asks an API, reads a file, writes to a database, sends a notification. Anything crossing a boundary.

That's it. Every program is some mix of those four. When the AI shows you a chunk of code, asking "what's this storing / deciding / repeating / talking to?" usually surfaces the point.

When this is useful: when you want to understand what you're approving, or when you're trying to follow what changed. "Walk me through this code in terms of store / decide / repeat / communicate" is a pretty good prompt.

Project architecture — where new code goes

Early on, everything lives in one file. That's fine. Eventually one file gets too big: you scroll forever, the AI starts mixing unrelated bits when it edits, you can't remember where you put something.

The fix is splitting: pulling chunks of code out into separate files, each with a focused job. A login bit, a data-loading bit, a "show the page" bit.

When to do this: when your file is over a few hundred lines, or when you find yourself searching it for things. Trust the discomfort; that's the signal.

How to ask: "This file is getting big. Can you help me split it into a few smaller files, grouped by what they do? Show me the plan first before changing anything." The "show me the plan first" matters; splitting badly can make things worse. Review the plan, then approve.

Don't worry about "good architecture" as a thing. Worry about "can I find what I'm looking for." If yes, you're fine.

Branches and pull requests

In step 6 you learned about commits (local save-points). In step 7 you learned about pushing (sending commits up to GitHub). Branches and pull requests are the next layer up.

A branch is a parallel line of work. Imagine your project as a path through a forest: a branch is a side trail you can wander down, try something out, and either merge it back into the main path or abandon it.

A pull request (or "PR") is a proposal to merge one branch into another, with a description of what changed. PRs are how teams review each other's work before it lands.

When you'll want them:

• You're collaborating with someone else and want them to review your work before it goes into the main project.
• You want to try a big change without messing up what's working. (Branch off, try it, if it works merge back; if not throw the branch away.)
• You want a clear history of "what changed and why"; PRs give you a place to write the why.

How to ask: "I want to try adding levels to my game without breaking what works. Can you set me up on a new branch?" Or: "Can you make a pull request for the multiplayer changes? Here's what I want the description to say: …"

Managing multiple projects, with aliases and modes

v1 assumed a single project folder (the tutor's). Once you start a second project, you need a way to keep them organised and quick to launch.

The rule: one folder per project, each its own git repo. Don't put two projects in the same folder; they'll collide.

The launcher pattern (from your step 10b closing lesson):

Your tutor was launched by typing one word: tutor. That word is a bash alias, a line in your ~/.bashrc that says "when I type 'tutor', cd into this folder and run gemini."

You can make one for every project. Ask any Gemini:

Then close and reopen Git Bash for the alias to load, and you've got a one-word launcher for your new project.

Notice the mode part; see the Approval modes section below for what your choices are.

Long sessions, context, and starting fresh

Every AI conversation has a memory limit (the context window). The Helpful notes page has the short version; here's the practical version for when it actually bites.

What you'll notice: the AI gets slower; it starts confusing things from earlier in the session; it forgets details you set up an hour ago.

Three responses, roughly in order:

1. End the lesson and come back tomorrow. End lesson tells your tutor to save your progress; progress.md will carry the state forward. A fresh session will be sharper.
2. Ask the AI to summarise into progress.md first. If you've been doing something big and want the next session to start with rich context, ask: "Before we end, can you write up what we did today into progress.md? Lots of detail; I want to be able to come back to this." Then end the lesson.
3. Start a fresh conversation with the goal stated explicitly. For non-tutor projects (where there's no progress.md), open a new gemini conversation in the project folder and start with: "I'm working on X. We did Y yesterday. Today I want to do Z." Treat each fresh start like talking to a stranger: give them everything they need.

The bigger lesson: with the tutor, resume works because progress.md exists. With other Geminis (in other project folders), each conversation is blank. You'll need to give them context every time.

Approval modes — choosing your level of friction

Gemini has three "approval modes" that control when it asks you before doing something. Your tutor sets you up on auto_edit for v1 because that's the middle ground. Once you're confident, you might want to change.

The three options:

• auto_edit (where you are now): file edits happen silently. Terminal commands (like running a script) and network calls (like fetching from an API) still ask. Good middle ground.
• yolo: everything happens silently, including terminal commands and network calls. Faster flow, more trust required. Best when you really know what you're doing in a given project, and the AI has a proven track record.
• default: every single thing asks. Slower, safer. Best when you're doing something genuinely risky or want to slow down deliberately.

How to switch: per project, you can bake the mode into the project's launcher alias. The alias your tutor uses is:

Notice the --approval-mode=auto_edit at the end; that's where the mode goes. For a new project, you can change it:

When you ask the AI to set up an alias for a new project, just tell it which mode you want; it'll fill in the right flag.

A caution: yolo mode skips the "are you sure?" prompts for terminal commands too. If the AI decides to run rm (delete) on something, you won't get asked first. Worth knowing.