Infrastructure as Prompt: The Next Evolution of Infrastructure Engineering?
How AI agents may change the way teams create, review, and maintain infrastructure — and what that could mean for infrastructure engineers
By Morteza Baniadam
Infrastructure engineering has already gone through a major transformation.
In the early days, engineers created and maintained infrastructure manually. They worked through cloud portals, command-line interfaces, scripts, spreadsheets, tickets, and configuration documents. The process depended heavily on individual knowledge, and reproducing the same environment was often difficult.
Infrastructure as Code changed that model.
Tools such as Terraform allowed teams to describe infrastructure in version-controlled configuration files. Infrastructure changes could be reviewed, tested, automated, and repeated across environments. Instead of relying only on manual actions, organizations could treat infrastructure more like software.
Now another approach is beginning to emerge: Infrastructure as Prompt.
The term is still new and does not yet have one universally accepted definition. In this article, I use Infrastructure as Prompt to describe an agent-driven interaction model in which engineers express infrastructure intent, while AI agents use context, tools, policies, and existing infrastructure code to prepare controlled and reviewable changes.
The goal is not simply to replace one syntax with another. The deeper change is in how humans communicate with infrastructure.
From manual operations to infrastructure intent
The evolution can be simplified into three stages:
- Manual infrastructure: Engineers directly configure resources through portals, commands, and scripts.
- Infrastructure as Code: Engineers translate requirements into structured code that can be versioned and automated.
- Infrastructure as Prompt: Engineers describe the required outcome and constraints, while an agent helps translate that intent into a reviewable infrastructure change.
With Infrastructure as Code, the primary interface is code.
An engineer receives a requirement, finds the correct repository, understands its modules and conventions, checks the existing configuration, writes the required change, resolves validation errors, reviews the plan, and prepares the deployment.
With Infrastructure as Prompt, the primary human interface can become intent.
Instead of starting with resource blocks or provider-specific syntax, an engineer might begin with a request such as:
Create a private application environment with high availability, encrypted storage, restricted outbound connectivity, and no public access.
A capable infrastructure agent should not immediately generate and deploy resources. It should first understand what the request means in the context of the actual environment.
It may need to determine:
- Which environment and region are affected?
- Which standards and approved modules apply?
- What already exists?
- Are there conflicting, overlapping, or duplicate configurations?
- Which security and compliance policies must be enforced?
- What dependencies could be affected?
- Who owns and approves the change?
- Is the change permanent or temporary?
- How will success be validated?
The agent can then convert the requirement into a structured proposal and prepare the smallest appropriate infrastructure change for review.
More than text-to-Terraform
Infrastructure as Prompt is sometimes presented as a simple pipeline:
Prompt -> Terraform -> Deploy
Natural-language code generation is certainly part of the story. Tools already exist that can generate Infrastructure as Code from prompts or help engineers interact with infrastructure tooling through AI assistants.
But code generation alone is not enough for production infrastructure.
A generated configuration may be syntactically correct while still being operationally wrong. It may duplicate an existing resource, violate a naming convention, create an overly broad firewall rule, use an unapproved module, ignore an environment-specific dependency, or increase the blast radius of a change.
The real value appears when the agent understands more than the prompt.
A useful infrastructure agent needs:
- Context: Existing code, state, inventory, documentation, architecture, and previous changes
- Domain knowledge: Networking, cloud platforms, security, reliability, cost, and operational practices
- Organizational rules: Naming conventions, approved modules, ownership, review requirements, and deployment procedures
- Tools: Repositories, CI/CD systems, policy engines, cloud APIs, monitoring platforms, and ticketing systems
- Guardrails: Limited permissions, human approvals, audit trails, fail-closed behavior, and clear safety boundaries
- Feedback: Validation results, policy violations, failed plans, deployment outcomes, drift, and operational signals
The prompt is only the entry point. The agent provides the reasoning and orchestration needed to turn human intent into a controlled change.
A possible Infrastructure as Prompt workflow
A practical workflow could look like this:
Request -> Structured Intent -> Context-Aware Agent -> Reviewable Change -> CI/CD and Policy Checks -> Human Approval -> Controlled Execution -> Feedback
The first important step is converting a free-form request into a structured intent contract.
That contract can capture the desired outcome, environment, constraints, ownership, security requirements, expiry, and acceptance criteria. Before any repository change is created, the engineer can review and confirm the agent’s understanding.
The agent then examines the current environment and prepares a proposed change. Depending on the organization, that proposal might be a Terraform pull request, a Pulumi program, a Kubernetes resource, a Crossplane claim, an internal platform request, or an API operation.
CI/CD pipelines and policy engines can validate the proposal. An engineer reviews the technical impact and approves or rejects it. Only after those controls succeed should the change move toward execution.
This is not unrestricted prompt-to-production.
It is intent-to-controlled-change.
Where does Terraform fit?
Terraform and other Infrastructure as Code tools can currently provide a strong implementation layer beneath an infrastructure agent.
Terraform offers structured configuration, dependency handling, state management, planning, and a version-controlled workflow. These characteristics make proposed changes easier to inspect and integrate with existing engineering controls.
An agent can operate above that layer. It can understand a requirement, inspect an existing repository, identify the correct modules, prepare a narrowly scoped change, and submit it for review.
However, Infrastructure as Prompt is not necessarily tied to Terraform or any other single tool.
Different agents may use different IaC languages, controllers, platform APIs, or internal abstractions. Future infrastructure interfaces may hide more implementation details from the engineer while still preserving structured validation, policy enforcement, and auditability underneath.
Get Morteza’s stories in your inbox
Join Medium for free to get updates from this writer.
The important change is not which tool ultimately executes the request. It is where the human begins interacting with the system.
Why this approach could matter
Infrastructure environments are becoming more complex. Teams operate across multiple clouds, platforms, repositories, security boundaries, and regulatory requirements. Even experienced engineers spend significant time locating the correct module, reading documentation, comparing configurations, and translating tickets into implementation details.
Infrastructure as Prompt could reduce some of that friction.
Faster change preparation
Agents can search repositories, documentation, and existing configurations more quickly than an engineer performing each lookup manually. They can prepare an initial proposal while the engineer focuses on architecture and risk.
Easier access to organizational knowledge
Important infrastructure knowledge is often distributed across code, documentation, tickets, and the memories of experienced team members. A grounded agent can make that knowledge easier to access during a change request.
More consistent changes
When agents follow approved modules, naming conventions, security policies, and pull-request templates, they can help reduce inconsistent or duplicated configuration.
Faster onboarding
New engineers may be able to work with complex infrastructure repositories sooner if an agent can explain the structure, locate relevant components, and guide them through the established workflow.
Continuous maintenance
The same approach can extend beyond initial provisioning. Agents may assist with drift analysis, troubleshooting, dependency reviews, policy remediation, upgrades, documentation, and proposed maintenance changes.
These benefits are not automatic. They depend on the quality of the context, integrations, permissions, policies, and evaluation process surrounding the agent.
The risks are different from traditional automation
Traditional automation executes a predefined procedure. An agent can interpret a goal, choose tools, and propose actions that were not explicitly scripted in advance.
That flexibility creates value, but it also introduces new risks.
An infrastructure agent can misunderstand an ambiguous request, use incomplete context, follow malicious instructions hidden in untrusted content, or propose a technically valid change with an unacceptable operational impact.
For that reason, production-oriented Infrastructure as Prompt requires strong controls:
- Least-privileged access
- Clear repository and environment scope
- Structured confirmation of intent
- Policy-as-code and security validation
- Plans, tests, and reviewable diffs
- Protection against instructions embedded in untrusted tickets or files
- Human approval for material changes
- Complete audit trails
- Safe rollback and recovery procedures
- Continuous evaluation using realistic failure cases
The more capable an agent becomes, the more important these controls become.
What could this mean for infrastructure engineers?
Infrastructure as Prompt is not only a tooling change. It may change how infrastructure work is divided between humans and machines.
Engineers currently spend substantial time translating requirements into configuration syntax, locating examples, updating repetitive blocks, and coordinating routine workflow steps. Agents can increasingly assist with this mechanical translation.
That does not make infrastructure knowledge less important. It makes deep infrastructure knowledge more valuable at a higher level.
Engineers may spend more time on:
- Architecture and system design
- Defining infrastructure intent and acceptance criteria
- Building reusable modules and internal platforms
- Designing security policies and operational guardrails
- Reviewing agent proposals and understanding blast radius
- Evaluating agent reliability
- Investigating complex failures and unexpected interactions
- Connecting infrastructure decisions to business requirements
Knowing Terraform, Kubernetes, networking, cloud platforms, and security will still matter because engineers must judge whether an agent’s proposal is safe and correct. But syntax knowledge alone may become less differentiating as agents handle more routine authoring.
The infrastructure engineer of the future may not only manage infrastructure. They may also design, constrain, evaluate, and supervise the agents that manage it.
Where should teams begin?
Teams do not need to start with autonomous production deployment.
A safer adoption path is incremental:
- Use agents to explain repositories and existing infrastructure.
- Let them review requests and identify missing information.
- Allow them to prepare read-only analysis and proposed changes.
- Require pull requests, automated validation, and human approval.
- Test the workflow using realistic edge cases and failure scenarios.
- Expand permissions only when the agent has demonstrated reliable behavior.
The first goal should not be maximum autonomy. It should be a useful, repeatable, and reviewable workflow.
Final thoughts
Infrastructure as Code changed infrastructure from a collection of manual actions into something structured, versioned, and automatable.
Infrastructure as Prompt may introduce the next interaction layer: engineers express intent, agents interpret that intent within the context of the real environment, and existing engineering controls determine whether the resulting change is safe to execute.
The approach is still emerging. Its terminology, architectures, and tools will continue to evolve. But the direction is increasingly visible: natural-language interfaces, context-aware agents, structured infrastructure changes, and human oversight are beginning to converge.
The most interesting question is not whether an AI model can write Terraform.
It is whether we can build infrastructure agents that understand enough context, follow enough policy, and operate with enough control to become trustworthy engineering collaborators.
Infrastructure as Code changed how we define infrastructure.
Infrastructure as Prompt may change how we communicate with it.
Do you see Infrastructure as Prompt as the next stage of IaC, or as a new interface that will exist alongside it? And which skills should infrastructure engineers develop for this transition?
