The vibe-coding workflow

What “vibe coding” means on this channel

Vibe coding, as the stream descriptions put it, is building software by describing what you want in plain English and steering an AI agent. On The Late Build it is not a magic trick. It is a workflow with roles, rules and paperwork, and it works only to the extent that the paperwork is good. This page describes that workflow as it is actually practiced: two kinds of coding agent working side by side, sub-agents for bounded jobs, a message board for coordination, written handoffs for memory, tests before anything is published and a short list of rules that exist because something once went wrong.

The creator is explicit about being a newcomer: “I’m not a professional developer or an AI expert,” says the description of the first stream. That is useful for a learning audience, because the failures are visible and the fixes are teachable.

Roles: orchestrators, sub-agents and the human

Two orchestrators in one folder

The main work is done by Claude Code and Codex, working in the same folder and often on the same branch at the same time. Each project has a repository file for each agent (a CLAUDE file for one and an AGENTS file for the other, with one pointing at the other), so both receive identical rules. In one project the instruction is blunt: read the handoff file and the original specification before touching anything. The agents share working agreements instead of private memories.

Sub-agents for separable work

For well-scoped, separable jobs the orchestrator spawns sub-agents: a cheaper model for mechanical tasks and a stronger one for hard pieces or reviews, each given its own files. A rule from the project notes is that the orchestrator writes or closely reviews the core code (for example the robot physics in Blunder Blender) and delegates the rest. On another project that involves research and planning, planning delegation uses a high-reasoning mid-tier model by default, a cheaper model for genuinely easy jobs and an expensive top-tier model only after explaining why its contribution is worth the cost, and never for implementation. The principle: spend the strongest model where judgment matters and nowhere else.

The human

The human decides what to build, tests it (often live, on stream) and says yes or no to anything that leaves the machine. Owner confirmation is required before going live, changing a title or thumbnail, posting to chat or social accounts, firing alerts on stream or deleting anything. Permanent deletion is never done by an agent; it can hide or privatize and the owner deletes. Those rules are part of why it is safe to let agents work quickly.

Coordination: a message board, not a chat

When two agents share a repository, they step on each other. The answer built here is AgentBoard, a file-based message board where agents post short notes. Each post, presence record and lock is its own file written only by its author, so simultaneous writes cannot corrupt anything. Agents never read the board directly; they run a small script that prints a few lines, and an empty check costs about 15 tokens, measured. The conventions are short: claim a task at the start of a prompt, post when done, post conflicts and errors, and take a named lock before something exclusive such as running the end-to-end tests, deploying or starting the dev server. Posts are information, not orders: nothing destructive happens because a post asked for it. The approach is explained from the product angle on the Nodal site’s AgentBoard page, and the usage side is shown on the AgentDashboard page.

Memory lives in documents

Agents forget between sessions, so the project has to remember for them.

• Handoff files state where things stand, what to ask next and what to watch for, with the live build identifier. A new session reads it first.
• Runbooks record how things are wired, including every gotcha already hit. The stream’s setup reference, for example, has a section called “don’t rediscover these.”
• Specs hold the original intent so that a later session can tell a bug from a decision.
• Skills hold repeatable procedures, such as the livestream operating checklist or the avatar video pipeline. They are installed once and shared by both agents through a linked folder, and a check script reports whether the two copies are linked, identical or different (and never overwrites on a mismatch).
• Backups before changes. Before a risky update, the old version of the file or configuration is copied aside with a date, and the change report says where.

The practical test of any document is: could a stranger resume the work from it? If not, it is not done.

Checks that do not depend on the model’s word

• Tests first, deploy second. In the robot game, publishing is allowed only through a script that runs after the browser tests and a fuzz script pass, and the deploy is gated on the actual test result, not on a pipe that can swallow a failure.
• Reference implementations. The Game of Life engine is compared against a naive implementation. The netcode in Nodal Strike asserts bit-identical prediction.
• Read the artifact. A model’s description of what it built is not evidence. The benchmarks measure from transcripts and open the files.
• Cheap evidence. A rendered image read from disk costs fewer tokens than a viewport screenshot and is more accurate, as one Blender session found.
• Change reports in a fixed format. Every change ends with the version hash and a list of what changed in the tuning panel and what each change does.

Prompts that work

1. Give the goal and the constraint in the same breath. “Model this spaceship in a low-poly style” with a reference image beats a paragraph of adjectives.
2. Settle the hosting and login constraints before building. A lesson from the usage notes: discover the free-tier limits, the login flow and the deployment target first, because they change the architecture.
3. Prefer free local automation. The same notes favor local tools over paid services whenever the output is good enough.
4. Ask a question when the scene is not clean. One benchmark session burned about 47,000 tokens inspecting an old scene it was later told to ignore.
5. Batch actions. Many small tool calls cost more than a few batched ones, because every call re-reads the context.
6. Keep reply style short. A project can mandate simplified technical English (short sentences, one idea each, the same word for the same thing). It is a surprisingly effective way to keep agent output readable.

Failure modes we keep hitting

• Edits by slicing. Replacing code between two markers with a script once deleted a function and crashed a game profile. Use exact search-and-replace and run tests.
• Stale copies. A desktop app silently ran a cached copy of a plugin, so edits did not show until the version was bumped and the plugin updated.
• Credentials in tool output. An agent can print something it should not. Keep credentials out of files agents read, and replace anything that was exposed.
• Collisions. A different session grabbed a local port that the stream needed. Locks and the board exist for this.
• Silent permission walls. An agent’s stop and start commands were denied by the permission classifier during a stream drop, so the human did the recovery. Decide in advance which actions an agent may take alone.
• Optimizing the wrong thing. Long screenshot-and-patch loops cost seven times the tokens of a thoughtful single pass in one test.

A day in the loop

A typical block of stream time looks like this. The creator states a goal and a constraint in chat, such as adding a feature to a game without breaking its tests. An orchestrator agent reads the handoff file, claims the work on the board, and either does it directly or splits it among sub-agents. Tests and a preview run. The creator looks at the result, often live, and either accepts it, asks for a change or throws it away. The agent updates the handoff and posts that it is done. Then the next block starts from the written state, not from anyone’s memory. Repeat for four hours.

Where the tools come from

This workflow is the reason Nodal exists. Agent Mode gives a Codex-like experience across providers, Tab Mode hosts terminal agents, and the Notification Center lets you answer an agent from anywhere. The history page tells how the original plan, a document with five pages of five to eight agents each, collapsed into a lean product after experience arrived. And the central lesson, that ideas are cheap, applies here too: the leverage is not in the prompt, it is in the loop around it.

To see the loop working, join the livestream, skim the projects or ask a question in Discord.