Skip to content
zero2vibecodelearn vibe coding
Level 1 · How it sees your project 7 min Reviewed by the author · Aug 4, 2026

Give it the right context, not all of it

Pointing at the two files that matter beats saying "look around the project". Finding those two files is a terminal skill you already have.

Level 1 · 0 / 4 lessons0%

The single biggest difference between a frustrating session and a good one is not the style. It is whether the agent was pointed at the right place.

The two failure modes

Too little. “The checkout is broken, fix it.” Broken how? Which file? What should it do instead? The agent now has to guess three things, and a wrong guess costs you a turn.

Too much. “Read the whole project first, then fix the checkout.” Now it burns a large part of its attention reading files that have nothing to do with the problem, and the relevant detail competes with forty irrelevant ones.

The target is in between and it is narrow: the specific place, the specific outcome, the specific constraint.

Find the place first

You have a terminal. Use it before you use the agent.

In the exercise below, the bug is somewhere in the checkout logic and you do not know where. Two commands settle it: find to see the JavaScript files, grep to find the one that mentions checkout.

Now your request stops being a search task and becomes an instruction:

In src/cart.js, checkout returns the number of items instead of the total price. It should sum item.price for every item in the cart. Do not change addItem.

Quick check

Which request will produce the best first attempt?

The shape of a good request

Three sentences is usually plenty.

  1. Where. "In src/cart.js…"
  2. What outcome. "…checkout should return the summed price, not the item count."
  3. What must not change. “Do not touch the API layer, and do not add a dependency.”

That third sentence does more work than people expect. Anything you do not forbid is on the table — not because the agent is disobedient, but because it genuinely does not know that adding a library would annoy you.

Paste the error, not the story

When something fails, paste the actual error text. A stack trace is dense, specific, high-value context. Your description of the error from memory is none of those things.

When you genuinely do not know where to look

Sometimes finding the place is the task, and that is a legitimate request — just make it the whole request:

Where is the discount calculated? Do not change anything, just tell me the files.

A read-only turn. You get an answer, you check it is plausible, and now you have your address for the real turn. Two cheap turns beat one expensive muddle.

Context has a cost

Everything the agent reads takes up room in the session and takes up attention. “Read everything just in case” is not free thoroughness — it is a worse answer, later, for more money. The previous lesson explains why.

What not to bother with

  • Personas. “You are a senior engineer” does not beat naming the file.
  • Politeness formulas. They cost and change nothing.
  • Long preambles about your project’s philosophy. If it matters every session, it belongs in a file — level 3.

Say where. Say what. Say what not to touch. That is the whole technique.

Should I paste file contents into the conversation?
What if the project is huge?

Try it yourself

The agent is stuck. Decide what to hand it.

Check your understanding

Answered 0/3
Mode:

Why is "have a look around the project and fix the bug" a weak request?

What are the three things a good request carries?

You do not know which file owns the behaviour. What is the cheapest way to find out?

Finish the task in the terminal and answer the questions to complete the lesson.

📝 My notes

Saved automatically in this browser · shows up on the Notes page.

Task

Find the file that owns the checkout logic, then look at the exact lines — so you can point at them instead of waving.

Tab complete · history · Ctrl+L clear · help commands

  • Not done: List the JavaScript files
  • Not done: Search for the checkout logic
  • Not done: Find the exact place it lives

Lesson Q&A

Why is "have a look around the project and fix the bug" a weak request?

Searching is not free, and a vague target means it picks its own definition of done.

What are the three things a good request carries?

Location, outcome, constraint. Everything else is decoration.

You do not know which file owns the behaviour. What is the cheapest way to find out?

You have a terminal and you know how to use it. Ten seconds of grep saves a long, expensive detour.

Which request will produce the best first attempt?

Location, outcome, constraint. The third one is the part most people leave out, and it is the one that prevents surprise edits.

Move between lessons with · search with ⌘K