Adopting AI-assisted engineering without losing the audit trail

Context

Engineers had already adopted AI assistants. Not as a pilot and not by permission: the tools were in editors, in terminals and in review workflows because they were useful, and the practice was some way ahead of anything written down.

An organisation in that position has a choice between two documents. One lists what is forbidden and is written by people who are not doing the work. The other says where the line sits and why, and is written by the people who will have to live on the near side of it. Together with a peer engineering manager I co-authored the second kind: AI-assisted development guidelines for an engineering organisation.

This is the organisational version of a rule I already work to on my own systems, which I set out in Automation that keeps human judgment. The interesting part here is not the rule. It is what it takes to make a rule hold across people who did not write it.

The constraint

Two failure modes, pulling in opposite directions.

The first is the accountability gap. An assistant that can read a codebase, run a suite, open a pull request and push a change is genuinely useful, and it is also an efficient way to lose the record of who decided what. When something goes wrong afterwards, “the tool did it” is not an answer anyone can act on.

The second is the document nobody follows. Guidelines that arrive as an edict get satisfied on paper and worked around in practice, which is the same lesson as the one in From test execution to release confidence: a standard that is announced rather than agreed buys compliance and not behaviour. A rule that engineers consider unreasonable does not stop the activity. It stops the activity being visible.

So the guidelines had to be strict at exactly the points where the audit trail breaks, and permissive everywhere else, and they had to be recognisably written by practitioners rather than issued at them.

My role and decision scope

I co-authored the guidelines with a peer engineering manager and took them through to adoption. Neither of us could impose them. The route to adoption ran through review by other engineering managers and senior engineers and then leadership sign-off, which meant the text had to survive people who were free to refuse it.

What I could decide: what the rules said, which of them were hard guards rather than defaults, and how the rollout was staged. What I could not decide: whether the organisation accepted them. That distinction shaped the drafting more than anything else in the document.

What changed in the system

Three rules carry the weight. A four-eyes principle for production deployments, so nothing reaches production on a single person’s say-so and less still on a tool’s. A secrets and credentials rule, because an assistant that reads a repository reads whatever the repository holds, and the cheapest control is that the material is not there. And human-only pull-request merges: an assistant may draft the change, open it, argue for it and revise it, and a person merges it. Everything else in the guidelines is guidance. Those three are guards.

The rules mark a boundary rather than a technology. They do not enumerate approved tools or models, which would have dated the document within a quarter. They name the actions where a person has to remain answerable, which is stable whatever the tooling turns into next.

The draft was reviewed, repeatedly, by the people it binds. Multiple rounds with four other engineering managers and senior engineers, each round changing the text, before it went for leadership sign-off. That is slower than writing it alone, and it is the reason the guidelines describe recognisable working practice instead of an idea of it. Collaborative authorship is not a courtesy here. It is the mechanism that makes the rules survive contact with a busy week.

Rollout was staged rather than announced. A pre-check with a technical strategy group first, small enough that objections arrived as a conversation, and then the wider organisation in August 2026. The first stage exists to find the sentence that reads clearly to its authors and ambiguously to everyone else.

Evidence and outcome

The evidence here is structural, and only structural. The guidelines exist. They were co-authored, reviewed across several rounds by other engineering managers and senior engineers, signed off by leadership, and adopted organisation-wide.

There is no outcome to report yet, and I am not going to construct one. The rollout completed in August 2026, which is far too recent for anything I could say about its effect to be more than an impression. No adoption figures, no compliance rate, no before and after. When there is something real to say, it will be because the guidelines have been through enough ordinary weeks to have been tested.

What I would change

I do not know yet, and the honest thing is to say so rather than to invent a retrospective for a document that is weeks old. The reflection that belongs in this section does not exist.

What I will be watching for is narrower than a verdict. Whether the guards hold on a busy day, because a rule that is followed when there is time and skipped when there is not is not a guard, it is a preference. And whether review quality changes now that more of what arrives in a pull request was drafted by a tool, in either direction: reviewers reading more carefully because they no longer assume a human thought about every line, or reading less carefully because the change looks polished. Those two are the questions I would want a case study to answer, and I would rather leave the section open than fill it.