How I Split Work with Agentic Coding Tools: Architect, Reviewer, Agent

Texodus started as a model test. My Prompt Vault repository holds a spec called "Markdown Editor — Tauri 2 Desktop App" in the Hard category: forty-four lines of requirements I use to see what models do with a non-trivial task. One of those runs produced code good enough to be worth finishing. Today it is an editor for macOS, Windows, and Linux that has been through four major versions and a Linux packaging saga with nothing whatsoever to do with AI.

The question I get asked most often is not which tool I use. It is what this looks like over the long run. Here is the answer.

Architect: the spec that is not in the prompt

The public spec is forty-four lines with no section numbers anywhere. Yet the Texodus sources still carry references like these:

// ── Window close confirmation (§4.4) + Tauri drag-drop (§4.1) ──
/* Implements the 3-button flow required by spec §4.4 (Save / Don't Save / Cancel) */
// Debounce rendering (§6.2)

They point at a detailed, numbered specification — it runs to §12.8 — that I wrote myself, using that public prompt as the starting point. This is probably the clearest answer to what the human actually does here: not "ask for a Markdown editor", but turn a page of requirements into a document the code can cite and that you can later check implementation against, line by line.

Those markers are still in the sources four major versions later, and a rule in the agent instructions requires keeping them: "§N.N comments reference the original product spec — keep them intact". A §4.4 next to the unsaved-changes dialog is not decoration. It is an address: it takes a second to find how the behavior was meant to work, instead of reconstructing the intent from the code.

The boundary follows the cost of a mistake

The agent does not get the same freedom everywhere in the codebase. The line is drawn not by type of task but by what an error costs. The Texodus rules mark it in plain text:

services/markdownSanitizer.ts — single source of marked options + the DOMPurify whitelist, shared by live preview and export so sanitization can't drift. A regression here = XSS.

The cold-start race (macOS Opened fires before main exists) is handled in main_window_is_empty — read its comments before touching.

Where a mistake is cheap — layout, refactoring, routine changes — the agent works on its own. Where it is expensive — the sanitizer, cryptography, saving files — the freedom ends.

The rules file is an archive of mistakes already made

The most useful thing I have learned from all of this: agent instructions consist almost entirely of prohibitions, and every prohibition is the trace of something that once broke. Not an abstract style guide — a list of expensive lessons written in the imperative.

From Kivarion, my password manager:

onDragOver must decide with isEntryDrag, never with getData: the drag data store is in protected mode for the whole drag, so getData returns '' there — which is exactly how entry→group drag came to be silently dead.

Do not move it back into the webview, and do not reintroduce argon2-browser.

The second rule comes with a full paragraph of reasoning: the WASM call is synchronous no matter what the promise looks like, and kdbxweb re-derives the key on every save — so the interface froze for the length of the KDF on every auto-save.

From Texodus:

AppState.pending_files is a queue per window label — several "Open With" files can target one window before the frontend drains; don't collapse it back to a single slot.

Every one of these lines was written after something went wrong. Their value is that they stop anyone from returning to the "simpler" solution that already turned out to be the wrong one — the agent, and me six months later.

Reviewer: I look at everything, I read selectively

I go through every diff. But I do not read all of it closely — only the parts that touch critical and important code. That is the only honest way to work at the speed agents give you: reading every line would eat the entire gain, and reading nothing means eventually shipping a regression in the sanitizer.

So the other half of review is automated. The rules contain a one-line gate:

Run typecheck + test + lint before declaring frontend work done.

Work is not done until those three commands pass. The tests cover exactly the dangerous places — the sanitizer is tested for stripping XSS, and the rules even record why the test environment is jsdom rather than happy-dom: happy-dom's parser mishandles siblings after a <script>, which would have made the test useless.

This is a system, not one project's setup

CLAUDE.md lives in many of my repositories. In Texodus and Kivarion an AGENTS.md sits next to it — I work with two agents in parallel, and each one needs its own file carrying the same knowledge about the project. Those files never reach the public repositories: they are in .gitignore and stay local.

Rules pay off best where things break quietly. For example, the CLAUDE.md for this site records that routes are linked by name, so renaming one silently breaks both the links and the active-menu highlight, and that the sitemap generator parses the routes file with a regex — which is why the one-line route format must not be touched. Neither tests nor reading a diff catches that.

Where it breaks: the line between JS and Rust

The most expensive problem I have hit was not code quality. It was that the agent has no memory between sessions.

In a Tauri app, almost every task has two places it could be solved: the JavaScript frontend or the Rust backend. The agent kept getting this wrong — and it decided differently in different sessions and different tasks. Not because the choices were bad: each individual one was defensible. The problem is that every new session starts from zero, so any decision not written down in the project gets made again, differently. Architecture does not drift because of one big mistake. It drifts because of a dozen small ones, each perfectly reasonable on its own.

There is exactly one cure: draw the boundary explicitly, in writing. In Texodus the rules list all five Rust commands and state what belongs to the backend and what to the frontend. In Kivarion the line is drawn harder, with the price attached:

KDBX 4's KDF runs in the backend, not the webview. […] Do not move it back into the webview.

The frontend has no direct filesystem access; saveDatabase serializes the db and calls the Rust save_database command.

Which closes the loop on the archive of mistakes: the rules I quoted earlier exist because of exactly this problem. The agent does not remember architectural decisions. The repository does.

What it comes down to

The split is simple. I own the spec, the boundaries — both trust and architectural — and the critical parts of the code. The agent owns the volume of work inside those boundaries. Tests and the linter make sure I never have to take its word for it.

All of it reduces to one principle. An agent has no memory between sessions, so the project's memory has to live in the project: a numbered spec the code can cite, and a rules file that grows out of every expensive mistake. Whatever is not written down will be decided again — and differently next time.

How I pick models for this kind of work, and why I do not trust leaderboards, is on the AI page and in Prompt Vault.