Telling your agent what you want — Learning Center

Here is the part nobody quite believes until they do it: you can build real, working software without writing a line of code yourself. Not a mockup, not a slideshow of what it would look like — the actual thing, running. You do it by describing what you want to an agent that does the building.

So the most important skill here isn't a programming language. It's the much older, more human skill of asking well — saying what you want clearly enough that someone capable can go do it. You already do this with a contractor, a designer, a colleague. The only new thing is that the someone is an agent, working from a chat box.

This lesson is about that first request. Get it right and you'll feel something specific: I described what I wanted, and a working thing came back. That feeling is the whole point. Everything else builds on it.

you're descriBing an outcOme, not dictAting steps

The instinct, when people first sit down with an agent, is to control how it works — to spell out the steps, the files, the technology, as if you do the engineering and the agent just types it up. That's backwards, and it makes the result worse.

The agent's job is the how. Your job is the what and the why. You describe the outcome — what it should do, who it's for, what “good” looks like — and let the thing that's good at building figure out the construction. Under the hood, an agent reads your request, does something, looks at what happened, and goes again until the job is done. You don't need to understand that loop to use it. You just need to hand it a clear destination.

Watch the difference. Here's a request that tries to do the agent's job:

“Make an HTML page with a flexbox layout, three div columns, a JavaScript function that sorts an array, and a button with an onclick handler.”

You've just spent your effort guessing at construction details you may have wrong — and you've boxed the agent into your guess. Now here's the same need, described as an outcome:

“I want a simple page where I can paste in my to-do list and have it sorted by priority. I'm the only one who'll use it, and I want it to look clean and calm, not busy.”

That second version is shorter and better. You said what it's for, who it's for, and what good feels like. The agent picks the layout, writes the sorting, chooses the button — and because you described the destination instead of the road, it can choose a better road than you'd have spelled out.

what the aGent actuAlly does With that

When you send a request like that, the agent doesn't just paste back text. It builds — writes the page, runs it to see if it works, fixes what's off, and hands you something you can open. Then it usually tells you what it made and what it assumed, which is your cue to react.

So a good first request kicks off a real back-and-forth. You describe; it builds; you look at what came back and say “more like this, less like that.” You're not writing a perfect spec on the first try — you're starting a conversation with a capable builder. The first message just needs to be good enough to get a real draft. Something concrete to react to beats a paragraph of perfect requirements you agonized over.

give it the Whole picTure, not hAlf of one

The most common reason a first request disappoints isn't that it was too short. It's that it was incomplete — it left out something the agent couldn't guess, so the agent guessed, and guessed differently than you'd have wanted.

Think about what a new colleague would need to ask if you gave them this job and then left the room. They'd want to know:

Who is this for? Just you, your team, customers, the public? It changes everything about how it should look and behave.
What does it need to do? The actual job — not the buttons, the purpose.
What's the feeling or style? Playful, serious, minimal, dense. The agent has taste, but it's not a mind reader.
How will you know it worked? “I can paste a list and get it back sorted” is a finish line the agent can aim at — and that you can check.

You don't have to answer all four in formal sentences — just don't leave a hole where one of them should be. And keep the picture consistent: don't ask for “dead simple” in one breath and list fifteen features in the next. If the picture contradicts itself, so will the thing that comes back.

A quiet superpower: the more specific you are about the finish line, the better the result — because now the agent can check its own work against it, not just hope it guessed your taste. “Done means I can type a city and see today's weather” is worth more than three sentences of adjectives.

specificitY is the dial That contrOls quality

Here's the rule to carry out of this lesson: vague in, vague out. Specific in, specific out. The detail you put into describing the outcome is the single biggest lever you have on how good the result is — bigger than any trick or magic phrasing.

“Build me a website” gets you a generic guess, because you gave it nothing to aim at. “Build me a one-page site for my dog-walking business, with my hours, my neighborhood, and a button to text me” gets you something that's actually yours — because every detail you added was a guess the agent no longer has to make.

And specific does not mean technical. Not one word in that better request was code — it was all plain description of the real thing you wanted. That's the move: be richly specific about the outcome, and stay out of the construction.

three staRter requEsts you Can steal

Below are three fill-in-the-blank prompts. Each already does the work this lesson taught — names the purpose, the audience, the style, and the finish line. Pick the closest one, fill in the blanks, and send it. That's your first build.

A personal tool. “I want a simple tool for myself that lets me __________ (e.g. track how much water I drink each day). It's just for me, so don't make me sign in. Keep it __________ (e.g. clean and quiet). I'll know it works when I can __________ (e.g. tap a button and see today's count go up).”

A page for other people. “Make a one-page site for __________ (e.g. my pottery class). The people seeing it are __________ (e.g. beginners deciding whether to sign up). It should feel __________ (e.g. warm and handmade, not corporate) and the main thing I want them to do is __________ (e.g. email me to book a spot).”

Something that works with information. “I have __________ (e.g. a list of my expenses) and I want to __________ (e.g. see them grouped by category with a total). It's for __________ (e.g. me, at tax time). Show me a first version I can react to — I'll know it's right when __________ (e.g. each category adds up correctly).”

Send one. Read what comes back. Then say what's off — “make the total bigger,” “I meant weekly,” “this feels too plain.” That second message is where the real building happens, and it's the rhythm you'll use from here on.

One honest note, so you start with your feet on the ground. An agent is a strong collaborator, not a wish-granting genie — the pitch was never “software that builds itself.” It's you and the agent building together, with you holding the direction. A clear first request doesn't end the conversation; it earns you a good first draft to steer. That's not a limitation to apologize for — it's exactly the deal you want, because it means the result is still yours. The next lesson follows that draft into the back-and-forth, where a rough first try becomes the thing you actually meant.