One model, different working environments
Chat applications, editor assistants, and tool-using agents can all use language models. Their working capabilities depend on the information they can see, tools they can call, and permissions they have.
Don't infer capabilities only from the interface. A chat application may have tools; a terminal agent may lack a particular permission. Establish whether it can read the project, modify files, run commands, and inspect results.
Pasting an error into chat doesn't automatically provide the whole project. Supply relevant context or let an authorized tool read specific files.
Take this with you · Find out what the assistant can actually see and do.
Choose for the task, not just the name
Models vary in capability, speed, cost, and input limits. One model may perform differently across tasks. Small evaluations on your real examples are more useful than guessing from product names.
Names, prices, and settings change. This course teaches a decision method, not a permanent best-model ranking. A simple conversion and a complex project modification need not use the same setup.
Compare options against the same brief and acceptance conditions. Record completion, time, and actual cost rather than just answer length.
Take this with you · Use your own task to evaluate a model.
More processing for some difficult problems
Some models or tools expose reasoning budgets that allow extra computation before an answer. This may help some difficult tasks, add latency or cost, and still fail to guarantee correctness.
Check the current tool's capabilities and controls. Important work still needs bounded steps, sufficient evidence, and independent checks. “Think deeply” is not a quality guarantee.
A multi-file change needs understanding of the existing structure and effects. Requesting inspection before modification is more concrete than merely asking for extra care.
Take this with you · More computation doesn't replace missing information or acceptance conditions.
Maintain a concise project note
Record the goal, current implementation, startup steps, and stable constraints. This helps later work begin with useful context. How a tool loads project notes depends on its actual features and configuration.
Notes become outdated too. Maintain them and distinguish facts, hypotheses, completed work, and remaining work. A transcript of every discussion is not the same as a current project summary.
“Local storage only; no login; start with this command; refresh restoration still unverified” is actionable context. Yesterday's ten alternative plans need summarizing.
Take this with you · A handoff should explain the present state and next action, not repeat the entire past.
A brief: goal, context, constraints, and checks
An actionable description includes the user and goal, current conditions, expected behavior, scope constraints, and completion criteria. Ask for clarification when an ambiguity materially affects implementation.
Debugging also needs steps, expected and actual outcomes, and exact errors. Label “I suspect the database” as a hypothesis. Complete descriptions reduce guesswork, but complex work still needs iteration.
“Improve the list” is vague. Rejecting blank tasks with feedback while preserving existing actions and refresh restoration defines observable behavior.
Take this with you · Professionalism comes from precise information and checkable results, not jargon.
Assemble a brief someone can act on
Add a goal, context, constraints, and acceptance checks. Watch one vague request become specific.
Make something useful for me.
0/4 information categories supplied. Write your own version in the chapter challenge below.
This checks the structure of information, not model quality, and doesn't guarantee a real AI will execute it correctly.
Which helps most when deciding whether AI has implemented saving?
Choose an answer before reading the explanation.
Write a list-improvement brief that lets someone tell whether it is done.
Think first, then uncover help as needed. Later chapters expect more complete descriptions and clearer checks.
Bring this chapter's context to your AI. Going deeper is optional; you can keep reading without it.
Turn my vague request into questions and let me supply the missing information first.
One approach you can make your own
I'm learning computers and AI-assisted programming from scratch. In this chapter I learned: Driving AI：Match tasks to actual tools and permissions；Maintain context and separate observations from guesses；Write a complete brief and verify its outcome Turn my vague request into questions and let me supply the missing information first. Check my understanding first. Explain one small question at a time with a concrete example and the limits of any analogy. Ask a scenario question, then adapt to my answer. Distinguish facts, guesses, and uncertainty; suggest hands-on ways to check. Confirm the version before giving tool-specific advice, and don't invent features or references.
Complete this chapter
Mark the sections as read, finish the experiment, and pass the scenario check to record completion. You can visit the next chapter at any time.
Read the original references
This is an introduction. These official resources help you check details and explore further.
Anthropic · Building effective agentsYou can guide a single task. Finally, connect repeated work into a process you can observe, retry, and verify.