Posts

In my organization, we have a great number of repositories that contain overlapping logic. For example, to manage our large number of cloud environments, we have separate repositories just for Terraform. We've split up our code based on purpose and audience to better organize our work. However, this creates challenges when we need to make a change that spans multiple repositories. This challenge has always existed, but it was manageable when doing work manually – you can just open the multiple repositories in your editor of choice and have multiple terminal tabs open for working with git in each repository. But as we lean into the use of agentic tooling (AI agents that can act on your behalf) to automate repetitive tasks – especially when we want those tools to perform broader changes that require context across multiple repositories – this becomes a bigger challenge. In this post I’ll walk through how I use git worktrees and a simple directory convention to give those agents the right context to work safely across many repos.

I finally stopped fighting with my homelab deploy process and turned it into something that feels almost civilized.

I've been working with Terraform for over 6 years now, and during this time, I've encountered several common mistakes when designing modules that can lead to frustrations, mismanagement, and even mistrust in the tool itself.

My infrastructure team, as part of a larger Terraform Restructure initiative, is moving our Terraform repositories to be apply-after-merge. There are significant changes in process between these two approaches; not all are obvious.

In Terraform, I've found that KISS > DRY and that the use of complex data structures as inputs are a gilded foot gun.