The quality of agent written code depends on the work you do before the agent edits a file. I spend real time defining the product, the architecture, the limits, and the proof that will tell me the result works. Then I turn that master plan into phases that an agent can complete and I can review. The model handles more typing. I keep control of the decisions.
My method has four connected parts. A master plan gives the work direction. An agentic layer turns that direction into clear operating instructions. Test driven development gives the agent fast and objective feedback. An indexed LLM Wiki in Obsidian carries useful context from one session to the next. Human validation closes every phase. This structure works across tools, whether I use Hermes Workspace, Codex, Claude Code, or another capable coding agent.
I get the master plan right before I build
A vague idea gives an agent room to make decisions that belong to you. I start by writing the problem in plain language. I define who needs the product, what they need to do, what the system must protect, and what success looks like. I also list the facts I know, the questions I still need to answer, and the parts of the current system that must stay unchanged.
Next, I map the architecture. I name the main parts, the data that moves between them, the external services, and the failure paths. I record design constraints, privacy limits, performance needs, and the tests that will prove the result. The plan does not need to predict every line of code. It needs to settle the choices that shape every later line.
I use an agent during planning, but I do not ask it to own the plan. I ask it to inspect the repository, find existing patterns, expose conflicts, and challenge missing assumptions. Then I review its findings and update the master plan myself. This takes longer than sending one large build prompt. It also prevents hours of repair after an agent commits to the wrong structure.
I translate the plan into phases and clear tasks
A master plan gives the project one direction. A phase plan gives an agent one finish line. I divide the work by dependency, not by how many agents I want to run. A typical sequence covers the foundation, the core behavior, integration, and final product review. Each phase must leave the system in a state I can inspect and test.
Every phase states its goal, allowed scope, task order, inputs, acceptance tests, and stop condition. Each task names the part of the system it owns and the result it must return. I keep tasks small enough for one agent to hold the relevant context without losing the original intent. If a task needs a long explanation of three different systems, I split it again.
This structure also makes parallel work safer. Agents can handle independent tasks at the same time when their files and responsibilities do not overlap. I keep one owner for shared architecture and final integration. More agents do not create more speed when they compete for the same code or make conflicting decisions.
- Give every phase one testable outcome.
- Write the acceptance criteria before implementation starts.
- Assign one owner to every shared part of the code.
- Stop the phase when the evidence is ready for your review.
I build an agentic layer around the codebase
The codebase tells an agent what exists. The agentic layer tells it how to work. I keep a small set of living documents that connect the master plan to daily implementation. They describe the architecture, current phase, coding rules, test commands, design constraints, known risks, decisions, and handoff format.
The top level instruction file acts as a map. It tells the agent which document to read for each kind of task. It does not repeat the whole project history. The current phase document contains the active work. A decision log records choices that later agents must preserve. A handoff file explains the exact state of the work. This hierarchy keeps stable rules separate from temporary task notes.
I refine these documents when a failure exposes a weak instruction. If an agent keeps touching files outside scope, I make the boundary explicit. If a reviewer cannot reproduce a check, I define the command and expected result. The agentic layer improves through use. It becomes a practical operating system for the project, not a pile of prompts.
I use an indexed LLM Wiki as selective memory
A new agent session starts without the reasoning that shaped earlier decisions. Pasting the full project history into every prompt wastes tokens and hides the useful facts inside noise. I solve that problem with an LLM Wiki stored as plain Markdown in Obsidian.
The vault holds durable knowledge. It contains architecture notes, product rules, research, decisions, useful code patterns, known failures, and validated solutions. An index lists each note with a short description and links related topics. The agent reads the index first, selects the few pages that match the task, and follows links only when it needs more detail. It gets the right context without loading the whole vault.
I keep raw sources separate from the wiki and mark validated claims clearly. After a phase passes review, the agent updates only the notes affected by that work. I check important changes before they become shared memory. This prevents one weak summary from spreading across later sessions. Obsidian gives me a readable view of the same knowledge graph that the agents use.
“The wiki is a persistent, compounding artifact.”
Andrej Karpathy, LLM Wiki
I use test driven development as the agent loop
Test driven development turns a requirement into feedback an agent can act on. Before the implementation starts, I define the next behavior as a test and confirm that the test fails for the right reason. The agent writes the smallest change that makes it pass. Then it refactors while the tests protect the behavior.
This loop narrows the agent task. The model does not have to guess what done means because the test states the contract. A failure returns concrete evidence and sends the agent back to a specific problem. Small red, green, and refactor cycles also produce changes that I can review without reading a huge diff.
Tests do not replace judgment. An agent can write a weak test that approves its own mistake. I review the test names, inputs, edge cases, and expected behavior before I trust the implementation. I also keep product checks beside code checks. A passing unit test does not prove that a mobile layout works, that a workflow feels clear, or that the feature solves the right problem.
I close every handoff with human validation
A useful handoff lets the next person understand the state of the work without replaying the whole session. I require a short report that lists what changed, which tasks finished, which tests ran, what evidence passed, what remains open, and which wiki pages need an update. The agent also records any decision that affects later phases.
Then I validate the phase myself. I review the diff, run the relevant checks, open the product, and compare the result with the phase plan. I reject work that passes technical checks but misses the product intent. I approve the next phase only after the current one meets its acceptance criteria.
This human gate keeps small errors from becoming architecture. It also creates a clean handoff to a fresh agent. The new agent reads the master plan, the current phase, the latest handoff, and the indexed wiki pages named for its task. It starts with focused context and a verified baseline. I explain the wider control model in How I Keep AI Agents Accountable.
The loop I keep
My method follows one repeatable loop. Plan the system. Break the plan into phases. Give each task a clear contract. Load only the context that changes the work. Write the test. Let the agent implement and check the result. Review the handoff yourself. Update the project memory after validation. Then start the next phase.
This process asks more from you than a clever prompt. You must make decisions, maintain the knowledge layer, inspect evidence, and stop weak work before it spreads. In return, your agents spend less time guessing and more time completing useful work. That is how I move quickly without handing product judgment to the model. It is also how I judge whether an AI prototype deserves to become a real product.
