From Meeting Transcript to Terraform Apply: An Architecture That Keeps Humans in Charge
The fantasy is simple: upload a meeting transcript, ask an AI to build the platform, return after lunch to find Azure deployed.
I do not want that system.
I want the useful version: AI compresses the distance between conversation and implementation, while named humans still own requirements, architecture, cost, security and deployment authority.
The path from transcript to terraform apply should contain gates. Not because the model is weak, but because infrastructure has consequences.
Stage 1: turn conversation into explicit requirements
Meeting transcripts are full of incomplete sentences, status performance and assumptions that nobody notices because everybody in the room shares context. They are evidence, not specifications.
Give the transcript to a strong model such as GPT-5.6 Sol and ask for a structured requirement pack:
- business objective and success measures;
- functional requirements;
- security, availability, recovery, performance and residency constraints;
- known systems and integrations;
- explicit decisions;
- assumptions;
- contradictions and unanswered questions;
- owners and deadlines.
Require every important claim to point back to a transcript passage. The model should distinguish “the client decided” from “the model inferred.”
Human gate 1: requirement workshop
The architect and stakeholders review the pack. They correct names, reject invented certainty and answer the smallest set of blocking questions. The approved requirement baseline becomes versioned input for design.
Stage 2: create the HLD
The model can now draft the High-Level Design: context, architecture principles, major Azure services, trust boundaries, data flows, identity model, networking posture, availability zones, observability, recovery objectives and major alternatives.
It should also create Architecture Decision Records. A diagram without the rejected alternatives is just a picture.
Generate diagrams as code - Mermaid, PlantUML or Structurizr - so they can be reviewed and versioned beside the design. The diagram should be derived from the same named components used in the HLD, not drawn independently as decoration.
Human gate 2: architecture approval
Cloud, security, application, data and operations owners review the HLD. Cost assumptions are checked against expected usage. Policy exceptions are explicit. Only an approved HLD may become an LLD.
Stage 3: make the LLD executable
The Low-Level Design removes ambiguity. It defines subscriptions, resource groups, regions, naming, tags, SKUs, address spaces, subnets, private endpoints, DNS zones, identities, role assignments, encryption, diagnostic settings, backup, retention, alerts and deployment dependencies.
Every Terraform module should be traceable to an LLD component. Every LLD component intended for deployment should map to code, an external dependency or a declared manual action.
This traceability matrix is the bridge that prevents documents and infrastructure from quietly becoming different systems.
Stage 4: let Codex inspect before it writes
For a new repository, Codex can scaffold providers, backend configuration, reusable modules, environment roots, tests and documentation.
For an existing Terraform architecture, generation must begin with inventory:
- Read module boundaries, versions and naming conventions.
- Inspect state and backend configuration without exposing secrets.
- Identify existing resources, imports and ownership boundaries.
- Detect policies, CI workflows, tests and security scanners.
- Produce an impact plan before editing.
The instruction should be to extend the established architecture, not replace it with the model's favourite layout.
Codex works on a branch. It edits only approved scope. It runs terraform fmt, terraform init -backend=false, terraform validate, module tests and the repository's security checks. Failures return to the code loop; they do not disappear into a confident summary.
Human gate 3: code review
Reviewers compare the code against the LLD and the plan against the code. They focus on destructive replacements, identity, public exposure, network routes, data retention, cost-heavy SKUs and drift.
Stage 5: plan is evidence; apply is authority
Terraform's plan/apply separation is exactly what an AI-assisted workflow needs. Generate a saved plan in automation, render a human-readable summary and retain the full artefact securely. Plan files can contain sensitive data and must never be committed to Git.
The agent may explain the plan, but it does not approve its own work.
Human gate 4: apply approval
A named approver accepts the exact saved plan. Automation applies that plan, not a freshly generated surprise. Production requires stronger separation than development: protected environment, short-lived identity, policy checks, audit trail and rollback or forward-fix procedure.
Stage 6: prove the deployed state
Deployment is not completion. Run smoke tests, policy compliance, connectivity checks, private-DNS resolution, diagnostic verification, backup validation and cost-tag checks. Compare deployed resources with the LLD traceability matrix. Produce an evidence pack with outputs, exceptions and unresolved risks.
Then update the HLD and LLD if reality changed. Documentation is part of state.
What AI should own
AI should own the tedious continuity: extraction, cross-referencing, first drafts, diagram consistency, code generation, validation loops and evidence assembly.
Humans should own ambiguity, trade-offs, risk acceptance and irreversible authority.
That is not a slower version of autonomy. It is a faster version of engineering.
Build an artefact chain, not a document pile
The most important property of this workflow is traceability. Each artefact should inherit identifiers from the one before it.
A requirement might be SEC-014: all workload data must remain in India. The HLD maps SEC-014 to a regional topology, approved service list and disaster-recovery decision. The LLD maps it to exact regions, resource settings, private endpoints, diagnostic destinations and policy assignments. Terraform variables and module outputs reference the same decision. Tests prove the deployed resources comply.
Without those links, AI can produce five individually impressive documents that disagree in five quiet ways. With them, a change becomes visible. If the business later approves cross-region recovery outside India, the team can see which diagrams, decisions, modules and tests require revision.
The chain should look like this:
transcript evidence → requirement ID → architecture decision → resource design → code → plan → test evidence
That is the real product. The prose is only one view of it.
Make the HLD decide and the LLD instruct
High-level and low-level design documents often fail because both hover at the same altitude. The HLD becomes a collection of cloud icons. The LLD repeats those icons with more arrows.
An HLD should explain the important choices: why this topology, why this platform boundary, why this identity model, why this recovery target, why this integration pattern. It should show trust zones, data movement, availability assumptions and the ownership split between platform and workload teams.
An LLD should be executable in spirit even when it is not code. It names resources, subnets, address spaces, ports, private DNS zones, identities, roles, encryption settings, retention periods, scaling rules, deployment order and validation commands. If two competent engineers can read the LLD and build substantially different platforms, the detail is not yet low enough.
This is where a model is valuable. It can compare the LLD against a checklist, find undefined values, detect a subnet that appears in the diagram but not the table and notice that the recovery objective has no backup configuration. It should raise those gaps before it generates Terraform.
Existing Terraform changes the job
Greenfield generation is the easy case. Most useful work enters an estate that already contains modules, state, naming rules, exceptions and history.
Before changing existing Terraform, the coding agent should inventory:
- module sources and pinned versions;
- provider constraints and aliases;
- backend and workspace strategy;
- naming, tagging and resource-group conventions;
- existing state addresses and imported resources;
- policy-as-code and CI checks;
- variables supplied outside the repository;
- local patterns that are intentional even when they are not fashionable.
Then it should propose the smallest coherent change. Rewriting a working module into the agent’s preferred style is not architecture. It is vandalism with good formatting.
State deserves special treatment. The agent may inspect state metadata when authorised, but state files and saved plans can contain secrets and sensitive attributes. They belong in controlled backends and protected CI artefacts, never inside the prompt or the repository.
The gate matrix
A practical pipeline can classify gates by evidence and authority:
| Gate | Evidence presented | Decision owner |
|---|---|---|
| Requirements accepted | transcript citations, assumptions, open questions | product owner + architect |
| HLD accepted | options, trade-offs, risks, cost range | architecture authority |
| LLD accepted | resource design, security controls, traceability | engineering + security |
| Plan accepted | exact saved plan, policy results, destructive changes | environment approver |
| Release accepted | deployment tests, exceptions, rollback readiness | service owner |
The model can prepare every column. It cannot quietly become every owner.
What to automate first
Do not begin by allowing an agent to apply production infrastructure. Begin where error is cheap and evidence is strong.
Automate transcript classification, requirement extraction, glossary generation, diagram linting, Terraform formatting, provider validation, module documentation and test-evidence assembly. Next, allow pull-request creation in a sandbox repository. Then introduce ephemeral environment deployment with cost limits. Only after evaluations show consistent behaviour should the system prepare production plans.
Autonomy should expand through demonstrated control, not excitement.
The destination is not infrastructure that builds itself. It is an engineering system in which every handoff loses less context, every decision has an owner and every deployment can explain how a sentence in a meeting became a resource in a cloud account.