How we use AI — and the checks that keep it from going wrong
Everyone says AI speeds up development. Almost nobody shows the checks that stop that speed costing quality. Here is how ours are set up.
How we use AI — and the checks that keep it from going wrong
The claim everyone makes
That AI speeds up development is now asserted everywhere. What is rarely included is which checks stop that speed from costing quality — and that is exactly where a client is rightly sceptical. Research by the University of Melbourne and KPMG (May 2025) found that a third of Dutch people are willing to trust AI, against 46 percent worldwide. That concern is not irrational. It can only be answered with evidence rather than a promise.
Below is how ours is set up: what AI does, what it does not, and which gates every change must pass before anything reaches production.
Where AI sits in our process
We use Anthropic's Claude as a fixed part of the development process. In practice it appears in four places:
- Code review — a second pair of eyes on every change, consistently attentive to consistency and edge cases.
- Writing tests — the part that is first to be dropped under time pressure, and precisely the part that determines whether someone else can take your software over.
- Large refactors — mechanical changes across dozens of files, where people make mistakes through repetition.
- Documentation — recording what was built and why, so it does not stay in someone's head.
The gates every change must pass
This is the part that genuinely matters, and the part you can verify. Before anything reaches production, these four checks must pass — automatically, on every change, without exception:
- The full test suite. For this website that is over a thousand automated tests.
- Static analysis, catching faults that would otherwise surface only on particular input.
- A style check, keeping the code readable for whoever looks at it after us.
- A syntax check across the entire codebase.
If one fails, nothing ships. That applies whether or not a change involved AI — and that is the whole point. The gates do not ask where the code came from.
On other projects the bar is higher where needed: at Dit Petje, where one codebase serves three brands, the count stands at 1,693 tests with static analysis across 439 files.
What AI does not do
Architectural choices, deciding which problem to solve first, and the conversation with you: that remains human work. Every line of code that reaches production has been reviewed by an experienced developer. AI proposes; we decide and carry the responsibility.
Equally important is what does not go in. Client-confidential data stays out of AI contexts — no production databases, no access keys, no personal data. Where a specific case is unclear, we agree it with you beforehand rather than afterwards.
What this does not claim
We do not present AI as a way to be cheaper. The effect shows in lead time and in actually finishing work that otherwise slides — tests, documentation, cleanup. Anyone promising that AI halves your costs is selling something other than what we describe here.
And honestly about the limit: AI sometimes produces code that looks correct and is not. That is not an edge case but a property of the tool. It is precisely why the gates above exist, and precisely why everything is reviewed. The tool is fast; the checking around it is what makes it usable.
Share this article
Curious what is possible?
One conversation is usually enough to tell whether it fits. A reply within 24 hours, and no middlemen.