How I work with AI
A method for using AI to build faster, with real infrastructure and discipline around every step
I use AI to build faster, not to build blindly. Everything I ship with AI sits on real, production-grade infrastructure, with verification, version control, and documented guardrails around every step. AI is the accelerator, not the foundation.
Most AI-built work is a black box. The output looks fine, sometimes great, but there's no infrastructure underneath, no trail behind it, and no way to know what the AI got right or wrong because nothing was verified. The work runs and then it can't be handed over. I work with AI as a disciplined engineering practice, and these are the five principles that make it one.
The five principles
1. Set up before building
Before any code is written, I source the relevant skills from Claude's skills repository and configure the MCPs to match the stack. Production quality is built in from the first prompt, instead of retrofitted later. The AI's environment is part of the design problem, so I treat it as one.
2. Real infrastructure, not a black box
I build on the stack a serious team actually runs at enterprise level:
- a headless CMS (Strapi)
- database and backend services (Supabase, Render)
- React and Next.js for web, Expo for apps, and
- real end-to-end testing (Playwright, Maestro)
AI accelerates the work on top of that foundation. It doesn't replace the foundation with something generated under the hood that you cross your fingers and hope one-shots correctly.
3. Never accept output blindly
I review everything the AI produces, test thoroughly, and commit often. AI speeds up the work, but it never gets the final say. The judgement about whether something is right stays with me.
4. Persistent memory, so mistakes don't repeat
When a mistake is made and fixed, I document the lesson as a retro, stored in Notion for the team and written into a .md file the AI reads. Before any prompt is actioned, the AI is instructed to review those lessons and the project's .md files, never to assume or guess, and always to defer to official documentation. Lessons compound instead of recurring, and there's far less room for hallucination.
5. Everything tracked and handover-ready
Every milestone and task is tracked in Linear and documented thoroughly. Any teammate, or future me, can pick up the thread without archaeology. The process is built for handover from the start, instead of reconstructed at the end. It also means that when Claude compacts its memory (and it will), it has a source of history to refer back to.
Why it matters
The market is full of people who can prompt a tool. What gets shipped safely takes more:
- the right setup
- verified output
- infrastructure that scales
- and a documented trail behind every decision
That discipline is what makes AI-assisted work safe to ship and safe to hand over. It's the difference between someone a team trusts with the codebase and someone they have to clean up after.
