The last three weeks were some of the most revealing I have had in AI-assisted software development.
Claude Fable came back into the picture, and in the same stretch, OpenAI released GPT‑5.6 with Sol, Terra, and Luna. The market signal was obvious: frontier labs are no longer shipping isolated breakthroughs so much as compressing the gap between capability, price tiers, and deployment cadence. Anthropic now sells Fable 5 as its top-end long-horizon model at roughly twice the list price of Opus 5, while OpenAI is framing GPT‑5.6 as a family that scales from flagship capability down to more cost-sensitive work. xAI, meanwhile, is pricing Grok 4.5 aggressively enough that it has to be taken seriously in any cost-performance discussion.
And yet the most important thing I learned in those weeks had very little to do with launch pages or benchmark slides.
The real breakthrough in my environment was preparation.
We had stories ready. We had work split into pieces that could actually be executed by agentic coding systems. Once that queue existed, the throughput became absurd. Across Codex, Claude, Cursor, Grok, and other tooling in the workflow, more than 2M lines of code were written in roughly ten days. That number sounds like hype until you see what made it possible: not magic, not autonomy in the abstract, but a steady stream of bounded work with enough structure for the models to keep moving.
That is the first thing that too many people still miss. The output explosion does not happen because the models suddenly became self-directing engineers. It happens because humans prepared the battlefield.
The second thing I learned is that the bugs show up faster at scale than the marketing ever admits.
Codex is a good example. OpenAI's own material around long-running work makes clear that durable threads come with a trade-off: continuity is useful, but long-running threads can also become more expensive and harder to manage than starting fresh. The Goals feature is designed precisely to keep a thread attached to a bounded objective, rather than turning every difficult task into an ever-growing prompt. In practice, that matches what I have seen. If a process runs too long, the better pattern is often to stop it, ask for a clean handover, restart the session, and continue with a fresh goal. That is not just a convenience. It is often operational hygiene.
There is also a more concrete Codex problem that now has a visible public paper trail: subagent and local-state blowups.
Open issue #34061 documents a case in which a resumed parent thread produced thousands of child JSONL logs and hundreds of gigabytes of persisted session history. Another issue explicitly warns that fork_context=true can cause large parent histories to be snapshot into child agents, amplifying both correctness risk and token burn. Yet another public report shows that Codex cold starts degrade into 1–5-minute waits once ~/.codex accumulates large SQLite logs and session state. Taken together, those reports describe a failure mode that many power users will immediately recognize: on. Once the local metadata layer gets large enough, session persistence becomes a serious part of the product experience.
This matters because multi-agent coding always looks better in demos than it does on a stressed development machine.
The promise is clear. OpenAI's multi-agent docs describe why parallel subagents can accelerate independent workstreams, and that promise is real. But the same docs also warn that subagents increase token usage and may not be a good fit for tasks that involve frequent writes to shared mutable state. The parallel-agent guidance on ChatGPT Learn is even more explicit: start with read-heavy work such as exploration, tests, triage, and summarization; be more cautious with write-heavy flows because conflicts and coordination overhead rise quickly. That warning is not theoretical. Anyone who has watched a fleet of agents stampede toward a full test suite at the same time knows exactly what it means.
In my own setup, this is now one of the defining operational problems of the whole category.
The issue is not whether the models are smart enough to parallelize. They clearly are. The issue is that they still need far better orchestration boundaries, because “smart enough to delegate” is not the same thing as “smart enough to preserve machine health, local priority, and cost discipline under contention.”
That same mismatch shows up in pricing.
Cursor illustrates the problem neatly. Its current pricing is transparent: there are two monthly usage pools, one for Cursor's own models and one for third-party "Other Models." It also shows that Auto is not a single thing. Auto Cost uses flat token pricing, but Balance and Intelligence bill at the routed model’s rate, and the router may choose among models such as Composer, GPT‑5.6, Claude, or Grok. For people doing occasional interactive work, that flexibility is attractive. For bursty, industrial workloads, it can become a trap. A month's premium budget can vanish in a few very productive days.
I tested exactly that failure mode in one review-heavy scenario.
One project took on roughly 500k new lines of code. Our review system flagged about 1,500 issues across that delta, including duplicates and false positives. Cursor CLI was tasked with grinding through them. The raw token volumes were huge. The output was useful. But the economics were wrong for my use case. When intensive review and fix-up work can consume a monthly allowance in a week, the tool may still be good, but the subscription stops making sense.
That tension is now everywhere.
Claude is still the system I enjoy working with most. But it is also the one that makes me most conscious of cost. Codex, especially in the broader GPT‑5.6 ecosystem, can often carry far more throughput than its critics admit. Grok 4.5 is not a joke; its public pricing and positioning make it a legitimate contender. Anthropic's own pricing makes the Fable-versus-Opus trade-off obvious enough that it almost writes the editorial for you: frontier capability is there, but so is the invoice.
And then there is the hardest problem of all, the one no launch event really solves.
Across almost every frontier coding model I use, there is still a frustrating gap between underpowered and overengineered.
The choice is too often between a model that is not thinking hard enough and one that is thinking far too hard for the task at hand. Anthropic's own guidance for Fable 5 effectively acknowledges this. It says higher effort can overplan, that routine work may benefit from lower effort, and that brief instructions often outperform bloated scaffolding. OpenAI says something similar in its GPT‑5.6 guidance: when migrating from earlier models, start with the same reasoning level and then test one level lower, because the newer models can often preserve or improve quality with fewer tokens. That is a technical way of saying the same thing many of us are discovering empirically: the effort dial is still too easy to overshoot.
Maybe part of that is still on us.
Maybe the instruction files are too long. Maybe some of the scaffolding is now fighting the models instead of helping them. That theory is at least consistent with Anthropic's own context-engineering guidance, which says context should be informative but tight. There is a real possibility that some of the overcomplications we blame on the models are being amplified by overgrown prompt infrastructure.
But even after accounting for that, the broader conclusion remains unchanged.
The models are making fewer obvious mistakes than before. But the mistakes they still make are often more dangerous precisely because they are harder to spot. They hide inside code that otherwise looks polished, deliberate, and professional. The better the implementation looks from a distance, the more suspicious I have learned to become.
That is why I remain skeptical of the current wave of AI-coding triumphalism.
I understand where the hype comes from. If you have not lived inside these systems every day, the throughput alone can feel miraculous. And some of it genuinely is. But daily hands-on use also exposes the other side: billing uncertainty, orchestration failures, long-session fragility, a tendency toward either shallow simplification or elaborate overdesign, and the persistent need for human packaging, review, and judgment.
We are still very far from an ideal LLM coding world.
The hype is not completely wrong. But it is still much less honest than the operational reality.
