DevOps on Cloudy Mountains

Your AI Agent Is a Contractor. Treat It Like One.

Tue, 22 Sep 2026 10:00:00 +0100

For a big part of my career I was the contractor. Consultancy after consultancy, client after client. And one thing kept surprising me: the team that was supposed to help us was often the least helpful group in the building.

Access requests took weeks. Questions got one-line answers, if any. In meetings we were the outsiders who didn’t know how things worked here, the ones who would break something, the expensive people who needed everything explained twice. Sometimes it was subtle. Sometimes it was not subtle at all.

The AI-Native Internal Developer Platform

Tue, 26 May 2026 10:00:00 +0100

Internal Developer Platforms have a well-known dirty secret: most developers do not use them. The platform team builds something genuinely useful — curated pipelines, Terraform modules, Helm charts, GitOps patterns, cost guardrails — wraps it in a service catalogue, adds a web portal, writes runbooks, and waits. Adoption trickles in, usually driven by mandate rather than enthusiasm.

This is not a technology problem. It is a distribution problem. The platform team solved the right problem and delivered it to the wrong address.

Testing Terraform Plans with OPA and Conftest (and Atlantis)

Thu, 15 May 2025 23:58:44 +0100

As I mentioned in my previous blog post, my first OPA policy was just to catch one simple parameter, if we have in the S3 Terrafom module set the force_destroy = true.

Here’s a simple OPA policy that will catch this dangerous configuration:

package terraform.plan

deny[msg] {
 # Find all resources in the plan
 resource := input.resource_changes[_]
 
 # Check if it's an S3 bucket
 resource.type == "aws_s3_bucket"
 
 # Look for force_destroy in the configuration
 resource.change.after.force_destroy == true
 
 msg := sprintf("S3 bucket '%s' has force_destroy set to true. This is dangerous as it allows bucket deletion even when not empty.", [resource.address])
}

This policy works by:

How I Learned the Hard Way That Terraform Needs Policy as Code

Sun, 30 Mar 2025 13:00:44 +0100

At a glance

Context: a cloud consultancy engagement, bootstrapping 15 new AWS accounts for a client with Terraform 0.11/0.12.
Incident: I accidentally deleted the S3 bucket that held the Terraform state for all 15 accounts.
Cost: all 15 accounts were recreated and provisioned again from scratch. Because everything was code, that took less than two days. The real cost was our reputation with the client.
Fix: policy as code. OPA policies evaluated against every terraform plan in CI, failing the pipeline before a dangerous change reaches apply.
Outcome: 15 workload pipelines gated, and every pipeline created after them inherited the same checks.

What went wrong?

A few years ago, while working for a cloud consultancy company, I made a mistake that I will never forget. I accidentally deleted a Terraform state bucket: the S3 bucket that stored the state for bootstrapping 15 AWS accounts, each packed with resources. To make things worse, it belonged to a very tough client.