We are currently witnessing a massive shift toward agentic engineering, but we are doing it backwards. Instead of treating the LLM as a magic typewriter for syntax, we should be using it as a requirements architect.
The Shift from Code Generation to Specification Mapping #
The real power of a modern LLM isn't its ability to remember the syntax for a for
loop; it's its ability to ingest messy, human-centric ideas and transform them into a rigorous, structured specification.
In the 80s, we had the concepts of formal methods and structured specification, but we lacked the compute and the linguistic intelligence to make them scalable for every developer. Today, we have both. The goal shouldn't be "AI generates code." The goal should be:
-
Elicit Requirements: Use the LLM to interview the user (or yourself) to uncover edge cases, constraints, and business logic.
-
Generate Formal Specifications: Use the LLM to output a high-fidelity, machine-readable specification (like a JSON schema, a TLA+ model, or a highly structured Markdown spec).
-
Deterministic Mapping: Use that specification to drive the actual code generation or, even better, to guide a deterministic compiler or code generator.
By focusing on the specification, you create a "source of truth" that persists across the entire Software Development Life Cycle (SDLC). If the requirements change, you update the spec, and the code follows. This is how civil engineers build bridges—they don't just "vibe" a structure into existence; they work from blueprints and circuit diagrams.
A Practical AI Workflow for Engineering #
If you want to move away from the "prompt-and-pray" method, try shifting your prompt engineering toward specification generation. Instead of asking for code, try a workflow like this:
"I want to build a rate-limiter for a distributed API. Ask me 10 questions to
uncover the specific constraints regarding latency, storage, and algorithm
type (e.g., Token Bucket vs Leaky Bucket)."
"Based on my answers, generate a formal technical specification in YAML
format that defines the state transitions, error conditions, and
input/output schemas."
"Using the YAML specification provided above, generate a TypeScript
implementation that strictly adheres to these state transitions."
When you follow this path, the LLM isn't just guessing what you want; it's working within a sandbox of its own logic that you have verified. This is how we bridge the gap between the chaos of LLM randomness and the necessity of software reliability. We are finally in a position where we can combine formal methods with massive compute to move beyond "coding by vibes" and into actual automated engineering.
Next Building a decentralized agent mesh is useless if the nodes →