You decide what the assistant does
Working with judgement means choosing which jobs to give a coding assistant, which to keep, and how to check what comes back. It matters because the assistant will try anything you ask. It will not tell you when a job is too risky or too big for it.
The skill is not typing prompts. It is deciding.
By the end of this lesson
Note
I can decide what to delegate to an assistant and what to keep.
Key words
| Word | What it means |
|---|---|
| Delegate | to hand a job to someone else, here an assistant |
| Ownership | being the person answerable for the work |
| Safety net | tests that catch a change that breaks something |
| Workflow | the steps you follow every time |
| Judgement | weighing risk and effort to make a choice |
The cells students fill in are left blank in this preview.
Delegate small, checkable, low-risk jobs
A job suits an assistant when it is small, when you can check the result quickly, and when a mistake would do little harm.
Keep a job when it touches secrets, money or who may log in. Keep it when nobody has decided what it should do. Keep it when you could not tell whether the result was right.
Worked example: five jobs, five decisions
| Job | Delegate? | Why |
|---|---|---|
| Draft a list of test ideas | Yes | Small, and you will read every one |
| Rename a variable everywhere | Yes, with tests | Boring, and tests would show a miss |
| Explain an unfamiliar function | Yes, then verify | You can check it against the code |
| Design how logins work | Keep | A mistake lets the wrong person in |
| Decide what the product should do | Keep | It is a choice about people, not code |
The cells students fill in are left blank in this preview.
A safe workflow works in small steps
First, make sure tests exist and you know what they say. That is your safety net. Then ask for one small step and read the change. Then run the tests again.
Save the work in small steps, with a message you wrote yourself. If a step goes wrong, you can go back one small step, not a whole afternoon.
Count the tests that protect the project
docker exec -w /home/node/project agent grep -c "test(" shop.test.jsShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Five tests are the net under any change
The command counts the lines that start a test in the project's test file, and it printed 5. Those five tests are what would catch a careless change.
Before you delegate a job, ask whether the net is wide enough for it. If it is not, widen it first.
Delegate a small job: ask for test ideas
docker exec -w /home/node/project agent opencode run "Suggest three more tests for the change function in shop.js, as a numbered list with the expected answer for each. Do not change any file."Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
You still judge what comes back
The ideas you get will differ from a classmate's. That is expected. Read each one and work out its expected answer from the rule yourself. Keep the ones that are right and useful.
This is delegation done well: a small job, a read-only request, and a person deciding what to keep.
A common mistake
Warning
Many people think that if the assistant wrote it, the assistant is responsible for it. It is not. Whoever ships the code owns it, including its faults, so you must understand every line you accept.
Reviewing takes time, so count it
An assistant writes in seconds, but a person must read what it wrote. A long change can take longer to review than to write by hand.
That is why big jobs are split first. Count about one minute of review for every 10 lines, rounded up, and add it to the plan.