In this article
In my first blog post of the year, I talked about taming the unknown unknowns using AI agents.
A big part of that experiment was figuring out how agents should actually work together. Things like working as a team, shipping real software into production, and most importantly keeping humans in the loop throughout the entire process. Since then, we’ve started to see the rise of what people are calling AI software factories. The names and implementations might be different, but most of them follow a pretty similar pattern.
- You start with an idea.
- You plan it.
- You build it.
- You test it.
- You deploy it.
- You monitor it.
Then you take what you learned and feed that information back into the process.
That pattern caught my attention because I’ve basically spent the last couple of years experimenting with exactly that.
Almost 20 Applications Later
I’ve now built close to 20 different application experiments using individual AI agents and swarms of agents.
Some of those experiments have been pretty random.
I built what has turned into a surprisingly popular application for managing a firearms inventory. I’ll write a separate blog post about that one later.
I built an e-commerce-style website for fans of free Chick-fil-A nuggets that eventually had to evolve into free Chick-fil-A breakfast sandwiches when the promotion changed. I’ve also used swarms of agents to take a microservice-based product from planning all the way through development, deployment, and monitoring.
That one deserves its own post too.
But after doing this over and over again, I started noticing something. The applications were different but the process really wasn’t.
I Keep Building the Same Foundation
Almost every application I build starts in roughly the same place. I create a Git repository with some kind of starting codebase and that application normally needs somewhere to run. Since I work primarily in Azure, that usually means provisioning something inside one of my Azure subscriptions.
Then comes the Resource Group and whatever Azure services the application needs.
The exact resources change a little depending on the experiment, but I kept finding myself building the same basic cloud foundation again and again.
- Resource Group
- Static Web App
- Function App
- Storage
- Application Insights
- Log Analytics
- Managed Identity
- Monitoring
The interesting part was never creating those resources but the interesting part was the application I wanted to build on top of them.
Eventually I started asking myself the obvious question:
Why am I rebuilding this every single time?
This Is Where Scaffolds Come In
I think about a scaffold as a reusable starting point for something I’ve done enough times that I’ve developed an opinion about how it should work. I’m not trying to create a platform that can solve every possible application architecture. I’m trying to eliminate work I’ve already solved. So I took the Azure pattern I kept repeating and turned it into a reusable Terraform module.
You can find it in the Terraform Registry here:
Terraform Registry - Gogorichielab/scaffold/azurerm
The source is also available on GitHub.
Now when I start another experiment, I can call the module from the project’s Terraform configuration, give it a few parameters, and let it build the cloud foundation for me.
module "scaffold" {
source = "Gogorichielab/scaffold/azurerm"
workload = "myapp"
environment = "dev"
location = "eastus2"
}
If the application needs backend functionality, I can enable that too.
module "scaffold" {
source = "Gogorichielab/scaffold/azurerm"
workload = "myapp"
environment = "dev"
location = "eastus2"
enable_function_app = true
enable_managed_identity = true
}
Within about four or five minutes, I have the Azure side of the application scaffolded and running.
From there the application itself could be written in .NET, Java, PHP, JavaScript, or whatever makes sense for the experiment. The scaffold doesn’t really care about the idea I’m testing.
It just gives the idea somewhere to live.
Building While Azure Is Building
This is probably my favorite part of the workflow.
Once I kick off the Terraform deployment, I’m not sitting around waiting for Azure. My agents and I can already be working on the application. While Azure is provisioning the infrastructure, I’m usually think through the idea, writing requirements, breaking the application into pieces, creating issues, and starting development.
By the time the application needs somewhere to deploy, the cloud environment is normally already waiting for it.
That changes the way I think about the beginning of a project.
Instead of:
Idea → Infrastructure → Setup → Planning → Development
I’m much closer to:
Idea → Planning + Infrastructure + Development
Those things can happen at the same time.
And when you’re using agents that can already work in parallel, removing another sequential step makes a surprisingly big difference.
Scaffolds Are Part of the Software Factory
The more I’ve experimented with agentic development, the more I’ve realized that the agents themselves are only part of the story.
The real acceleration comes from everything around them.
- Reusable instructions
- Reusable workflows
- Reusable agents
- Reusable infrastructure
- Reusable deployment patterns
- Reusable monitoring
- Reusable scaffolds
Every time I build another application, I learn something that can improve the starting point for the next one.
That’s one of my favorite things about Infrastructure as Code.
The lessons from one experiment don’t have to stay inside that experiment. They can become code than that code becomes a module. That module becomes part of the factory and the next idea starts a little further ahead than the last one and for me, that’s what this Terraform scaffold has become cutting time from idea to POC.
It’s not really about saving four or five minutes provisioning Azure resources. It’s about removing another piece of repetitive work between:
“I wonder if this would work…”
and
actually finding out.
- Build it once
- Learn from it
- Improve it
- Reuse it
Then let the agents get back to work.