Coding models that generate 20 times faster can also produce technical debt 20 times faster when developers keep old habits.
2
Fast models make continuous testing, linting, refactoring, and review practical at every step of a workflow.
3
Developers can preserve context across short sessions with bounded tasks and four files: agents.md, plan.md, progress.md, and verify.md.
Summary
Sarah Chieng argues that faster coding models require developers to change how they work. Cerebras and OpenAI's Codex Spark generates code at 1,200 tokens per second, compared with roughly 40 to 60 tokens per second for the Sonnet and Opus families. That speed makes some workflows practical, such as running validation after every change and generating many implementation options before choosing one. It also makes existing bad habits more costly. Large prompts, oversized commits, many unverified agents, and unattended sessions can create technical debt very quickly. Chieng recommends assigning planning to a larger model and execution to a faster one, treating the model as a pair programmer, steering it with tight limits, and refactoring continuously. Since fast generation fills context quickly, she recommends breaking work into bounded goals and storing plans, progress, agent definitions, and verification results in persistent files.
Fast generation multiplies the cost of old coding habits
Chieng says developers have adapted to slow AI generation by writing massive prompts, trying to one-shot tasks, making huge commits, and running many agents at once. Codex Spark changes the scale of the problem. It generates code at 1,200 tokens per second, while the Sonnet and Opus families generate roughly 40 to 60. A habit that produced 50 tokens per second of bad code can now produce 1,200 tokens per second of bad code. The speed removes waiting, but it does not remove the need for developers to inspect and direct the work.
Inference speed is improving across the whole stack
Chieng attributes faster models to simultaneous improvements across hardware, model architecture, and inference software. Hardware teams are addressing the memory wall, which she says accounts for 50 to 80 percent of inference latency through movement of weights and KV cache values. Cerebras distributes memory across its wafer in SRAM so each core can access needed values directly. Disaggregated inference separates prefill, which is compute-bound, from decode, which is sequential and memory-bound. At the model layer, mixture-of-experts architectures activate only part of a model for each token. Inference companies also improve speed through KV cache reuse.
Developers need to verify the large amount of code that fast models produce
Chieng describes an online culture of six cloud-code terminals, 500-agent swarms, and agents spread across several screens. She says these setups can generate massive amounts of code that nobody verifies. With faster inference, that becomes increasingly dangerous because technical debt accumulates at a scale developers may not know how to handle. Her playbook starts by treating verification as part of each step instead of a final activity. The concern is practical: faster output increases the amount of code moving through the workflow, so unexamined output becomes more expensive to clean up.
Speed is now a separate choice from intelligence and cost when selecting models. Chieng suggests using a larger model such as GPT-5.4 or GPT-5.3 for planning and long-horizon work, then using Codex Spark to execute the resulting steps. A larger model can also turn a successful difficult session into a reusable skill or captured trajectory. A smaller, faster agent can then repeat that workflow in the background. This divides the work between forming a plan and carrying out a verifiable sequence of actions.
Continuous validation becomes practical when generation is fast
At 1,200 tokens per second, Chieng says validation is effectively free. She recommends adding test suites, linting, pre-commit hooks, diff reviews, and browser-based quality checks to every stage of the workflow. These checks should run as work proceeds rather than only at the end or before code is pushed. The reason is that fast inference removes much of the waiting that previously discouraged developers from running checks repeatedly. Validation can therefore happen after each change while the relevant context is still available.
Generating many alternatives lets developers choose better output
Chieng uses a navbar as an example. Instead of asking a slower model for one version, a fast model can generate 15 versions in roughly the same time. Five sub-agents can generate 15 versions each, producing 75 options from which the developer chooses. She recommends this for work where variety matters, including research directions, architecture directions, and graphic design. The method can improve model output without requiring the developer to write an extremely detailed prompt or supply a complete example. Her claim is that selection from many attempts can add human taste to otherwise generic output.
Fast coding should feel like real-time pair programming
Chieng says developers should stop treating an agent session as something they start before leaving for a break. They can sit with the model, ask it to gather context across the repository, ask how the code works, and make decisions while implementation proceeds. The developer should remain in the front seat. She recommends steering with concrete constraints, such as banning file deletion, setting a maximum diff size, limiting the model to reading and writing, or telling it to change only a specific area. This active collaboration is how she says developers can avoid code they do not understand.
Persistent files keep short sessions from starting over
Fast generation fills context much sooner. Chieng compares a former ten-minute path to compaction with a new path that can reach compaction in 30 seconds. She recommends breaking large work into small, bounded goals and externalizing memory in four files. agents.md defines agents and sub-agents. plan.md contains the overall plan and checklist. progress.md records what has been done and what remains. verify.md records the checks performed at each step. A new session can read progress.md and continue from the right point instead of trying to reconstruct the previous session from its context.
