Viewpoint
Automation that keeps human judgment
A working principle for AI-assisted engineering: let tooling investigate, draft and challenge, and keep publication, approval and merge with a person who can be asked why.
Context
I lead the adoption of AI-assisted and agentic practices inside a quality engineering function, and I build my own tooling in the same shape on my own time. This is a viewpoint rather than a case study, because the interesting part is the rule, not any particular implementation of it.
The constraint
An agent that can read a codebase, run a suite and open a pull request is genuinely useful. It is also a very efficient way to lose the audit trail. The failure mode is not that the tool is wrong. It is that when it is wrong, nobody can say who decided.
Accountability goes first. If a change was approved by a process rather than a person, there is no one to ask why, and “the tool suggested it” is not an answer a reviewer can act on. Confidence goes next. An agent that finds twelve issues, nine of which do not reproduce, has not saved anyone time. It has moved the work from finding to disbelieving.
The rule I work to
Tooling investigates, drafts and challenges. People publish, approve and merge.
Tooling may
- Investigate
- Draft
- Challenge
Cheap, reversible, no effect outside this machine.
Only a person may
- Publish
- Approve
- Merge
Anything that reaches a colleague, a customer or a public repository.
Concretely, in the way I have my own systems set up:
Investigate freely. Reading code, running suites, reproducing a failure, searching history, gathering evidence. Cheap, reversible, no external effect. An agent should do as much of this as it can.
Draft freely, publish never. A review comment, a ticket, a commit message, a release note: all drafted by the tool, none of them sent. Anything that leaves the machine and reaches a colleague, a customer or a public repository passes through a person first. Not a rubber stamp on a batch, an item-by-item decision.
Make findings survive an adversarial pass. Before a finding reaches me, a second pass tries to disprove it, and anything that cannot be reproduced against the source or a real run is dropped rather than shown. The point is to protect the credibility of what does reach me. A tool whose output I have to re-verify is a tool I will stop using.
Log the refusals, not just the actions. When a guard rejects something the tool wanted to do, that rejection is the interesting record. A system that logs only what it did looks flawless right up to the day it does not.
Why this is a quality engineering position
Because it is the same argument as the one about release confidence, applied one level up. The purpose of a quality system is to make risk and evidence visible so that a human decision can be a good one. A tool that hides the decision inside an automated pipeline has removed the thing the system was for, and it will feel like an improvement for exactly as long as nothing goes wrong.
What I would change
I have been too conservative in one direction and not conservative enough in another. Too conservative about letting tooling investigate, where the risk is close to zero and the return is large. Not conservative enough about the boundary between drafting and publishing, which needs to be a hard structural guard in the tool rather than a rule I remember. A rule I have to remember is a rule that fails on the day I am busy.