The biggest difference isn't which AI dev tool you use.
It's how tightly you structure your process, and getting multiple AIs to catch each other's blind spots.
It's been quiet on my end. Mostly because I've had, and still have, a full focus on developing the next application. The most complex one so far. But more on that later.
What I do want to share here is how I build. After a while working with various AI dev tools, one thing has stuck with me most: the biggest difference isn't in the tool itself, but in the discipline around it. That's become the real win for me, and I'll come back to it below.
First the experience, then the method
Through earlier proofs of concept, Snuffl.app, an internal sales pipeline application, AI Dev Tools and a few smaller projects like the Kijklijst app, I've gathered a fair amount of experience with different AI dev tools and tech stacks. What struck me from the start: organisation and process need to be tightly arranged to keep an overview and not fly off in all directions. That was already true before the generative AI era, but you arranged it differently.
My approach follows BMAD (Business Model Agile Delivery), with one core principle: documentation before code.
Every change starts with a requirements document and, when there's an architectural choice, an ADR (Architectural Decision Record) that captures what we build and why. Only then comes the code, in that same order: first the docs commit, then the implementation. That way, not just the result is preserved, but also the reasoning behind it. Agile, but with a paper trail that holds up.
On top of that, automated tests are written for every development to safeguard quality. And I work with a combination of Claude (Cowork & Code) and Codex. Alongside the documents for the platform's various developments, there are also more general documents about approach, lessons, architecture and security. The LLMs use those to get up to speed.
My near-standard approach to a new development
- 1
With Claude Cowork I share my vision for a component to be developed, so Claude can think along, and I gather input where needed to feed it.
- 2
Claude Cowork reads up, starts research, and draws on its data across different angles via sub-agents.
- 3
Claude then comes back with extensive feedback that surprisingly often contains genuinely good ideas I hadn't thought of myself, but that fit perfectly.
- 4
Once the vision is sufficiently thought through and ready for development, I first share it with Claude Code, which takes the lead. Claude Code dives in first and often comes with good input related to the code and to what's been learned from earlier developments, also a document that's maintained.
- 5
After some back-and-forth and agreement, I give the go-ahead to write the requirements document, and an architecture document too if needed.
- 6
Once the documentation is ready, I share it with Codex, with a prompt written by Claude Code, for an extensive review. That often surfaces particular issues that Claude Code (and Fable 5 too, by the way) had overlooked.
- 7
The review goes back to Claude Code, which checks the points against the code, conventions, database and security. Often they're valid. Very often. This is where I feel an enormous gain over working with just one LLM.
- 8
After the changes, another Codex review goes over it to confirm everything was processed correctly. Sometimes more than once. In some cases I flip it: Codex in the lead, Claude Code as reviewer. And you see the same picture, Claude Code still pulls out things Codex missed.
Only with my approval on the documents may building begin, according to the strict rules that are in place. It looks like a lot of preparatory work, and relatively it is: I spend longer on the documentation and on jointly thinking through behaviour and implementation than the LLMs need to write the code.
AIs that catch each other's blind spots
This is the insight I most want to pass on. Whether I put Claude Code or Codex in the lead, the other consistently pulls out things the first one missed. Not occasionally, but structurally. Having two strong models review each other demonstrably produces sharper code than a single model, however good that one is.
In between, I sometimes have Gemini do a full code review. It didn't build along, but it looks over the shoulder on request. And what stands out in those full codebase reviews: all three (Codex, Claude Code, Gemini) reach the same verdict, but Gemini comes back with the fewest points to fix. Codex and Claude Code are much sharper on that. Claude most of all.
What it yields
A codebase that's documented from top to bottom, with these principles as the basis for every development (from the lessons document):
Security and scalability first
Data and compute frugality as a priority when working with data
Reuse over rewrite
UX deserves special attention
Follow existing conventions, solve structurally, no quick fixes
Update documentation with every development; AI reviewers are advisors, not authorities
And this is the verdict Claude Fable 5 delivered after an extensive hour-long code review of this platform:
This is a surprisingly mature pre-launch platform.
The foundation is demonstrably strong: multi-layered tenant isolation, handling of external writes that never masks a partial failure as success, privacy protection before every AI call, strict authentication and a solid CI pipeline. In this review I found no exploitable blocker — no auth bypass, no cross-tenant leak, no data loss.
There are always points that crept in despite the care. And that's precisely the advantage of this way of working: because everything is documented and structured, those points are easy and targeted to resolve.
The prompt I use for a full review
For anyone who wants to try it themselves: this is the full prompt I used for the Claude Fable 5 go-live review, from goal to report structure, translated from the Dutch original. Only the project name and paths have been anonymised.
You are working in the repository: `[path to the repository]` Goal: Produce a read-only, in-depth go-live readiness report for a Product Owner about the platform. Make NO edits, commits, branches or files. Your task is analysis and reporting only. Language: Write the report in Dutch. Technical terms may remain in English. Main instructions: 1. First read `AGENTS.md`, `control/manifest.yaml`, `docs/PROGRESS.md`, `docs/roadmap.md`, `docs/architecture/external-write-register.md`, `docs/architecture/docs-status-governance.md` and `docs/requirements/151-execution-coverage-contract.md`. 2. Then inventory all `.md` files in the repo, excluding `.git`, `node_modules`, build output and dependency folders. Use the documentation to understand what the platform claims to do, what has been released, what the blocked paths are, and which status claims are canonical. 3. Then analyse the actual codebase broadly and deeply: backend, frontend, database/migrations, auth, tenant isolation, external write paths, AI/prompts, sync/jobs, UX flows, tests, CI/CD, configuration, security headers, error handling and operational readiness. 4. Compare documentation claims against the real implementation. Explicitly report stale docs, conflicts, missing substantiation and claims not backed by code. 5. Make no assumptions without evidence. Support concrete findings with `file:line` references. Method: - Work read-only. - Use specialised review passes as if deploying these roles: - Software Engineer - Software Architect - Senior Security Officer - Senior Compliance Officer - UX/UI Expert - If real subagents are available, use them. If not, run the analysis per role separately yourself. - Start with a broad inventory, then move to critical paths. - Pay extra attention to vulnerabilities, privilege escalation, tenant data leaks, auth/session/CSRF/CSP, secret handling, external writes, auditability, RLS, prompt injection, AI boundary controls, dependency/security posture and privacy/compliance risks. - Be critical and independent. Do not give a reassuring conclusion if the evidence is insufficient. - If you cannot verify something, mark it as "not verified" and explain what would be needed to verify it. Key angles: - Security - Scalability - Architecture and overall setup - Legal / compliance readiness - Optimal UX - Go-live readiness - Operational manageability - Test and CI maturity - Data integrity and tenant isolation - External write risks - AI/LLM risks and prompt governance Output: Produce a report for a Product Owner with technical appendices. Report structure: # Go-Live Readiness Report ## 1. Executive Summary - Overall impression - Go-live advice: Go / No-Go / Conditional Go - Key risks - Key strengths - Top 10 actions before go-live ## 2. Readiness Scorecard Give scores 1-5 with brief substantiation for: - Product maturity - Code quality - Architecture - Security - Privacy/compliance - Scalability - UX/UI - Observability/operations - Test coverage - Documentation reliability ## 3. Key Findings Order by severity: - Blocker - High - Medium - Low - Observation Per finding: - Title - Severity - Role(s) involved - Impact - Evidence with `file:line` - Why this matters for go-live - Recommended fix - Any test/validation needed ## 4. Analysis Per Role ### 4.1 Software Engineer Assess code quality, maintainability, error handling, tests, dependency management, CI, typing, backend/frontend consistency. ### 4.2 Software Architect Assess module boundaries, data flow, multi-tenant architecture, sync/jobs, external write choreography, AI integration, technical debt, scalability and evolvability. ### 4.3 Senior Security Officer Assess auth, JWT/refresh/cookies, CSRF, CSP, RLS, tenant isolation, secrets, external writes, audit logs, SSRF, prompt injection, dependency risk, logging of sensitive data and privilege boundaries. ### 4.4 Senior Compliance Officer Assess GDPR, data minimisation, retention, auditability, consent/legal basis, processor risks, external platform data, AI processing, logging, export/erasure and documentation required for go-live. ### 4.5 UX/UI Expert Assess core flows, error messages, loading/empty/error states, consistency, accessibility, i18n, trust around external writes, demo/read-only signalling, onboarding and go-live-worthy polish. ## 5. Documentation vs Code - Which docs are reliable as a source? - Which docs appear stale or conflicting? - Which claims are not demonstrably implemented? - Which go-live claims are still missing? ## 6. Go-Live Gap Analysis Make a concrete list: - Must fix before live - Should fix soon after live - Can defer - Needs PO decision - Needs legal/security owner decision ## 7. Recommended Roadmap To Go-Live Make a phased plan: - Phase 0: gather evidence / verification - Phase 1: resolve blockers - Phase 2: hardening - Phase 3: pilot/go-live - Phase 4: post-live monitoring ## 8. Residual Blind Spots State explicitly what you still do not know despite the analysis, for example because no staging access, secrets, CI results, production configuration or runtime logs are available. ## 9. Considered-and-Refuted List important risks you investigated but did not confirm, including evidence for why you are not raising them as findings. ## Appendices Add technical appendices with full details: ### Appendix A: Markdown Inventory All relevant `.md` files grouped by type, with brief function and reliability. ### Appendix B: Architecture Map Describe backend, frontend, database, auth, sync, AI, jobs and external writes. ### Appendix C: Security Checklist Detailed checklist with status: OK / Risk / Unknown / N/A. ### Appendix D: Compliance Checklist Detailed checklist with status: OK / Risk / Unknown / N/A. ### Appendix E: UX Flow Review Review of the main user flows and UX risks. ### Appendix F: Test and CI Analysis Which tests exist, which risks they cover, which gaps remain. ### Appendix G: Evidence List All important `file:line` references clearly grouped. Before you start: Ask at most 5 clarifying questions if truly needed. If you can start without answers, note your assumptions and begin the read-only analysis immediately.
The application isn't live yet
But I hope to share and show more before too long. Stay tuned. Want to spar in the meantime about a docs-first AI development process? We're happy to think along.
