You want to make the first contact with the agent impressive: give it a large task and see what it can do. That is exactly the mistake that makes the first experience vivid and useless. The goal of the first cycle is not the volume of code but a causal chain seen with your own eyes: request, tools, diff, verification.
The naive move is to hand over a big task on a live project and judge the result by whether "it looks like what I wanted." It seems this way you will understand the agent's capabilities faster. In fact a big task hides the mechanics: it is unclear what the agent read, what it changed and why the tests behaved as they did. The temptation is heightened by the fact that a big result looks more convincing: many changed files create a sense of power, even when you physically cannot verify them.
It breaks on the impossibility of verifying. A large diff on unfamiliar agent behavior can be neither read quickly nor accepted with confidence; "it seems to work" is not a proof but a retreat. Without an observable chain from request to verification, the first cycle teaches nothing but a general impression, and an impression does not carry over to the next task.
The professional move is to deliberately shrink the scale to the observable. Open a small repository and check the Git status. Ask the Ask mode to explain one module without changes - a safe way to see how the agent reads code. Pick a small bug or a single test. State the acceptance criteria and the forbidden areas. Allow only the actions needed for this task. Review the diff, run the narrow tests, then the full relevant suite. Make a commit with your own meaningful message. Each step here is chosen to answer for one link of the chain and not blend with its neighbors: reading apart, editing apart, verification apart.
The point of this scale is to make every link visible. Ask without changes shows reading apart from editing. A small bug gives a diff you can read in full. Narrow tests before the full run localize the effect before you widen the check. Your own commit message records that you, not an autopilot, closed the task. A small task is not a toy but a laboratory where every transition is visible. The full relevant suite at the end is needed not for show but to catch the effect of an edit beyond the file where it was made - a narrow test will not see that.
Two steps in this cycle keep it safe, and they are easy to underrate. Acceptance criteria turn "fix the bug" into a checkable condition: a specific test green, a specific scenario reproduced. Forbidden areas and allowing only the needed actions outline the radius: the agent does not touch what you did not open, because it has neither the task nor the permission for it. Together they make the result both checkable and bounded.
Fifteen minutes on a toy task seem wasted next to the temptation to solve a real one at once. But it is an investment in a reference: having once seen a clean chain of request, tools, diff and verification, you get a template against which you compare all subsequent, more autonomous sessions. Skip it, and you pay by learning to read the agent's behavior on an expensive task, where a mistake costs more. That minute pays off precisely because you hand the next, real task to the agent knowing what its clean work looks like, and so you notice a deviation before it becomes expensive.
You should verify the cycle itself by whether you saw all four links, not just the outcome. Is it clear what the agent read in Ask mode. Does the diff read in full and match the acceptance criteria. Are the narrow and then the relevant tests green. Is your meaningful message under the commit, not an auto-generated one. If even one link stayed invisible, the cycle did not do its job, however good the result.
The engineering conclusion: the first cycle is a calibration of trust, not a display of power. It sets the standard of observability by which you later tell controlled autonomy from uncontrolled. The smaller and more transparent the first task, the more reliable that standard and the calmer the next step up in autonomy.
The typical failures are predictable. People take a large task and accept "it seems to work" for verification, having seen not a single link. They skip the acceptance criteria and then argue with themselves whether the bug is closed. They allow everything at once and get a diff wider than the task. They agree to an auto-generated commit and lose the last step, where a human makes the decision. The sign is the same: the first cycle was measured by volume, not by observability. Make it small and transparent, and it becomes the reference it was meant to be.