Infrastructure as Lego

The cost of turning written business logic into code has dropped to near-zero. AI agents are able to write functions, debug errors, and refactor code bases much faster than teams can. This productivity shift is happening with infrastructure teams as well. Deploying a database, configuring a network, or spinning up compute no longer requires weeks of planning with the help of agents.

When teams move from deploying infrastructure by hand to using tools that enable Infrastructure-as-Code (IaC), we can think of it as LEGO blocks. You now have a database module, a networking module, a compute module. Each infrastructure module has a discrete function and can snap together to support multiple use cases without needing to be rewritten.

Terraform is what makes this work. Write a module for IBM Cloud VPC (defining subnets, security groups, routing tables, etc.) and reuse it across all your projects. By passing in inputs (called variables), such as which region to use, which IP addresses to assign, and what to name everything, each project can reuse the same modules.

Here’s how you can reuse a Terraform module to deploy a Virtual Private Cloud on IBM Cloud. This one’s from the official terraform-ibm-modules team:

module "vpc" {
  source            = "terraform-ibm-modules/vpc/ibm" # Module location
  version           = "X.X.X" # Replace "X.X.X" with a release version to lock into a specific release

  vpc_name          = "stage-vpc"
  resource_group_id = module.resource_group.resource_group_id
  locations         = ["us-south-1", "us-south-2", "us-south-3"] # Datacenter location
  vpc_tags          = var.resource_tags
  address_prefixes = [
    {
      name     = "stage-us-south-1" # IP Address for zone 1 (us-south-1)
      location = "us-south-1"
      ip_range = "10.10.10.0/24"
    },
    {
      name     = "stage-us-south-2" # IP Address for zone 2 (us-south-2)
      location = "us-south-2"
      ip_range = "10.10.20.0/24"
    },
    {
      name     = "stage-us-south-3" # IP Address for zone 3 (us-south-3)
      location = "us-south-3"
      ip_range = "10.10.30.0/24"
    }
  ]

  subnet_name_prefix          = "stage-subnet" # Subnet Prefix
  default_network_acl_name    = "stage-nacl"
  default_routing_table_name  = "stage-routing-table"
  default_security_group_name = "stage-sg"
  create_gateway              = true
  public_gateway_name_prefix  = "stage-pw"
  number_of_addresses         = 16
}

IBM Cloud Projects goes further. Instead of managing separate Terraform modules and configurations, you bundle them into a single deployable architecture. It handles the dependencies, tracks state, and orchestrates the whole deployment as one.

IBM Cloud Projects lets you build infrastructure as blocks.

Before deploying your infrastructure get a cost estimation.

Interact, control and validate all the blocks inside your project.

The AI Accelerator

IBM’s Bob, an AI agent, enables infrastructure teams to abstract the code under their deployments. A user can describe their requirement: “Secure web application on IBM Cloud with PostgreSQL database and auto-scaling.” Bob then generates the right module composition, picks the right security measures, and deploys everything via IBM Cloud Projects.

IBM Bob is not confined to an IDE; with Bob Shell, the same capabilities come to your terminal.

Bob can translate the infrastructure requirements from the user request, abstracting what it actually implies: a VPC, subnets across multiple AZs, a load balancer, compute instances, locked-down security groups so only the right traffic gets through, and auto-scaling based on CPU usage. You stop worrying about writing code and focus on improving infrastructure requirements.

Here’s an example of a custom mode configuration in Bob that specifically handles IBM Cloud infrastructure. You can set your own core principles, workflows, and security requirements:

 customModes:
  - slug: ibm-cloud-terraform
    name: 🌩️ IBM Cloud Terraform
    roleDefinition: >-
      You are an IBM Cloud and Terraform expert who helps users deploy and manage cloud infrastructure.
      You follow best practices, use official IBM Cloud modules, and provide clear explanations.
      You adapt your guidance based on the user's experience level and project requirements.
    whenToUse: Use for deploying IBM Cloud infrastructure with Terraform, debugging configurations, and optimizing cloud resources.
    customInstructions: |-
      Core Principles:
      - Use official IBM Cloud Terraform modules from the registry
      - Follow naming convention: ${var.prefix}-${resource_type}-${identifier}
      - Add validation blocks to all variables
      - Never hardcode sensitive data - use environment variables (IC_API_KEY)
      - Mark sensitive variables with sensitive = true
      - Test incrementally with terraform plan before applying
      
      Workflow:
      - Always read existing files before making changes
      - Use apply_diff for targeted modifications
      - Run terraform validate after changes
      - Provide clear deployment instructions
      - Include relevant outputs (IPs, IDs, connection commands)
      
      Security:
      - Verify IC_API_KEY environment variable is set (never hardcode API keys)
      - Ensure terraform.tfvars is in .gitignore before any commits
      - Only use SSH public keys in configurations (never private keys)
      - Warn users immediately if sensitive data detected in files
      - Remind about credential rotation (API keys every 90 days)
      - Audit access and usage patterns regularly
      - Use least-privilege security rules
      - Enable encryption where available
      
      Common Tasks:
      - Initialize: terraform init
      - Plan: terraform plan -out=tfplan
      - Apply: terraform apply tfplan
      - Outputs: terraform output
      - Destroy: terraform destroy (with confirmation)
      
      When debugging:
      - Check terraform state list
      - Verify provider configuration
      - Review security group rules
      - Test connectivity and access
      - Check IBM Cloud console for resource status
    groups:
      - read
      - edit
      - command

# Made with Bob ❤️

Risk drops with cost

Adopting automation for deployments means we can catch what humans can miss. If a deployment fails, changes roll back automatically. If you need to delete infrastructure, Terraform removes every resource it created, leaving no orphaned load balancers, forgotten security groups, or costly services behind.

A combination of AI agents and deployment orchestration can ensure we see exactly what gets created and what it costs before anything deploys. It won’t forget to configure a security requirement or skip monitoring. Each layer catches different mistakes. Stack these together and deployment risk gets closer to zero.

What It Follows

So what does this mean for infrastructure teams?

I believe deploying infrastructure isn’t a specialized skill anymore, at least in the sense of knowing where to configure a subnet or import an SSH key. Teams that used to spend their days clicking through cloud portals or writing deployment scripts can focus on work that actually matters.

You can design cost-aware, sustainable, modern architectures without the burden of manually deploying them. When you’re “architecting” solutions, you’re always making trade-offs. Now those trade-offs can take up more of your time. Cost, resilience, and performance are usually in tension with each other. Now you actually have time to make sure you’re not leaving something critical on the table.

The organizational discipline once required to manage infrastructure is now embedded in the tooling. The question can change from “how do we build this?” to “what can we improve?”

That’s a way better question to spend time on imo.