What It Can and Can't Do
It can fill in the implementation, but not the judgment. Knowing where the line sits tells you which part is yours.
It can fill in the implementation, but not the judgment. The calls you skip, it will make for you—and make them look plausible. That is its most useful behavior and the source of every surprise.
What you'll run into:
- What it produces runs, but it isn't what you wanted
- You ask for a list, and it adds sorting, filtering, pagination, and an export button
- By the third round of edits it has forgotten the first round's agreements, and you explain them again
Where the line is
When you split a task into "hand it over" and "keep it yourself," the criterion is not difficulty—it's whether the task has one right answer.
| Kind of task | Who | Why |
|---|---|---|
| Turning a description into code | It | Plenty of examples; approaches converge |
| Refactoring, renaming, bulk replace | It | Mechanical, with a clear right and wrong |
| Explaining unfamiliar code | It | Reading is easier than creating |
| Matching a reference look | It | A concrete target makes the goal clear |
| Deciding what to build and what to skip | You | Depends on your situation, which it doesn't know |
| Judging whether a solution fits this context | You | Needs specific users and constraints |
| Trade-offs: more features or faster | You | A value judgment with no standard answer |
| Acceptance: does this count as done | You | You set the standard; it can only measure against it |
It will write a complex algorithm faster than you, but it can't decide whether to build the feature at all. That's where the line sits.
How it fills the blanks
It won't say "you weren't clear." It fills the gap with whatever shows up most often in its training data. Ask for "an order list" and it may add pagination at ten per page, newest-first sorting, a search bar, and an export button—while leaving out empty states, loading states, and error states, exactly the three your real environment needs. What it adds is not necessarily what you wanted, and what it omits is often essential. This bias is systematic, not accidental.
The behavior saves a lot of boilerplate, but two more traits matter. It only sees what you give it: it doesn't automatically remember yesterday's decisions across sessions. And it invents things with a straight face—APIs, parameters, and libraries that don't exist. A model doesn't distinguish between knowing and not knowing; it just completes the next token by probability. hallucination-wiki Anywhere accuracy matters, verify.
So the division of labor becomes
- You write the judgment down; it follows it. Whatever judgment stays in your head, it can only guess at.
- Be explicit about what not to do. Otherwise it will helpfully fill it in (see the not-doing list).
- You own acceptance. It can self-check, but you have to supply the criteria, concrete enough to check item by item.
- Things you have to repeat—write them into a file. Don't re-explain each time, and don't count on it remembering.
String these four together and you get what the rest of this section is about: how to write specs, how to manage context, and how to lock constraints into files.