Every Product Needs a Repo Now
The important thing about Fable 5 is not speed.
It is the size of the work you can plausibly hand off.
Most product teams are still talking about AI through the language of speed: faster PRDs, faster research synthesis, faster release notes, faster product briefs. That was the last loop. Prompt. Response. Steer. Response. Polish.
That loop is useful and real, but still mostly turn-based.
Fable 5 points at something different. Anthropic says the model's lead grows as tasks get longer and more complex, and the published pricing is $10 per million input tokens and $50 per million output tokens. Access details may change. The product signal is the new unit of work.
I have been trying to push frontier models into longer runs. GPT 5.5 will take in more than Opus 4.8. Fable goes further.
The best example was Grizzly Study Buddy, my education app sandbox. It started with a tight purpose: upload a spelling list, then generate a word search or flash cards. Then I violated the rule I am arguing for here. I let it grow too quickly. Bugs spread everywhere. I moved on.
Then one of my girls told me Grizzly Study Buddy was broken.
That made it a perfect Fable task. The job was not to invent a new product direction. It was to re-ground the project around its original purpose, clean up the accumulated mess, and make it playable again. The run stretched over 24 hours, with some downtime for approvals and rate limits, and burned a couple million tokens.
Then the next long run made the point even harder to ignore. A Codex goal task for Grizzly Study Buddy ran for about 3 days and 15 hours and used 91,710,089 tokens. This was not a vague brainstorming task. It completed the official problem-bank expansion and an approved scoped Supabase sync for math and language.
The verified result: 177,620 approved local rows across 1,455 K-8 curriculum nodes, 0 gaps, 0 errors, 0 warnings, and 93,380 app-facing rows synced to claude_problems. It also preserved 3,277 legacy remote-only rows and left 84,240 non-app-facing rows unsynced because science, social studies, and other out-of-scope content still need app support review. No full all-subject sync. No deletes.
It worked because the task fit the repo.
Engineering Work Has The Right Substrate
Engineering work is where long-running AI shows up first because it already has the right environment.
A repo gives the model a place to work. Files. Tests. Naming conventions. Prior patterns. Errors. Logs. Build output. Existing architecture. A definition of done that can often be checked by something more concrete than taste.
That does not make coding easy. Anyone who has tried to ship AI-written code past a demo knows better. But it does mean the agent has a durable work surface. It can inspect the product, make changes, test the changes, learn from failures, and conform to what is already there.
That is why coding, app building, and database work are blurring the line between PM and developer first. A small team, or even a solo founder, can hand off larger implementation chunks because the work is wrapped in structure.
The repo is not just storage.
It is context with rules.
Product Management Has Vibes In Six Tools
Product management is not there yet.
Not because PM work is safe from AI. It is not. A strong model can already burn through research, synthesize messy inputs, update product sheets, draft user guides, pressure-test positioning, and turn scattered materials into something close to done.
The problem is that product work has more decision points where there is no clean right answer.
Coding has plenty of judgment, but a lot of coding work is bounded by standards. The API should behave this way. The migration should preserve this data. The tests should pass. The build should work.
Product work has customer tradeoffs, internal politics, market ambiguity, timing questions, pricing beliefs, and rushed, irreversible decisions where the answer depends on what the team believes, not what the compiler says.
That is the art of PM.
A wrong coding run may leave you with failing tests. Annoying, but visible. A wrong product run can leave you with a polished artifact pointed in the wrong direction.
That is how you burn tokens and create rework at the same time.
The Best PM Use Case Is A Product Package
I am not convinced yet that product management has a clean equivalent to the 24-hour refactor, let alone the 3-day database run.
The closest useful example is a full product package.
Not "be the PM." Not "decide the roadmap." Not "figure out the strategy while I sleep." Something more bounded: research, findings, analytics, product sheets, user guides, persona-specific messaging, brand fit.
That is real PM work. It is also work a strong model can probably do well if the right material exists.
That is the catch.
The model needs the product context. Not just the facts. The connective tissue. Why one segment matters more than another. Which claims are approved. Which customer problems are loud but low-value. Which analytics are reliable. Which decisions expired quietly six months ago.
Most teams do not have that in one place.
They have a wiki. A roadmap. An analytics tool. A deck. A sales folder. A Slack history. A half-updated FAQ. A PM who remembers why the pricing page says what it says.
Coding has repos. Product management has vibes in six tools.
That gap is why long-running AI lands unevenly.
Every Product Needs A Repo
The missing artifact is the product repo.
A product repo is not a folder full of documents. It is the durable context environment an agent can work inside. It should survive the prompt, grow with the product, and teach the model how the team thinks.
It needs facts:
- product capabilities
- customer segments
- analytics snapshots
- pricing logic
- product sheets
- brand rules
- scoped release rules
But facts are the easy part.
The harder layer is relationship context:
- why the product is positioned this way
- which customer problems matter most
- where the team has changed its mind
- which claims are off-limits
- what good output looks like
- where the agent has to come back to a human
That last line matters.
Every product repo needs an autonomy boundary. The model can research, synthesize, compare, draft, update, and package. It should not silently make rushed, irreversible decisions when the answer depends on judgment, strategy, or market belief.
You do not want an agent deciding product direction because it found a convincing pattern in old material. You want it to expose the decision point, frame the tradeoffs, and stop.
Asking is part of the system.
Onboard The Agent Like A Teammate
The setup pattern I keep coming back to is the reverse interview.
Do not just upload the knowledge base and hope the model gets it. Make the model interrogate the product repo.
Ask it what questions it has, what seems inconsistent, what assumptions it is making, and what it would need before creating customer-facing work.
The next step is to quiz it.
Have it write a one-page brief, draft a customer email, explain the product to a specific persona, or write an elevator pitch for a skeptical buyer.
Those are not throwaway tasks. They are onboarding tests.
Small outputs tell you whether the model has actually absorbed the product without forcing you to read pages of restated context. If the short artifact is wrong, the long run will be worse.
That is the mental shift.
The product repo is not a prompt helper. It is the team's durable AI work environment.
This Is Where PM Gets More Important
The lazy version of this argument is that stronger models make PMs less necessary.
I think the opposite is true.
Stronger models make weak product context more dangerous. They can produce better-looking wrong answers. They can run longer in the wrong direction.
The PM role moves upstream.
Not just "review the output." That is too late. The higher-value work is deciding what can be delegated, building the product repo, setting the autonomy boundary, and writing the run brief before the model starts spending real money.
A cheap prompt can be sloppy. A 91-million-token run cannot.
That is the shift product teams should take from Fable 5. Not that every PM task is suddenly ready for long-running delegation. Most are not there yet.
The signal is narrower and more useful: the teams that get durable AI work will be the teams that give models durable work environments.
Developers had repos first.
Product teams are next.
What would have to be true in your product's repo before you would trust an agent to work inside it for a day?
Get AI strategy updates in your inbox.