Source-linked AI summary
Specifications: The missing link to making the development of LLM systems an engineering discipline
Ion Stoica, Matei Zaharia, Joseph Gonzalez, Ken Goldberg, Koushik Sen, Hao Zhang, Anastasios Angelopoulos, Shishir G. Patil, Lingjiao Chen, Wei-Lin Chiang, Jared Q. Davis
TL;DR
Natural-language ambiguity makes it difficult to specify and verify LLM tasks, complicating the development of modular, reliable systems. The paper develops a framework around clear task specifications and argues that reducing ambiguity supports engineering properties such as verification, reuse, and automated decision making.
Problem
LLM task specifications are often ambiguous, in part because they use natural language, making it difficult to build more powerful and reliable systems from simpler components.
Source: §1 · p. 1, §9 · p. 18Method
The paper draws on engineering lessons to develop a framework for clear statement specifications and solution specifications that make outputs verifiable.
Source: §2 · p. 6, §9 · p. 18Results
The paper argues that less ambiguous statement specifications make correct outputs more likely, while less ambiguous solution specifications make outputs easier to verify.
Source: §1 · p. 3Takeaways & Limitations
Clear specifications are presented as the foundation for engineering properties that support modular, reliable LLM systems and automated decisions.
Source: §9 · p. 18Formal specification frameworks are difficult to write and consequently cover narrow use cases, such as settings with very high failure costs.
Source: §3 · p. 6
Abstract
from arXiv · showhide
Despite the significant strides made by generative AI in just a few short years, its future progress is constrained by the challenge of building modular and robust systems. This capability has been a cornerstone of past technological revolutions, which relied on combining components to create increasingly sophisticated and reliable systems. Cars, airplanes, computers, and software consist of components-such as engines, wheels, CPUs, and libraries-that can be assembled, debugged, and replaced. A key tool for building such reliable and modular systems is specification: the precise description of the expected behavior, inputs, and outputs of each component. However, the generality of LLMs and the inherent ambiguity of natural language make defining specifications for LLM-based components (e.g., agents) both a challenging and urgent problem. In this paper, we discuss the progress the field has made so far-through advances like structured outputs, process supervision, and test-time compute-and outline several future directions for research to enable the development of modular and reliable LLM-based systems through improved specifications.
1 Introduction
LLMs promise another software revolution, but natural-language prompts make tasks ambiguous and outputs difficult to verify. The paper argues that clearer task specifications can support more reliable, modular LLM systems.
1 Introduction
- Specifications describe expected behavior, inputs, and outputs, helping developers decompose systems, reuse components, verify behavior, debug failures, and automate decisions.The paper distinguishes what a task should do (statement specification) from how to verify its outputs (solution specification).Source: §1 · p. 1
- LLM prompts often describe ambiguous, ill-defined tasks, contributing to hallucinations and making reliable system development difficult.Without clear solution specifications, applications may rely on humans to judge outputs, limiting fully automated decisions.Source: §1 · p. 2
- Existing efforts include structured outputs that constrain output formats and reward models that help select likely correct solutions from candidates.Structured formats specify output syntax more readily than semantics; reward functions must be precise enough to support automatic evaluation.Source: §1 · p. 3
- The paper advocates a coherent framework for improving task specifications, moving both statement and solution specifications toward less ambiguity.Less ambiguous task statements make correct outputs more likely, while less ambiguous solution specifications make outputs easier to verify.Source: §1 · p. 3
- Even inherently ambiguous tasks can be made clearer by asking users for clarification or stating assumptions in the answer.The paper illustrates both approaches with a travel-time prompt that omits cities and transportation mode.Source: §1 · p. 4, Figure 3 · p. 4
2 Challenges with today’s LLMs: building modular and reliable systems
The paper frames costly, monolithic model development and unreliable LLM products as barriers to progress. It draws on engineering’s shift toward modular systems and argues that specifications are the foundation for reliable, reusable components.
2 Challenges with today’s LLMs: building modular and reliable systems
- State-of-the-art model development costs hundreds of millions of dollars and are expected to climb to billions, while monolithic models make errors difficult to diagnose and fix.The paper argues these challenges can slow progress and hamper AI-industry growth.Source: §2 · p. 5
- The paper draws on engineering lessons to propose a transition from monolithic LLMs toward modular systems built from components.The authors note that modular AI efforts exist, while breakthroughs have largely continued to come from a handful of frontier labs.Source: §2 · p. 5
- Engineering industries moved from bespoke artifacts toward standardized, interchangeable components, lowering the cost and barriers to building complex systems.Modularity also makes systems easier to improve by isolating, repairing, or replacing faulty components.Source: §2 · p. 5
- LLM products face failures across varied scenarios because their flexibility leads them to handle ambiguous tasks, yet practical deployment often requires reliability without human supervision.The paper points to engineering processes and rigorous testing as precedents for ensuring reliability over time.Source: §2 · p. 5
- Specifications are the key building block for verifiability, debuggability, modularity, reusability, and automated decision making.The paper’s central thesis is that specifications describe what each component should do and how to verify its outputs.Source: §2 · p. 6
3 Specification, the foundation of software engineering
A task specification should state what a system must do and how to verify its outputs. The paper distinguishes ambiguity in these two parts and explains why specification precision varies with context and the cost of failure.
3 Specification, the foundation of software engineering
- A task specification includes a statement specification describing what the task should do and a solution specification describing how to verify its outputs.The two are complementary: implementation bugs mean the statement alone cannot establish that a solution is correct.Source: §3 · p. 6
- A task is unambiguous only when both its statement and solution specifications are unambiguous.Solving an equation is given as a case where substitution verifies a solution, while the longest-river question leaves an answer difficult to verify.Source: §3 · p. 6
- Specifications assume an interpreter, and the paper uses an average user rather than an expert as its default assumption.For factual questions, that user may not know the answer and could be misled by an incorrect response.Source: §3 · p. 6
- Formal specification frameworks are difficult to write, so they tend to cover narrow use cases where failure costs are very high.The paper cites chip design and nuclear reactor control as examples.Source: §3 · p. 6
- Lower-cost software failures can be addressed with weaker specifications, such as unit tests that cover common inputs but not every code path.Preconditions and postconditions can also filter some incorrect outputs without specifying every correct relation.Source: §3 · p. 6
- An unambiguous specification can describe stochastic behavior, whose outputs may be checked statistically.The paper gives an M/M/1 queue as an example and notes that confidence intervals can assess whether outputs meet specifications.Source: §3 · pp. 6–7
4 The five properties of software engineering?
The section presents five properties of software engineering—verifiability, debuggability, modularity, reusability, and automated decision-making—and explains how specifications support them.
4 The five properties of software engineering?
- Modularity and reusability let teams build components in parallel, assemble them, and use existing components such as query-parser libraries.Clear statement and solution specifications also help components exchange expected inputs and outputs and support reasoning about end-to-end behavior.Source: §4 · p. 7
- Verifiability uses solution specifications, often input-output tests, to check that a component produces correct outputs.For a query optimizer, verification checks that optimizations do not change query results.Source: §4 · p. 7
- Debuggability locates and fixes a failure through a top-down search from system to component, module, function, and instruction.The process relies on clear solution specifications to identify where behavior diverges from expectations.Source: §4 · p. 7
- Automated decision-making lets systems act without human supervision, which matters when people are too slow or error-prone.The query optimizer is an example; mission-critical systems include car anti-lock brakes and airplane takeoff and landing systems.Source: §4 · pp. 7–8
- Automated systems must avoid failures rather than rely on people to detect and remediate them, so their specifications tend to be less ambiguous.Automotive and aerospace industries use formal specification and verification tools such as SPARK and SCADE Suite.Source: §4 · p. 8
5 Comparing LLM development and software development
Traditional software development implements a task specification in a program, then applies inputs and verifies outputs. LLMs combine a task description and input in a prompt, reducing the need for programs and detailed specifications but leaving prompts vulnerable to ambiguity.
5 Comparing LLM development and software development
- Traditional development turns a task’s statement specification into a program that maps input to output, which can be checked against a solution specification.The LLM path instead takes a task description and input together in a prompt and directly produces an output.Source: §5 · p. 8, Figure 5 · p. 8
- LLMs trade specification unambiguity for the ease of writing tasks in natural language, and ambiguous prompts can produce undesired answers.The paper introduces approaches to address this challenge in the following section.Source: §5 · p. 8
- The sorting example pairs a program and its execution with an LLM prompt containing the same task description and input; neither example shows a solution specification.The prompt asks ChatGPT to sort the numbers 3, 1, 4, 1, 5, 9 in ascending order.Source: §5 · p. 8
6 Task specifications in LLMs
Natural-language prompts make it accessible to specify many tasks, but their ambiguity can leave task requirements unclear. The section distinguishes prompts that can be clarified from those that remain inherently ambiguous, and notes that statement and solution specifications can be unclear separately.
6 Task specifications in LLMs
- Natural language offers accessibility and generality for specifying tasks, but its inherent ambiguity creates a conflict for clear task specifications.The paper frames clarification approaches as a way to make specifications less ambiguous.Source: §6 · p. 8
6.1 Are LLM prompts inherently ambiguous?
- A prompt is inherently ambiguous when it is very hard or infeasible to disambiguate; a poem request in Shakespeare’s style lacks a clear way to specify or verify a good answer.The user might not know what a good poem looks like before seeing one.Source: §6.1 · p. 9
- A travel-time question can have a clarifiable statement specification, yet its solution specification may remain unclear because the prompt gives no way to check correctness.The missing details include which Venice and Paris are meant and whether travel is by car, train, or airplane.Source: §6.1 · p. 9
- A word-counting prompt leaves case sensitivity unclear, but adding an explicit instruction resolves the statement ambiguity; unit tests can specify expected outputs.The example contrasts a case-insensitive generated program with the desired case-sensitive behavior.Source: §6.1 · p. 9, Figure 7 · p. 10
7 Disambiguating LLM specifications (prompts)
The paper adapts human strategies for resolving ambiguity into approaches for clarifying LLM prompts, while noting that natural-language prompts often omit details humans infer from shared context. The approaches range from iterative clarification and context-building to structured outputs and improved instruction following.
7.1 How do humans deal with ambiguity?
- Human communication resolves ambiguity through multi-turn clarification, task-aware context, and models of the people communicating.These strategies let people leave details unstated when later questions or shared context can supply them.Source: §7.1 · pp. 10–11
7 Disambiguating LLM specifications (prompts)
- LLM communication cannot assume the shared context and iterative exchanges that let people leave details implicit, motivating techniques tailored to LLM interactions.The paper draws its proposed approaches from how people handle ambiguity in communication.Source: §7 · p. 10, §7.1 · p. 11
7.2 Solutions for prompt disambiguation
- Iterative disambiguation can use differing outputs to reveal prompt ambiguity, then ask the user questions or suggest clarifications.Different outputs do not always imply ambiguity, since an unambiguous prompt may have multiple correct answers.Source: §7.2 · pp. 11–12
- LLMs can expose assumptions in their answers so users can check whether those assumptions match their intent and refine the prompt.Suggesting clarifications or stating assumptions may require fine-tuning or post-training.Source: §7.2 · p. 12
- Domain rules and procedures can disambiguate specifications, but checking adherence is challenging when rules are informal.Formalizing rules where possible is a research direction.Source: §7.2 · p. 12
- Repeated interactions can reveal which prompts and models perform well, informing prompt changes or routing prompts to a suitable model.The paper also proposes externalizing preferences through detailed prompts or user feedback on example images.Source: §7.2 · p. 13
- Schemas constrain output syntax and pseudocode describes task behavior, but neither necessarily captures output semantics or removes ambiguity.Improving instruction following remains important even when prompts are unambiguous; possible avenues include test-time compute, pre-training, and post-training.Source: §7.2 · p. 13
8 The five engineering properties in the LLM context
The paper applies five engineering properties to LLM systems and proposes research directions for improving their specifications and development. It discusses verification, debugging, modular construction, reuse, and automated decision-making.
8 The five engineering properties in the LLM context
- The paper applies five engineering properties to LLM systems to identify challenges and suggest approaches for addressing them.The properties discussed are verifiability, debuggability, modularity, reusability, and automated decision-making.Source: §8 · p. 13
8.1 Verifiability: challenges and solutions
- Step-by-step verification can make individual solution steps easier to check, though correct steps do not guarantee end-to-end correctness.Execution can also help verify outputs, but should be reversible or isolated to limit the risk of irreversible mistakes.Source: §8.1 · p. 15
8.2 Debuggability: challenges and solutions
- LLM debugging is difficult because models are black boxes, while trial-and-error prompt changes neither guarantee correctness nor provide straightforward fixes.Proposed directions include generating and checking multiple outputs, automatic prompt generation, decomposition, and statistical methods for locating problematic components.Source: §8.2 · pp. 15–16
8.3 Modularity
- Task decomposition can organize complex systems into subtasks, with research exploring how to choose decompositions that balance performance and cost.The paper also identifies diverse proposals as a way to increase the chances of finding solutions that pass a task’s solution specification.Source: §8.3 · pp. 16–17
8.4 Reusability
- The paper argues that unclear specifications impede combining existing LLM services into larger systems, and identifies component selection and substitution as research directions.Component substitution raises the question of whether application performance can be predicted after replacing an LLM.Source: §8.4 · p. 17
8.5 Automated decision making
- Automated decision-making requires clear solution specifications, automatic verification, and inclusion of human context needed to assess correctness.Required verification tools must also be invoked automatically and their results interpreted unambiguously.Source: §8.5 · p. 17
9 Summary
The paper attributes engineering disciplines’ progress to five properties and argues that clear specifications underlie them. It identifies natural-language ambiguity in LLM task specifications as a challenge and calls for techniques to clarify specifications and verify outputs.
9 Summary
- The paper identifies verifiability, debuggability, modularity, reusability, and automatic decision making as five properties behind engineering progress.It links the first two to building systems from scratch, the next two to reliable LLM-based systems, and the last to systems requiring no human intervention.Source: §9 · p. 18
- Clear statement specifications and solution specifications form the foundation for these engineering properties.Statement specifications describe what a task should accomplish; solution specifications provide information to verify output correctness.Source: §9 · p. 18
- Because natural-language ambiguity makes LLM task specifications unclear, the paper argues for techniques to clarify them, verify outputs, and debug systems.The authors say this could support the five properties and accelerate development of more powerful and reliable solutions.Source: §9 · p. 18
Appendix A: The five engineering properties: Software Systems vs LLMs
Appendix A compares traditional software development with LLM prompting in relation to five software-engineering properties.
Appendix A: The five engineering properties: Software Systems vs LLMs
- The appendix presents a comparison of traditional software development and LLM prompting across five software-engineering properties.The supplied passages identify the comparison but do not provide its individual entries.Source: Table 3 · p. 22, Appendix A · p. 22
Appendix B: Why modular AI systems?
The appendix gives reasons to build modular AI systems from components rather than rely only on a single LLM call. It describes potential benefits in accuracy, cost, iteration, and integration with software.
Appendix B: Why modular AI systems?
- Decomposing complex tasks and aggregating independently solved subtasks can provide more reliable results.The passage also notes domain-specific training or fine-tuning and aggregation of multiple LLM calls as ways to improve accuracy.Source: Appendix B · p. 22
- Domain-specific fine-tuning can match or exceed a generic frontier model such as ChatGPT at a fraction of the cost.The passage says stitching together existing LLMs can also lower development cost.Source: Appendix B · p. 23
- Subtask components can make systems easier to debug and improve by isolating weak components, fixing specialized tasks, and reusing existing components.Source: Appendix B · p. 23
- Modular systems can combine LLMs with software components, such as using a calculator for arithmetic when it is faster and more accurate.Source: Appendix B · p. 23
- Figure 11 depicts three query-optimizer designs: text-to-SQL, text-to-intermediate-representation, and implementing the whole system in an LLM.The figure describes the last option with date and metadata assumed to be in model training or the prompt context.Source: Figure 11 · p. 23
Appendix C: Research projects
Appendix C points to research projects focused on verifiability and debuggability and presents a table of projects related to the five engineering properties.
Appendix C: Research projects
- The appendix identifies projects focused on verifiability and debuggability and includes a table of projects supporting the five engineering properties.The supplied passages do not describe the individual projects.Source: Appendix C · p. 23, Table 4 · p. 24
Appendix D: Frequently asked questions
The FAQ argues that rapid model progress does not replace modularity and reusability as a growth path for LLMs. It also describes how reducing ambiguity through structure and more detailed specifications supports collaboration and system use.
Is modularity necessary?
- Successive model generations do not replace modularity: the authors argue LLMs lose a major growth vector without modularity and reusability, paralleling assembly-line-era car production.The passage contrasts manually building each car generation with the assembly line used to produce the Ford Model T.Source: Appendix D · pp. 24–25
Can humans collaborate despite ambiguity?
- As human organizations scale, they add clear organizational roles and processes to reduce ambiguity; the army is presented as an especially structured example.The authors describe unambiguous communication standards and behavior tied to positions in the command chain.Source: Appendix D · p. 25
Are ambiguous specifications inherent to the task?
- Task ambiguity is described as difficulty specifying a task, not an inherent task property; users can externalize preferences such as image colors and proportions.The example asks someone else to choose a picture from “Golden Gate Bridge at sunrise,” prompting more detailed instructions.Source: Appendix D · p. 25
What are examples of engineering specifications?
- Engineering specifications can target builders with enough detail to build a system or users with enough detail to operate it; Figure 12 shows radio specifications for both.User specifications may describe setup, controls, expected behavior, errors, and troubleshooting.Source: Figure 12 · p. 25, Appendix D · p. 25