How to Use Claude Opus 5.5 for Long Coding Tasks

How do you get Opus 5.5 to finish long coding tasks without getting lost?

Give it less instruction and more feedback. Keep prompts short (goal, definition of done, off-limits areas), hand it a measurable benchmark, require careful tests before you review anything, attach reference designs for UI work, and split big jobs across an orchestrated team. A developer who built a large desktop app (Pandode) mostly with Opus 5.5 reports that these five habits fixed most of the "starts well, then drifts" problem on runs of an hour or more.

Why do long tasks go wrong in the first place?

Two things usually break. First, over-specified prompts. If you script every step, the agent follows your order even when a better one exists. Second, context. In a single chat the window fills up, earlier decisions get lost, and quality drops near the end of the run.

The habits below attack both. The first four make the agent's work checkable. The fifth keeps any one agent from carrying too much.

Habit 1: How simple should your prompt be?

Simpler than most guides suggest. The creator's resume-at-reset feature in Pandode started from about three sentences: an agent can hit its usage limit mid-task, the app should wait for the reset and continue on its own, and the user must be able to cancel. No files named, no storage plan.

Opus found the places where each agent reports its limits and built the feature around them. Hand-written steps would have missed some of those spots, because the author did not remember where they all were.

A simple prompt still needs three things:

1. What you want.
2. How you will know it is done.
3. What the agent must not touch without asking (for example, the database format or user data).

Keep the goal and the limits clear. Leave the route open.

Habit 2: Why give the agent a benchmark?

"Make it faster" is a weak goal. The agent edits code, declares victory, and you cannot verify it. A benchmark changes that. The agent runs it, makes a change, runs it again, and knows immediately whether the number improved.

This also suits long runs. The number tells the agent there is more to do, so it does not quit at the first plausible fix.

Examples from Pandode:

The follow-up gain came from starting the next process in the background when a turn ends. Opus tried several ideas, and the benchmark showed which one worked.

The prompt pattern is two steps: "Write a benchmark for this and show me the number," then "Make the number better."

Habit 3: How do you get good tests out of Opus?

Ask for them directly. The creator's observation is that Opus writes strong code but can ship a feature with one small test or none. You then find a basic error within seconds of opening the app, and on a long task that wasted time compounds.

Ask the agent to think about how the feature can break. Request a small, deliberate set, not a hundred hollow ones:

• The empty case
• The error case
• Two things happening at the same time

Then set the rule: nothing reaches you until it passes. Tests also protect long runs from silent regressions, since a change in one file can quietly break another over an hour of edits.

A real case is the worktree merge in Pandode. Merging agent commits into main is risky, so Opus wrote tests for uncommitted changes and for conflicts. In both, the app must stop and change nothing. That is how it behaves today.

To avoid retyping this, put a line in your CLAUDE.md, such as: write careful tests for every feature and run all tests before saying you are done.

Habit 4: Do reference designs really help?

Yes, for anything visual. "Make it look good" forces the model to guess your taste, and guesses tend toward the familiar generic look (purple gradients, big rounded cards). Collect a few screenshots from design inspiration sites, attach them, and say "make it feel like this."

According to the creator, Opus 5.5 reads reference images well. It picks up spacing, font sizes, colors, and mood. In Pandode, elements like the approval bar above the prompt box, the collapsed "worked for" row, and the task board all followed supplied references. If you have no reference, even a rough sketch of the layout beats nothing.

Habit 5: How should you orchestrate Opus, Sonnet, and Codex?

Use one lead agent and several workers. The lead plans, splits the job, and reviews. Each worker gets a small, clear task with fresh context. This addresses the main failure mode of long single-chat runs.

The setup described:

• Opus 5.5 as architect. Planning and reviewing.
• Sonnet as workers. Faster and cheaper, and strong when the job is well defined.
• Codex as reviewer. A model from a different company tends to catch different mistakes than Opus and Sonnet do.

The earlier habits carry over. The architect can assign one worker a benchmark and another the optimization, have a worker write tests that everyone else must pass, and pass the mood board to the design worker.

The Pandode GitHub view (repos, pull requests, issues, one-click actions) came from one team task. One Sonnet worker took the data layer, another took the interface and the reference designs, a third wrote tests, and Codex reviewed the whole change. It came back passing tests and matching the references.

Pandode lets you save named teams, such as an Opus plus Codex team for hard features or a cheaper team with GLM workers for simple jobs. You do not need that specific app to copy the pattern. Any setup that separates planning, implementation, and independent review follows the same logic.

What small habits help on any long run?

• Queue or steer mid-run. In Pandode, Enter queues a message for when the agent finishes, and Command+Enter steers immediately without stopping.
• Use a worktree. The task runs on its own branch and cannot disturb other agents working on main.
• Watch your limits. Long tasks burn tokens. A resume-at-reset option lets a task continue after a usage limit clears instead of dying overnight.

Is this workflow foolproof?

No. The creator is candid that the architect sometimes splits work oddly and a worker can head the wrong way. You still review the result. The gain is that you review less often, and the basic problems are already gone when you do. Note too that the claim that Opus 5.5 is the best model for this work is one practitioner's opinion, not a benchmarked result.