Terraform modules that survive their second year

The Terraform that hurts is rarely the Terraform that was badly written. It is the Terraform that was written well for one situation and then bent into six others.

The first habit is treating a module's variables as a public API. Once someone else consumes your module, every variable you add with no default is a breaking change and every variable you remove is a broken plan. Students learn to version modules and to add optional inputs rather than reshaping required ones.

The second is limiting blast radius by state boundary rather than by folder aesthetics. A state file that contains the VPC, the cluster, and the application is a state file where a bad apply takes down everything. We split state at the boundary of what can fail independently, which usually means networking, platform, and workloads are three separate states with explicit data lookups between them.

The third is making drift visible before it is urgent. A nightly plan that posts its diff to a channel turns drift from a discovery during an outage into a Tuesday morning conversation. This costs about forty lines of pipeline configuration and is the single highest-return thing most teams are not doing.

Where AI helps here is unglamorous and real: generating the first draft of module documentation from variable definitions, reviewing plans for destructive operations before a human looks, and explaining an unfamiliar module to an on-call engineer at 3am. It does not design your state boundaries. You still have to do that.