When we talk to customers about AI-assisted development, the first question is usually not a technical one. It is: "So who checks this?" A fair question. In an ERP system, one wrong line of code can come back a month later as an error someone spots in accounting.
In this post we explain how our own way of working answers that question.
Four approval points
In every piece of work we do with Claude, a person stands at four points:
- Analysis approval. Claude studies the request and the existing system and prepares an analysis document. The analyst reads it, corrects it or approves it.
- Code approval. No code is written without the analyst's explicit "start development" approval. This has turned out to be the rule that saves the most time, because it stops us building code on top of a misunderstood request.
- Build, synchronisation and test. These are done by people, in Visual Studio.
- Check-in and go-live. The team decides what goes into source control and what goes live.
On top of these there is one hard rule: there is no write access to production. Claude works in the development environment. Production is only looked at when something needs to be read.
Rules are not remembered, they are enforced
In the first months we wrote our rules down as a document. Then we noticed that a written rule is a rule that gets forgotten on a busy day. That applies to people and to AI alike.
So we built some of the rules into the way the work itself runs. For example:
- A file must be checked out from source control before it is edited.
- Every changed object must be added to the Visual Studio project.
- Every code change must carry a comment.
These checks run automatically in Claude's working environment. If a rule is broken, the work does not move on. That leaves no room for "I forgot".
"Claude + date + reason"
One of the most valuable habits we picked up is this: every code change Claude makes has a one-line comment next to it. Who made it (Claude), when, and why.
New objects that Claude creates also get a separate prefix. So when you look at an object, you can see straight away whether it was created by AI or by a developer.
At first sight this can look like bureaucracy. But a year later, when you are tracing the source of a bug, or an audit asks "who wrote this code?", those lines are very useful. What came from AI and what came from a person stops being a matter of debate.
Where is testing?
Let us be honest here too: testing is not automated on every project. Claude prepares the test scenarios, and on some projects we have automated the user interface tests. But the final word on build and test belongs to the team. We do not have a flow of "AI wrote it, AI tested it, it went live", and we do not want one.
Why so many rules?
Because speed is only worth something together with trust. AI makes us considerably faster in analysis, code and documentation. The way to keep that speed is to know that every step has an owner. That way our customer sleeps well, and so do we.