Docs / Make changes safely

AI-assisted review

Exploring An idea only. Nothing is built, and it may never be. We describe it so customers can tell us whether it would help.

AI-assisted change review for infrastructure is an idea we are exploring for TractorStack, not a feature. The thought is modest: a long tofu plan or Ansible diff is hard to read, and a short summary in plain language could help a reviewer see what a change really does and where the risk is. People would still read the plan and people would still approve. The summary would be a reading aid, nothing more.

The problem it would try to help with

Review is where most mistakes should be caught, and it is also where people are tired. A merge request that changes one variable can produce a plan with hundreds of lines, because a module touches many resources. Reviewers skim, and the one line that replaces a database VM instead of resizing it gets missed. The guardrail checks catch the rules you can write down in advance. A summary might help with the things that are harder to write as rules.

What AI-assisted change review for infrastructure might look like

If we build it, a summary could appear on the merge request next to the plan, covering:

• what will be created, changed and destroyed, grouped by service rather than by resource;
• anything that replaces rather than updates, such as a VM or disk being recreated;
• changes that could cause downtime, open network access or affect backups;
• a short list of questions a reviewer might want to ask the author.

It would sit beside the real plan, never instead of it, and it would be labelled clearly as generated text.

What it would not do

• Approve anything. Approval stays with a named person, as described in change requests and sign-off. A summary saying “low risk” is not a sign-off.
• Replace guardrails. Rules that must always hold belong in policy checks, which are predictable and testable. A language model is neither.
• Change the plan. It would read, not write.

Where it would run, and your data

Plans contain hostnames, IP ranges and sometimes configuration that you would not want to leave the building. Any version of this would be designed to run on site, with a model hosted on your own hardware, or to send nothing outside your network unless you have explicitly agreed to it. Secrets would be stripped from plans before summarising. This follows the same principle as your data stays on site. Running a model locally needs a GPU or a patient CPU, which is a real cost; see capacity and cost planning.

Honest limits

Language models can be wrong while sounding confident. A summary might miss a risk or invent one. That is the main reason this stays an idea under evaluation: it is only worth having if reviewers find it saves time without making them trust the plan less carefully. If you would use something like this, or would refuse to, we would like to know at sales@infratractor.com.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com