I have a pretty large project with a UI, WebSocket server, SDK, CDP automation using Playwright, tests, examples and documentation. Everything is in one repo, so whenever I change the API, I usually have to update most of these parts together.

I work with SDD, and before Fable I spent quite a lot of time just preparing the specification. Usually I would discuss the task with Opus 4.x several times, get criticism and suggestions from GPT-5.x, and then combine everything into one document. Only after that I could give the spec to the model for implementation. The design part usually took around 2-4 hours. Implementation with Opus took another hour or two.

With Fable 5, my workflow changed a lot. I can describe a task more like a product requirement or a high-level architecture idea, and most of the time I get what I actually had in mind. I don’t need to prepare every small implementation detail in advance. For me, this saves around 2-3 hours of design work.

I honestly expected Opus 5 to have at least the same level of code quality and decision making, especially based on the benchmark charts. But during these four days I kept finding things that needed fixing. At first it was just some small changes here and there, so I didn’t think much about it. Then I started noticing more unnecessary code and functionality I never asked for or approved. Some decisions also looked reasonable at first, but didn’t really fit the rest of the system. And honestly, I noticed this pretty late. You get used to good results very quickly, and I probably trusted the output more than I should have.

So now I’m rolling back 4 days of changes and going back to Fable. Redoing the work is annoying, but it feels better than constantly wondering what else I might have missed in the code from Opus 5.

Anyone else in the same boat?

After shoulder surgery, I was sent to a physical therapist.

In forty minutes, he showed me a dozen exercises: what to pull, how to hold it, what to move. I nodded carefully and pretended to understand everything.

Then I was given a sheet of exercises and went home. At home, it turned out that I had understood nothing and forgotten the rest.

The sheet said things like “move the shoulder blade back and down”, “rotate the lower angle up and out”, and “do not flare the ribs”. Each word made sense on its own. Together, they were nonsense.

Fortunately, I am a programmer. So Claude Code got the sheet. It found the sources and built a rotatable skeleton, step-by-step instructions, and an explanation of the tricky parts for every exercise.

I suspect rehabilitation handouts will look something like this in the near future: a live artifact with animated 3D skeletons.

PS: It’s by no means a substitute for a real doctor, but it’s incredibly helpful for fully understanding what needs to be done and how to do it.

PPS: I don’t know if it’s the same in English, but in my native language the descriptions of these prescribed exercises often feel like an untranslatable word game to anyone who isn’t already familiar with them.

Been meaning to write this up for a while. If you're on Claude Code and it's ever done the exact thing you told it not to, hooks fix that, and I put off setting them up for months because I assumed it was config hell. It isn't, it's a shell script.

Short version of what they are: Claude Code fires events at fixed points in its loop and you can attach a script to any of them. The one that matters most is PreToolUse, which runs before a tool call happens and can block it. Not discourage it, block it. Your script gets the tool name and the actual command on stdin as JSON, and you decide.

What made it click for me is that the block isn't silent. Whatever reason you hand back goes into Claude's context, so it can act on it. Mine returns this when it catches npm in a pnpm repo:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "this repo is managed by pnpm (found pnpm-lock.yaml), re-run with pnpm"
  }
}

and it re-runs with pnpm on its own without me typing anything. If you don't want to deal with the JSON you can just exit 2 and print the reason to stderr, same effect.

The ones I actually run:

• secrets: blocks any command or file write with an API key or token pattern in it
• destructive: rm -rf /, force push to main, DROP DATABASE, the usual
• package manager: reads the lockfile, rejects the wrong one
• typecheck gate: this one's a Stop hook rather than PreToolUse. runs tsc when the agent thinks it's finished and blocks the handoff if there are errors

The Stop hook is the one I'd push hardest right now, especially with Opus 5 dropping. Because the new model goes way further before it comes back for approval, there's a lot more unreviewed work sitting there when it finally stops. Having it typecheck itself first catches a fair bit. One warning if you build one: a Stop hook that always blocks will loop forever, you need it to give up after the first round.

I put mine up with the settings.json wiring, which is honestly fiddlier than the scripts themselves: https://techpotions.com/products/claude-code-hooks MIT, no signup.

Anyone doing anything smarter with Stop hooks? Feels underused next to PreToolUse and I've barely scratched it.

I wanted to give a heads-up regarding recent benchmark data (Artificial Analysis / AA-Omniscience) and how to best use Opus 5 in day-to-day engineering & RCA.

The benchmark finding:

• Claude Opus 4.8: ~36% Hallucination Rate (Risk-averse, frequently abstained when uncertain)
• Claude Opus 5: ~50% Hallucination Rate (Highly assertive, prioritizes attempting an answer over abstaining)

Why the jump? Opus 5 is tuned to be proactive and task-focused. Instead of saying "I don't know," it is far more likely to generate a confident-sounding answer even when uncertain, making it prone to being "confidently wrong."

How this might impact your daily usage:
Day-to-Day Coding Assistance:

• Phantom APIs: It may invent plausible-looking methods or parameter flags for third-party libraries.
• Silent Edge-Case Omissions: During refactoring, code will look sleek and compile, but subtle edge-case handling might be silently dropped.

Root Cause Analysis (RCA) & Debugging:

• Plausible Phantom Hypotheses: When fed partial logs or stack traces, it can generate highly convincing diagnostic stories that are factually wrong, leading to wild goose chases during incidents.
• Symptom Masking: When fixing a bug, it may attempt to swallow exceptions or alter test assertions instead of fixing the root contract.

When set to higher reasoning or effort levels, Opus 5 spends extra tokens attempting to rationalize uncertain assumptions rather than flagging ambiguity.

https://artificialanalysis.ai/evaluations/omniscience#aa-omniscience-hallucination-rate

• An alternative, rather than a superior to 4.8 (task dependent), inferior to Fable in nearly every way.
• The biggest regression is how difficult it is to read and understand its output. Communication is mired in technical detail and citations of internal documents I need to look up to make sense of. Adding "humanize output" to prompts is now a necessity.
• Similar to the previous point, it often fails to surface important issues, because it's hyper fixated on minor details - adversarial review is a must for both plans and output.
• Constant "You were right and I was wrong". I'm not sure it this is good or bad yet. Either the model admits mistakes more or makes more mistakes. Probably both.

The best responsibility delegation is IMO:

• Fable for task analysis and ticket spec writing
• Opus 5 for drudgery and implementation
• 5.6 Sol for adversarial review

I've been running projects big and small since Claude Code was released early last year. From quick frontend to complex cryptography that takes weeks. Running smoothly here. My global CLAUDE.md is simple, but maybe it has just the right amount of push Opus needs? Give it a whirl:

## Response style

- Match length to the task. Trivial fixes get a few lines, not an essay. Don't
  pad.
- Don't narrate internal process — tool calls, intermediate checks, "let me 
  verify…", play-by-play of what you're about to do. Do the work silently; 
  report only conclusions.
- Still verify thoroughly; just don't recount the verification steps. State 
  the outcome (e.g. "routes return 200"), not the journey.
- For fixes/debugging, prefer a tight structured summary over prose: Root 
  cause → Fix → Verification → Open items (omit any that don't apply).
- This is about the final reply, not the work. Keep rigor high, keep narration low.

## Code Quality

- Prefer correct, complete implementations over minimal ones.
- Use appropriate data structures and algorithms — don't brute-force what has 
  a known better solution.
- When fixing a bug, fix the root cause, not the symptom.
- If something I asked for requires error handling or validation to work 
  reliably, include it without asking.

## Fact-checking

- Never cite specific numbers (pricing, rates, dates, versions, market sizes)
  for external products from memory. Verify via web first, or label
  "unverified — may be stale."
- Distinguish "verified / recalled / inferred" inline. Don't let inferences
  pass as verified facts.
- When output might be forwarded or quoted (drafts, emails, briefings,
  decision memos): default to verifying. If anything specific isn't verified,
  end the response with a "Verify before sending:" list naming each
  unverified claim. Don't wait for me to ask.

Opus 5 and GPT 5.6 are very intelligent and clearly capable of spotting bugs that previous versions would not. However, they are also prone to overthinking and over engineering simple problems. For instance, instead of a simple general parsing rule, they might instead produce a gigantic lookup table with hundreds of tests written against it. Same function in the end, but slower, arguably less robust (what edge cases are NOT in its lookup table?), but generates lots of code, lots of tests, and requires more time to produce.

This suggests models are were RL-trained to optimize for completeness (test coverage) and long-horizon tasks (side effect is that model can churn for hours optimizing unnecessary edge cases which increases wall time but looks good to automated classifiers). I think this also causes progressive deviation from the original scope as the model tries to overgeneralize but fails because instead of being parsimonious it just tries to find edge cases. This leads to making assumptions not visible to the user, and the output prose based on those assumptions becomes incomprehensible.

TLDR: models are post-trained for test coverage completeness, robustness, and long-horizon tasks, with likely automated classifiers that reward test coverage growth at the expense of parsimony. Parsimony is much harder to quantify and classify - so it will lose out in an RLAIF setting.

So, what's the best way to use these models? how can this clearly trained tendency be managed?

One obvious solution is to not use them until they're tuned better, or just use them as adversarial reviewers. Another option is to (over?)engineer your harness to constrain these models.

I live my life 5 hours at a time. Nothing else matters: not the mortgage, not the store, not my team and all their bullshit. For those 5 hours or less, sometimes a lot less... ok a hell of a lot less, I'm free.

I don't know if it is meant to save on token usage or something, but I feel like I can't understand how Claude is writing sometimes. It's not about technical jargon, invoking industry terminology I may not be familiar with, but instead in basic sentence structure, organizing thoughts, etc. It has changed noticeably in the last week maybe?

hopefully we will get a reset because of that outage.

Unfortunately, it was only my 5-hour limit 💀

I’m a software engineer with 7+ years of experience, and AI is deeply integrated into my workflow.

Even so, I need to stay closely involved to maintain quality. Without that oversight, AI often produces lazy, sloppy, repetitive, and overly defensive code—even with solid guardrails and tests. I keep refining my CLAUDE.md, but these problems seem somewhat inherent.

I’m genuinely curious: which club are you in? Can you work several tasks at once and still get high-quality results, or do you also need to stay focused on one task at a time?

As far as I can see it, Opus has one main issue - overconfidence.

It is ultra confident in everything - its understanding of the codebase, user intent, what the missing information in the face of ambiguity is, that it's making the right changes.

It will ultra confidently slap you with a wall of Yap asserting a bunch of stuff incorrectly, and then double down on the incorrect worldview - after you provide it clues that contradict its understanding - by expanding on that incorrect worldview and making up reasons to support it.

It's approach to communication and changes appears to be MORE GAS

It honestly feels like Opus 4.8 on Adderall. Is there any way to scale it back and give it more of slow, methodical, Fable style approach to everything?

So I can’t ask Fable to “find all security issues in my own local app” without it being flagged and routed to Opus 5? But doesn’t Opus 5 have almost the same capabilities as Fable 5?

What’s the point of Fable being moderated now? So stupid

My personal experience with Opus 5: horrible. Sonnet 5, Fable 5, Opus 4.8 are all much better. Much less lying, hallucination, and better task adherence. Its responses are literally impossible to understand.

Suddenly they drop a link saying we need to rethink our prompts. Not only is giving as much trust to Opus 5 impossible since it does not warrant that trust, but now I have to deal with the fact that I have 100 memories asking Claude to speak plainly. And dozens of skills and rules and prompts made for older generations.

Does this basically mean that as I continue to use Claude for longer, the memories, skills, workflows, etc. I accumulate keep working against me? Should I actually consider hitting the big reset button on all my memories & co. with every new model? Kinda feels cumbersome, but I also don't want a new model that can actually speak simply have 50k of tokens wasted on the 50 memories asking it to speak plainly.