Stop Prompting, Build a Software Factory: The Age of Agent Rigs

Four years and thousands of hours of hands-on practice, plus long conversations with some of the sharpest people in the field, distill into one claim: the era of prompting for one snippet at a time is ending, and the era of self-running agent rigs is beginning. In this long YouTube conversation the speaker argues that his job, and yours, will look fundamentally different twelve months from now, and he backs it with a live build of a small working rig. My reading: this is not a tool demo, it is a thesis about AI-assisted work changing direction.

Every great transformation has triggered the same fear, and people have adapted every time. When automation replaced floors of clerks doing arithmetic by hand, accounting did not vanish; the shape of the job changed. Facing agents calls for the same posture: think like a conductor, not like someone about to be replaced. What convinces me is the historical pattern: the fearful do not win, the early adapters do. Selling panic is easy; building rigs is hard, and the second one pays.

Soon each of us will run an organization of thousands of entities, some human, most of them agents. In such a structure approving every decision one by one is impossible, because even the fastest frontier model produces work far faster than a human can review it. Keeping the human in the loop becomes the very bottleneck that slows the system. I find this thesis heavy but fair: unblocking five agents by hand is already a real burden today, and running five hundred that way is unthinkable.

Agent loops and software factories

An agent loop is a rig that owns one small recurring job end to end and runs on its own whenever triggered. When many loops join up and operate without human approval, you get a software factory; a loop may still consult a human, a factory should run on its own fuel. My practical takeaway: instead of dreaming of grand automation, pick one small job I do every day and turn it into a loop. Rigs that start narrow grow; rigs that start broad stall.

In every organization the scarcest resource is the leader's time, and most of us spend it without knowing where it goes. Measuring the flow of time for a few weeks exposes the gap between belief and reality: a line item imagined at twenty percent can turn out to be sixty. The step after measurement is handing a small slice of that time to an agent loop. I like this discipline: measure first, delegate a small slice next, and do not rush the expansion.

How we interact is changing too; the era of asking questions in a chat window is behind us. The new frontier models are so fast and capable that the problem is no longer asking, it is keeping up with the flowing work. For someone already touching hundreds of agents a day, that number multiplying next year would be no surprise. The opportunity I see sits right there: while most still work with old habits, those who build rigs earn an honest head start.

As scale grows, single agents give way to layered teams: a smart manager agent distributes the plan, a middle layer coordinates, light and cheap models do the labor. An agent's job should not be doing one task but launching and supervising ten worker agents. Seen this way the leverage changes: designing tasks where twenty, fifty, a hundred agents do meaningful work is the core expertise of the future. I have adopted this frame: we no longer design tasks, we design task-launching systems.

Even with a strong local model, running everything on a personal computer stalls past a point. Permission popups, opening tabs, and twenty-plus agents racing while I work slow the bench down and scatter attention. And when I want to switch away, the agents keep sharing the same environment. My own practice points the same way: after a few parallel jobs the local setup turns inefficient.

On security the cloud answer pulls ahead; the view relayed from Vercel holds that the cloud gives a far sturdier ground for safety. The logic is simple: when agents run in isolated sandboxes, a breach stays trapped in one environment and the main bench is never at risk. The SaasRise record confirms Vercel's move to separate the model from deployment agents into a sandbox design. I find this argument strong: as the attack surface grows, isolation is a necessity, not a luxury.

The showcase example is a deep security sweep running every ninety minutes: the software probes itself continuously and catches an open door early. Small teams with such rigs can match the output volume of staffs hundreds strong. The Jellyfish research paints a similar picture: engineering teams that adopt the tools intensely pull ahead in output and satisfaction. My verdict: boring but critical jobs like security sweeps are the strongest advertisement for factory thinking.

Triggers, capabilities, and model economics

What launches a rig matters as much as how it runs. Manual launching is normal for a transition period, but the goal is removing the person: running on a schedule, waking on outside events, triggering on movement in the software repository. Outside stimuli such as web hooks and error signals are the parts that make a rig genuinely autonomous. My suggestion: note every manually launched job and regularly review which ones could be scheduled.

Anthropic's Agent Skills idea makes expertise packable: a folder of guides, scripts, and reference files turns a general agent into a trained hire ready for a special task. Connection to the outside world passes through a universal protocol gate; the capability carries the inner procedure while the protocol called MCP carries outside access. The Ravichaganti review draws this pair cleanly: one spends the context budget efficiently and cannot replace the other. I care about this split: cramming everything into one standard gets expensive and brittle.

I expect capability chains to be the next step: systems will infer from a person's past agent traces which steps follow each other and propose the likely sequence. If three operations run back to back with high probability in a given situation, the system will offer them as one package. That means a layer learning from observed behavior. I feel a cautious curiosity: output rises, but trace-tracking and privacy questions grow with it.

Subscription economics shapes the picture too: entry, middle, and top tiers ship at similar prices on both sides, yet the model choice multiplies the work coming out of the same plan. The Replicas comparison lays token costs and context windows of frontier models side by side and makes the table concrete. The Coursiv review points the same way: limits reveal themselves in actual use more than in announcements. My conclusion: when buying a plan, look at work per budget, not at price.

On comparisons the scores run close: the Daily.dev summary puts the two tools' accuracy rates side by side within less than a point. The Terminal-Bench measurements on the Replicas side show a similar closeness, with the gap opening in working style. So the winner is not a model but a workflow fit. I find this result important: this is a working-style decision, not a shopping list.

In practice the two styles complement each other: the locally running assistant leads in interactive supervised work, the cloud fleet in bulk jobs delegated and reviewed later. The Daily.dev comparison draws this split sharply: one for live fixes, the other for handed-off batches. Coursiv confirms the dual-use pattern: most teams run one as supervisor and the other as background fleet. My advice matches: distribute by job type instead of marrying one tool.

Research offers a cautious optimism: the METR note reports the early slowdown finding reversing with new releases, with participants unwilling to give the tools up. That complicates measurement but signals direction. My reading: the output gain is observation now, not claim, yet it is not evenly spread. What opens the gap is not the tool itself but the discipline of building rigs.

Final word: the scissors are opening, and the output gap between rig-builders and entry-plan stayers widens every month. The cost is smaller than assumed; the real cost is waiting. The live demo in the conversation proves it: a simple rig raised from a short voice command becomes a line that reviews the product nonstop. My call is plain: start today with one small loop, grow the factory over time.