In his post Claude Code is Great, Leo Godin states a thesis I repeat to myself and colleagues at least once a week: using LLMs effectively is a skill we all need in 2026
. I agree completely — and I think most online arguments about LLMs go off the rails because people debate the models instead of their own skill at using them. I've spent the last year and a half with Claude Code as a DevOps engineer, so I want to walk through a few of his points — where I agree, where I'd add my own experience, and where I'd push back gently.
Context is the only skill that matters
Godin calls it the Goldilocks Zone: not too much, not too little, just right. My experience matches. In practice I've ended up with a split: global rules live in CLAUDE.md and load every session, retrievable knowledge lives in a separate memory system with an index that's pulled in by relevance. A hard line between the two: universal rule — CLAUDE.md; project- or topic-specific — memory. Duplicates are forbidden because they drift.
Why this works: the model doesn't remember what you didn't put in context. Any attempt to "drop everything in just in case" ends with Claude losing the plot by step five or six. Godin has a nice metaphor for it: thirty minutes about coffee and cheese before you ask about Krokus, and the listener obviously won't recall which cover you meant. LLMs are no different.
Context management is the difference between success and failure.
Signed. I'd only refine it: context discipline is not a one-off effort, it's a continuous hygiene. Once a week I walk through my CLAUDE.md and memory index and throw out everything that's stale. Without that routine, any reasonable system becomes a graveyard of rules within a month — rules the model dutifully reads and dutifully applies, in all the wrong places.
The orchestrator must be blind
The most actionable section is the one where Godin says your job is orchestration, not comprehension
. He bakes it into his implement-sprint skill; I bake it into my agent teams: the lead agent only knows the current step and is forbidden to read architectural docs. Sub-agent implementers do that, each with their own context window.
This setup is counter-intuitive in human terms. A good tech lead is exactly the person who keeps the full picture in their head. But an LLM orchestrator is not a human: the wider its view, the faster it degrades. I hit the same wall on my own before reading Godin — my power-plan and self-improve skills used to wander through the project until I made "read only these two files" an explicit rule. The effect matched what he describes: autonomous task completion instead of constant loss of focus.
"Blame processes, not people or LLMs"
Godin offers a trick: when Claude spirals into self-blame after a failure, redirect it with I believe in blaming processes not people or LLMs
. I tried it. It works. The magic isn't the exact wording. The magic is that you shift the model's attention from what I did wrong to what about the process let this happen. Two different reasoning modes, and the second is far more productive.
I'd add an adjacent trick: when a session derails, ask Claude to analyse its own log — what happened, which decisions led to the dead end. The analysis then turns into a process change: a new rule in CLAUDE.md, a new branch in a skill, a new checklist. Without that loop, improvements don't accumulate. Without it, "LLMs got dumber" isn't a diagnosis of the model — it's a diagnosis of an engineering practice that isn't there.
Framework or your own scaffolding
Godin admits he tried Spec Kitty, BMAD, Open Spec — and settled on his own starter. So did I. What's interesting isn't the conclusion, it's the reasoning: an external framework decreases your learning
. That's a rare and honest stance. A ready-made wrapper speeds up your first five tasks and slows your growth on the next fifty — you don't understand why it works, and when it breaks (new model, new Claude Code release, backend change) you have no tool to fix it.
One caveat though: writing your own makes sense only if you use the tool daily. For a one-off script or weekend project, grab the ready-made. For steady work, build a lightweight harness and let it evolve. My /power-plan, /self-improve, /publish-note are exactly that — a harness that grew out of specific recurring pains.
Where I'd push back
Godin writes: /clear is your friend. /compact is not
. Right in spirit, but with a nuance. /compact isn't evil — it's a tool with a narrow window of usefulness. If you catch the session before it degrades (not when the model is already confused), compaction works: it preserves the thread and lets you continue. The problem isn't the command, it's that people invoke it too late. That's a classic human perception bug: we only notice the context is full once the model is already off-track — and by then there's nothing left worth compacting.
The takeaway
Good article. Not about the tool — about the skill. That's its value: it cures frustration through ownership. If it doesn't work today, your process is wrong today. That's bad news and great news at once: a process is fixable, a skill is trainable, context is prunable. Waiting for Anthropic to "bring back the good Claude" is pointless — it never went anywhere.
The original is shorter than my commentary and easy to read: Claude Code is Great. Recommended.