A DevOps Perspective on Turning AI Skepticism Into the Right Kind of Productivity

A few years ago I would not have believed that an assistant reading from a chat window could become a real working partner for someone in infrastructure and platform engineering. My first contact with these tools left me unimpressed. They invented configuration properties that simply did not exist, they answered as if every tool only ever had one version, and they could not hold enough context to be trusted with anything beyond a quick question. By 2026 that picture changed completely for me. I now work every day alongside an assistant that reads full repositories, recognizes the patterns I already use, and produces work that feels like it came from an actual member of the team.

This article is a personal account of that journey, told from the perspective of someone working in DevOps, infrastructure, and platform engineering. I am not going to claim to know the best way to build enterprise applications with AI, since that is not the kind of work I focus on. What I do know, in detail, is how I reshaped my own way of working to get consistent, high quality outcomes without losing time to bad advice. That includes the mistakes that cost me real hours, the guardrails I built afterward, and the toolkit of skills and instructions that now sits between me and every task I touch. By the end of this article you will understand how that toolkit evolved, why I still refuse to trust a single answer at face value, and where I plan to take this setup next.

From Skepticism to a Daily Working Buddy

The earliest experiments felt closer to a novelty than a tool. Asking a chat based assistant for help with a configuration file often produced a property that sounded correct but did not exist in the actual software, or an answer clearly written for the wrong release of a service. Those failures were not subtle. They were the kind of mistake that anyone with a bit of experience would catch immediately, which made it hard to imagine handing over anything more serious than a quick lookup.

What changed by 2026 was not a single breakthrough but a combination of better underlying models and a much more deliberate way of working on my side. The assistant became able to read an entire repository, recognize the conventions already in place, and produce output that matched them instead of imposing a generic style. That shift let me start treating it as a working buddy rather than a search engine with a chat interface.

Figure 1: How trust in daily AI use moved from early skepticism, through a cautious experimentation phase, through a moment of overconfidence that led to a costly mistake and a real dip in trust, and finally to a working buddy relationship built on structure and verification.

There is something bittersweet in this change that I want to be honest about. Developing used to feel like a craft, something closer to an art than a mechanical process. Now it looks a lot more like what most companies always wanted it to be, a reliable means to an end. I am not criticizing that shift, and I am not complaining about it either. It is a natural evolution, and I made peace with it. What matters more to me now is that the assistant works in parallel with me. I can hold more than one issue or task active at the same time, which means I can chip away at technical debt without ever losing focus on my main assignment, and I can keep a running memory of my troubleshooting sessions that turns into precise postmortem reports and improvement notes almost for free.

Working this way, in parallel and with far less manual reconstruction, sits at odds with a belief that gets repeated across the industry: that shipping more code, faster, is what productivity actually looks like. That gap between the belief and what I actually experience day to day is worth pulling apart properly.

Defining What Productivity Means

Productivity tends to get measured badly across software work in general, not only in infrastructure and platform engineering. Counting lines of code produced, pull requests opened, or resources created through an assistant are faulty measures wherever they get applied, since none of them say much about whether the underlying work was actually good, for a developer or for someone in my position. For me, productivity means something else entirely, and it has two parts. The first is reaching a state where every delivery holds real quality without sacrificing the time it takes to get there. The second is that a meaningful share of what I deliver is not for myself at all. It is productivity for other people, achieved through platform work and automation that removes friction from their day long before they would ever notice it was there.

No more technical debts left behind

Before I built a structured way of working, a technical debt item like cleaning up an old script or hardening a manifest would sit untouched for weeks because it always competed with whatever incident or deployment was the priority of the day. Now I can hand that kind of task to the assistant as a side task, review its result between the higher priority items, and merge it once I am satisfied. The debt gets paid down without ever displacing the main task from my attention.

Automated postmortems with instant memory

When an incident happens, I used to spend real effort afterward reconstructing the timeline for a postmortem: what was tried, in what order, and why. Now the assistant keeps that memory as we investigate together, so producing a precise postmortem or an improvement report afterward takes minutes instead of an afternoon of reconstructing my own notes from memory.

Platform automation that multiplies other people's time

Some of what I build never touches my own task list at all. A standardized Grafana dashboard template, or an automated onboarding step for a new host joining monitoring, saves time for whoever uses it next, not for me. That compounding effect, work that quietly removes friction for other engineers long after I finish it, is as real a productivity gain as anything I deliver on my own tasks, even though no pull request count or delivery metric would ever capture it.

None of that quality came automatically, though. Trusting the assistant enough to let it carry technical debt, write a postmortem, or automate something other people rely on only became possible after a few investigations went badly wrong first.

The Wild Goose Chase, and What It Taught Me

The clearest of those bad investigations came from trusting an assistant's evaluation of a problem a little too much. On one occasion I accepted a diagnosis at face value instead of checking the primary source myself, and what should have been an hour of investigation stretched into two full days chasing a conclusion that was simply wrong. That kind of experience is uncomfortable, but it was also the moment that pushed me to build real discipline around how I use these tools rather than treating every answer as final.

Figure 2: The two paths an investigation can take. Accepting a finding without verification risks turning a short problem into a multi day detour, while checking primary sources and asking a second model to criticize the finding keeps the investigation on a short, predictable path.

Two days spent chasing a one hour problem

The two day investigation I mentioned above is the clearest example. The assistant proposed a plausible sounding root cause early on, and because it sounded reasonable and matched a story I already half expected, I moved straight to trying fixes based on it instead of confirming it against logs and configuration first. Two days later, after the fix repeatedly failed to hold, going back to the primary source revealed the real cause in under an hour.

A second opinion catches the gap before it costs time

Since then I set up a habit, and eventually a standing instruction, that turns any non trivial investigation into a three way job instead of a conversation with a single assistant. I validate the primary source of information myself, in parallel with a first model working through the same investigation on its own. Once both of those are done, I bring in a second, different model whose only task is to criticize the first model's output and cross check it against my own observations so far. In a later, similar situation, that second model, prompted specifically to look for holes in the reasoning, flagged that the first model's evidence was incomplete before I ever acted on it. That single check redirected the investigation before any time was lost, and it is now a standard part of how I validate anything non trivial.

That change, splitting the work into my own verification, a first model's independent investigation, and a second model's critique of both, improved my success rate enough that I no longer dread being sent on a wild goose chase by an overconfident answer. I still remain the one accountable for the outcome, the assistant simply gives me a faster way to get there when I use it with the right amount of skepticism.

That single habit did not stay a personal quirk for long. It became the seed for a much larger set of rules I now rely on with every task.

Building a Layered Instruction System

Once I understood how much the quality of results depended on how I set things up rather than on the model alone, I built a layered structure of instructions that now underlies everything I do.

At the top sits a set of global instructions that apply across every project I touch. These capture rules I never want to repeat by hand, such as always using a different model to criticize a piece of work before accepting it, or, whenever I ask for a new skill to be created, using one model to draft the prompt and a different model to actually author and execute it. Below that sit project specific instructions, and below those, repository specific instructions for the parts of a project that have their own conventions. One rule sits above all of them as a kind of meta rule: whenever I use a strong statement like always do this or do this always in conversation, that statement itself needs to be captured back into the instructions so it is never lost to a single session.

Figure 3: The instruction hierarchy that shapes every task. Global rules apply everywhere, project rules narrow that down, repository rules handle local specifics, and any strong directive I state in conversation gets written back into the global rules so it persists.

A global rule born from the wild goose chase

The global rule about always using a different model to criticize a finding is the one that came directly out of the wild goose chase experience described above. It now applies automatically to every project I work in, professional or personal, without me needing to remember to ask for it each time.

A narrow rule that stays local to one repository

A repository specific instruction might record something as narrow as which command validates changes in a particular codebase, or a safety check that must run before any mutating command against a specific cluster. These live only where they are relevant, so the global instructions stay focused on things that genuinely apply everywhere.

Instructions only set the rules, though. Where those rules actually turn into repeatable work is a smaller, more concrete layer built from skills and, to a lesser extent, agents.

The Daily Toolkit: Skills Over Agents

Most of the practical value I get day to day comes from a set of custom skills rather than from autonomous agents, and that distinction matters enough that I want to spell it out clearly.

On the professional side I have built skills to create standardized reports, to keep a running memory of notable events and mistakes, to investigate specific Kubernetes issues with a consistent method, to create Grafana dashboards that follow a fixed standard instead of one off layouts, and to develop small scripts, since I still believe not everything should be produced by an assistant. On the personal side I keep a smaller set: a planner for study topics and home server improvements, a diary that records changes to my own infrastructure, and an article writer that turns notes like the ones behind this piece into a finished, structured article.

Figure 4: The skill and agent ecosystem I currently run. Skills carry most of the daily workload on both the professional and personal side, while agents remain a smaller, more experimental layer on top.

A consistent method for every Kubernetes investigation

The Kubernetes investigation skill is a good example of a professional skill earning its place. It enforces the same method every time an issue comes up: gather the right context, confirm the working cluster, collect the mandatory evidence, and only then reason about root cause. That consistency is worth more to me than any single clever answer.

A searchable history of infrastructure changes

The infrastructure diary skill is the personal equivalent. Every completed change to my home network or home server gets recorded in the same narrative format, which means I can grep years of history later and actually find what I am looking for, instead of relying on memory alone.

Agents have had a smaller role so far. I keep exactly one on my personal setup, a memory keeper that supports the diary and report skills, and I run seven on my professional setup. Honestly, the professional agents have not yet shown a clear productivity improvement over well built skills with clear instructions. I keep experimenting with them, but for now the bulk of my real gains come from the more constrained, more predictable skill layer.

Looking ahead, I have a few concrete plans building on this foundation. I want an agent that automatically drafts troubleshooting reports the moment an incident starts, so that whoever is on call gets a solid starting point instead of a blank page, which should meaningfully cut down the time it takes to reach a fix. I am also planning a skill to generate documentation in one fixed format across onboarding guides, knowledge base entries, and simple help pages, so that anyone reading them knows exactly what to expect. Alongside that, I want a skill that scaffolds new workloads from a small set of predefined developer inputs, as a stopgap until proper platform automation exists to do that job on its own.

Conclusion

Looking back at where I started, deeply skeptical of a tool that could not get a configuration property right, the distance to where I am now is significant. The real turning point was never the model alone. It was building the right structure around it: a layered set of instructions that captures decisions once and applies them everywhere, a habit of checking primary sources myself and asking a second model to criticize any important finding, and a set of narrowly scoped skills that do one job well instead of a handful of agents that promise everything and deliver an unclear amount. I do not think I have reached the ideal setup yet, and I expect the instructions, skills, and even the balance between skills and agents to keep shifting as I learn more. What I do know is that I can now work alongside this assistant without dreading being sent on another wild goose chase, and that alone has changed how much I get done in a day without giving up any of the quality I care about.