How Theo Uses Opus 5.5 for Longer Coding Tasks

The more I use Opus 5.5, the more impressed I am with its code, collaboration and ability to stay on a long task. I am walking through an Anthropic guide by Addy Osmani to see how to get more value from it, adding examples and disagreements from my own work.

The guide says the model can work longer independently, explain what it did and think before replying. Its first suggestion is to hand over the whole task, say what done means and identify when it should stop for input. I call the same idea prompting wider: involve the agent earlier and let it go further.

For example, do not just say to start a feature. Describe the desired behavior, ask for a screenshot that helps verify it and specify that a pull request should be prepared. A finish line gives the agent a concrete target, although the result still needs review.

The guide also suggests removing redundant instructions to think carefully, and looking first for what the agent needs from you after a long run. In my experience it often reports that clearly, but sometimes I still have to ask for the missing status.

One of my own runs stayed on max reasoning for six and a half hours without getting where I wanted. I switched to high, asked for the state of the work and then explicitly told it to continue; it reached a useful point about ten minutes later. This is one example, not a controlled comparison of settings.

I then wanted the work moved to another machine. Instead of doing all the setup manually, I described the target, where to find connection information, the repository and environment it needed, and how I wanted to see the new task in T3 Code.

I specified that the agent should check its setup and report failures. I explicitly authorized the particular environment-variable handling I expected, and asked it not to interrupt the computer I was actively using with browser or computer-use requests. Access to credentials and remote machines still depends on the user’s actual permissions and safeguards.

The prompt also gave it an out: if something did not work as expected, it could ask me for help. I want an agent to continue through routine steps, but to surface genuine uncertainty rather than improvise endlessly or assume that every risky action is authorized.

The setup took about 17 minutes and the remote thread appeared, but I then noticed it had completed only phase zero of the planned rewrite. I sent a follow-up asking it to continue through the remaining phases and eventually provide a testable link. A clear goal still does not guarantee the agent will follow every step correctly.

The guide’s simpler example is a migration: say which endpoints should move, what tests must pass and when the agent should ask for help. The useful structure is the objective, a verifiable definition of done and a stopping condition for problems the agent cannot resolve.

I also prefer not to add generic instructions to think harder. I believe the model already reasons and can adjust its effort. My explanation that different settings act as ceilings while max imposes a higher floor is my interpretation of behavior, not a verified description of the internal mechanism.

In my Skate Bench test, x-high averaged 338 tokens and about six seconds per response, while max averaged roughly 5,000 tokens and 50 seconds. The displayed score rose from 78% to 79%; I estimate max cost about 13 times more. These are results for this particular benchmark and run.

I acknowledge that more effort might help on some difficult or deceptive questions, but I personally avoid max and usually choose high or x-high. I find x-high somewhat slower and occasionally more attentive to details. Other tasks can have different tradeoffs, so measure rather than treat my preference as a rule.

Long runs make restarting expensive. If I notice a missing requirement or a wrong direction while an agent is working, I can send a follow-up to steer it. The aim is to add context without losing the original task; it is still worth checking that the agent retained all the requirements.

I say older steering behavior sometimes caused a model to complete only the newest request and forget the rest. Newer models feel better at incorporating an interruption into the ongoing work. That is my experience of the behavior, not evidence of a specific training method.

For design work, I found Fable’s default examples more attractive on the Which AI showcase, while Opus responded well to specific direction. A vague request to avoid a generic look may simply produce a different default. The examples are subjective and do not establish a general design ranking.

The guide suggests naming patterns to avoid, such as particular backgrounds, heading treatments or button shapes. Then inspect the result and iterate. I often annotate a screenshot with an arrow and ask for the affected area to be improved, giving the model visual context.

For long runs, tell the agent which stops you want. The guide gives a CLAUDE.md example: keep going when a step needs no input, but stop when a decision is genuinely blocked or before destructive actions such as deleting data or force-pushing. Adapt that rule to the project and its actual approval requirements.

I added a version of that rule to my own configuration. The guide also recognizes that a collaborative or pair-programming session may call for more frequent check-ins. The right level of autonomy depends on the task, the user’s wishes and the consequences of the actions.

For a large audit, migration or review, splitting work among subagents can help explore different areas within separate contexts. I find it useful to state when delegation is permitted or desired; the agent may not start subagents on its own, and parallel work still needs coordination.

When a long run ends, first look for an unresolved decision or approval request, then read what changed and what was found. The guide proposes a consistent summary format. I often ask an old thread for its current status and what it needs from me.

One of my most common questions is: what are the risks of merging this change today? I ask for the worst plausible outcome and what the reviewer has checked. The answer helps direct my attention, but a model’s confidence is not a substitute for evidence or an appropriate human review.

I also like having a different model family review an implementation. In my experience OpenAI models can dig deeply into details and sometimes find issues Claude missed, though they may report more low-value findings. Opus 5.5 has also improved at review in my own comparisons.

My small T3 Code evaluation asks models to find improvements and uses a judging panel to assess findings. In the displayed results Astra and Grok 4.7 each had eight supported findings, while Opus 5.5 had five and Opus 5 had four supported and two unresolved. These are results from my setup, not an independent ranking across all repositories.

Ask an agent to distinguish confirmed findings from things it cannot verify. Give it relevant tests, a runnable environment or browser access when appropriate, but have it report missing credentials, hardware, subjective judgments or other obstacles. Passing checks does not prove every behavior is correct.

The guide also describes what happens when a message is flagged by the model’s safeguards: the app may switch models or pause, depending on settings. I have seen fewer flags recently. Such behavior and settings can change, and a flag does not by itself establish that a legitimate request was unsafe.

The guide cautions against requesting hidden reasoning traces. If you want to understand a change, ask for its rationale, evidence and limitations. I also recommend attaching relevant screenshots or charts: a visual error report can give the agent context that would otherwise take many words to describe.

My practical checklist is to define done, supply the tools and context required for verification, name when the agent should stop and inspect the results. Trust can let an agent work further, but that trust should be paired with checks and boundaries suited to the task.