GUARDRAILS · 5 DAYS · €4,000 EXCL. VAT

Putting the guardrails in: code, deployment, AI agents

Your teams develop with AI assistants. Code comes out faster than before, and you have no way of knowing that a project rule has been breached — until a release reveals it.

Who it is for

Technical director or team lead whose developers work with AI tools.

The principle

An instruction written in a document gets forgotten — especially at two in the morning, before an urgent fix. A rule verified by machine reminds you on its own, on every change. That is all I do here: turn your instructions into automatic checks.

Ce que je fais

Five days. We first write down your invariants, meaning what your system must guarantee in all circumstances — phrased from your real incidents rather than from general recommendations. I then make them verifiable by machine.

  1. 01

    Boundaries the code can no longer cross

    Rules that refuse to let one part of the code call another it has no right to call.

  2. 02

    Contracts checked again on every integration

    Between your software components, so a change on one side does not silently break the other.

  3. 03

    A deployment able to go back

    To an identified version, without improvisation.

  4. 04

    Agent documentation

    A document your AI tools read before acting on your repository: what they are allowed to do, what they are not allowed to read, and what must be refused them.

What you receive

  • The apparatus in place and proven on your code
  • Each rule delivered with the case that makes it fail — a rule never seen to say no is not a rule
  • The documentation that lets your team extend it without me

The scope

Guardrails go on the architecture you have. If it has to change, that is a separate engagement, and I tell you in the first days rather than spreading it over five.

Après

The architecture engagement, when what needs protecting does not exist yet.

The questions I get asked

Will this slow my developers down?

At first, a little: a rule that has never been verified is breached somewhere, and those places all surface at once. That is the visible part, and it is short. After that, the question is no longer that one: it is who discovers the problem — the machine, at the moment the code is written, or your customer, after a release. A guardrail does nothing but move that discovery.

We already have tests and code review.

Those are two devices that verify the code does what is expected. Neither verifies that a separation between two parts of the system has not been crossed, nor that what two services had agreed to exchange has changed without warning. A tired code review on a Friday evening lets through what a test always refuses. Guardrails replace neither tests nor review: they cover what neither of them looks at.

What if the team works around the rules?

Then the rule was a bad one, and that is information. A guardrail is switched off deliberately, with a trace and a reason — never by oversight and never in silence. The difference between the two is the whole value of the apparatus.