AI workflow
How I build with AI
I build with Claude Code. It drafts the code and the tests; I own the architecture, review every change, and nothing merges until the tests pass. You get working increments sooner, with more tests and documentation than a hand-typed codebase usually gets.
The loop
Four steps, split between me and the agent
01
Rules written down
- Me
- Architecture, patterns and the definition of done go into the repo, where the agent reads them.
- Claude Code
- Works inside those rules on every change.
02
Plan before code
- Me
- Approve or change the approach before anything is written.
- Claude Code
- Proposes the plan, the files to touch and the edge cases.
03
Build behind a gate
- Me
- Steer in small steps: one screen, one branch, one pull request.
- Claude Code
- Writes the code and the tests, which must pass before a pull request opens.
04
Review and ship
- Me
- Read every line, test in real browsers and devices, then merge.
- Claude Code
- Drafts the pull request description and keeps the docs current.
Guardrails
What stays the same with or without AI
Only with your OK
AI touches your code only if you agree, and only with the tools you approve.
Every line reviewed
I read and answer for every change before it merges.
Tests gate every change
Nothing merges with a failing test.
Your repo, your process
The rules and skills live in your repository, so your team keeps them.

Worked example
Mousike
Mousike is a music event booking platform, in production. I built the Flutter web frontend; the backend is a colleague's Django API. Google Antigravity from February, Claude Code from May.
Time to production
An 18-month build, shipped in about six months
- Estimated for the same scope without AI
- 18+ months
- From first commit to production, with AI
- ~6 months

AI used
Tools and models, from the commit history
Tools
- Google Antigravity
- Claude Code
Models
- Claude Sonnet 4.6
- Claude Opus 4.6
- Claude Opus 4.7
- Claude Opus 4.8
- Claude Fable 5
- Claude Opus 5
Set-up
What is in the repository
CLAUDE.md and ARCHITECTURE.md
The layers, error handling, dependency wiring and component naming, written once so every change follows them.
A custom responsive-design skill
Teaches the agent how the Figma tablet (744) and mobile (390) artboards map onto the app, without moving the existing breakpoints.
One screen, one branch, one pull request
The agent runs the tests before it opens a pull request; I review and merge.
CI deploys every merge
GitHub Actions builds the WebAssembly release and ships it to AWS S3 and CloudFront.
Who does what
The split on this project
Me
- The architecture and the rules the agent follows
- Scope, plans and trade-offs
- Reviewing and merging every pull request
- Testing in real browsers and on devices
- Working with the client and the backend engineer
Claude Code
- Drafting screens from Figma inside those rules
- Writing unit and widget tests
- Wiring API endpoints, DTOs and mappers
- First-pass debugging and refactors
- Pull request descriptions and commit messages