ExpertsFMI left Claude for months. Opus 5.5 is why I'm back
How I AI · September 22, 2026
5 Selected Lessons:
heuristic · 2 reasoning_pattern · 1 framework · 1 priority · 1
What matters most when judging a new AI model release
Source
How I AI — I left Claude for months. Opus 5.5 is why I'm back (September 22, 2026) · at 21:44 ▸
When this applies
when forming an overall adoption verdict on any new tool/vendor release with multiple competing performance dimensions
The takeaway
Rank adoption-relevant dimensions in the order: usability/friction first, then core task reliability, then cost/speed, then specialized strengths — because each lower tier is only valuable if the tier above doesn't block usage.
Why it works
Usability (friction/annoyance) is the gating factor that determines whether users will even access a tool's other strengths (cost, speed, intelligence, design quality); it is checked first and can veto the rest.
One level up
When multiple quality dimensions exist, identify which one acts as a gatekeeper to the others and evaluate it first.
Where it stops holding
This stops working when the tool is used in automated/background contexts with no direct human interaction, where 'annoyance' is irrelevant.
Detail
hierarchy:
- Not annoying to use (usability/friction)
- Good at long-running agentic tasks (reliability)
- Fast and cheaper (cost/speed)
- Exceptional at front-end design and SVGs (specialized strength)
- Safety/conservatism as a known trade-off to factor in
rationale: The host explicitly lists these as her ordered takeaways/conclusion about the model after testing.
In their words
One, it is not annoying. Two, it's good at long running agentic tasks. Three, it's fast and cheaper, so we love that. Four, it is exceptional at front end design.
Personal real-workload benchmark suite for evaluating new AI model releases
Source
How I AI — I left Claude for months. Opus 5.5 is why I'm back (September 22, 2026) · at 0:00 ▸ · at 3:17 ▸ · at 7:59 ▸
When this applies
when evaluating whether to adopt a new version of any tool/platform your business depends on
The takeaway
Test new tools against your own representative task set across multiple categories (long-running tasks, writing voice, creative/visual output, safety behavior) before trusting vendor benchmarks.
Why it works
Running the new release through the actual categories of recurring work (not synthetic benchmarks) surfaces real strengths/weaknesses that marketing benchmarks hide or bury.
One level up
Build a repeatable internal evaluation ritual rather than relying on vendor-published performance claims.
Where it stops holding
This stops working when the evaluator's task set isn't representative of the broader user base, or when time constraints prevent thorough multi-category testing before a decision is needed.
Detail
procedure:
- Identify recurring task categories that represent real daily workload (coding, knowledge work, creative, long-running agentic tasks).
- Run the new model across all categories, including multi-turn/long-running tasks that can fail silently.
- Check specific sub-signals: does it follow instructions, catch edge cases, resist prompt injection, match writing voice.
- Compare against previous model and competitor models on the same tasks.
- Synthesize into a qualitative verdict plus task-specific adoption recommendations, not a single aggregate score.
benchmarks: {"long_running_steps":"25-82 steps per single prompt","cost":"$4/input token, $20/output token vs Opus 5 pricing"}
rationale: Vendor benchmarks bury weaknesses; direct testing on your own workflows reveals where a tool actually helps.
In their words
I have been testing OPUS five five across a bunch of real work. So PRD writing, prototyping, code based auditing, agentic voice.
Perceived speed vs. actual speed in long-running agent tasks
Source
How I AI — I left Claude for months. Opus 5.5 is why I'm back (September 22, 2026) · at 5:40 ▸
When this applies
when any automated or long-running process lacks status updates, causing users to distrust or distrust-abandon it even though it's objectively faster
The takeaway
Perceived latency is a function of feedback frequency, not just completion time, and can override actual performance gains.
Why it works
Humans infer system health from visible feedback cues; absence of feedback is interpreted as failure or slowness regardless of true throughput.
One level up
Design the communication layer of a system as carefully as its core performance, since trust is built on legibility, not just speed.
Where it stops holding
This stops working when users genuinely don't care about intermediate status and only judge final output quality/time.
Detail
approach: Separate 'is the model fast' from 'does the model feel fast'; test both independently when evaluating or building agentic UX.
signals:
- long silent stretches during otherwise successful tasks
- user repeatedly checking if the system is still working
- narration style removed in pursuit of reducing verbosity
rationale: The balance between model performance, perceived latency, and reply format all shape end-user experience, independent of raw speed.
In their words
So while the model was fast, it did not feel fast on longer turns because it was so quiet, and I constantly found myself being like, are you working? Are you there? What's happening?
Evaluate tools on friction/annoyance, not just capability benchmarks
Source
How I AI — I left Claude for months. Opus 5.5 is why I'm back (September 22, 2026) · at 0:00 ▸ · at 3:17 ▸
When this applies
when deciding whether to adopt or abandon any tool, vendor, or process based on its headline performance metrics
The takeaway
The user experience layer (tone, friction, perceived responsiveness) often determines adoption more than the underlying capability metrics.
Why it works
Daily usability friction compounds over many interactions and drives abandonment even when the underlying capability is strong, because users interact with the experience layer, not the benchmark layer.
One level up
Judge a system by how it feels to use repeatedly, not by how it scores once.
Where it stops holding
This stops working when the task is a one-off or high-stakes enough that raw capability outweighs any ongoing friction cost.
Detail
rule: Weight the 'is it annoying' test above raw benchmark comparisons when deciding whether to use a tool daily.
threshold: If a tool causes repeated frustration ('blood would boil') despite capability, abandon it regardless of intelligence claims.
rationale: Capability gains are wasted if the interaction model drives the user away before they can use that capability.
In their words
I stopped using Claude because it was annoying. Annoying.
Route work to the model/tool that excels at that specific task type
Source
How I AI — I left Claude for months. Opus 5.5 is why I'm back (September 22, 2026) · at 15:06 ▸ · at 19:44 ▸ · at 21:44 ▸
When this applies
when you have access to multiple tools/vendors with different relative strengths and must allocate tasks efficiently
The takeaway
Maintain a portfolio of tools and route each task to the one with demonstrated superiority for that task type, rather than committing fully to one tool.
Why it works
Different tools are tuned/optimized for different output types; using the best-fit tool per task type captures quality gains that a single-tool default would miss.
One level up
Optimize at the task level, not the vendor level, when quality varies by task across providers.
Where it stops holding
This stops working when the overhead of managing multiple tools/contexts outweighs the quality gains from task-specific routing.
Detail
rule: Use the specific model/tool best suited to each category of work; don't force one model to do everything.
threshold: Decision made after direct side-by-side testing across multiple task categories (design, video editing, computer use, coding review).
rationale: Opus 5.5 is 'probably the best' at front-end design and SVGs, but Codex remains preferred for computer use and video editing — so the host splits usage accordingly.
In their words
Where am I using it a lot practically? I'm using it in PR review. I'm using it in architecture questions, and then I'll be using it in front end.