This is the last part of Ariel’s seven-part “AI Concepts from Zero to Pro” series, and it’s the one where theory turns into practice. Six parts covered what a model is, how context works, why agents lie, and how to manage memory. Part 7 asks the question that actually matters: how do you get an agent to do real work while you’re asleep, and wake up to something you’d ship?
If you missed the foundations, the full dictionary post covers the basics. This one is about workflows.
Human in the loop vs. AFK
The first split is simple. Human in the loop means you and the agent go back and forth in one session: you give an instruction, it answers, you think, you correct it. AFK (“away from keyboard”) means you hand over a task, walk away, and look at the result later. Sometimes you don’t even look at the result.
Neither one is better in general. It depends on the task. Ariel’s example is a database schema migration. You don’t run that AFK overnight. You stay in the loop, watch each step, and catch the wrong column before it costs you a weekend.
AFK only works when the agent can make its own decisions without wrecking anything. In practice that means sandboxes. The setup he describes: the agents get hyper-permissive “do whatever you want” mode, but the real file system is read-only, each agent writes only inside its own sandbox, there’s no network access, and the output is a pull request against the main codebase. The agent has lots of freedom inside a box it can’t break out of.
A common AFK pattern: when the agent hits an unclear decision, it doesn’t wake you up. It asks another agent for a second opinion.
Checks: the black-and-white definition of done
The most important ingredient for a good AFK run is automated checks. These are deterministic, pass/fail tests that live in the environment and tell the agent whether it’s done, without you having to.
Not “evaluate whether this is good.” More like: “Good means I can log in. Good means asking for my location returns a location. Good means this spot has a ride available and that spot doesn’t.” Before a long run, whether that’s one night or two weeks, you generate those tests up front.
Then you wrap the agent in a control loop. Normally an agent’s run ends when it sends you an answer. In a loop, the run ends when the tests pass. Two lines from the source he walks through are worth repeating:
- Even a broken test is a test, and it’s better than no test.
- A check is not a review. A check says whether something works. It says nothing about whether the code is secure, clean, or GDPR-compliant.
He also gives a check that isn’t really a “test” in the usual sense. He built his own data access layer, and agents keep trying to reach the database their own way. A static check that scans the whole codebase and confirms 100% of database access goes through his layer gives a yes/no answer on every run. That’s a check too.
Reviews: specific, separate, and actually read
A review is an inspection: code review for code, plan review for a plan, QA for the final product. An automated review means another agent reads the work, ideally with a different model, a different system prompt, and different parameters. It’s non-deterministic and involves judgment, which is exactly why it isn’t a check.
The key is to be specific. “AI review” means nothing. “A security and breaking-changes review that verifies the diff matches the ticket” means something. If AFK runs keep producing bad PRs, add more focused automated reviews before the merge.
Then there’s human review of AFK output, and the uncomfortable use case that goes with it: the agent’s summary said it deleted the dead code. The human actually checked, and the dead function was still there. Read the diff, not the summary.
Vibe coding done right
Ariel’s definition: vibe coding is what you’re doing the moment you remove human review of the code from the process. You stop looking at what the agent did and only look at the result.
Done badly, it piles up problems until the codebase can’t be fixed, which is why people limit it to prototypes. Done properly, with automated checks, a solid design concept, and grilling, it’s not a synonym for sloppy code. Sloppy code comes from letting the AI work sloppily.
There’s one hard exception: authentication and other sensitive flows. “The login works, that’s all I checked” is how passwords end up in log files. If you’re a developer, read what it did. If you’re not, interrogate the agent or bring in someone who can.
Design concept, grilling, and prototypes
- Design concept: the high-level spec. You and the agent talk until there’s a hand-off artifact that defines everything needed to build the thing. If the agent “did exactly what I asked and still got it wrong,” you don’t have a design concept yet. It’s filling the gaps with assumptions. Tell it: don’t assume, ask.
- Grilling: the technique for building that design concept. “I have a new task. Grill me.” The more ruthless you tell it to be, the more questions it asks. 30, 40, even a few hundred is fine. Grilling is always human in the loop. If an agent already went straight to implementation and got the logic wrong: roll it back, grill first, document everything.
- Prototyping: for decisions words can’t settle. Colors, ordering, flow. His example: arguing for half an hour over whether a form should be one page or a three-step wizard. Tell the agent to prototype both and you’ll know in five minutes. Then take what you learned back into more grilling.
DX vs. AX
Developer Experience (DX) is how comfortable the environment is for a human: fast feedback, clear errors, docs that answer questions, setup that works the first time.
Agent Experience (AX) is the same question for the agent, and here’s the twist: agents are stateless, humans are stateful. A new hire becomes productive in a week because someone sits with them and they remember. An agent forgets every session. So “our DX is great, new people ramp up in a week” tells you nothing about AX. Test AX separately.
When the same model and the same harness do great work in one repo and terrible work in another, the instinct is to blame the model or rewrite the prompt. The fix is usually the repo. Good AX has three dimensions:
- Lots of good automated checks, plus types and linters.
- Good architecture: clear folders, clear interfaces, names that say what they mean.
- A free context window: a lean agent MD, most knowledge in skills, simple tools, so every session starts in the model’s smart zone.
His example: the agent writes excellent API code and a mess on the frontend. That’s because the API is full of rigid rules and the frontend has none. He also gives practical advice that sounds annoying but works: have the agent load the codebase with comments. Ugly to humans, gold for the next agent session.
The software factory
All of this leads to the current hot concept: the software factory. Without a factory, every session starts because a human opened Claude Code. Even an AFK session starts because you wrote the brief and hit go.
In a factory, sessions start from triggers: a bug report opens a ticket, the ticket wakes an agent, and the agent runs the whole thing AFK under all the rules above until it hits a decision big enough for a human, or hands over a final result for review. Triggers can be an issue, a chat message, a cron schedule, or another session finishing.
Two important details:
- A factory doesn’t have to own the whole codebase. You can build one for just the UI, or just the database layer.
- Humans can step in at any point in the factory’s scope. Push the idea to the extreme and you get a dark factory: a plant run 100% by robots, so nobody bothers turning the lights on.
๐ฅ Roast Corner
Everyone wants a dark factory. Almost nobody has a single deterministic test.
That’s the gap this video exposes. People jump straight from “I asked ChatGPT for a function” to “my agents ship PRs overnight” and skip every boring step in between: sandboxes, checks, specific reviews, a design concept, a repo an amnesiac can navigate. Then they wake up to a PR that “deleted the dead code” without deleting the dead code, and blame the model.
The model isn’t your problem. Your problem is that the definition of done lives in your head, your repo has a 4,000-line agent file and zero tests, and you read the summary instead of the diff. A software factory with no checks isn’t a factory. It’s a very fast way to make the same mistakes while you sleep.
Also, a note to everyone who says “vibe coding” as an insult: the sloppiness was never the vibe. It was the missing tests.
๐ค AI for Humans
If you want to try AFK work this week without burning anything down, here’s the shortest version:
- Pick a task with a black-and-white finish line. “The login page loads and accepts a valid user.” Not “improve the auth flow.”
- Write the checks first. Even rough ones. Even broken ones. Tell the agent its run ends when they pass, not when it feels done.
- Box it in. Sandbox, no network, read-only access to everything that matters, output as a PR or a separate folder.
- Add one targeted reviewer. A different model with one job, such as “find security problems in this diff.”
- Read the diff. Especially anything touching login, passwords, payments, or personal data.
- Before any big task, say “grill me.” Let it ask 30 questions. You’ll get a better result than from any prompt you could write alone.
Do that a few times and you’ll have the beginnings of a software factory. Then you can argue about the lights.
๐ฌ Comments