A developer needs an Azure application environment. The Terraform repository already has most of what the team needs, but someone still has to find the right module, understand its inputs, connect the dependencies, and explain the resulting pull request. A familiar request lands in the platform team’s queue, somewhere between a provider upgrade and the next production issue.
GitHub Copilot and Claude Code are changing how much of that work an engineer has to do manually. They can help navigate an unfamiliar repository, draft Terraform configuration, update related files, and explain failures. With the appropriate tools and permissions, an agent can also run commands and use their output to revise its changes.
For Site Reliability Engineers and Platform Engineers, the opportunity extends well beyond producing HashiCorp Configuration Language (HCL) faster. AI can make the platform’s accumulated knowledge easier for other developers to use. That is where the value starts to compound: the same reviewed modules, conventions, and delivery practices can support more teams with less repetitive intervention.
Realizing that opportunity changes the job. We spend more effort making good infrastructure decisions reusable, giving tools the context to follow them, and establishing evidence that a proposed change is ready. Faster authoring makes those responsibilities more consequential.
From Code Completion to Working Across the Repository
Infrastructure work rarely fits inside a single resource block. Adding an Azure service may require module inputs, environment configuration, role assignments, diagnostic settings, documentation, and changes to a deployment pipeline. The tedious part is often coordinating all those pieces while preserving the repository’s existing conventions.
Both GitHub Copilot and Claude Code agentic coding tooling support exploring a codebase, editing files, and running commands. Their capabilities overlap, and the experience depends on the interface, configuration, and permissions you provide. Treating these AI coding tools as autocomplete alone misses much of what these tools can now contribute.
In a Terraform project, that makes a more useful request possible: examine how this repository provisions Azure application environments, identify the established pattern, and propose the smallest change needed for another environment. The engineer can evaluate a concrete proposal instead of starting every request with a blank file.
The same approach helps with maintenance. An assistant can locate consumers of a module input, draft a coordinated update, and prepare migration notes. It can also investigate a provider error against the configuration and the provider version the project actually uses. Those are useful starting points for review; a confident explanation still needs to agree with the documentation and the command output.
The Platform Becomes More Valuable When AI Can Use It
Platform teams already invest in reusable Terraform modules because repeating infrastructure decisions across application teams is expensive. A well-designed Terraform module for Azure, AWS or other cloud resources can establish supported naming, tagging, identity, networking, and monitoring behavior. Its interface gives developers a manageable set of choices while the implementation carries the team’s engineering decisions.
AI gives that investment another route to adoption. An application developer can describe the intended outcome and ask the assistant to find and use the approved module. The platform team gains a way to deliver guidance directly inside the developer’s workflow, where it can shape the actual change.
Consider a team whose Microsoft Azure application patterns require managed identity, centralized diagnostics, and private connectivity for a dependent storage account. A generic request to “write Terraform for this application” leaves the assistant considerable room to improvise. A request grounded in the team’s preferred modules, maintained examples, and documented constraint context gives it a much better foundation.
This is the force multiplier I would prioritize. Improve the supported path until both developers and their AI tools can follow it easily. Every successful reuse carries forward the work that went into reviewing that pattern.
There is a corresponding responsibility. If a module makes an insecure choice easy, or an old example omits an important dependency, AI can repeat that pattern across more projects. Repository quality becomes part of the platform’s operational effectiveness. An abandoned example is no longer just an untidy corner of the documentation; it may become the starting point for somebody’s next pull request.
Give the Assistant the Decisions Behind the Code
A repository shows how infrastructure is described. It often provides a weaker account of why those choices were made. The assistant may see private endpoints without knowing the organization’s connectivity requirements, or find a lifecycle setting without understanding the incident that led the team to introduce it.
That missing context is work for the platform team. Record which modules are supported, where environment configuration belongs, how provider upgrades are handled, and which changes need additional review. Explain the reasons behind unusual constraints so the assistant has a basis for preserving them.
Both tools offer mechanisms for supplying project guidance. GitHub documents repository instructions through .github/copilot-instructions.md, with support varying across Copilot features. Claude Code supports project instructions through CLAUDE.md. There is even the ability to use a AGENTS.md file that’s a more agentic coding tool agnostic way to specify instructions. Keep that guidance concise, reference maintained documentation, and verify that the interface your team uses actually loads it.
For HashiCorp Terraform, useful instructions identify the approved module sources, provider constraints, validation commands, and environment boundaries. They should also tell the assistant when to stop and ask for engineering judgment—for example, when a change would replace a stateful resource or widen an Azure role assignment. Instructions help guide behavior; permissions and pipeline controls establish what the tool can actually do.
We should also make uncertainty an acceptable result. Asking the assistant to identify missing requirements before editing can reveal an unresolved networking decision or an unclear ownership boundary. Discovering that ambiguity early is useful engineering progress, even when no HCL has been generated yet.
What a Better Daily Workflow Looks Like
Let’s return to the request for an application environment hosted in Microsoft Azure. Start by asking the assistant to inspect the repository and explain which module and existing environment provide the closest fit. Have it identify the intended Azure subscription, state configuration, dependencies, and unresolved choices before proposing edits. An engineer should be able to trace that explanation to the actual files.
Once the approach is agreed, keep the change focused. Ask the assistant to add the environment using the approved module, preserve provider constraints, and update the relevant documentation. Resist combining that request with a repository-wide cleanup. Small changes make it easier to understand whether a difference is necessary and whether an unexpected replacement belongs in the plan.
The validation loop then supplies feedback the assistant can act on. After initialization in an appropriately isolated environment, formatting checks and terraform validate can catch problems in the configuration. Existing module tests, security checks, and policy checks add evidence about the requirements the team has chosen to enforce.
These checks answer different questions. HashiCorp explicitly notes that terraform validate does not validate remote services or provider APIs. A configuration can pass validation and still fail against Azure permissions, quotas, or service constraints. It can also describe a deployment that is entirely valid and inappropriate for the application.
A plan from the intended execution context is therefore essential review evidence. Have the assistant summarize additions, updates, deletions, and replacements, and point out identity or network changes. Then compare that summary with the actual plan. The summary helps the reviewer navigate the evidence; the underlying evidence remains necessary.
Separate permission to prepare a change from permission to deploy it. An assistant that can edit a branch does not automatically need production credentials. Planning also needs deliberate access design: it can involve reading remote state, contacting Azure APIs, and executing provider or data-source logic. Give each stage the access it requires, and retain a controlled approval and execution path for production changes.
Where the workflow uses a saved Terraform plan, apply the approved artifact through that controlled path, regenerating and reviewing it when the relevant inputs or environment change. Protect it as sensitive data. HashiCorp warns that saved plan files can contain sensitive values in cleartext, even when terminal output hides those values. Raw state, credentials, and unredacted plans should stay out of unapproved AI conversations.
SREs Gain Another Tool for Reducing Toil
For SREs, the most useful gains may come from work that surrounds a deployment. An assistant can help trace which Terraform resources describe an affected Azure service, explain a configuration difference, or turn a reviewed fix into a clearer runbook. During an investigation, reducing the time spent locating relevant files can leave more attention for forming and testing hypotheses.
That assistance needs operational context. Terraform configuration expresses desired infrastructure; it does not provide a complete account of runtime health. Azure Monitor telemetry, deployment history, service dependencies, and the team’s service level objectives still shape the diagnosis. An AI explanation of a timeout is a hypothesis until the evidence supports it.
Post-incident work presents an especially useful opportunity. Once engineers establish the cause, AI can help draft the module change, regression test, documentation update, or migration guidance that prevents the same failure from returning. That connects incident learning to the platform other teams will use next week.
State management remains an engineering responsibility throughout this work. Terraform’s Azure Blob Storage backend supports state locking, which helps coordinate access to state. A lock cannot determine whether the team selected the correct environment or whether replacing a database is acceptable. Likewise, reverting a Git commit does not automatically undo a completed infrastructure change or restore lost data.
This is why SRE expertise remains central as authoring gets faster. Someone must understand the failure modes, recovery options, and blast radius of the proposed change. AI can help assemble and explain the information; the operating model must preserve clear responsibility for acting on it.
Measure the Platform Outcome
It is tempting to measure this transition in generated lines of Terraform or the time needed to produce a first draft. Those numbers can look impressive while review queues grow. A platform team creates value when application teams can obtain supported infrastructure with less effort and operate it dependably.
Track the complete workflow: time to an accepted change, review effort, rework, adoption of approved modules, and deployment outcomes. For SREs, look at whether repetitive operational work declines and whether incident fixes become reusable improvements. These measures help distinguish useful acceleration from simply moving the bottleneck to the next person.
A practical starting point is one well-understood Azure module and a recurring request the team already handles. Improve its examples and instructions, let the assistant prepare bounded changes, and evaluate the results. Use the mistakes to improve both the platform and its validation. Expand the workflow as the evidence supports it.
There is a learning opportunity here, too. Ask the assistant to explain dependencies, challenge an assumption, or walk through a plan, then verify the answer. Junior engineers need opportunities to build that understanding, and experienced engineers need time to review the decisions that carry operational consequences.
GitHub Copilot and Claude Code make it practical to delegate more of the mechanical work of managing Terraform projects. Platform Engineers can use that capacity to extend well-supported infrastructure patterns across more teams. SREs can use it to turn operational knowledge into improvements that last beyond the next incident.
The most valuable result is a platform that more people can use successfully, with engineers spending more of their time on the decisions that make it dependable. That is an outcome worth engineering for.
