More code than ever. Who has read it?

“

Your team has been working with AI coding tools for months. Tickets close faster, and the codebase is growing at a pace it never has before. Ask in your next meeting who read the last big change line by line, and if the answer is a shrug, you already know the problem.

An AI tool writes what it is told and guesses the rest. Without fixed rules it guesses a little differently every day, while everyone on the team gives it slightly different instructions. That is how a codebase now turns into legacy at the same speed it grows.

I set up the guardrails that let your team keep its pace and still understand the code it ships.

”

Guardrails for your team

I start by looking at how your team works today: which tools are in use, and what ends up in the codebase without anyone checking it. From that I build guardrails out of three parts, which together are usually called a harness.

Rules: Architecture, naming and the shortcuts nobody should take are written down in files that the tool reads with every task. That gives everyone on the team the same instructions, although the model can still overlook a rule.

Skills: Recurring tasks get a fixed workflow: implement, check, hand over. The steps always run in the same order, whoever on the team starts them, and once a workflow is in place the whole team can use it.

Hooks: Gates trigger on their own at fixed points, for example after every change, and they work whether or not the model remembers a rule. If the tool tries to push code that doesn't compile, the gate stops it.

A rule is something the model is asked to follow. A gate is something it cannot get past, which is why anything that must never happen belongs in a gate.

Tests before anything is accepted: Every change runs against automated tests before anyone accepts it. The AI usually writes those tests too, so a person decides whether they test the right thing. Where tests are still missing, I start with the places where a bug would cost you the most.

Reviews against your rules: After every task, an automated review checks the latest changes against your rules and reports where the tool deviated from them. A person then goes through the change, which is kept small enough to read in one sitting.

Documentation that keeps up: After every change, a fixed workflow compares the documentation with the code, so what is written down matches what is running.

I build all of this together with your team, so everyone understands why a rule or a gate is there and can adjust it when the code changes. → Link to Knowledge Transfer

All of this costs some of the speed that AI gives you. It writes code and tests quickly, but a person still has to read both. What remains is speed you can still rely on a year from now.

When this is worth it, and when it isn't

If your team is one or two people who mostly use AI to complete lines of code, you don't need me for this. A file with a few rules is enough, and you can write it yourself.

How does your team work with AI today? That is where we start.

Let's get in touch!