The first useful task sets the tone for all further work, and it is worth choosing by one criterion: it must be small but complete. Small - so the diff fits in your head and any mistake is visible at once. Complete - so it has a goal, a boundary and a closed verification. Good candidates are predictable: fix a specific failing test, update one validation rule or add a narrow regression test. A bad candidate is a vague "improve the module", which has no unambiguous sign of completion.
Why small and complete rather than fast and broad. A broad first task on unfamiliar code almost guarantees drift: the agent changes a lot, and there is nothing to check, and you are left with a beautiful but unproven change. A small task with a closed verification, on the contrary, immediately shows whether the "reproduce - change - verify" chain works in this repository. It is a cheap calibration of the environment before trusting the agent with more serious changes.
A closed verification is the heart of such a task. It means the change has a signal that fails or explicitly captures the problem before the edit and goes green after it. Without this signal, "fixed" is a claim, not a proof. So the first step of a good task is not the edit itself but reproducing the problem with an existing project command: a test that must fail first turns the work from confidence into a checkable fact.
It helps to see once what such a task looks like as a contract. Below is a short wording: the goal, the boundary (which module and tests to touch, do not add dependencies), the requirement to first reproduce the bug, then run the targeted test and typecheck, and at the end show the diff and separately list the unchecked. You return to this form on every new task: it is the boundary and the verification, not the length of the request, that make the result assessable.
The order of steps within the task matters more than their set. First reproduce the problem with an existing command, then make the minimal change, then repeat the same signal and confirm it went green, and only then expand the check to neighboring tests and typecheck. The reverse order - "run everything" right away - blurs the signal: it is unclear what exactly got fixed and what broke along the way. A narrow signal first, a broad check later.
The boundary in the request is not a formality but protection from drift. Explicitly saying "change only module Y and its tests, do not add dependencies" is cheaper than rolling back extra changes across the tree later. An agent given no boundary tends to fix the adjacent "while at it", and the very first such edit on poorly understood code creates more work than it saves. A narrow boundary on the first task is a rehearsal of the discipline that will serve on all the following ones.
The report closes the loop and makes the result honest. A good summary of the first task names what was done, which files changed, which commands ran with which exit codes, and separately what remained unchecked. The last point is especially valuable: an explicitly named unchecked boundary is more honest than a silent "done". It shows where you need to recheck yourself and does not pass a partial check off as a full one.
The typical first-task failures are predictable. Taking too broad a goal with no unambiguous sign of completion. Starting with the edit rather than the reproduction and losing the signal that proves the fix. Forgetting the boundary and letting the agent drift across adjacent files. And accepting "done" without a report of what exactly was checked. Start with a small complete task, reproduce the problem before the edit, hold the boundary and demand a report - and the very first task will calibrate both the agent and your process.
Goal: fix bug X.
Boundary: change only module Y and its tests; do not add dependencies.
First reproduce the bug with an existing project command.
After the fix, run the targeted test, then typecheck.
Show the diff and separately list what was not checked.