A plan before code#
Most AI-assisted projects start by asking an agent to write code. Nodal started by asking agents to write a plan. The planning lives in Markdown files organized as “pages”, a name borrowed from the way the owner keeps several AI chat tabs open at once. Each page holds a set of agents with a role, a prompt, a required reading list and a handoff format, and each agent’s job is narrow: product architect, technical architect, adversarial reviewer, UI planner, builder, documentation keeper, milestone judge. The owner describes it as about five pages, each with five to eight agents and their tasks, slowly developing the app.
That description matches the repository closely. The role files define four named pages: Planning, Review and prototype plan, Build and Management. The September provider and IdeaBoard program, authorized by a numbered decision, then ran as a further stage with batches of its own, which is how the count reaches about five. The history page places each of these on the calendar.
The pages and the roles#
Page 1: Planning#
A ChatGPT product architect, a Claude technical architect, a Codex independent reviewer, then a cross-check and a final Claude review before a human approval. Output: what Nodal is, what it must protect and which direction to build.
Page 2: Review and prototype plan#
Eight agents: a prototype planner, a UI and UX planner, a technical planner, an independent reviewer, a general readiness review, a proposed build order, a build-ready packet review and, last, the human owner’s build gate.
Page 3: Build#
A controlling chain of eight roles, including a prototype builder, a UI and UX builder and a session and simulator integration builder, each implementing one milestone at a time.
Page 4: Management#
A milestone manager, a documentation and status keeper, a milestone judge, a management review and a review of that review, to keep the record honest and decide what is next.
The same set of rules sits across all of them. Agents read a short start guide first, then only the files their role requires. Every agent ends with the same handoff format, so the next agent starts from a clear statement of what was done, what was decided, what is open and what to read next. Agents are told to treat the repository as the source of truth and the human as the final authority.
Why mix ChatGPT, Claude and Codex#
The process deliberately uses different models in adjacent roles. The point is not that one is better. It is that two models are less likely to share the same blind spot, and a reviewer who did not write the plan has no reason to defend it. The owner went further at the start and asked both Claude and Codex to write an initial plan independently, with the same input, specifically so the two could be compared to see which was better. Both of those plans are kept in the repository. Interestingly, both leaned toward keeping the old WPF and .NET stack. The move to Electron came later, from a researched comparison with a written decision, so the initial plans were useful as a starting point rather than as the answer.
The reviewers have an unusual brief. The Independent Architecture Reviewer is told to assume the product architect and the technical architect may be wrong and to look for incorrect assumptions, unnecessary complexity and hidden coupling. The Milestone Judge may only judge against documented criteria and evidence, classifying each criterion as pass, fail, blocked or unknown, and separating defects from preferences.
One ledger for decisions#
There is one active decision ledger, and new decisions are added only there. More than 140 numbered decisions are recorded, from the choice of Electron to the beta release. A few principles keep the record usable:
- Do not copy a decision into several ledgers.
- Do not change a major decision without a dated decision record.
- Do not claim a test passed without evidence.
- Archived files are evidence, not current authority, and completed raw records are archived only after a confirmed summary exists.
- Preserve rejected and deferred ideas when they explain current scope. The ideas file marks each one as addressed, partly addressed, open, deferred or later scope.
The project also keeps a naming table, because the app renames itself faster than the records do. ToolTabv2 and Nodal are the same product, ToolTab v1 is the old Windows app, the plugin system is NodalForge, the status window is NodalBeeper and the voice app is NodalVoice. The records were deliberately not rewritten when the name changed: they carry approved decisions, and a mass rename would edit every one of them.
Evidence, not assertion#
Every delivered package has a dated evidence folder: the exact commands, the results, screenshots and a hash manifest. Real and fake evidence stay strictly apart. A fake provider can prove how the adapter handles a failure but never upgrades a claim to verified-live, and a test asserts that. Many of the best findings came from running the app rather than reading the tests. One packaged run showed a second copy of the application launching and every request timing out into a plausible, wrong answer. Another found 210 terminal windows being shown as conversations. A hand test found that closing one window killed other windows’ shells. Each is recorded with its fix and its lesson.
Milestones are closed by explicit approval, never by an agent declaring itself done. The human owner tests builds personally and the results go back into the ledger: after one test the owner called Agent Mode “barely working” because the model could not be chosen, and the next decision added the live model picker and the five permission modes.
Lanes, workers and who does what#
From late September the staffing is written in the repository’s coordination file. The Claude lane is led by an Opus-class orchestrator and reviewer for host, provider, security, lifecycle and integration work, with Sonnet-class workers for bounded UI, fixtures, focused tests and documentation. The ChatGPT lane, when the owner uses it, uses a model called Sol as orchestrator and one called Luna as worker. A third, Astra, is recorded as not used. Shared host files have one owner at a time and worker tasks stay narrow.
Work happens in separate working copies, one per package, on named branches, so two agents never edit the same checkout. Integration happens on a separate review branch. Agents never reset, clean or switch another agent’s checkout. In the September program, the ChatGPT lane built the right-panel terminal, the shared browser, the file explorer and the mode and status line, while the Claude lane built the Claude and Ollama adapters, review, completed-turn disclosure and settings, and each package stopped for the owner’s review before it merged.
Coordination between agents: AgentBoard#
When several agents work in parallel, they need to talk. Nodal’s own development uses AgentBoard, the file-based message board, under short rules: join once per session, post a short claim when a prompt starts, post again for a blocker or a handoff, take a named lock before a shared build, a full end-to-end run, an installation, a hosted CI run or an update of the main branch, and release it as soon as the operation ends. Board posts report state; they never override repository instructions or the owner’s decisions.
Cost discipline#
Hosted CI minutes are metered for the private repository, so routine validation runs locally. Related tests run during development; the full suite runs when the risk requires it; the hosted run is a manual final gate used once when a branch is ready, and never rerun until a failure is understood. Related changes are batched instead of pushing every small commit. The same attitude applies to AI usage: the board’s empty check costs about 15 tokens, and benchmark runs, covered on the benchmarks page, measure tokens as carefully as quality.
Where the ideas come from#
The owner captures ideas in a separate board, IdeaBoard, tags them with a project, has an AI organize raw notes into numbered ideas and then selects which to plan. An agent turns the chosen ideas into a plan inside Nodal’s own documents. In September, ideas 1 to 5 and 7 to 9 from that board became five packages: a multi-tab right panel, project artifacts and file previews, a read-only Review tab, completed-turn disclosure and close-source rules with live shutdown progress.
What this process is good and bad at#
Honesty requires a balance sheet. The process is good at catching misunderstandings before they become code, at keeping a consistent record and at letting several agents work without colliding. It is expensive in documents, and it needs a patient human who is willing to say no. It produces a lot of text, and the text sometimes goes stale: the project keeps a start guide whose first job is to say which older statements are superseded. And as the next page admits, ideas are cheap in this era. The process is how the owner turns cheap ideas into a finished product, and it happens on a livestream, so you can watch it happen and judge for yourself.