Steve Yegge has a way of making developer tooling sound like a roadside dare. His new essay, “The Shape of Things to Come,” is long, messy, funny, wildly confident and worth reading if you care about where AI coding is headed.
The short version is not that everyone should copy his setup. Yegge says Wheelhouse, the orchestration system he is using around his old MMO Wyvern, is closed-source and built for him. The useful signal is the shape of the work: many agents, long-running tasks, persistent memory, queues, review gates, generated work items and a human acting less like a typist and more like an operator.
GearPulse’s view: this is relevant because the first wave of AI coding made developers feel fast. The second wave is making them feel busy. The third wave, if Yegge is even partly right, will be about managing throughput without letting quality, security and product judgment collapse under the volume.
That sits in the same lane as our recent Vercel scriptc article and MCP labeling analysis. The developer-tools story is moving from novelty to operations. Once agents can produce more code than a team can comfortably review, the bottleneck is no longer generation. It is control.
What Yegge is really describing
Yegge’s essay is full of specific language around loops, graphs, Beads, Wheelhouse, “cities” and a “Wish Factory.” Strip away the personality and the core claim is sober: if coding agents are going to work for hours across large systems, they need structure around them.
Beads is the public piece of that world. Its GitHub repository describes a persistent, dependency-aware issue graph for coding agents, with commands for ready work, claiming tasks, dependency links, sync, memories and agent setup. In other words, it is issue tracking shaped for non-human workers that forget context unless the system keeps it for them.
Claude Code’s official hooks documentation points in the same direction from another angle. Hooks let teams run deterministic commands at specific lifecycle points instead of trusting the model to remember every house rule. OpenAI’s Codex repo similarly frames coding agents as tools that run inside a local workflow, reading, editing and executing in the developer’s environment.
The pattern is bigger than one tool.
| Old mental model | Newer agentic model | Why it matters |
|---|---|---|
| Chat with a coding assistant | Dispatch work to an agent with tools | The unit of work becomes a task, not a prompt. |
| Markdown TODO list | Dependency-aware work graph | Agents need clear next actions and blocked states. |
| Human remembers project context | Persistent project memory | Long-running work needs continuity after compaction and handoff. |
| Review every diff manually | Gate, test and sample outputs | Human attention becomes the scarce resource. |
| CI catches finished work | Harnesses steer work while it is happening | Faster generation needs earlier feedback loops. |
That table is the part worth carrying into Monday morning. You do not need Yegge’s exact machine to feel the problem.
The prediction may be too hot. The lesson is not.
Yegge makes aggressive claims about human code review, CI/CD and the future of agent work. I would treat those as sharp forecasts, not settled facts. Most companies are not ready to let autonomous workers roam across production codebases overnight. Compliance, security, data access, flaky tests, product nuance and plain old code ownership still matter.
But the mistake would be dismissing the whole thing because the rhetoric is loud.
The practical lesson is already visible: AI coding is becoming an operations problem. If an agent can create ten branches, edit dozens of files, run tests, summarize results and ask for review, then the developer’s job changes. You need queues. You need policy. You need repeatable checks. You need logs. You need a way to see what was attempted and why. You need to know when the model is stuck versus when it is confidently wandering.
DoltHub’s Beads field report is useful here because it frames Beads as a way to keep long-running work on track across context loss. That is less glamorous than “the end of software engineering” and much closer to the daily reality of using these tools.
The human role gets narrower and more valuable
The scary version of this story is that agents replace developers. The more realistic version is that agents make sloppy delegation painfully expensive.
If you give a human junior developer a vague task, they may ask a clarifying question. If you give an agent a vague task with write access and time, it may produce a confident pile of almost-right changes. Multiply that by ten workers and your old review process becomes a denial-of-service attack on your own judgment.
That is why Yegge’s emphasis on orchestration matters. The future developer does not just write code. They design the work system: what tasks are allowed, how they are split, what tests must pass, what files are off-limits, when a worker should stop, how results are compared and how much risk is acceptable for the next run.
There is a personal spin here: the developers who benefit most from agents may not be the ones who write the cleverest prompts. They may be the ones who write the clearest constraints.
A sensible adoption path
Most teams should not start with an all-night agent factory. Start smaller and more boring.
| Step | What to try |
|---|---|
| 1 | Use agents on narrow maintenance tasks with obvious tests. |
| 2 | Keep a structured task graph instead of loose markdown notes. |
| 3 | Add deterministic hooks for formatting, tests, secret checks and protected files. |
| 4 | Require agents to cite files changed, commands run and residual risk. |
| 5 | Compare agent output against human baselines before increasing autonomy. |
That is not anti-agent caution. It is how you get leverage without turning your repository into an archaeological site of half-finished experiments.
The more powerful these systems become, the less acceptable it is to treat them as magic chat boxes.
Bottom line
Yegge’s Wheelhouse essay is captivating because it sounds like one engineer operating a software factory from a year in the future. The reason to read it is not to believe every prediction. It is to notice the infrastructure he keeps circling back to: memory, graphs, gates, queues, harnesses and taste.
AI coding is getting faster. That part is obvious. The harder question is whether developers can build the operating discipline to keep up with what they just unleashed.