Practical insights on Platform Engineering, Azure, GitHub, Terraform, and AI-powered delivery
Thomas Thornton 
The Draw.io MCP Diagramming Agent Skill provides a reusable working method for creating clear, editable diagrams with Draw.io MCP. It supports cloud architectures, network topologies, CI/CD pipelines, Kubernetes platforms, event-driven systems, C4, UML and more, while applying consistent guidance for layout, containment, connector routing, labels and validation.
Agent skills are only useful if the agent knows when to use them. A clear description acts as selection metadata, helping the agent load the right guidance, avoid noisy context, and produce more consistent results across repeated engineering tasks.
A quick HolmesGPT demo using Azure AI Foundry, Azure OpenAI and a local kind cluster. Deploy a deliberately broken Kubernetes pod, ask HolmesGPT to investigate it, and see how it identifies the root cause from the pod spec, scheduler events and cluster state.
Agent skills, custom instructions, and MCP configuration are becoming part of the engineering trust boundary. This post walks through using NVIDIA SkillSpector in GitHub Actions to scan AI skill repositories, surface findings in SARIF or PR comments, and make risky agent behaviour visible during normal review.
AI-assisted engineering is moving beyond “can the agent do the task?” and into the same practical concerns platform teams already deal with: cost visibility, ownership, observability, governance, repeatable workflows, and sensible defaults.
This post looks at why AI engineering needs boring platform controls, from APIM policies and token visibility through to Agent Skills, MCP, Terraform modules, OpenTelemetry, and evaluation loops.
AI-assisted engineering is moving beyond proving that agents can complete tasks. The harder question is whether those workflows can be repeated, reviewed safely, kept within sensible cost, and improved over time.
This post looks at why platform teams need to treat AI usage as more than activity metrics, with a focus on token visibility, repeatable agent skills, controlled context, practical guardrails, and measurement that connects AI-assisted work to real engineering outcomes.
I have added optional animated traffic flows to my Draw.io diagram skill. The rule is simple: only animate a connector when the movement helps explain the design. Most diagrams should stay static. For normal architecture diagrams, static connectors are usually the right choice. If the diagram is showing platform layout, ownership boundaries, service dependencies, or … Read more
One of the easiest mistakes to make with GitHub Copilot Agent Skills is treating them as somewhere to store every useful instruction you have ever written. It usually starts well, you create a Terraform module skill, an Azure architecture skill, a pull request review skill, or a cost optimisation skill. It helps, so you add … Read more
Building Terraform modules is rarely the hard part. The harder part is deciding whether a module should exist at all, where the boundary should sit, how much of the provider surface to expose, and which platform defaults should be opinionated rather than endlessly configurable. In this post, I walk through why I built a terraform-module-creator GitHub Copilot skill to help with that design work up front, using live Azure MCP and HashiCorp MCP guidance to shape better module boundaries, interfaces, documentation, validation, and long-term supportability.
GitHub Copilot Rubber Duck is interesting not because it adds more AI to the workflow, but because it focuses on a more important problem. In agent-driven coding, the real issue is often not generating code, but catching weak assumptions and flawed plans before they spread across larger changes. This post looks at why a second opinion inside GitHub Copilot CLI makes sense, where it could genuinely help, and why review quality matters more than more generation.