Kyle LeMarbe

For two weeks, I handed real DevOps work to an AI assistant. Not a demo. Real repos, real docs, real decks, and real email threads. The point was not that it could do tasks. The point was that it could do them in a bounded, verifiable, reversible way.

The best way I can explain the value is with one weird example. A vendor sent me an email about an Azure migration article I had written. Something felt off, so I asked my assistant to read the thread and tell me if it looked AI written. It said yes. Then it found the argument gap in the pitch itself. That is the kind of thing I care about. Not fake confidence. Useful judgment.

1. What it spotted in the email

The second email had the usual machine polish. It repeated itself, stacked tidy reframes, and leaned on buzzwords without getting into real numbers or real failure modes. The clearest tell was a duplicated sentence. It said the same thought twice in slightly different wording. That felt like two drafts stitched together and never cleaned up.

But the more important catch was technical. The email tried to solve a problem about an autonomous agent having no deterministic internal reasoning trail by pointing to S3 Object Lock and CloudTrail. That does not actually solve the problem. CloudTrail records actions. It does not explain why the model chose them. My assistant saw that immediately.

I used that analysis to draft a playful reply. The human still stayed in the loop. The assistant gave me the tells and the technical gap. I decided how to use them.

2. Untangling a legacy Git repo without blowing away history

I had a legacy enterprise repo that had grown sideways. The current code lived on one branch. Older versions were also sitting as top level folders in main. The obvious fix would have been to force push the current branch over main. I did not want that. I wanted the content fixed without erasing history.

The assistant chose the safe path. It created a new merge commit on main whose tree matched the current release branch exactly. It used the GitHub Git Data API, so there was no giant local clone and no risky rewrite. The new commit had two parents. One parent preserved the old main history. The other pointed at the current release line.

Then it verified the result. It checked that the tree hash on main matched the release branch tree hash. It checked that every branch was still present. It also reported what it did not do. No force push. No branch deletion. No history loss.

After that, I enabled branch protection on main. Pull request required. One approving review. Force pushes blocked. Deletions blocked. Conversation resolution required. I left admin enforcement off because I wanted an emergency path, and I did not add required status checks because the repo did not have CI yet. I appreciated that it told me those tradeoffs instead of pretending they did not matter.

3. Editing a PowerPoint by rewriting its XML, then looking at the output

Another task was a 12 slide architecture deck that needed real content changes on slides 3 through 8. I did not want a rebuild. I wanted surgical edits to the existing file.

The assistant treated the .pptx like what it is, a zip of XML files. It made exact string replacements in the slide text runs so the surrounding structure stayed intact. It first read the slide XML to confirm the exact text, including entity escapes and spacing quirks, before changing anything.

Then it did the part I liked most. It rendered the deck to images and used a vision model to inspect the slides visually. That caught a real layout problem. One slide had bullets that were too long for the fixed text box. They wrapped into the footer. The assistant measured the geometry, trimmed the content, re rendered the deck, and fixed a spacing issue it introduced on the next pass.

It also kept backups at each stage. That mattered. If the edit had gone sideways, the rollback path was already there.

4. Answering an architecture question by reading our own wiki

I gave it a question that was really an institutional knowledge test. I wanted to know whether the same customer had different IDs in production and test, and whether onboarding automation should assume those IDs were the same.

It did not guess. It read the actual pages that defined the identifiers, then pulled the answer together from those sources. The result was clear.

• The Site ID is the real customer sequence number. It stays the same across environments.
• The Tenant ID is environment specific. Prod and test get different Tenant IDs.
• Automation that keys off tenant naming needs to expect a different secret or path per environment.

That answer mattered because it surfaced a downstream risk I would have wanted called out anyway. If onboarding code assumes one tenant ID per customer, it will break as soon as the same customer shows up in more than one environment. The assistant did the research, gave me the answer, and then wrote the finding back into the source document when asked.

What all four stories had in common

The value was not autonomy. It was structure.

• Bounded. Each task had a clear scope. It also reported what it left alone.
• Verifiable. Tree hashes, rendered slides, cited docs, and textual tells gave me ground truth.
• Reversible. Merge commit instead of force push. Deck backups. Drafts instead of blind sends.
• Human approved the risky step. Anything external still waited on me.

That is why I trust this pattern. It does not ask me to believe the model. It shows its work, checks its output, and leaves the final call where it belongs.

Closing thought

I am not interested in AI as a magic answer. I am interested in it as a tool that can take real work off my plate without taking over judgment. Two weeks of using it that way made me more confident, not less. It was useful because it stayed inside the guardrails and got better when the evidence changed.

That is the bar for me now. Bounded. Verifiable. Reversible. If it cannot do those three things, it is not ready for real DevOps work.