AI does the heavy lifting. I make the calls.
I use AI agents every day, but I never hand them the keys. Every feature I build goes from my requirements to a written spec, an implementation plan and code, and I review each step, going back and forth until I'm happy with it.
My toolsClaude CodeCursor
I write specs before code. Every feature starts as a specification anyone on the team can read, not a prompt that disappears.
I stay in the loop. I check every spec, plan and change, and send it back until it's right.
I give each job its own agent. Product, architecture, data, development, code review and documentation each get a specialist.
From an idea to production
Solid arrows move the work forward. Dashed arrows are where I send it back. Click a step to see the idea behind it. A feature starts from my requirements; a bug fix starts from triage.
- Next step
- I iterate until I'm satisfied
- I ask for a change
- Knowledge base: read & write
Tap a step to explore it.
Feature
Bug fix
Then continues at the implementation plan.
- Define requirements (My checkpoint): I describe the problem, the users and what success looks like, in plain language: goals, constraints and the edge cases I already know about.
- Feature specification (AI agents): The AI drafts the feature specification. A Product Owner agent covers the business side: user stories, acceptance criteria, scope, and what is explicitly out of scope.
- Validate the spec (My checkpoint): I review the spec and send it back with comments, back and forth until I'm satisfied. Nothing moves to planning until the spec says exactly what I want built.
- Implementation plan (AI agents): The plan turns the spec into code-level decisions. An Architect agent applies the project's existing design patterns for the front end and back end, and a Data Engineer agent defines the data models, constraints and migrations.
- Review the plan (My checkpoint): I challenge the technical choices and iterate on the plan until I'm satisfied. This is where mistakes are cheapest to fix.
- Implementation (AI agents): Developer agents implement the plan in small, tested steps. A Code Reviewer agent checks every change against the plan, the patterns and the tests before I see it.
- Acceptance (My checkpoint): I test the result against the spec. If I'm not happy, I ask for a new implementation, and the change request updates the spec and the plan as well as the code, so the documents never drift from what's built. For a bug fix, the change request goes back to the investigation instead.
- Shipped (Done): Shipped means the code is committed. From here, CI/CD pipelines take over: they test and check the code, then handle the staging environment and production releases. The spec and plan stay with it as living documentation.
- Bug fix: Bug triage (My checkpoint): When the task is a bug, it reaches me already triaged by a person: confirmed, prioritized and with whatever material there is, including how to reproduce it.
- Bug fix: Bug investigation (AI agents): A QA / Product Verification agent reads everything provided, reproduces the bug and runs a Five Whys analysis to find the root cause. It documents the bug and decides whether it's a lesson worth keeping; if it is, the knowledge base learns it so future work avoids it. Then the fix goes to the implementation plan.
- Specs, plans, reviews & decisions (Knowledge base): Every spec, plan, review, validation, decision and bug lesson becomes documentation, as Markdown files in the repo or a RAG index (retrieval-augmented generation). The knowledge is prepared ahead of time, so the right passages are found and handed to the AI with each question, and every feature makes the next one better. I write it for two readers: in full detail for the AI, and short and visual for people to read and validate.
One source of truth, two readers
Everything I approve ends up in the knowledge base, in two forms: in full for the AI, and short and clear for the people who validate it.
For the AI: as detailed as possible
Precise enough that the agents can follow it without guessing.
- Explicit rules and conventions
- Design patterns with examples
- Edge cases and constraints
- Decisions and the reasons behind them
For people: easy to read
Concise enough that I can read and validate it in minutes.
- Short summaries
- Diagrams and visual flows
- Decision tables
- No walls of text
Same knowledge, two views: what the AI follows is always something a person has read and approved.
A living document
This is how I work today, and it works for me. It's not a recipe that will work for everyone. I keep revisiting how I work, looking for ways to do it better, so this page changes with me. If you have a better idea, I'm open to discussing it.
The tools I use
Each one has its own job, and what one produces often feeds the next.
Claude Code
Where I write code, every day. I use Claude on the web for quick questions and to explore ideas, especially when I'm away from my laptop, and Remote Control lets me drive Claude Code from wherever I am.
Want to try Claude? My referral link gives you a free week. Claude referral link (opens in a new tab)
Google Stitch
Where web and app UIs start. I give it the project's specs, branding and colour palette, build the first mockups, and hand them to Claude Code to implement.
ChatGPT
For exploring and checking ideas. With the project's scope, and through MCP, I ask it for branding images and product names, and to weigh the options. What comes out goes back into Claude Code and Stitch.
Gemini
I use it less, much like ChatGPT. Comparing the answers from different tools helps me make better decisions.
Cursor
I used it the way I use Claude Code now. I chose Claude Code to keep costs down.
Codex
I used it inside Xcode, on a SwiftUI project.
Want to compare notes?
This is how I build software with AI today. If you'd like the details, or you work differently and want to swap ideas, let's talk.