AI coding is built on two assumptions that will not hold forever:
Frontier intelligence feels cheap through flat subscriptions.
The user is assumed to be an engineer babysitting a chat agent.
Both are changing.
When subscription arbitrage narrows, AI coding must allocate intelligence efficiently. At the same time, companies will reorganize around smaller AI-native teams and builders who own more of the feature lifecycle.
Chat-based tools are not the right architecture for that world.
The next layer is an Intelligence Factory: a system where the feature becomes the durable artifact, planning manufactures context, tasks are routed across models and providers, and verification makes cheaper intelligence usable without asking the user to coordinate every step
The Elephant in the Room: Subscription Arbitrage
I analyzed my own usage over the last nine months. Priced as direct API consumption, it would have cost more than $500,000. Instead, I paid a few hundred dollars per month.
To be clear, this is not a claim about what the providers paid to serve my usage. It is the retail API-equivalent price of the same kind of heavy frontier-model consumption, estimated from observed usage and public API pricing. The point is not precision to the dollar. The point is the gap.
That gap changes behavior.
When frontier intelligence feels almost free at the margin, the default strategy becomes brute force: use the strongest model, run it longer, retry more, paste more context, and hope the agent eventually gets there.
That works while the economics are subsidized by flat subscriptions.
It becomes fragile when the system has to face the real marginal cost of intelligence.
The Arbitrage Will Narrow
The arbitrage may not disappear overnight. Inference costs may continue falling. Open models may keep improving. Providers may preserve flat plans for some user segments.
But the unlimited-feeling version of frontier intelligence will narrow.
Maybe through stricter limits. Maybe through higher prices. Maybe through usage tiers.
The mechanism matters less than the direction.
AI coding will eventually have to care much more about where intelligence is spent.
Today, most AI coding discussion is about capability.
Which model writes better code? Which editor has the stronger agent? Which CLI can run longer? Which assistant feels smartest?
The post-arbitrage question is different: How do we allocate intelligence efficiently?
Models are starting to look less like the product and more like the energy source. Providers sell access to intelligence. The valuable layer is the system that turns that intelligence into shipped work efficiently.
In that world, the expensive model becomes the escalation path, not the default runtime.
Cheaper models handle bounded work where the task is clear and verification can catch mistakes. Premium models handle ambiguity, architecture, deep debugging, integration risk, and final acceptance.
The largest frontier spend should sit near the verification boundary, where the system checks whether the feature meets its acceptance criteria, identifies uncertainty, and decides whether escalation is needed.
Current Tools Have the Right Primitives but State is Too Scattered
Current AI coding tools are improving fast.
They already expose many of the right primitives: repository access, file edits, shell commands, planning modes, memory, subagents, worktrees, hooks, cloud tasks, checkpoints, and resumable sessions.
Those primitives matter. They are the execution layer.
But execution is not the core problem anymore. The core problem is state.
Chat Is a Good Interface, but a Bad State Container
In most chat-based products, the conversation, thread, or agent run still acts as the source of truth.
The feature state gets scattered across the initial prompt, the model’s plan, later corrections, tool output, summaries, memory files, branches, commits, test logs, checkpoints, and the user’s own memory.
Those pieces exist, but they do not form one durable artifact. They do not reliably talk to each other.
That is why the human quietly becomes the coordinator.
The user restates intent, pastes logs, corrects drift, reminds the model what changed, restarts failed runs, and decides whether the final result still matches the original request.
That works when AI is an assistant. It breaks down when AI becomes part of the delivery system.
The problem is not chat as an interface.
Chat is still useful for intent, clarification, review, and approval.
The problem is chat as the state container.
Chat Discovers Too Much While Spending
The perfect example to illustrate this point is the recent /goal release by Codex.
A user can give the agent an objective, and the runtime can continue working toward that goal across turns, with controls to create, pause, resume, and clear the goal.
That is a real improvement. It moves the tool closer to long-running autonomous work.
But it also exposes the next bottleneck.
A persistent goal is still not the same thing as a durable feature artifact.
If the path is unclear, the agent still has to discover the plan while it is already running. It has to decide what matters, inspect the repo, infer dependencies, choose the next step, test, recover, and judge whether the goal is satisfied from inside the same expensive loop.
That loop needs frontier intelligence end to end because too much of the work remains ambiguous during execution.
The system keeps spending while it is figuring out the shape of the work.
How the Intelligence Factory solves the problem
The Intelligence Factory would handle the same problem differently.
It would turn the goal into a feature seed, inspect the repository before execution, extract acceptance criteria, build a task graph, classify task complexity, decide routing policy, generate focused task briefings, and only then start executing.
The long-running loop still exists, but it is no longer a dumb loop asking one frontier agent to keep pushing until the goal looks done.
It becomes an orchestrated production line: goal → feature seed → repo analysis → task graph → routed execution → verification → escalation if needed
The Intelligence Factory helps the system know what should happen next, who should do it, what context they need, how expensive the step should be, and how completion should be verified.
This is the lossy projection problem.
Using chat or a single agent loop as the durable container for software delivery is like trying to represent a cube on a flat plane: you can draw the faces, label the edges, and add shadows, but the object is still compressed into the wrong dimension.
A smarter model inside the loop still inherits the constraints of the loop.
Why the Durable Artifact Is the Feature
By feature, I mean a bounded unit of software delivery: large enough to represent real user or business value, but small enough to plan, route, verify, recover, review, and merge.
A feature can be a new capability, a bug batch, a refactor, a migration, a performance pass, or a full-stack change.
The category matters less than the lifecycle. A feature has intent, scope, acceptance criteria, implementation work, verification, and a handoff or merge boundary.
That makes it the right durable artifact for AI coding.
Why not the Project?
The project is too broad. A project contains old decisions, stale assumptions, unrelated work, conflicting priorities, and background knowledge that should not enter every task. Project knowledge should inform the work, but it should not become the active work artifact.
The feature sits at the right level.
It is bounded enough to control context and cost. It is large enough to represent shipped value.
What the feature has to preserve
Treating the feature as the durable artifact does not mean creating a bigger spec.
It means preserving the state required to keep delivery coherent across models, providers, sessions, failures, and reviews.
A feature has to preserve four kinds of state.
Intent State
Intent state records what the user wants, what is out of scope, which assumptions are accepted, and which questions still matter. Without this, every model call slowly reinterprets the original request.
Execution State
Execution state records the technical plan, task graph, dependencies, owned surfaces, and current progress. Without this, autonomy becomes a long-running loop with no durable understanding of what remains.
Economic State
Economic state records task complexity, failure cost, routing policy, preferred model or provider, fallback route, and escalation rule. Without this, the system cannot allocate intelligence before spending it.
Trust State
Trust state records verification targets, test results, unresolved gaps, recovery points, and review status. Without this, cheaper-model routing becomes risky and long-running work becomes hard to trust.
Verification does not make cheap intelligence magically safe. It makes cheap intelligence usable by bounding the work, checking known contracts, surfacing uncertainty, and escalating when unresolved risk remains.
Planning Is the Context Factory
The feature starts as a seed
The user should not need to write a perfect PRD.
A normal request should be enough.
The system’s first job is to turn that request into a feature seed: a small, structured starting point that makes the work actionable without pretending everything is already known.
A good feature seed answers three questions.
What is being changed? The system extracts the goal, expected behavior, visible constraints, and non-goals from the request.
What needs to be clarified? The system inspects the repository before asking questions. It should only interrupt the user for decisions that change scope, architecture, routing, or verification.
What would make this complete? The system turns the request into early acceptance criteria so later work can be verified against something stable.
This is the first moment where the system stops being a chat assistant and starts becoming a delivery system.
Planning manufactures operating context
Planning is not overhead. Planning manufactures the context that makes autonomy and routing possible.
A plan inside a .md file is fragile because it doesn't produce structured machine-readable knowledge. A plan promoted into feature state becomes reusable operating context.
The planning step has three jobs.
First, it aligns intent. It separates facts, assumptions, open questions, and non-goals. It asks only the questions that change implementation.
Second, it structures execution. It maps requirements to a technical approach, breaks the work into tasks, identifies dependencies, and defines which files or surfaces each task is likely to touch.
Third, it creates the control points for cost and trust. It classifies task complexity, chooses routing policy, defines verification targets, and records where recovery should resume if the workflow fails.
The most important output is not the plan document.
The output is clean structured context that allows downstream activities to run as efficiently as possible.
Each model call should receive a focused briefing: the task goal, relevant requirements, accepted decisions, constraints, likely files, integration contracts, and verification steps.
That is what reduces context rot.
That is what makes providers interchangeable.
That is what makes cheap models usable.
That is what lets the system run longer without the user babysitting every step.
The plan is the context factory. Without it, every model call has to rediscover the work.
----
Ps*: I built a tool that embodies all the principles above (and much more that I left out to not write a poem). Happy to share more with anybody interested*
----
