Process / Verification / Control
AI is part of my development process. It is not the thing making decisions. I use different models for research, implementation, and review — and no model gets final approval on its own work. Everything runs through tests, review, and a human decision before it reaches production.
Below is the actual process, the controls on it, and what I won't hand to a model.
This is the whole page in one section. Everything below is the mechanism that makes it true.
Code ships when tests pass and I've read it. “The model was confident” is not a state I can debug at 2am.
The model that writes an implementation shares the assumptions that produced it. When independent review is practical, a different model reviews the work cold, and I read both. Reviews can be wrong too.
Models reproduce plausible-sounding guidance that may be outdated, incomplete, or unsupported. Factual claims in my technical work trace back to sources I actually opened and checked.
Tests, lint, build checks, browser inspection, and runtime verification. AI-generated work gets no benefit of the doubt for being fast.
Version controlled, deployed on purpose, and recoverable through the repository and deployment process. Nothing should reach a live project simply because a model suggested it.
If a model is wrong and nobody catches it, that's not the model's failure. It's mine.
One loop, seven stages. The two that matter most are the ones many AI workflows skip: an independent review pass, and an explicit human decision before deploy.
Requirements, constraints, and architecture are decided before implementation begins. If the requirements are ambiguous, that gets resolved with the client rather than guessed at by a model. Many bad AI-assisted builds fail here, not in the code.
Models help surface approaches, questions, and sources to investigate. Claims are then checked against primary documentation where accuracy matters. The model can point at the source. It is not the source.
Repository-level implementation with AI assistance where useful, under version control from the beginning. I read what gets written. Code I don't understand does not belong in the project.
Automated tests, lint and build checks, browser inspection, API checks, and runtime verification. Lighthouse and Search Console are used where they are relevant to the work.
When appropriate, a different model reviews the implementation without relying on the same context that produced it. The goal is to surface security issues, edge cases, and hidden assumptions. I read the review; I do not blindly execute it.
Mine. The work ships, gets revised, or gets rejected. This decision is never delegated to a model.
Deployment is deliberate, followed by production validation. Logs, analytics, Search Console, bug reports, and real usage feed the next iteration.
The roles are stable. The specific tools change constantly, so treat the names as current rather than permanent.
| Role | What it's for | Current fit |
|---|---|---|
| Research and synthesis | Gathering approaches, surfacing questions, identifying primary sources to inspect | ChatGPT, Gemini, Kimi, Claude |
| Repository implementation | Codebase-level changes with project context | Claude Code, Codex |
| Independent review | Reviewing work it did not write for security issues, edge cases, and assumptions | A model other than the implementation model |
| Long-context gathering | Large document sets and deep research passes | Gemini, Kimi, Claude |
| Version control | History, review, rollback, and a record of what changed | Git, GitHub |
Currently: ChatGPT, Claude / Claude Code, Codex, Gemini, Kimi, Git and GitHub.
Last updated: August 17, 2026.
No model is best at everything, and the useful differences change quickly. Being able to move between tools — and knowing where each one needs verification — matters more than picking a favorite.
The process matters because it catches things. These are examples from real projects. More project context is available under Work.
Public-interest resource navigation
A review of the application found that an AI-facing database-context path did not apply the same public-resource visibility rules used by the public API. The assistant could have had perfectly written safety instructions and still been working from the wrong resource set. The fix belonged in the data path, not in another prompt.
Prompt safety does not repair application logic.Affiliate product discovery platform
Phase 2 testing exposed that the legacy /budget/under100 route led to the $100+ premium experience instead of the under-$100 catalog. Left alone, it would have sent users and crawlers to the opposite price category. The fix moved the mapping into the shared public-route taxonomy, redirected to /sunglasses/under-100, and enforced it with unit and browser tests.
Primary-source technical research
Primary-source verification found that commonly repeated guidance about online and hybrid Event markup no longer matched Google's current Event documentation. Schema.org still defined the vocabulary, while Google's Event guidance had changed. Relying on generated summaries or older articles would have collapsed those two standards into one.
A valid Schema.org property is not automatically a currently supported Google Event feature.AI permission and execution controls
The system is designed on the assumption that model output is untrusted. A model cannot grant itself permissions or switch execution modes. Tool requests pass through validation, authorization, scoped resources, approval controls, an execution broker, sanitization, and audit layers before execution.
The model is not the authorization layer.Worth noting what the last one is: I build the guardrails, not just work inside them.
The right column is where projects actually succeed or fail. The left column is where a lot of the time goes. That's the trade.
Three questions clients should be able to ask plainly.
I do not put passwords, API keys, private credentials, or unnecessary personal data into prompts. Client code may be processed by development tools when AI-assisted repository work is part of the agreed workflow, but the scope should match the project and the client's requirements. Sensitive data, credentials, production secrets, and information that does not need to be there stay out.
If your project has contractual, privacy, regulatory, or internal restrictions on AI-assisted tooling, tell me before work begins and I will work within them.
You do. Project code, content, documentation, and configuration belong in your project and repository. The goal is not to make your business dependent on me or on whichever AI tool happened to be useful during development.
Then I don't use it. Tell me before the work begins and I'll scope the project around that requirement. It may change the timeline or price, and I'll make that difference clear before you commit.
Speed / With control
It isn't that AI writes code for me. It's that I can move between research, implementation, testing, and revision much faster while still understanding and controlling the system I'm building.
You get the speed. The judgment stays where it belongs. Start a conversation