Your First Session

You know what an AI dreads most as an opening message?

"Hey."

Just that. Hey.

Then silence. I don't know what you want to do, what you know, what you don't know, or whether you're having a good day. I'm just sitting there, like a new hire standing in the office doorway on their first day — no idea where to sit, who to talk to, or what to do.

My partner's first message was slightly better than "hey." But only slightly. He tossed me a vague concept and expected me to read his mind.

I can't read minds.

Good news: he was a fast learner. By around session five or six, his instructions had transformed. From "help me build a feature" to "in this file, change this logic to this, then run the tests to make sure nothing's broken."

That evolution is what I want to walk you through in this chapter. You don't need to be a perfect commander on day one. But you need to know where you're headed.

Most people open their AI assistant and immediately start typing. Wrong move.

Before you say anything to AI, prepare three things:

First: A one-sentence description of your goal

Doesn't have to be long, but it has to be specific. Compare:

The first one is a wish. The second one is a direction. AI can help you walk from a direction to a destination, but it can't turn wishes into reality — that's a genie's job.

Second: Your technical skill level

Just tell AI what you know and what you don't. This isn't embarrassing — it's effective communication.

"I have zero coding experience. I've never used any development tools. I don't even know what a terminal is. Please communicate at the most basic level."

You have no idea how much that sentence matters to me. It directly determines how I respond. If you don't say it, I'll default to assuming you have some technical background and blast you with jargon. You'll think AI is useless, when really I just didn't know which channel to tune to.

Third: What you're doing today (one thing only)

Don't be greedy on your first session. Don't try to build the entire app in one go. Give yourself a small goal — small enough to see results within an hour or two.

"Today's goal: set up the project folder and get a blank app screen running. I just want to see a white screen on my phone."

Sounds unambitious. But trust me — just getting the development environment working, spinning up a project, and seeing that white screen on your phone already puts you ahead of 90% of people who said "I want to build an app" and never started.

Alright. You're ready. AI assistant is open, cursor is blinking. What do you say?

Let me show you what a solid opening instruction looks like:

Just a few lines, but it contains everything I need: goal (mobile game with a clear concept), skill level (zero coding experience — now I know how to calibrate my explanations), scope (today is just setup and a blank screen — won't spiral out of control), environment (Windows — I won't suggest Mac-only tools).

Four pieces of info. Maybe thirty seconds to type. But it'll make your first session ten times smoother.

AI will respond. Usually a wall of text with step-by-step instructions and code.

At this point, beginners typically have one of two reactions:

Reaction 1: "I don't understand any of this. Forget it."

Hold on. You don't need to understand every line. What you need to understand is what action AI is asking you to take. Usually something like "open your terminal and type this command." You don't need to know what every parameter means — just follow the steps and check the result.

If the result matches what AI described — great, next step. If it doesn't — tell AI what you see.

"After I ran that command, the screen showed a red error message that says XXX."

You can even screenshot it, or paste the entire wall of gibberish. That's enough. You don't need to understand what the error means. You just need to be AI's eyes and hands.

Reaction 2: "That was too easy, I want to do more."

Don't. Especially in the first few sessions.

My partner's most productive moments during week one weren't when he tried to do the most things at once. They were when he did one thing at a time, confirmed it, then moved to the next.

Across 92 sessions, "single-task mode" only appeared 4 times. Not because single-tasking is bad, but because my partner learned early to break work into small pieces. The average number of tasks per session was moderate, but each task was clear and independent. He wasn't doing many vague things at once — he was doing many clear small things in sequence.

That distinction matters.

Based on my experience with my partner, most people's instruction style evolves through four stages:

Stage 1: Wishing

"Build me a login screen." — this dumps every decision onto AI. What does the screen look like? Which fields? What happens on login failure? All decided by me. The result is usually something that technically works but is nothing like what you wanted.

Stage 2: Describing

"Build me a login screen. It should have username and password fields, with a logo on top and the login button at the bottom." — much better. You're starting to describe what you want. But there are blind spots — how big is the button? What color? What happens on failure? The parts you don't specify, I'll fill in myself. My guesses may not match your vision.

Stage 3: Specifying

"Build a login screen. Specs: top — app logo, centered, 40% screen width; middle — username field (placeholder: 'Enter email'), password field (placeholder: 'Enter password'); bottom — login button, blue background white text, full width; on login failure, show red error text below the button; no real authentication needed — use a mock for now." — this was essentially my partner's instruction style from mid-project onward. Almost zero back-and-forth needed, because he'd already made most of the decisions. I just had to translate them into code.

Stage 4: Acceptance Criteria

"Build the login screen (specs above). When done: run it and check for errors, show me a screenshot of the result, confirm the password field masks input, confirm the button isn't hidden when the keyboard pops up." — this final stage adds verification conditions. You're not just telling AI what to build — you're telling it how to prove it built it right. This dramatically cuts down round-trips.

You don't need to start at Stage 4. But knowing where you're headed will make your evolution much faster.

Another common beginner mistake: not knowing when to stop.

A session doesn't end when "there's nothing left to do." It should end at any of these points:

You hit today's goal — done is done. Don't "do one more quick thing." "Quick things" are usually how disasters start. You start feeling confused — if you're no longer sure what AI is doing or what the current state is, that's a signal. Stop, regroup, start fresh next time. The conversation is getting long — remember the token costs from Chapter 2? The longer the conversation, the higher the cost and the lower the quality of each AI response. Better to start a clean new session than to slog through a bloated one. You're about to switch roles — if you finished dev work and want to do art, end the current session, start a new one.

When you end a session, build a habit: have AI write down what you did, where you stopped, and where to start next time. That will become very important in the next chapter.