At some point, every larger infrastructure-as-code project reaches a stage where changes stop being local. Updating a module version, changing an input contract, or migrating between architectural approaches suddenly requires coordinated changes across many places and often across multiple repositories.

In theory, these are “simple” updates: bumping a version, removing an input, adding a new configuration block. In practice, manually refactoring such changes is time-consuming, error-prone, and difficult to review safely. Text-based scripts built around tools like grep or sed help only up to a point. They do not understand the structure of the configuration, are sensitive to formatting, and, most importantly, are not deterministic. Each execution requires another round of manual verification to ensure the result is actually correct.

Over the years, I’ve had the opportunity to work on many projects and see a wide range of approaches to Infrastructure as Code using Terraform. Some of them scaled well, others didn’t. A few worked great early on, but as the project grew, and new resources had to be added under time pressure and shifting priorities, the codebase became harder and harder to maintain. It was still “infrastructure as code”, but each change took longer, and refactoring became too costly to be worth the effort.

Why yet another Gradle plugin

Recently, I wanted to deepen my understanding of Build Scans, Develocity, and their practical applications, so I started going through the courses on our DPE University platform. In my daily work, I interact with Develocity from the operational and production side (maintaining open-source instances among other things), so I wanted to better understand the product, especially from the end-user perspective, to support my daily engineering work.

Welcome to my blog!

I’ve built it to document and share my personal experiences in building solutions for cloud architecture, platform engineering, and AI-native tooling.

You won’t find beginner tutorials here. This blog focuses on documenting real-world decisions, trade-offs and patterns that emerge in production systems.

What to expect

• Practical, implementation-focused posts grounded in real projects.
• Structured patterns for building and evolving platform architectures.
• Technical insights on Gradle, OpenTofu, GitOps workflows, and AI-native systems.
• Clean, minimal, and deliberately noise-free.

Let’s get started

To respect your time and avoid leaving you with just a welcome and a list of future topics, I want to share how this blog is set up: fully automated and declaratively managed. Following one of my favourite principles: