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.

Measure	Value
Projects	23 working directories
Sessions	About 60
Model responses	About 7,750, of which roughly 98% came from Opus 5.5
Largest project	The WordPress and Next.js migration, with more than 3,000 responses across ten sessions

A response count is not a productivity score. One long debugging session can produce hundreds of responses, while a useful script might take a dozen. The numbers do show how fast Opus became my default for everything, instead of something I reached for on hard days.

My Setup

The configuration is small, and most of it is there to remove friction:

Model: Opus by default. I sometimes switch to Sonnet for lighter edits, and keep Sonnet at medium effort when I do.
Permissions: auto mode, so routine reads, edits, and commands run without a prompt each time, while risky actions still stop and ask.
Worktrees: new worktrees start from a fresh base, so experiments don’t inherit half-finished changes.
Figma: the Figma plugin is enabled, so the agent can 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 changed the feel the most. With Codex I approved the plan and then watched it execute. 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.

That step matters more to me than which model I pick. When I asked Opus to study my SES Guard project, that first read let it find problems beyond the IAM lockdown I had 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 did. You can read about that project in A Circuit Breaker for Amazon SES.

It is also where wrong assumptions are cheapest to catch. If the agent describes a structure that does not exist, I correct it before any file changes.

Show, Don’t Describe

Much of my work is visual: landing pages, brand sites, invitation templates, and client reports. Describing a layout in words leaves too much open to 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 new direction instead of a copy.
Existing data, such as a spreadsheet, a CSV export from GitLab, or an earlier invoice in JSON, so the output is built around real content.

The rebuild of this website started from a Figma template the same way. The first pass was close but incomplete, so I followed up with what was missing: the hero photo, example notes, and project details. Follow-ups that name exactly what is missing work far better than asking for something “better.”

Ask Before It Builds

Some of my most useful prompts 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 did a dry run and went through the output with it before I trusted the real copy. For anything that can delete, overwrite, or send data, I would rather spend one more message confirming what will happen than find the mistake afterward.

For larger tasks, Opus often replies with a short list of questions before it starts. I answer just as briefly, sometimes only “1. yes 2. it’s OK 3. no”, and the plan that follows is built on those answers instead of guesses.

Make the Work Repeatable

A finished result helps once, and a process I can repeat helps every month. When a task is likely to come back, I ask the agent to write down how it did it.

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 to save the method in the project folder. For a monthly activity report built from GitLab merge requests, I asked directly how I could produce the PDF next month without an AI agent at all.

I do the same outside client work. After Opus helped me track down the red messages in my system boot log, I asked it to save what it found and changed in a notes file. Next time something similar happens, I start from that record.

This also helps when the first version is too technical. The activity report started as a template aimed at developers. I asked for a version 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. The decision was saved as a memory, along 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 didn’t have to repeat them.

I treat memories like any other project documentation: short, specific, and corrected when they go out of date. A wrong memory misleads as badly 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 frontend, setting up its staging domain, and adding WhatsApp source tracking to advertising landing pages. The architecture is in Headless CMS for a Brand Site.
Client deliverables: performance and activity reports I could send directly, in versions for technical and non-technical readers.
My own business and site: a new static site for Rayatiga, the redesign of this website, and automated deployment to Cloudflare Pages through GitHub Actions, following the approach in A Practical Deployment Pipeline.
Tools I use: an invoice builder with a proper interface, a small CRM that grew out of it, a finance tracker I tested on my phone over ADB, and an Apps Script web app that logs 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. They were no easier technically than before. Starting them just became cheap enough that I stopped putting them off.

What Stays Mine

The 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 is still 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 says 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 on 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 time, and I expect my habits to keep changing. For now, Claude Code with Opus 5.5 is where most of my work starts. It helps me finish more, and in particular it helps me finish the things I used to leave for “someday.”