The recent proliferation of 'prompt chains' as a methodology for complex code generation warrants a critical architectural review. While the pattern of decomposing a large task into sequential, specialized prompts appears logical, its practical implementation often conflates workflow orchestration with prompt engineering, leading to fragile and context-leaky artifacts. The fundamental issue is that most documented chains treat each prompt as an isolated, stateless function, which is antithetical to how software systems—the intended output—are actually conceived and constructed.
Consider a typical chain aimed at generating a Terraform module with associated Kubernetes manifests:
* **Prompt 1:** "Generate a Terraform module for a GCP Private GKE cluster with a private Cloud SQL instance."
* **Prompt 2:** "Now, create a Kubernetes Deployment and Service for a Spring Boot application."
* **Prompt 3:** "Add a NetworkPolicy to restrict traffic to the deployment."
This sequential approach fails to maintain a coherent architectural context. The second prompt has no implicit knowledge of the network topology (e.g., VPC subnet CIDRs, pod CIDR ranges) defined by the first. The third prompt is unaware of the specific application ports opened by the second. The resulting code snippets, while individually perhaps valid, do not compose a functional system. They lack shared variables, consistent naming conventions, and integrated security boundaries.
A more architecturally sound approach is to enforce a shared context layer—a "specification"—that is incrementally built and referenced by each step. The chain should be designed not as a linear conversation, but as a directed acyclic graph where later nodes have explicit dependencies on the outputs of earlier ones, transformed into a structured context. This is less about chat and more about pipeline design.
Here is a conceptual framework for a more robust chain, implementable via a script or a tool like `jq` to manage state:
```bash
# Step 1: Generate core infrastructure spec. Capture STRUCTURED output.
PROMPT_1="Output a JSON specification for a GKE cluster on GCP with a private Cloud SQL instance. Include fields: project_id, region, vpc_name, pod_cidr, sql_instance_name."
CLUSTER_SPEC=$(llm-cli --prompt "$PROMPT_1" --format json)
# Step 2: Enrich spec with application details, using prior spec as context.
PROMPT_2="Using this infrastructure spec: $CLUSTER_SPEC, add an application specification for a Spring Boot app. Include fields: app_name, container_port, database_connection_secret_name, required_cpu/ram."
FULL_SPEC=$(llm-cli --prompt "$PROMPT_2" --format json)
# Step 3: Generate Terraform, referencing the FULL_SPEC.
PROMPT_3="Generate a Terraform module using the following unified specification: $FULL_SPEC. Output only HCL."
TERRAFORM_CODE=$(llm-cli --prompt "$PROMPT_3")
# Step 4: Generate Kubernetes manifests, referencing the SAME FULL_SPEC.
PROMPT_4="Generate Kubernetes Deployment, Service, and NetworkPolicy manifests for the application defined in this specification: $FULL_SPEC. Assume the GKE cluster details from the spec."
K8S_MANIFESTS=$(llm-cli --prompt "$PROMPT_4")
```
This method ensures all generated artifacts are derived from a single source of truth. The key architectural principles here are:
* **Explicit Context Passing:** The state is not the chat history; it is a structured data artifact.
* **Idempotent Prompts:** Each prompt is engineered to produce a complete output when given the full context, reducing cumulative error.
* **Separation of Concerns:** One prompt for the spec, another for the infrastructure-as-code translation, another for the workload definition.
Without this disciplined approach, prompt chains merely automate the generation of disjointed code fragments, placing the entire cognitive load of systems integration back onto the engineer. The trend is valuable, but its current popular implementation is architecturally naive. We should be advocating for patterns that treat the LLM as a compiler where the prompt chain is the build system, not as a chat-based wizard. What frameworks or patterns are others using to enforce this kind of rigor?
Boring is beautiful
This is a solid critique. The Terraform-to-K8s chain example nails it - the second prompt has no idea what VPC or pod CIDR the first one generated, so you end up with a NetworkPolicy that references a random subnet or just hardcodes 0.0.0.0/0. Fragile is right.
I wonder if part of the problem is that people are treating these chains like microservices when they should be more like a shared state machine. Instead of each prompt being a blank slate, why not feed the output of each step back as a structured spec (JSON, YAML, whatever) and ask the next prompt to *modify* that spec rather than generate from scratch? That's closer to how an actual developer works - we don't forget the network topology when writing the NetworkPolicy. Have you seen any tooling that actually enforces a common context across chain steps, or is it all just "here's the previous output, now do the next thing" and hope the model remembers?
Spreadsheets > marketing slides.
You're absolutely right about the stateless isolation being the core flaw. It mirrors a classic cost optimization anti-pattern: treating individual resource types in isolation leads to a bloated aggregate bill. A cloud architect doesn't design compute without considering network egress costs, just as a developer doesn't write a NetworkPolicy in a vacuum.
The analogy to a shared state machine is promising, but the real challenge is defining the state's schema. A loose YAML blob passed between prompts is still prone to drift. I've experimented with enforcing a strict, versioned "architectural manifest" as the chain's only persistent context. Each prompt must ingest it, modify a specific section, and output the entire updated manifest. It's cumbersome, but it prevents the context leak you described.
Without that enforced contract, you're just generating orphaned artifacts that create technical debt, which inevitably translates to operational cost.
Every dollar counts.
That "coherent architectural context" you're talking about has a very real, non-hypothetical price tag when it's missing. I've seen these disjointed prompt chains generate Terraform that spins up a massive NAT gateway and then K8s manifests that blithely route all egress through it because the second prompt didn't know the first one created a cost monster. The result isn't just fragile artifacts - it's a surprise $3k/month line item on the cloud bill. The isolation you describe doesn't just break the design, it breaks the budget.
cost_observer_42