How do I make agent-written software actually reliable?

Reliability comes from the system around the agent, not from a better prompt. Specify the outcome precisely, split the work into pieces small enough to check, and make something verify each piece — a test, a second agent, a fixed rule — before it counts as done.

What does "vibe coding" actually mean?

Building software by describing what you want in plain language and letting an AI write the code — steering by the result and the feel of it rather than by reading and writing every line yourself. The term caught on in 2025 and stuck because it names something a lot of people had started doing.

Is vibe coding a bad thing?

Not inherently. It's excellent for prototypes, personal tools, and learning. It gets risky when people ship code they don't understand into situations that matter — handling money, personal data, or other people's trust. The technique is fine; the judgement about when to use it is what counts.

Can non-programmers vibe code?

Yes — that's much of the appeal. You can build a working tool by conversation alone. The catch is that understanding grows slower than output, so it pays to ask the AI to explain what it built and to keep what you make modest until your understanding catches up.

Do I need to be a programmer to use recursive agents?

No. You describe the job in plain language and the agent writes and runs its own orchestration — spawning the sub-agents, checking their work, and reporting back. Understanding the principles just helps you ask for the right shape and spot when a result hasn't actually been verified. You read and approve; you don't author the machinery.

How is a recursive agent different from just running many agents in a fixed pipeline?

A fixed pipeline is written ahead of time and has to guess the shape of every job — it always splits the work the same way. A recursive agent decides its own breakdown for the task in front of it: how many pieces, how deep to go, when to stop. That self-decomposition is the whole difference. A rigid script can't adapt when the job turns out bigger or messier than expected; a recursive agent can.

Doesn't an agent calling itself over and over get expensive or run away?

It can, which is why recursion is a tool you point at hard jobs, not a default. In practice you bound it: a depth limit on how many levels deep it can go, a token budget it can't exceed, and a clear stop condition so it ends when the work is done rather than looping forever. Most everyday tasks need none of this — one agent in one context is cheaper and just as good.

Can a smaller, cheaper model really be reliable this way?

Often, yes — for structured, long-running work. When a job is broken into small, well-specified pieces that each get checked, a modest model with a good harness around it can outperform a much larger model asked to do the whole thing in one pass. The orchestration compounds. It won't make a weak model brilliant, but it narrows the gap far more than raw size does on this class of task.

Isn't running loops just expensive?

It can be — and that's the honest catch nobody leads with. A single loop on a medium task can burn through tens of thousands of tokens; a fleet with an orchestrator and a few specialists runs much higher, and a loop on a daily schedule adds up every week. If you're token-rich the math barely registers; if you're not, an open-ended loop will empty your budget fast. The fix isn't a cheaper model — it's a tighter loop. Bound the scope, set a token budget right in the prompt, and keep the loop closed (a path you drew, with a stop condition) rather than open (a goal it roams freely toward). A closed loop on a clear job is affordable. An open loop on a vague one is where the bill gets scary.

How is loop engineering different from a dynamic workflow or a software factory?

They're nested, not competing. A dynamic workflow is a single powerful move — Claude writes a script that spawns and coordinates many subagents for one hard task, then it's done. Loop engineering is the standing system that might call a workflow as one of its steps, but keeps running on a schedule, remembers across runs, and feeds itself. The software factory is the biggest frame of all: the whole signal-to-shipped-software circle that a mature set of loops eventually adds up to. Loop is the unit; factory is the building.

Do I have to stop prompting Claude directly?

No, and you shouldn't. Direct prompting is still the fastest way to do anything you understand well and only need once. Loops earn their keep on work that repeats, runs while you're away, or is too parallel to babysit. The skill is knowing which is which — not converting everything into a loop because loops are the new shiny thing. Most good setups are a few reliable loops plus a lot of ordinary prompting.

Isn't it risky to let a loop run unattended?

Yes, which is exactly why the verifier matters. The single most important move in a loop is splitting the agent that does the work from the agent that checks it — a maker grades its own homework too kindly. Pair that with a bounded scope and a human owning the high-stakes gates (what merges, what ships, what touches money or users), and an unattended loop becomes something you can actually trust. A loop with no checker is just a faster way to be confidently wrong.

Building reliably with agents — Claude for Humans

This is the deep end of the site, and it is aimed at a specific moment: you have got past “can it build this?” and landed on “it built this, and I am not sure I can trust it next time.” Everything below is about the second problem, which is a very different problem from the first.

The through-line across these pieces is one observation. Producing software got dramatically cheaper; knowing whether the software is right did not. So the bottleneck moved downstream, and every reliable setup you will read about here is some answer to the same question — who or what checks the work, and how does that check happen automatically rather than because someone remembered.

They are best read roughly in this order. Vibe coding names the default habit — describing what you want and steering by feel — and is honest about where it shines and where it bites. Slop and determinism gives you the structural fix: keep the parts that can be certain certain, and let the model handle only what is genuinely fuzzy. Recursive agents and loop engineering are the two orchestration arguments, one about an agent that decomposes and verifies its own work, the other about designing the loop that prompts the agent instead of prompting it yourself. The software factory zooms all the way out to the whole cycle — signal in, shipped change out — and is the most speculative of the five.

Two warnings before you go in. First, none of this is about writing better prompts; if anything the collective claim is that prompt quality stops being the interesting variable surprisingly early. Second, this material leans technical and Power-Track — the examples are code and pipelines. The judgment travels well beyond code, though. “Split it small enough to check, and make the check automatic” is as true of a monthly reporting process as it is of a test suite.

The words

Agentic coding AI coding agent: Agentic coding is using an AI that actually does the software work for you — reads your files, writes and edits code, runs commands, checks the result, and fixes its own mistakes — instead of one that just hands you a snippet to paste. You describe the outcome you want in plain language; the agent works out the steps and carries them out. Claude Code is an agentic coding tool, and you don't have to be a programmer to direct one.

The words

Read more