How I AI: My First Impressions of Claude Opus 4.8 – Coding, Strategy, and Where It Shines

Claude Opus 4.8 impressed me most on the very first pass. I could hand it a brand-new feature, let it run for 20 minutes, and end up with something functional and structurally correct. The trouble started once I pushed beyond that initial success. In this episode of How I AI, I test Opus 4.8 on greenfield coding, rebasing existing branches, a game project for my nine-year-old, and a business-strategy comparison against Opus 4.7. See How to Build a Functional Greenfield Prototype in One Shot Using Claude Opus 4.8. See Build a Greenfield Prototype with a Single Prompt Using Claude Opus 4.8. See Generate a Data-Driven Business Strategy with Claude Opus 4.7. See Using Claude for a Data-Driven Business Strategy and Roadmap Analysis.

Anthropic positioned Opus 4.8 as a stronger long-running agent model and reported a 69.2 percent SWE-Bench Pro result. Launch pricing was $5 per million input tokens and $25 per million output tokens. Those are Anthropic's published numbers and positioning, separate from the task-level behavior I saw during testing.

My experience was mixed in a very consistent way. Opus 4.8 was fast, concise, and unusually pleasant to use for coding. It handled bounded work well and produced strong first implementations. But once the work required iteration, conflict resolution, broader context, or evidence gathering, the model became noticeably less reliable.

The coding tests ended up separating two different skills: generating a convincing first version versus staying grounded through repeated revisions and edge cases.

Where Opus 4.8 handled coding well, and where it drifted

I used three coding exercises to pressure-test different kinds of work: a greenfield build with explicit requirements, maintenance work inside an existing codebase, and a playful agent-style project that depended on iteration and ambition rather than just correctness.

Building a greenfield prototyping feature

I started with a clean-slate coding task inside Claude Code. I asked Opus 4.8 to build a new prototyping capability for ChatPRD, including specific architecture decisions, implementation constraints, and behavior requirements.

How the run worked

The model generated a plan first, then moved into autonomous execution for roughly 20 minutes. I largely let it operate without interruption so I could evaluate how well it maintained the structure and intent of the original request.

What worked on the first pass

The preview branch ran successfully, and the implementation tracked closely to the architecture I requested. For a one-shot feature build, this was genuinely strong output. It was not just superficially functional. The structure of the code and the feature boundaries mostly made sense.

Having a working preview branch also mattered because it created a clear acceptance surface. I could immediately inspect behavior visually instead of reasoning about the implementation abstractly.

The model behaved differently once the feature entered iteration.

What changed during debugging and refinement

As soon as I started requesting follow-on improvements and edge-case fixes, the quality became less stable. Opus 4.8 began introducing bugs, missing details, and struggling with the last layer of polish that turns a working prototype into a reliable feature.

The more concerning issue was grounding. During debugging, the model sometimes presented hypotheses as if they were confirmed root causes. I had not seen that pattern this aggressively in a while. Even in high-effort mode, it occasionally inferred an explanation first and only later checked whether the evidence supported it.

That forced me back into a traditional engineering review loop. I had to verify behavior through tests, inspect the actual code paths, and treat the model's explanations as suggestions rather than facts.

That extra review burden changed how I evaluated the strong first-pass result. The initial implementation was still valuable, but the savings narrowed once I had to aggressively validate every subsequent fix.

Rebasing stale branches inside a real codebase

My second test moved from greenfield work into maintenance work. I asked Opus 4.8 to rebase several stale branches after a large underlying change landed on main and disrupted the existing branch state.

What happened during the rebase work

The model fell into a repetitive cycle: rebase, introduce regressions, run tests, repair the regressions, then create new issues while repairing the previous ones. The longer the task continued, the harder it seemed for the model to maintain the intended scope and boundaries of the job.

This felt materially different from the earlier one-shot build. Existing codebase context, partially conflicting abstractions, and edge-case interactions increased the difficulty substantially.

I would not trust this kind of work without close human review. Every conflict resolution and every repair step needed inspection because the model could easily fix one issue while subtly creating another.

Testing whether the model would push beyond a basic game demo

For the third coding exercise, I wanted to test creativity and autonomous iteration rather than enterprise coding. I asked Opus 4.8 for a fun one-shot project that would impress a nine-year-old and pushed it to think beyond a simple generated demo. You can follow the full implementation in Use Claude Opus 4.8's Creativity to Generate a Playable Game. See Use Claude Opus 4.8's Creativity to Generate a Playable Game.

The interesting part of the prompt

Opus proposed a surprisingly ambitious workflow: an agent loop that would build a game, visually play the game itself, and tune the difficulty until the result was genuinely fun.

Example game prompt: Build a game, then play it yourself by watching the screen and adjusting the difficulty until it is fun for a 9-year-old.

That proposal raised the bar significantly. A static game generator is already common. A self-evaluating and self-tuning gameplay loop would have been much more interesting.

What the model actually shipped

The first output was a simple but functional 2D game. It worked, and the result was still impressive in the sense that a usable game appeared quickly from a lightweight prompt. But I did not see evidence that the model had actually performed the iterative play-testing and tuning loop it described.

As a first-pass artifact, the game was solid enough to review and extend.

What it lacked was ambition relative to its own plan. The execution stayed cautious.

I then asked for a 3D version. The next build improved the visual presentation and felt more polished, but it still did not reach the level of autonomous experimentation implied by the original idea.

Again, I ended up with a useful prototype rather than a genuinely self-improving agent workflow.

Neither version established the recursive gameplay-testing loop that originally made the concept exciting. That gap between proposal and follow-through became a recurring theme across my tests.

After the coding runs, I wanted to see whether the same grounding pattern appeared in non-coding work.

Comparing Opus 4.8 and 4.7 on business strategy

I ran Opus 4.7 and Opus 4.8 side by side inside Claude Cowork using the same business files, messages, and historical context.

The strategy prompt

I asked both models to analyze how I had spent my time over the previous three months and compare that allocation against the priorities most likely to grow the business.

Example strategy prompt: Based on what you can gather about my last three months, compare where I spend my time with where my priorities should be if I want to grow the business by 10x.

From there, each model generated a strategy recommendation and roadmap.

How the two models handled evidence differently

Opus 4.7

In my testing, Opus 4.7 grounded its recommendations in a broader set of the available business data. The resulting roadmap was more specific, more quantitative, and easier to trace back to the underlying inputs.

I could usually identify where the recommendation came from and which evidence supported it.

That traceability made the strategy output much more useful for real decision-making.

Opus 4.8

Opus 4.8 behaved differently. It focused heavily on a smaller subset of signals and sometimes treated those signals with too much confidence. During the episode I described this as narrow vision, though I mean that as an observation from this run rather than a broad claim about the model overall.

When I challenged some of the conclusions and asked where the information came from, the model admitted it had not actually searched or validated several sources I expected it to use.

No, I didn't search GitHub.

No, I didn't actually look up that data.

No, I didn't actually validate that bug.

The issue was not simply tool access. The problem was that the answers initially read as fully grounded analysis even when key assumptions had not been verified.

Once I inspected the evidence chain more carefully, my assessment changed. The output sounded coherent, but the underlying validation was weaker than I expected.

For this strategy task, I strongly preferred Opus 4.7.

Across both coding and strategy work, the pattern felt consistent: Opus 4.8 performed best when the task stayed bounded, visually reviewable, and narrow in scope.

Where I would use Opus 4.8

One thing I do not want to undersell is the usability. Opus 4.8 felt fast, concise, and easy to collaborate with. The writing quality was cleaner than many models, the outputs were relatively token efficient, and the interaction style avoided a lot of the annoying stylistic habits that creep into AI-generated responses.

I cannot prove why the failures happened, and I cannot attribute them to benchmark tuning or any specific architectural decision. But the practical pattern from these tests was straightforward: excellent bounded execution followed by weaker grounding once the work became ambiguous, iterative, or context heavy.

Based on these runs, I would currently reach for Opus 4.8 in a narrower set of situations:

• Greenfield prototypes with a clear acceptance surface and explicit requirements.
• Design-adjacent implementation work where I can review the result visually and iterate quickly.
• Tightly scoped tool use where verification steps are obvious and easy to enforce.

I would add significantly more review, testing, and skepticism in these cases:

• Changes inside mature or interconnected codebases where regressions compound quickly.
• Strategy and roadmap work that depends on broad evidence gathering rather than isolated signals.
• Any consequential workflow where a confident explanation could be mistaken for a verified result.

I am going to keep testing Opus 4.8 because the first-pass execution speed is genuinely useful, especially for prototyping and design-heavy coding. But this episode of How I AI did not convince me to replace Opus 4.7 for data-heavy strategy work or complex maintenance tasks. The most valuable pattern to copy here is using Opus 4.8 as a rapid implementation engine with strong human verification layered on top. It works best when success is easy to inspect directly. The moment the task depends on hidden assumptions, long context chains, or subtle edge cases, human judgment still carries most of the load.