If there is such a thing as an abstraction ladder, infrastructure management has been climbing it. It began with raw scripts, then code, automation, and now it is moving toward orchestration. The next step will probably be to create a world where AI agents will be allowed to roam infrastructure and deploy to production. We’ll deal with this one at the very end of this post.
As with everything DevOps, each stage promised to simplify how teams provision and manage infrastructure. Yet every step also uncovered a new challenge.
Infrastructure-as-Code (IaC) made infrastructure reproducible. Terraform Automation and Collaboration (TACO) tools made it collaborative. But the next step that would make it safe, fast, and consumable still hasn’t been solved. This is a real pain. When we speak to engineering leaders, they are worried about the fact that environments take too long to launch, meaning that the business waits for “some DevOps guy” to get the needed infrastructure in place.
That’s where Bluebricks enters: it is an environment orchestrator that is a layer above TACO, that drives separation of concerns, provides UX, standards, and most importantly, a deterministic “catalog” for AI agents, so that they can deploy infrastructure.
The evolution so far: from code to collaboration
We started the journey with Infrastructure-as-Code tools such as Terraform, OpenTofu, Cloud Formation, Pulumi, Bicep and more. Using them, engineers define infrastructure as code, which, at the time, was a massive improvement over manual provisioning. With IaC, environments could be versioned, replicated, and reviewed, just like any other software.
The next level introduced manifest-driven abstraction, with tools such as Terragrunt. This began as a wrapper that added modularity, composition, and reuse. Teams could avoid repetitive IaC code (DRY), manage environments more cleanly, and reduce configuration drift.
But as IaC adoption scaled, new problems surfaced, primarily around collaboration, governance, and safety. Infrastructure required more than version control. State management, access control, policy enforcement, and visibility were needed too.
That led to the rise of TACO tools: platforms like Spacelift, env0, and Scalr, designed to help teams automate, govern, and collaborate on IaC at scale.
The TACO era: governance meets automation
TACO platforms brought structure to IaC execution. They added
- Centralized state management for shared environments
- Automated plan and apply workflows integrated into CI/CD
- Role-Based Access Control (RBAC) and approval workflows
- Audit trails for compliance and troubleshooting
In short, TACO tools turned Terraform from a local developer utility into a collaborative, auditable system of record for infrastructure that’s on the cloud
However, this evolution also introduced its own constraints. Today, these limits define what the next layer should do, especially as AI agents are just around the corner.
Before we do that, let’s understand what TACO doesn’t do.
The limits of TACO: code-centric, risk-prone, and rigid
Despite their sophistication, TACO tools remain fundamentally code-first. Every infrastructure change still begins as code in a repository, and every action still revolves around plan and apply commands.
That approach creates several systemic challenges:
1. The Flexibility Problem
Because TACO workflows are built around IaC code, any code can be planned or applied even if it runs afoul of standards, creates drift or breaks something. There is no separation of concerns between infrastructure definition and deployment execution, which means we’re always dealing, still, with some sort of Terralith, albeit better organized. The same repository that defines a database can also, even though this is an unintended consequence, alter a VPC or production cluster.
The result is human review. This means lengthy PR reviews, higher risk, and larger blast radii, in case something does go wrong.
2. The “lane” or non-agnostic problem
TACO pipelines are not tool-agnostic. When a workflow begins in Terraform and needs to move to Helm or Python scripts, the automation stops and the manual steps or human approvals begin. Each “lane change” introduces latency and risk and results in the long times it takes to add environments or modify them, hurting business performance.
3. The GitOps patch
To mitigate this, many teams added GitOps layers above TACO. While GitOps brings declarative sync and drift detection, it also adds complexity, with slower merge cycles, more YAML sprawl, and manual approval gates that undermine agility.
The Missing Principle: Separation of Concerns
The fundamental flaw with the TACO model is that it conflates two different concerns:
- Defining infrastructure (the “what”)
- Deploying infrastructure (the “how”)
Engineers, developers, and DevOps practitioners all touch the same Terraform repositories, creating tension between control and speed. It also introduces risk, and an interaction that may be the opposite of a good developer experience with a clear golden path and standards.
True infrastructure abstraction requires a layer that decouples the two. It should preserve IaC as the source of truth while giving teams (and AI agents) a safe, structured way to consume and deploy it.
That’s the gap Bluebricks fills.
Bluebricks (or: Environment Orchestration): the layer above TACO
Bluebricks builds on everything TACO accomplished: automation, governance, and visibility, and takes it one tier higher. It turns raw infrastructure code into reusable and versioned blueprints that define how infrastructure can be safely created, modified, and consumed, all the while keeping a strict separation of concerns and enabling end-to-end automation across different IaC tools, as well as maintaining standards.
Think of Bluebricks as TACO with UX, policy, and separation of concerns built in.
Instead of working directly with Terraform or Helm, engineers define Artifacts (modular building blocks) and assemble them into Blueprints: standardized, versioned deployment packages. These blueprints are:
- Immutable: No ad-hoc edits or drift.
- Policy-Enforced: Guardrails for cost, security, and compliance baked in.
- Version-Controlled: Every deployment traces back to a validated release.
- Tool-Agnostic: Orchestrate Terraform, Helm, and scripts seamlessly.
From the developer’s perspective, deploying infrastructure becomes as simple as selecting a certified blueprint from a catalog: a staging cluster, a database, a VPC, knowing it is pre-approved, compliant, and ready to execute.
More importantly, the same experience applies to AI Agents, delivering the deterministic context that ensures they do what’s right.
Workflows vs pipelines
Where TACO tools revolve around code pipelines, Bluebricks (and environment orchestration) revolves around workflows and standards.
It introduces several key capabilities missing from the TACO tier:
- Separation of Concerns:Platform teams author blueprints once; developers and AI agents consume them without touching code.
- Golden Paths: Pre-approved blueprints ensure safe, repeatable infrastructure delivery.
- Guardrails, Not Guidelines:Every blueprint enforces policies automatically from security, through cost and redundancy
- No-Code Interface: Deployment through intuitive workflows, not Terraform commands.
- AI and Human Friendly:Natural language requests (“Create a staging environment”) map directly to certified blueprints.
This architecture doesn’t replace Terraform. It builds on top of it Terraform and other IaC tools remain the foundational engines, while Bluebricks provides the operating layer that orchestrates them safely.
Infrastructure as experience
The trajectory of infrastructure management is clear:
- From scripts to code (Terraform)
- From code to collaboration (TACO)
- From collaboration to experience (Bluebricks)
Bluebricks embodies that next phase. It abstracts complexity without hiding it, bringing together governance, speed, and accessibility in one layer.
By decoupling code from deployment, enforcing policies by design, and offering a UX for both humans and AI agents, Bluebricks stands as the natural successor to TACO and finally closes the gap between infrastructure as code and infrastructure as a service.
