Turning plain English into Terraform you would actually merge

A prompt that returns cloud infrastructure demos beautifully. What decides whether anyone is still using it a month later is what the generated code looks like when something has to change.

DeployWhisper AI sells cloud provisioning to teams with no DevOps hire. You describe what you need, and it returns Terraform, a GitHub Actions pipeline and a running environment on AWS or GCP. We built it. The longest part of that build was not the model, and it was not the cloud APIs.

The demo is easy. The second week is the problem.

Any current model will produce something that looks like Terraform from a sentence. The first provision succeeds, the room is impressed, and the tool has proved nothing. The test arrives a month later, when somebody needs to add a queue and opens the repository: resource names that follow no convention, no modules, a region hard-coded in four places, and a state file nobody in the building can explain.

At that point the product has not removed the infrastructure work. It has moved it into a codebase nobody wrote, which is a worse place than where it started.

Constrain the output, not the prompt

The design decision that made the product viable was to stop treating this as a text-generation problem. The model does not write Terraform from nothing. It selects and parameterises modules from a fixed library, and retrieval is what makes that selection reliable: the description is matched against module schemas held in a vector store, and the schemas are strict about what a valid answer looks like.

• The module library is ordinary infrastructure-as-code that a person on the team wrote and reviewed. The model chooses and configures. It does not invent.
• Generated variables have to satisfy a schema before a plan is offered. A missing region fails validation instead of quietly acquiring a plausible default.
• Anything the description does not settle becomes a question in the conversation rather than an assumption in the code.

The third one is where most of these products fall over. A model asked for "a Node API and a database" can fill in twenty decisions without mentioning any of them, and every one it gets wrong is a decision the buyer did not know had been made on their behalf. Asking two questions costs ninety seconds and is the difference between a tool and a party trick.

Show the work while it is happening

Provisioning is slow, opaque and occasionally destructive, which is a poor combination for something a stranger is asking you to trust with an AWS account. Two things in the interface do the persuading. The generated Terraform opens in an editor before anything runs, so nobody has to accept a black box to use the fast path. And the runner streams its output to the dashboard over a socket while the provision is in flight.

Neither is a feature anyone asks for in a sales call. Both are why the second run happens. People do not trust a deployment tool because the first attempt worked; they trust it because they watched it work.

The credentials question arrives before the product question

This product asks for the most dangerous secrets a company owns: cloud IAM keys, and a GitHub token with write access to the repository. That is not a detail to be handled after launch. Keys live in a dedicated vault, scoped per tenant, and the runner receives what it needs for the length of a job rather than holding a standing copy.

Where we said no

Two classes of change are deliberately not automated. The tool will not silently destroy or replace a resource that holds data, and it will not touch production networking on an existing account. In both cases it produces the plan and stops. The reason is not caution for its own sake: an automation that is wrong once in a hundred runs is fine when the failure costs a rebuild, and unshippable when it costs a database.

Naming that boundary out loud turned out to help the sale rather than hurt it. A senior engineer who is told the tool refuses to guess at the dangerous half is more willing to let it handle the other half.

The part that generalises

Very little of the above is specific to Terraform. Wherever a model's output becomes an artefact that somebody else has to maintain, whether that is a migration, a contract or a report that feeds a decision, the design question is not how good the generation is. It is what shape the output is constrained to, and who has to live with it afterwards. That is the whole difference between AI that removes work and AI that relocates it.