HOW I BUILD
What happens between “I have an idea” and working software in an account you control. This is the sequence I follow when I build with AI coding tools, written for the person commissioning the work.
THE SHORT VERSION
AI coding tools can write software fast. What they can’t know is what your business means by “key account”, which exceptions matter, or what “done” looks like for you. So the first six steps below get those answers written down, and only the seventh starts building.
Each step ends with the same instruction to the AI: ask clarifying questions until nothing is ambiguous. Each step also adds to a decisions file. By the time code is written, you can see every choice we made, the question it answered, and why.
I adapted this from a workflow published by Edwin Vermeer, a Dutch developer who used it to ship a mobile game in about four weeks of evenings and weekends. His version is written for developers. This one is written for you. The credits are at the bottom of the page.
You describe what you want in plain language. A paragraph is enough. No specification, no technical detail, and no decisions about how it should work yet. The point is to record the intent and the reason behind it.
WHAT YOU GETA short written brief, in your own words, that everything else refers back to.
The AI restates the goal, lists its assumptions and the things it doesn’t know, and asks questions until the goal and the constraints are clear. I sit on your side of this conversation. Most projects that go wrong go wrong here, long before any code, so this step is allowed to take time.
WHAT YOU GETA clarified brief and the first entries in the decisions file.
Where there is more than one sensible way to build it, we look at several. Simple or flexible. Connect to the existing system or replace it. A person approves every step, or only the exceptions. We pick a direction on purpose.
WHAT YOU GETA short brainstorm document and a chosen approach, recorded in the decisions file.
The chosen direction becomes a specification: what it does, what it deliberately doesn’t do, what data it uses and who owns it, and the acceptance criteria that will decide whether it works. Written so you can read it and correct anything I assumed.
WHAT YOU GETThe specification, with acceptance criteria you signed off.
The spec is split into tickets: small, ordered pieces of work that can each be built, tested, and reviewed on their own. You can see what is done, what is next, and what depends on what.
WHAT YOU GETA numbered list of tickets, each with its own acceptance criteria.
Before any code, the spec and tickets are reviewed from several angles: an architect’s view of how the pieces fit, a security view of access and data, and a product view of whether this is what you actually asked for. Concerns go back into the spec. After a big change, we review again.
WHAT YOU GETA written review and an updated spec, so the expensive mistakes are caught on paper.
One ticket at a time. Tests are written first, the code is written to pass them, the result is reviewed, and the ticket is committed before the next one starts. You see working versions as the project takes shape, and we check every acceptance criterion before calling it done.
WHAT YOU GETWorking software in accounts you control, a test suite, and a decisions file that explains it.
WHAT THIS MEANS FOR YOU
The software is the obvious result. These four are what make it maintainable after I step back.
Every non-obvious choice, the question it answered, and what it cost. It stays with the project and with you. Whoever picks the work up later starts from the answers.
Tickets make the work legible. You can see what is built, what is next, and what is waiting on a decision from you.
The architecture, security, and product reviews happen before code exists, where a change costs a conversation.
The result lives in accounts you control, with the tests and the documentation. Handover is part of the build.
WHERE AI SITS
The AI does the typing: it drafts the spec, splits the tickets, writes the tests and the code, and reviews its own work. The judgment comes from you and from me: what matters, how it’s calculated, and what should happen next.
Inside the software, the same split holds. Ordinary code handles the calculations, matching, and rules. AI handles the parts that benefit from interpretation, such as reading a document or summarizing a conversation.
What a custom build includesCREDITS AND SOURCES
The sequence is adapted from Edwin Vermeer’s agentic coding workflow, published in his CodingAgentOrchestration guide and used to build Quadrim, an open-source game. His repositories include every prompt he used and a decisions log that ran to several hundred entries.
The steps lean on four open skill packs for Claude Code: Superpowers (brainstorming, test-first development, verification), Matt Pocock’s skills (specs, tickets, implementation, code review), Agency Agents (the architect, security, and product reviewers), and Anthropic’s Knowledge Work plugins.
The adaptation for a business reader, and the “what you get” at each step, are mine.
LET’S TALK
Tell me about it in a few words. Step one is the one above: your idea, in your words.
