How I work with AI
A method for using AI to build faster, with real infrastructure and discipline around every step
AI accelerates the work, on top of real infrastructure
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
The AI starts a project with whatever context it walked in with, usually nothing about your stack, your conventions, or what you're actually building. The first few prompts go out into a vacuum, the AI guesses, and you spend the next week refactoring around the guesses. By the time you wish you'd set it up properly, you're three commits past being able to.
The workspace is part of the design problem. 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.
2. Real infrastructure, not a black box
The AI ships something that looks like it works. Click around the demo, it all renders. Open the hood and there's no real database, no CMS, no test coverage, just a chat log holding the project together. When something breaks, there's nothing to debug, only a prompt to re-run.
AI accelerates the work on top of real infrastructure. It doesn't replace it. 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). The AI works on top of that foundation. Nothing gets generated under the hood that I have to cross my fingers and hope one-shots correctly.
3. Never accept output blindly
AI output is fast and confident, which makes it tempting to skim. The mistakes hide in the parts that look right: a regex that almost matches, a state update that fires once too many times, a function that handles 90% of the cases. By the time the bug surfaces, it's living in three places and the AI doesn't remember writing any of them.
Confidence is something I add to the output. 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
The AI doesn't remember what went wrong last week. It hallucinates in the same places, for the same reasons, every session, and the team waits for the next model release like that'll fix it. It won't.
If the AI can't remember, the system has to. 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
AI sessions don't leave a trail by default. The codebase changes, the prompts are buried in chat history, the decisions live in someone's head, and the version control story is "I committed the working version." When the project changes hands, or you come back to it after three weeks away, the only way to understand what was decided is to re-derive it from the code.
The project carries its own history. 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.
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. Sustaining that discipline takes a design background plus the ability to review the code the AI writes. It's the difference between someone a team trusts with the codebase and someone they have to clean up after.
