TL;DR
The short version
When a frontier model jumps a generation, the prompting habits your team built for the last one start costing you money and quality. The newer models are more tenacious and assume more agency, so old rule-lists and max-effort defaults now work against you.
This is The AI Daily Brief collecting the first weeks of field tips on Fable 5 and GPT 5.6 Sol. The through-line: the gains don't show up in benchmarks. Someone has to run the trials and turn them into how the team works — which makes a model upgrade a leadership problem, not a tooling one.
Built on Nathaniel Whittemore's AI Daily Brief episode, drawing on practitioner tips from Codex's Eric Provencal, Intuit's Christine Zhu, Matt Shumer, Daniel Miessler, and OpenAI's GPT-5.6 guidance. The +10–15% score / up-to-66% token figure is OpenAI's own internal testing — treated as a vendor claim.
A new model re-onboards the whole team
Most teams treat a new model as a drop-in upgrade: same prompts, same workflows, better output. That's the mistake. The first weeks of Fable 5 and GPT 5.6 Sol produced a pile of tips from daily users, and the common thread is that the old habits now work against you.
As the AI Daily Brief put it, this kind of knowledge "can't really be captured in anything like benchmarks, and just has to go be experienced through trial and error." That makes it a leadership problem: someone has to run the trials and turn the findings into how the team works — the same way you'd re-onboard a team onto a new system.
Your old prompt library is now a tax
The newer models are more tenacious — they keep going and assume more agency. Codex's Eric Provencal notes that people still prompt 5.6 Sol "exactly as they did 5.5," which now backfires.
Two changes matter for a team standard. First, say each instruction once. OpenAI's own testing found that removing repeated instructions raised scores by 10–15% while cutting tokens by up to 66% — the giant rule-lists your team wrote for older models make answers worse and cost more. (That's OpenAI's internal figure; treat it as a vendor claim, but the direction is clear.)
Second, set boundaries, not detail. A more tenacious model needs explicit stop-conditions — "prepare the message as a draft, don't send it," "use only the supplied sources." The cost of a missing boundary isn't a bad paragraph; it's an agent sending an unapproved message to a customer. For a leader, that reframes prompt review as a risk control, not a style note.
Spend less intelligence, not more
There are two dials now: model size and thinking effort. On effort, OpenAI's advice is to start where you set the last model, then test one level lower — the new generation usually needs less.
That's harder than it sounds. The instinct is to dial everything to max, because who wouldn't want the most intelligence on every task? For a team, that instinct quietly becomes a budget line. Making "match the compute to the job" a norm — cheap-and-fast for routine work, max reserved for genuinely hard problems — is a cost lever a leader can set once and apply everywhere.
Raise the ceiling on what you delegate
The bigger shift is ambition. Intuit PM Christine Zhu's productivity jump came when she stopped using AI to clear busywork and started handing it "hard tasks I didn't trust Claude with before." She maps this to Shreyas Doshi's three levels of product work — optics, execution, impact — and uses the model differently at each: autopilot for status updates, co-pilot for weekly planning, sparring partner for the high-stakes thinking most people keep for themselves.
The blocker on that top level is usually context. Tariq, on the Claude Code team, argues the work is now "bottlenecked by my ability to clarify its unknowns." His fix is to make the model surface your blind spots early — ask it for four wildly different design directions to react to, or to teach you what you don't know before you prompt.
A leader's job here is to build the shared context — project background, standards, the "who we are" files — that lets the whole team delegate at the impact level, not just the ambitious individuals.
Make trial-and-error the team's habit
Two practices turn this from luck into process. First, give the model a hard, checkable bar instead of an adjective. Matt Shumer stopped saying "make it high quality" — the model stops at its own low idea of good enough — and instead writes a concrete test, then loops the model against it until it passes.
The whole point of the loop is that Fable never gets to decide it's finished.
Matt Shumer
Loops — turn-based, goal-based, scheduled — are the interaction pattern spreading out of coding into knowledge work. Second, treat each release as context hygiene: Daniel Miessler re-runs a set of meta-prompts on every model jump, including a "self-model audit" that checks whether your saved context still describes who you actually are. For a team, that's a scheduled review of your shared prompts and agent files, not a personal ritual.
