Naoyuki Hirakawa

Building an LLM-Assisted Infrastructure Design Lifecycle

LLMs are useful in infrastructure design, but not because they can magically produce final architecture decisions. Their stronger value is in helping engineers turn fragmented information into structured, reviewable, and traceable artifacts.

1. Fragmented Engineering Work

Infrastructure design rarely starts from a clean source of truth. A design team may have meeting notes, an old design excerpt, a communication matrix, review comments, vendor answers, and a list of open questions. Each source may use different terminology. Some statements are confirmed. Some are assumptions. Some are requests. Some are unresolved issues that need customer, vendor, or engineering confirmation.

This fragmentation creates a practical problem. Before a team can decide what to build, it needs to know what has actually been said, where it came from, and whether it has been approved.

LLMs can help with this kind of structuring. They can extract candidate requirements, normalize terminology, identify contradictions, and draft review artifacts. But that assistance only stays useful if the workflow preserves source evidence and does not blur the line between draft and decision.

2. Why One-Shot Generation Is Not Enough

The tempting pattern is to ask an LLM to “create the design.” That shortcut is risky. In infrastructure work, a confident document can hide missing evidence. A polished paragraph can make an assumption look approved. A generated recommendation can accidentally commit scope, risk, or implementation behavior.

One-shot generation also misses the fact that design work changes over time. New comments arrive. A vendor clarifies behavior. A migration exception appears. A monitoring requirement moves from high-level design into detailed-design handoff. These changes are not just edits; they are semantic deltas that can affect scope, risk, and ownership.

The safer approach is to make the LLM part of a lifecycle. The workflow should ask: What source produced this claim? Is it confirmed or assumed? What changed since the previous cycle? Who must approve the change?

3. From Documents To Lifecycle

An LLM-assisted infrastructure design lifecycle can start with simple Markdown files:

This structure is intentionally plain. Markdown files are easy to review in Git, easy to diff, and easy to discuss. They make the workflow inspectable before any API or SaaS UI exists.

The lifecycle also encourages better prompts and better evaluation. Instead of asking for a final answer, each step asks for a bounded artifact: a source manifest, a requirements table, an unresolved issue list, a delta report, or an approval checklist.

4. Human Approval As A Design Constraint

Human approval should not be a footer. It should be a design constraint in the workflow.

In infrastructure design, humans must own decisions about architecture direction, scope commitment, customer-facing language, risk acceptance, detailed-design handoff, and production-impacting changes. An LLM can prepare the evidence and draft the artifact, but it should not silently approve the outcome.

A useful workflow makes this visible. Pending approval stays pending. Unresolved issues stay unresolved. Assumptions are not promoted into confirmed facts. Risk acceptance is not implied by the existence of a document.

This is not a limitation of the workflow. It is the point of the workflow.

5. Why Network Design Is A Useful Starting Point

Network and infrastructure design are good starting points for this pattern because the work naturally contains dependencies and uncertainty. Connectivity requirements depend on sources and destinations. Migration behavior may differ by branch or phase. Cloud security behavior may depend on policy configuration. Monitoring requirements may be known at a high level but deferred to detailed design.

These are not just technical details. They are review boundaries. Some belong in a high-level design artifact. Some belong in a detailed-design handoff. Some require customer confirmation. Some require vendor confirmation.

An LLM-assisted workflow can help sort those categories without pretending to be the final decision-maker.

6. Broader Applicability Beyond Networking

The same lifecycle can apply beyond network design. Many professional workflows have fragmented inputs, uncertain requirements, changing evidence, and approval gates. Examples include deployment planning, security review, operations readiness, migration planning, and customer success handoff.

The common pattern is not “generate the answer.” The common pattern is “structure the evidence, preserve uncertainty, identify deltas, and route decisions to humans.”

That is the direction I find most valuable for LLM-assisted engineering systems: not replacing expertise, but making expert review faster, clearer, and safer.

Practical Starting Point

The practical starting point does not need to be large. A small repository can define the lifecycle, provide templates, include synthetic samples, and run a few validation scripts. That is enough to test whether the workflow is understandable before any interface is built.

For example, a first version can check whether every requirement has a source ID, whether unresolved items remain visible, whether approval points are marked, and whether sample content stays public-safe. These checks are not comprehensive engineering validation. They are guardrails that make the workflow easier to review and harder to misuse.

This also gives technical reviewers something concrete to inspect. They can look at the source manifest, requirements table, delta report, and approval checklist instead of reading a generic promise that the system is “safe.” The evidence is in the files, and the files can improve over time.