Most of what teams learned about AI tools in the past year has been superseded, and some of the corrections are wrong too. We checked a popular list of 19 tips against the vendor documentation, and what the gap tells you about who should own AI tooling in your business.
Most of what your team learned about working with AI tools in the last year is now out of date. Not slightly out of date. Contradicted by the vendors' own documentation, in ways that quietly cost money and quietly widen access.
We watch this closely because we have to. When a client asks us whether their people should be using an AI assistant against company systems, the answer depends on settings that moved last month. So when a popular video went round recently listing 19 mistakes that experienced Claude Code users are still making, we did what we do with any guidance before it reaches a client: we checked it against the source. Roughly half of it holds up exactly. Eight of the claims are wrong, conflated, or describing a version of the product that no longer exists.
That gap is the actual story, and it's got very little to do with any one tool.
Why does AI guidance go stale so quickly?
Because adoption and product change are both running faster than anyone's internal documentation. ONS figures show reported AI use among UK businesses with 10 or more employees rose from around 12% to roughly 35% between late 2023 and 2026. That's a lot of organisations forming habits during a period when the products underneath them were being rewritten.
The spend follows the same curve. Research from Cledara found 79% of companies now pay for at least one AI tool, with the average adopter spending about $15,300 a year across 3.7 subscriptions, and AI coding tools taking roughly 18% of that budget. Those are US dollar figures, and worth reading as a direction of travel rather than a UK benchmark.
So you've got real money, real access, and a rulebook written against a version of the tool that's been superseded twice. Nobody sends a memo when that happens.
The persona example, and why the correction was also wrong
The clearest illustration is the advice everybody adopted first: open your prompt by telling the model it's a senior expert with 20 years of experience.
Research does undercut that. A study presented at EMNLP 2024 tested 162 personas across four families of language models and 2,410 factual questions, and found that adding a persona to the system prompt didn't improve performance against a no-persona control. Good finding, and worth knowing.
It's also routinely misreported. It wasn't Anthropic research, it wasn't a test of Claude, and it wasn't 2,500 prompts. It ran on open-source models. And Anthropic's own current prompting guidance still contains a section recommending you give Claude a role in the system prompt, so the vendor hasn't accepted the conclusion the way the retelling implies.
We're not splitting hairs for sport. This is what stale guidance looks like in practice: a real finding, stretched past what it showed, applied to a product it didn't test, and repeated until it sounds settled. If you're going to change how your team writes prompts, read the paper, not the summary of the summary.
What Anthropic has changed is more interesting. They've published that they removed over 80% of Claude Code's system prompt with no measurable loss on coding evaluations, and now favour designing better tool interfaces over supplying usage examples, because examples constrain exploration. That's a genuine reversal of the "stuff it with examples" era, and it came from the vendor rather than from inference.
Their replacement advice is refreshingly boring. Point the model at the source that answers the question, and describe what a finished result looks like. Then give it a check it can run itself, so the loop closes without a person in it. Anthropic's prompting documentation even supplies the phrasing, suggesting you ask it to verify its answer against your criteria before finishing.
One more from the same shift, and it's the single easiest thing to fix in any team's prompts: say what you want rather than what you don't. "Write this as flowing prose paragraphs" works better than "do not use markdown".
The costs nobody chose for you
This is the part that shows up on an invoice.
Anthropic documents that agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode. That figure gets repeated as though it applies to any delegated task, which isn't what the documentation says. It's published for agent teams, in plan mode, specifically. The broader principle still stands and it's a useful rule of thumb: delegation is cheap when something goes off to read and look, and expensive when it needs a lot of your existing context handed to it to do real work.
Model switching is the one that catches people out. Each model keeps its own cache, so switching model mid-conversation means the next request reads the whole history back with no cache hits. The popular conclusion drawn from this, that dropping to a cheaper model can cost more than staying on the expensive one, is arithmetic rather than vendor guidance. It's often right. It just isn't documented, and it's worth knowing which of those two things you're relying on.
Then there's fast mode, which is genuinely easy to get wrong. It's a high-speed Opus configuration that bills to usage credits on subscription plans, and the first time you enable it in a conversation you pay full uncached input for the entire existing context. Flip it on deep into a long session and you're re-paying for everything you've already accumulated. That charge lands once per conversation rather than every time you toggle it, and the setting only applies to the Opus models that support it.
On price, there's a wrinkle for UK buyers. Anthropic publishes plan pricing in US dollars only, with no UK pricing page, and notes that the figures shown exclude applicable tax. Pro is $17 per user per month billed annually and a Team seat is $20, with Claude Code included in every paid plan. At an early September 2026 rate of roughly $1 to £0.74, that's about £13 and £15 a head, before VAT. If you're budgeting in sterling, you're doing that conversion yourself and carrying the currency risk with it.
The access defaults nobody chose either
Cost is the visible half. Access is the half that matters more.
Connector tool access has three modes: Auto, which is the default, Always available, and On demand, which is the sensible choice once you've got ten or more connectors. This is set per conversation in the Claude apps rather than in Claude Code, and it's often described using option names that don't exist, which makes it hard to follow instructions confidently.
More significant for anyone writing internal rules: a delegated subagent starts fresh, with no conversation history, no invoked skills, and none of the files already read into the main session. It gets its own system prompt, the task it was given, and the full CLAUDE.md hierarchy, though the built-in Explore and Plan agents skip CLAUDE.md entirely. If your governance lives in an instructions file, some of your rules don't travel. You have to restate the ones that matter inside the task itself.
And one piece of widely-repeated advice is now simply obsolete. Pruning rarely-used MCP servers to save context used to be sound. Tool search is on by default now, so only tool names and server instructions load at session start, and extra servers cost you very little. Teams are still following the old version and losing capability for no benefit.
Why your written rules get ignored
Instruction files are where most organisations think their governance lives, so it's worth knowing how they load.
CLAUDE.md is read into context at the start of a session, and after a compaction Claude re-reads the project-root file from disk. Edit it mid-session and your change is invisible until the session compacts or you start a new one. Settings behave differently and are picked up as you go, which is exactly the sort of inconsistency that makes people believe a rule "sometimes works".
Length matters more than emphasis. Anthropic's guidance is to target under 200 lines per CLAUDE.md file, because longer files consume more context and reduce adherence. If the model keeps ignoring a rule you've written down, the fix usually isn't capitalising it. It's cutting the file. You'll also see confident figures quoted about how many instructions a model follows reliably, and we couldn't find those published anywhere by Anthropic, so we're not going to repeat them.
The related trap is assuming a bigger context window means better recall. On Anthropic's published long-context retrieval benchmark, Claude Opus 4.6 scored 76% on the 8-needle version of the 1M-token test. Those are February 2026 numbers for a model that's since been superseded, and Anthropic hasn't published equivalent figures for what followed. Treat the headline as directional: a larger window is more room, not more reliable memory. You can also cap it deliberately, since the auto-compact threshold is set as a token count rather than a percentage.
The practice that matters more than the other eighteen
Anthropic's own power-user guidance is blunt about this. The single most impactful tip is verification, giving Claude a way to check its own output.
Read that as a business point rather than a tooling one. Without a check, a person is the quality loop, and errors sit there until someone notices. That's precisely the failure mode we see in AI projects that stall: not a bad model, just no mechanism, so every output needs a human to read it and the promised time saving never arrives.
The documented options escalate sensibly. You can ask for the check in the same prompt, use an evaluator that re-checks a condition after every turn, add a hook that blocks the turn from ending until a script passes, or bring in a separate agent for a second opinion. Most teams never get past the first, and the first is still much better than nothing.
The data you might be deleting without knowing
A smaller one, easy to miss and annoying to discover late. Conversation history has a retention period that defaults to 30 days, configurable down to a minimum of one day, and auto memory files are excluded from that sweep. If anyone in your business assumes their working history is being kept, that assumption has an expiry date attached.
How we keep this current
None of the above is exotic, and none of it needs a specialist. It needs somebody whose job includes noticing when it changes.
In practice that means a few habits. We read the vendor's primary documentation rather than the commentary about it, and we check the date on anything we're relying on. We keep instruction files short, because a rule buried in a long file is a rule that doesn't apply. We build verification into the work instead of adding it to somebody's review pile. And we treat delegation as a tool with a price attached, good for going and looking at things, expensive for handing over work that needs a lot of context to do properly.
That's what we mean when we say AI consultancy rather than AI training. A training day teaches a version of the rules. Somebody has to keep them true afterwards, which is often what a fractional CTO ends up owning, alongside the harder question of which of these tools deserve to be wired into an automated business process at all.
If you're earlier in this than that sounds, our guide to what actually works with AI in a smaller business is a better starting point, and if the question is which subscription to buy in the first place, we've compared the main AI plans for UK businesses.
What this means for you
You don't need to act on 19 tips. You need to know who in your business owns the answer when a default changes.
So the useful thing to do this week is smaller than a project. Find out who owns AI tool configuration where you work, and have them check two things: what your current cost defaults are, and what your current tool-access defaults are. Neither was chosen by you, both have moved in the past year, and both are set to something today.
If the honest answer is that nobody owns it, that's worth knowing too. It's usually the point at which we get called. If you'd like a second pair of eyes on what your team is already running, book a discovery call and we'll go through it with you.
