Two ways of using AI
There are two ways to bring artificial intelligence into technical work. In the first, you ask it to decide: to propose the architecture, to pick the tools, to establish how things are done. It is fast, and the result is an organisation that works the way a generic model would work, with no identity of its own and no idea why it does what it does.
In the second, people write the rules (standards, conventions, gates, quality criteria) and the AI works inside them: applying them when executing and checking them when reviewing. That is the one we practise.
The double interpretation
A written rule is interpreted twice: when the person writes it and when the AI applies it. Most of the time the two match. When they do not, two very different cases appear:
- Breach: the work does not comply with the rule. It is corrected.
- Discrepancy: the AI understood the rule differently from its author. That is not an AI error: it is an ambiguous rule. The rule is clarified, and next time there will be no doubt.
Over time, that cycle produces something valuable: a set of increasingly precise rules, written in the organisation's own language, that any new person (or any new agent) can apply from day one.
What it takes
- Written rules, not implicit ones. If a rule exists only in somebody's head, the AI can neither apply it nor check it.
- Checkable rules. 'The code should be clean' cannot be validated; 'no secrets in the repository' can.
- A record of discrepancies and somebody to review them.
- The final word for people on everything the rule does not cover.
Closing the series
Software you can audit, a platform treated as a product, phases and gates, specification, template, registry, secrets, status, identical artefacts, comparable environments, automatic validation, traceability, learning from failures and agents working under human rules. It all points to the same thing: that the system keeps working, and can be explained, when whoever built it is no longer watching.
How we apply it: Platform Engineering.