Practical AI in DevOps: the series
Most of what gets written about AI in DevOps is written by people selling AI in DevOps. This series is our attempt at something more useful: a running account of what we actually run, what it costs us, and where it falls over.
PicNet has been building and running software in Sydney since 2001. We are a team of ten, all senior, all engineers, including the managers. That size matters for this topic. We do not have a platform team, a tooling team and an SRE roster to absorb operational load. If something needs watching overnight, one of us is watching it, which is a strong incentive to automate anything that can be automated and to be honest about the things that cannot.
Two parts of our own stack are behind most of what we will write about. The first is monitoring: we run more than a hundred automated operational checks across our infrastructure and our clients’ systems, and a growing number of them now involve some form of AI in the triage and summarisation layer rather than just threshold alerting. The second is development: our engineers use coding agents daily in production .NET work, including on Centazio, the open-source data integration platform we built and maintain.
That daily use is where the interesting material comes from. An agent that writes a passable integration test in thirty seconds will also confidently rewrite a config file it had no business touching. A summariser that turns forty log lines into one sentence will occasionally drop the line that mattered. We have had both happen. Knowing where each tool stops being reliable is most of the value, and it only comes from running the thing in anger.
So the series has a few commitments. We write about systems that are running, with the costs attached, in dollars and in engineering hours. Where something did not work, we say so and say why. We do not publish numbers we cannot stand behind, and we do not describe client work that we have not been given permission to describe.
The other commitment is about review. Humans review everything that matters. Every AI-generated change that reaches a production system in our work passes a person who understands the system and is accountable for it. That is a deliberate constraint, not a temporary one while the models improve. It shapes how we design these systems, because a workflow that produces output nobody can review in reasonable time is a workflow we will not ship.
This is written for IT managers, engineering leads and executives in Australian organisations who are being asked what AI means for their operations and want an answer with numbers in it. You do not need to be hands-on to follow along, though if you are, there will be enough detail to argue with.
PicNet builds production AI systems for Australian organisations. Talk to us about what a first project could look like.