How I work with AI

Everything on this site, and the way I work, is built with AI as a pair. That phrase gets used loosely, so here is what it means for me in practice: what I keep, what I hand over, and what catches the mistakes.

What stays with me

• The architecture and the data model. I decide what the system is before anything is generated.
• The scope. Every change starts as a short written brief with the constraints spelled out, and the model works inside it.
• The review. I read every diff. Code I don't understand doesn't ship, however clean it looks.
• The decision to ship, and the standard it has to meet.

What I hand to the model

• Implementation inside a scoped step, with the tests written alongside it.
• Refactors under an explicit plan, where the target shape is already decided.
• Migration scripts, boilerplate, and the first draft of documentation.
• Exploring an unfamiliar API or library before I commit to it.
• A second opinion on my own design, to argue against rather than accept.

The gates that catch what I miss

Three bugs AI-assisted code handed me, and what caught them

• A React hook placed after an early return, which mounted the assistant twice on mobile. Caught by a stricter lint configuration, not by reading the code, which is the point of having one.
• Oversized chunks that silently wiped whole embedding syncs, so parts of the site vanished from the assistant's memory without an error. Found during a retrieval audit, and now covered by the retrieval evaluation cases so it cannot come back quietly.
• A reranker that stopped running when a provider key expired, degrading answers with no visible failure. Fixed with provider health checks and a circuit breaker, so the system now says when it is degraded instead of pretending.

What it changes

One person can design, build and run a system with a CMS, a reasoning service, a retrieval layer, a design-token system and an analytics pipeline. That was not realistic for me before. The pace has a cost: it outruns documentation unless the reasoning is written down as you go, which is why every project on this site carries its decisions, its limitations and the things that didn't work.

How this applies beyond this site

The loop is the same whether it's my own system or one at work: scope the change in writing, let the model draft inside that scope, review every line, gate it with tests and evaluation, and measure what changed. The assistants I've built at work follow the same rule I hold myself to: do one job inside an existing workflow, ground every answer, and stay quiet rather than guess.

Ask Alex OS about it

Alex OS, the assistant on this site, was built exactly this way. Ask it how I work with AI and it will answer from this page and the notes behind it, with sources.