Working with Opus 5.5

Nine days in numbers

Claude Code keeps a local transcript of every session, so I could count instead of guess. These figures cover September 25 to October 3, 2026, on my own machine.

A response count is not a productivity score. A single long debugging session can produce hundreds of responses, while a useful script might take a dozen. What the numbers do show is how quickly Opus became the default for everything rather than a tool I reached for only on hard days.

My setup

The configuration is small, and most of it is about reducing friction rather than adding features:

• Model: Opus as the default. I occasionally switch to Sonnet for lighter edits, and I keep Sonnet at medium effort when I do.
• Permissions: auto mode, so routine reads, edits, and commands run without a prompt for each one, while risky actions still stop and ask.
• Worktrees: new worktrees start from a fresh base, so experiments do not inherit half-finished changes.
• Figma: the Figma plugin is enabled, which lets the agent read a design file directly instead of working only from screenshots.
• Environment: the terminal on Arch Linux, where my projects, scripts, and deployment tools already live.

Auto mode was the biggest change in feel. With Codex I approved the plan and then watched execution. Here, I spend less time approving individual steps and more time reading what came out of them.

Learn the project first

Many of my sessions start with the same sentence: "learn this project first." Before I ask for any change, I want the agent to read the repository, understand the stack, and find the conventions it should follow.

This matters more than the model choice. When I asked Opus to study my SES Guard project, that first exploration let it find problems beyond the IAM lockdown I originally asked about. When I came back to a project I had built without a ticket, the same exploration was enough for it to draft a Jira title and description that matched what the code actually did. You can read about that project in A Circuit Breaker for Amazon SES.

The exploration is also where I catch wrong assumptions cheaply. If the agent describes a structure that does not exist, I correct it before any file changes.

Show, don't describe

A large part of my work is visual: landing pages, brand sites, invitation templates, and reports for clients. Describing a layout in words leaves too much room for interpretation, so I give Opus the reference itself.

• Full-page screenshots at desktop and mobile widths, so it can compare its result against the target.
• Figma files through the plugin, when the design already exists there.
• A design brief such as a DESIGN.md file, when I want a fresh direction rather than a copy.
• Existing data, such as a spreadsheet, a CSV export from GitLab, or a previous invoice in JSON, so the output is built around real content.

The rebuild of this website started from a Figma template in the same way. The first pass was close but not complete, so I followed up with what was missing: the hero photo, example notes, and project details. Specific follow-ups like that are far more effective than asking for something "better."

Ask before it builds

Some of my most useful prompts are not instructions at all. They are questions asked at the right moment:

• "Before I implement, is the code in this repo up to date with the zip I was sent?"
• "Can I add edit and delete for transactions? Is it safe and possible?"
• "This is safe if the user refreshes the browser and does not call the API again, right?"
• "Is this as expected? The source wasn't touched, right?"

The last one came from a backup script. I asked Opus to add a confirmation step before rsync runs, then ran a dry run and checked the output with it before trusting the real copy. For anything that can delete, overwrite, or send data, I would rather spend one more message confirming the behavior than discover a mistake afterward.

For larger tasks, Opus often answers with a short list of questions before it starts. I reply just as briefly, sometimes only "1. yes 2. it's OK 3. no", and the plan that follows reflects those decisions instead of guesses.

Make the work repeatable

A finished result is useful once. A process I can repeat is useful every month. So when a task is likely to come back, I ask the agent to write down how it did the work.

A client performance report is a good example. I asked Opus to refresh the numbers with current PageSpeed Insights data without changing the format, then asked it to save the method into the project folder. For a monthly activity report built from GitLab merge requests, I asked directly how I could reproduce the PDF next month without an AI agent at all.

The same applies outside client work. After Opus helped me identify red messages in my system boot log, I asked it to save what it found and changed into a notes file. The next time something similar happens, I start from that record instead of from zero.

It also works when the first version is too technical. The activity report started as a developer-focused template. I asked for a version that a non-technical client could read, and kept both.

Memory that follows the project

Claude Code can keep small memories for a project and recall them in later sessions. On this website, that turned one correction into a lasting rule.

During the redesign, a display serif was added for headlines. I asked to remove it and keep only Geist and Geist Mono. That decision was saved as a memory, together with my preference for class-free CSS and slightly larger body text for long-form reading. When I came back days later to write a new note, the agent already knew those constraints, and I did not need to repeat them.

I treat memories like any other project documentation: short, specific, and worth correcting when they become outdated. A wrong memory is as misleading as a wrong comment.

Where it helped most

Looking back over the sessions, the work fell into a few groups:

• Company projects: moving a WordPress brand site toward a headless Next.js front end, setting up its staging domain, and adding WhatsApp source tracking to advertising landing pages. The architecture is described in Headless CMS for a Brand Site.
• Client deliverables: performance and activity reports that I could send directly, in versions for both technical and non-technical readers.
• My own business and site: a fresh static site for Rayatiga, the redesign of this website, and an automated deployment to Cloudflare Pages through GitHub Actions, which follows the approach in A Practical Deployment Pipeline.
• Tools I actually use: an invoice builder with a proper interface, a small CRM that grew out of it, a finance tracker tested on my phone over ADB, and an Apps Script web app for logging transactions into my cash-flow spreadsheet.
• Personal and system work: invitation templates, a backup script, and diagnosing boot errors on my Linux machine.

Several of those tools had been on my list for a long time. What changed was not that they became technically easier. It was that the cost of starting dropped low enough that I stopped postponing them.

What stays mine

The same principle from my earlier notes still holds. Opus can explore a repository, propose a plan, write the code, and even review it, but deciding what is correct remains my job.

Give context before asking for output
"Learn this project first" is the cheapest way to avoid confident work built on the wrong foundation.

Use references, not adjectives
A screenshot, a Figma frame, or a real data file communicates more than any description of what "good" looks like.

Ask the safety question out loud
Before anything destructive or customer-facing, confirm what will happen. Then check it with a dry run or a real device.

Leave a trail
Saved methods, notes, and memories turn a one-off session into something I, or a teammate, can repeat without the agent.

Nine days is a short period, and I expect my habits to keep changing as I use it for longer. For now, Claude Code with Opus 5.5 has become the place where most of my work starts. It helps me finish more, but more importantly, it helps me finish the things I used to leave for "someday."