How to get the most out of your tokens

[01] · BEGINNER

Make your tokens do useful work

This guide is for someone who can read a little code but is new to working with a coding assistant. You will practise a small change, learn how to check the result and decide which information is worth keeping for the next task. You can use any tool that lets an assistant read files and propose or make edits.

A token is a unit used to represent input and output; in text it can be a word or part of one. Your task description, supplied files and the answer all contribute to the work a model processes. Exact accounting varies by product. You do not need to count tokens manually to improve the way you work.

Tokens carry your instructions, context and the model’s response. A short request can still lead to a long, unproductive session if the goal is unclear or essential context is missing.

[02] · BEGINNER

Ask → Plan → Act

The goal comes first: what do you want to be different when the task is finished? Ask, Plan and Act turn that goal into a sequence you can supervise. They are stages of a conversation, so you can use them even if your tool has no buttons with those names.

During Ask, learn enough to describe the problem accurately. During Plan, choose the change and the evidence that will establish success. During Act, make that change and check it. If the evidence reveals a wrong assumption, return to Ask instead of continuing down the same path.

Ask → Plan → Act is a way of working, independent of the tool’s mode names. A small, clear task can move through these stages quickly; uncertain work needs more time in Ask and Plan.

[03] · BEGINNER

Context is what makes the request actionable

A prompt is the request you type. Context is the information available when the assistant responds: your request, the relevant conversation, any files it has read and results from commands. Saying “fix this” works only if “this” is already unambiguous.

For the exercise, two small files are more useful than a long description of your whole project. In a real project, start with the affected file, its tests and the error. Give the assistant a way to inspect more when needed. This keeps the first investigation focused without hiding necessary evidence.

[04] · BEGINNER

Start with one small task

Download both files below into the same new folder, for example token-practice. Open that folder in your coding tool. The function computes the average of a list; its tests describe the expected behaviour. One test deliberately fails so that you have a visible problem to solve.

Open a terminal in that folder and run the command below. You should see three tests: the normal and negative-number cases pass, while the empty-list case reports ZeroDivisionError. If Python is not available, set up Python 3 using your usual environment before continuing.

python3 -m unittest -v

Use a coding assistant that can inspect your project and show its changes. For the exercise, Python 3 is the only runtime dependency.

• Open a disposable copy of the practice folder in your editor or coding tool.
• Open average.py and test_average.py, then attach or name those files in the conversation.
• Run the tests once so you know the starting failure.
• Work through Ask, Plan and Act using the prompts below.
• Review the change and test output before keeping it.

Download average.py · Download test_average.py

[05] · BEGINNER

One goal, three useful prompts

Send the ASK message first and read the explanation. The assistant should connect the error to dividing by the length of an empty list. Then send PLAN: a useful answer should propose a small empty-input check, preserve the existing non-empty calculation and name the test command.

Read that plan before sending ACT. If it proposes changing the tests, adding a dependency or rewriting unrelated code, narrow the scope. Your goal is the empty-input behaviour, and that goal is enough to judge whether the proposed work is relevant.

ASK
Read average.py and test_average.py.
Why does empty input fail? Explain without changing files.

PLAN
Propose the smallest fix so average([]) returns 0.0.
Preserve non-empty behaviour and existing test expectations.
List the edit and the command that will verify it.

ACT
Implement that plan and run python3 -m unittest -v.
Keep the change local. Report the diff, results and checks not run.

[06] · BEGINNER

Watch a failure become evidence

Once the assistant acts, compare its edit with the expected change below. A diff shows the lines added and removed. For this task, you should be able to explain every changed line: the new condition handles an empty list, and the existing calculation still handles other inputs.

Run the tests again from the practice folder. All three should pass. If they do not, copy the failing command and error into the conversation and ask the assistant to diagnose the mismatch. Avoid a bare “try again”: it adds no evidence about what went wrong.

Illustrative walkthrough. The downloadable exercise starts with this bug:

def average(values):
    return sum(values) / len(values)

# average([2, 4, 6]) -> 4.0
# average([])        -> ZeroDivisionError

# Expected minimal fix
if not values:
    return 0.0
return sum(values) / len(values)

[07] · BEGINNER

Avoid paying for the same confusion twice

A common source of wasted work is a correction without new information. The assistant tries another variation, you reject it, and neither side has a clearer account of the failure. A concrete error or counterexample makes the next attempt more informed.

The same principle applies to the output you request. If your next decision is whether to accept a small fix, ask for the diff and test results. If you need to understand unfamiliar code, ask for an explanation. Choose the response that helps you make the next decision.

[08] · BEGINNER

Know how to keep or undo it

Verification is part of Act. The assistant’s summary is useful, but you should also inspect the actual file and test output. For this exercise, confirm that the expected test values are unchanged: passing a weakened test would not establish that the original goal was met.

Before a real task, save a checkpoint using version control or a separate copy. A branch names a line of work; it does not itself save all your current edits. When undoing a change, inspect the diff first so that you keep any work you made before the assistant started.

• Start from a saved checkpoint or a disposable copy. A branch alone does not save uncommitted work.
• Review each changed file. Use your editor’s diff view to compare additions and removals.
• Run the known example and an edge case yourself. Passing tests only cover the cases those tests exercise.
• To undo, use the editor’s revert control for the specific agent change after checking the diff. Preserve your own edits.
• Keep credentials and private datasets out of the exercise. Understand what a requested terminal command will do.

[09] · BEGINNER

Keep the context that earns its place

You do not need a skill to fix this function. A skill becomes useful when you repeatedly explain the same procedure—for example, how to validate changes in your project. It is a written recipe that a compatible coding agent can discover and load for that task.

After a successful run, ask the assistant to draft the procedure it followed. Review the draft against what actually worked. Keep general conventions in project instructions, and keep a task-specific sequence in a skill. The example below is a starting point; replace “the project’s documented test command” with your project’s real command when appropriate.

Project instructions hold general conventions that you would otherwise repeat. A skill captures a recurring task. Ask the agent to draft a skill from the verified workflow, then review it.

# validate-change/SKILL.md
---
name: validate-change
description: Check a small Python change and report evidence. Use after edits.
---
1. Read the task and inspect the diff.
2. Run the project's documented test command.
3. Check the requested behaviour and one edge case.
4. Report files changed, commands, results and checks not run.
5. Do not push or publish without an explicit request.
6. Propose reusable lessons; review them before saving.

The name and description help the tool discover the skill. Invoke it explicitly for the first trial and verify that it was loaded. Locations and optional features vary across compatible agents.

Sources: VS Code skills

[10] · BEGINNER

Take this into your next task

Before moving on, check that you can explain the bug, the plan, the final edit and the evidence that it works. That is the complete learning loop: the assistant helped you do the work, and you retained enough understanding to accept it responsibly.

For your next task, reuse the structure rather than copying the example’s details. State the goal, supply the relevant context, define a check and ask for the result you need. The advanced guide shows how to preserve that structure across repeated research work.

• ASK: make the goal and unknowns clear.
• PLAN: agree on scope, constraints and evidence of success.
• ACT: make the change, verify it and report the result.
• Keep the useful context and verified lessons for next time.

Advanced guide: reuse the same approach across research processes →