How I Turn Read-Only Analysis Into Safer Production Automation

By Vicente Arteaga Gomez

MisLinux · Last updated: May 5, 2026

This is part of my Kubernetes-on-Hetzner-and-operations series on MisLinux. It is about building safer automation from real operations, not about promising autonomous production.

The automation path I trust most rarely starts with a mutating script.

It usually starts with read-only analysis:

• inspect the live state
• preserve artifacts
• learn which fields really matter
• discover where the false signals are

Only after that do I want to automate the mutation.

Why I prefer this order

Because the read-only phase tells me:

What I learn	Why it matters for automation
true runtime contract	prevents automating the wrong layer
trustworthy proof signal	tells me what success should look like
rejected paths	stops the next tool from repeating them
safe scope boundary	keeps the mutation narrow

That means the later automation is grounded in reality instead of optimism.

The transition I want to see

The important thing there is that proof is not an afterthought. Proof is what bridges the investigation into the automation contract.

A small workflow example

# 1. Read-only inspection first
php inspect-current-state.php --out history/20260505-proof/

# 2. Build a proposed mutation from that evidence
php build-change-plan.php --from history/20260505-proof/

# 3. Dry-run the mutation
php apply-change.php --plan history/20260505-proof/plan.json --dry-run

# 4. Apply only once proof + rollback are explicit
php apply-change.php --plan history/20260505-proof/plan.json

This is much safer than starting from step 4 and improvising the rest around it.

What I watch for before promoting read-only work into automation

• Is the input shape stable enough?
• Is the output verifiable?
• Can I preserve a before-state?
• Is rollback explicit?
• Do I understand what *not* to automate yet?

The last question matters a lot. Some workflows should stay partially manual.

Failure case: skipping the read-only learning phase

If I skip the read-only phase, the first mutation script often makes one of these mistakes:

• patches the wrong representation
• treats a derived metric as the source of truth
• assumes a browser/UI state that was never actually reached
• writes a partial output where a full-file rewrite is required

Those are not abstract risks. They are exactly the kinds of misunderstandings that production tooling accumulates.

Why this matters for AI agents

This is probably the most useful pattern I have found for AI-assisted infrastructure work:

1. let the agent investigate read-only first
2. force it to preserve artifacts and explain the contract
3. then allow the mutating helper to exist
4. keep proof and rollback attached to the same workflow

That is a much better path than starting with "write the deployment fix."

What I'd do differently now

I used to think read-only analysis was just preparation before the "real" automation work. What I'd do differently now is treat the read-only phase as the place where the automation earns its right to exist.