COSPEC: A Specification Elicitation Framework for Context Co-Construction with LLMs

Abstract

Vibe coding uses repeated natural-language prompts and minimal code review in large language model (LLM)-based development. Development may end before sufficient client–LLM context co-construction occurs. We propose CO-constructed SPECification (COSPEC), combining Joint Application Development facilitation with Specification by Example. Within a four-stage cycle, the LLM presents prototype scenarios for client review and records approved scenarios as Given–When–Then (GWT) specifications. An automated exploratory evaluation used an LLM client given a reference specification and engagement policies. We conducted 150 runs across five conditions involving COSPEC, GitHub Spec Kit-based Spec-Driven Development (SDD), and vibe coding, varying Claude/Codex role assignments and Maker reasoning levels. Dialogues and artifacts showed client-role revision requests and acceptance reflected in scenarios and GWT specifications. Mean requirements coverage through co-construction favored SDD under diligent engagement and COSPEC under satisficing engagement; significant method differences were limited to particular requirement categories and Judges. Both methods covered more requirements through co-construction under diligent engagement. These observations support the feasibility of delegating specification writing to the LLM while involving clients through repeated responses. However, presentation medium and procedure varied together, preventing isolation of their effects. Whether this supports sustained human participation requires human evaluation.

1. Introduction

1.1. Vibe Coding and Context Co-Construction

Advances in large language models (LLMs) are changing software development. Rather than writing code directly, users can develop software by submitting natural-language prompts to conversational LLM services such as ChatGPT, Claude, and Gemini. This has made it easier and faster for people with limited programming experience to create the software they want.

Vibe coding is a development approach that has emerged in this setting. Fawzy et al. [1] define it as repeatedly describing desired outcomes to AI tools through natural-language prompts while reviewing the generated code only minimally. Their study reports that developers engaged in vibe coding tend to accept generated code without independent verification or delegate code quality checks and error correction to AI. When errors occur, they ask AI to fix them by providing error messages rather than analyzing the code themselves.

Insufficient review of artifacts in vibe coding may appear to be a matter of individual diligence. However, simply asking individuals to review the outputs is not enough to address the problem. An LLM can implement details that the client has not explicitly decided, relying on its own assumptions. The client must therefore check both whether the requested functionality has been delivered and whether the LLM’s decisions align with the client’s intentions. If those decisions are not presented for review, the client must also identify what has been decided and what needs to be checked.

When the client accepts an artifact without examining these decisions, the alignment between the LLM’s assumptions and the client’s intentions remains unconfirmed. Delegating further development in this state can allow more unchecked details to accumulate. A later review of whether the implementation behaves as intended must then revisit those earlier decisions. Deferring review can thus create a vicious cycle in which the amount to be checked increases and development continues without that review.

To interrupt this cycle, clients must be able to examine and adjust the proposed functionality and behavior and contribute to requirements decisions. The client checks whether a proposal matches their intentions and requests revisions where needed; the LLM incorporates those responses into subsequent decisions and implementation. This paper defines context co-construction as the process through which the client and the LLM align their understanding and jointly establish the context needed for development. From this perspective, the problem with vibe coding is that development can proceed and artifacts can be accepted without such checking and adjustment.

Artifacts accepted without checking and adjustment may retain problems that emerge only in actual use. Even when the code executes successfully, required features may be missing or behavior may differ from the client’s intentions under particular conditions. Discovering such problems late may require changes not only to the affected functionality but also to other parts that depend on it. Defects can become more expensive to correct when they are discovered later [2]. The consequences of skipped review in vibe coding may therefore extend to the cost of corrections during maintenance and further development.

1.2. Research Problem, Question, and Scope

Addressing the vicious cycle of vibe coding requires a development process in which clients can contribute to requirements decisions. Spec-Driven Development (SDD) formalizes requirements in a specification before implementation and uses that specification as the basis for implementation and verification [3]. Because SDD first produces a specification from the initial prompt, clients can review and revise it to reflect their intentions in development. However, a specification approval procedure alone may not elicit sufficient client contributions. If clients approve a specification without understanding it, the cycle of unchecked decisions accumulating in the implementation can recur.

This paper therefore proposes an approach in which clients progressively shape requirements by responding to concrete behavior. The LLM organizes requirements into scenarios and presents them one at a time through prototypes. Clients check whether the demonstrated behavior matches their intentions and can request revisions when it does not. The LLM revises and presents the scenario again in response, then records the confirmed content in a specification. It presents the next scenario only after the client has checked the current one. The recorded specification provides the basis for subsequent implementation and verification. Through this process, clients clarify their intentions and contribute to the context needed for development.

This leads to the following research question.

Research question. Can a development process be structured to sustain client participation in context co-construction without requiring the client to write or review the entire specification?

The objectives and empirical scope of this paper are limited to the following three points.

• The proposed framework focuses on recording scenarios confirmed and approved through prototypes in a specification to serve as a basis for implementation and verification. The retained specification could also support subsequent requirements changes, but we do not evaluate its effectiveness in change tasks or whether it reduces the cost of maintenance or further development.
• The empirical evaluation examines whether the process supports checking and adjusting requirements in response to the client role. This includes recording confirmed content in a specification and using it for implementation and verification. We do not evaluate a causal relationship between context co-construction and artifact quality.
• The empirical evaluation is limited to an automated environment in which LLMs perform development roles, including the client role. We examine whether the process operates under prescribed response conditions and do not generalize the observed interactions to human client participation. Whether the process supports sustained participation and context co-construction by human clients must be evaluated in future work.

We propose COSPEC (CO-constructed SPECification), a framework that implements this process. COSPEC combines the facilitator role from Joint Application Development (JAD) with specification through concrete examples from Specification by Example (SbE). We compare COSPEC with vibe coding and SDD in an automated environment where LLMs perform the development roles, examining whether context co-construction occurs through the proposed process.

2. Background and Related Work

2.1. A Conceptual Model of the Vicious Cycle of Vibe Coding

Section 1 describes a vicious cycle in which unchecked decisions accumulate, making subsequent review more difficult, and explains the need for context co-construction to address it. This section draws on theories of cognitive load, automation bias, and overtrust to explain how that cycle may arise. These theories inform a conceptual model of the cycle and the design direction of the framework. We do not directly test the causal relationships among the factors in the model.

Sweller [4] and Sweller et al. [5] distinguish intrinsic, extraneous, and germane cognitive load. Extraneous cognitive load refers to unnecessary load caused by how information is presented rather than by the complexity of the task itself. In LLM-based development, clients may need to review an artifact containing many decisions in which they did not participate. If those decisions and their underlying assumptions are not presented explicitly, clients must identify them in the artifact and reconstruct the requirements it embodies. This work can add to the effort required to judge whether the requirements match their intentions. This paper takes the position that presenting an entire artifact without exposing its decisions and assumptions may increase extraneous cognitive load.

Kahneman’s dual-process account [6] distinguishes System 1, which operates quickly and automatically, from System 2, which operates slowly and deliberately. High cognitive load can limit the resources available for deliberate review and judgment, increasing reliance on intuition and heuristics. Excessive reliance on the outputs of automated systems is termed automation bias [7]. We interpret this as suggesting that, when review imposes high cognitive load, clients may follow the LLM’s output rather than assess the appropriateness of each decision.

Errors associated with automation bias include errors of commission, in which incorrect instructions are followed, and errors of omission, in which problems not identified by the automated system are missed. In vibe coding, these may correspond to accepting incorrect LLM-implemented behavior without verification and accepting an artifact without detecting missing requirements, respectively. Parasuraman and Manzey [7] explain that automation bias is also associated with insufficient attention to verifying system outputs. Even when people recognize the need for review, attention to other tasks can lead them to skip checking the results. Explaining the importance of review or instructing people to review is therefore unlikely to prevent automation bias on its own.

Lee and See [8] argue that trust in automation should correspond to its actual capabilities. Trust that exceeds this level is termed overtrust. Repeatedly obtaining runnable artifacts from simple prompts may lead clients to trust an LLM’s development capabilities. If they infer from successful execution that their requirements have also been implemented as intended, that trust extends to the LLM’s judgments about requirements they have not checked. We suggest that insufficient review associated with automation bias can reduce opportunities to recalibrate this trust. Without review, errors and omissions are harder to detect, and trust formed from execution results may remain misaligned with actual capabilities.

Overtrust in the LLM may reduce the client’s perceived need to review its artifacts. Clients who believe that the LLM will correctly understand and implement their needs may not check for missing requirements or unintended behavior. If errors are not immediately apparent, they may maintain this trust and delegate the next development task. A self-reinforcing cycle can thus arise: overtrust reduces review, while insufficient review preserves an inaccurate assessment of the LLM’s capabilities.

A client’s decision to stop reviewing and accept an artifact can be interpreted through satisficing. Simon describes satisficing as a decision strategy in which the search stops once an acceptable alternative is found, rather than continuing to seek the best alternative [9,10]. In LLM-based development, clients may likewise stop reviewing once an artifact runs and has no obvious problems, reasoning that it only needs to work. They may then fail to notice missing functionality or behavior that differs from their intentions under particular conditions. This paper interprets acceptance of immediately visible execution results, followed by the cessation of further requirements checks, as one manifestation of satisficing.

This paper connects cognitive load, automation bias, and overtrust in a conceptual model of the vicious cycle of vibe coding. The model posits that, when the cognitive load of review is high, clients may rely excessively on LLM outputs and skip review. Insufficient review can reduce opportunities to discover errors or omissions and revise assessments of the LLM’s capabilities. If overtrust persists as a result, subsequent review may also decline. Continuing development in this state allows unchecked decisions to accumulate, increasing the amount and difficulty of future review. We define the vicious cycle of vibe coding as this structure in which skipped review makes subsequent review harder and can lead to further review being skipped.

Addressing this cycle requires a process that specifies what clients should check, when they should check it, and how their responses inform subsequent development. The scope of decisions reviewed at one time needs to be bounded, with opportunities to review and revise unconfirmed details before they enter subsequent development. We therefore seek to structure the process so that the LLM presents concrete requirements decisions and clients check their alignment with their intentions or request revisions. The LLM incorporates those responses into later decisions and implementation. The next section examines how existing approaches support client review and revision.

2.2. Existing Approaches

This section reviews existing approaches in relation to the vicious cycle described in Section 2.1. We consider output quality improvement, SDD, LLM-based requirements engineering, and AI-based prototyping tools. These are not mutually exclusive categories; they provide a way to compare the support offered by each approach and its client review process. We examine how each approach divides and presents material for client review, when review occurs, and how client feedback and revision requests are reflected in requirements and implementation.

2.2.1. Approaches to Improving Output Quality

Context engineering seeks to improve LLM output quality by systematically organizing information such as project structure, coding conventions, and architectural decisions. Prompt engineering guides LLM reasoning or constrains output formats through techniques such as chain-of-thought prompting [11] and prompt patterns [12]. Both approaches help obtain desired outputs by structuring the information and instructions supplied to the LLM. However, specifying information and output formats does not itself define a client review process. That process must be designed separately, with prompts instructing the LLM to follow it.

2.2.2. Spec-Driven Development

SDD formalizes requirements in a specification before implementation and uses that specification as the basis for implementation and verification [3]. Clients can review and revise the proposed implementation described in the specification to reflect their intentions. After implementation, the artifact can be checked against the specification to determine whether the agreed requirements have been met.

In tools that support SDD, the LLM drafts a specification for the client to review and revise. Kiro generates requirements, a design, and a task list in sequence, using approved requirements as the basis for the design [13]. GitHub Spec Kit provides four stages—specification, planning, task decomposition, and implementation—and calls for reviewing and revising the artifacts produced at each stage [14]. Similarly, Claude Code’s plan mode presents a plan for approval before modifying files [15]. These approaches reduce the work of writing a specification or plan from scratch and provide opportunities to check and revise generated content before implementation.

However, even when drafting is automated, clients must still identify and correct missing or misinterpreted requirements. When the entire specification is presented at once, they must understand individual requirements and their relationships and judge whether they align with their intentions. Requiring review and approval is therefore insufficient to establish that clients have understood and checked the content. This paper instead seeks to structure review around checking concrete behavior and requesting revisions, rather than reviewing the entire specification.

2.2.3. LLM-Based Requirements Engineering

Requirements engineering (RE) includes eliciting and analyzing stakeholder requirements, documenting them in a specification, and validating that they reflect stakeholders’ intentions and needs. Research on LLM-based RE has explored the use of LLMs in these activities [16]. Approaches include direct interaction with clients to refine requirements [17,18] and the use of virtual stakeholders to explore needs or generate interview material [19,20,21]. This paper focuses on how clients and LLMs interact to refine and confirm requirements. Table 1 compares representative studies and systems in terms of the LLM’s role, the elicitation or support approach, human participation or intended use, and the main outputs.

Table 1. Representative approaches to LLM-based requirements engineering and forms of participation.

Study/System	LLM Role	Elicitation or Support Approach	Human Participation or Intended Use	Main Outputs
LLMREI [17]	Interviewer	Questions and answers, with follow-up questions adapted to responses	Answer questions to describe desired behavior and conditions	Elicited requirements
AISD [18]	Specification author and implementer	Iteration from use case generation through implementation and testing	Review, revise, and approve use cases; test the system and provide feedback	Use cases, design, implemented system
Elicitron [19]	Stakeholder simulator	Virtual users describe experiences and participate in interviews	Provide design context; virtual agents generate interview responses	Diverse user needs and latent needs
Shen et al. [20]	Interview support	Generate follow-up questions from interview transcripts	Proposed use by interviewers who review and select questions	Follow-up questions
Görer and Aydemir [21]	Interview training support	Generate dialogue scripts from guidelines and examples	Proposed use as instructional material for learning to conduct interviews	Training interview scripts

Note: Human participation or intended use describes how each approach operates and its proposed applications. It does not imply that Shen et al.’s approach has been validated in real interviews or that the educational effectiveness of Görer and Aydemir’s approach has been established.

In the interviewer approach, an LLM elicits requirements through questions and answers with stakeholders. LLMREI [17] is a GPT-4o-based chatbot configured to ask one question, or two related questions, at a time. Stakeholders answer these questions to describe desired behavior and conditions. LLMREI then adapts its follow-up questions based on their responses and the conversational context. This exchange allows stakeholders to progressively refine their requirements.

In human-in-the-loop specification-to-code approaches, the LLM produces specifications and implementations while clients participate through review and revision. AISD [18] comprises four stages: use case generation, system design, coding and automated testing, and system validation. Clients review LLM-generated use cases, revise them as needed, and approve them. The LLM then designs and implements the system based on the approved use cases. After implementation, clients test the system themselves. When problems are found, they can request corrections or add and revise use cases to continue development.

In the stakeholder simulator approach, LLMs assume virtual stakeholder roles to explore diverse needs. Elicitron [19] generates virtual user agents with different characteristics. Each agent imagines using a product and describes its actions, observations, and difficulties. Elicitron analyzes interview responses from these agents to elicit latent needs. It aims to explore diverse user needs and previously unconsidered usage situations early in product design.

In the interview support approach, LLMs generate questions or instructional material to support human-led requirements elicitation interviews. Shen et al. [20] used GPT-4o to generate follow-up questions from interview transcripts. They instructed GPT-4o to avoid common interviewer mistakes when generating questions. Based on question quality assessments by separately recruited participants, they also suggested the potential use of these questions in actual interviews. Görer and Aydemir [21] proposed generating instructional dialogue scripts from interview guidelines and examples. These scripts depict conversations between interviewers and stakeholders and can serve as material for learning how to conduct interviews.

2.2.4. AI-Based Prototyping Tools

AI-based prototyping tools generate interfaces or working applications from needs described in natural language. Tools such as v0 [22], Bolt.new [23], and Lovable [24] implement and present the functionality and interface layout described by clients. Clients examine the interface and behavior and describe desired changes; the tools then revise the artifacts accordingly.

Reviewing artifacts generated by AI-based prototyping tools can provide opportunities to refine requirements. By examining the interface and behavior, clients may add or revise needs that they could not initially express clearly. Feedback on prototypes can therefore help refine desired functionality and behavior as well as correct errors. This paper uses this characteristic to structure a review process in which clients refine requirements by checking prototype behavior and requesting revisions.

2.3. How COSPEC Differs from Existing Approaches

The approaches reviewed above support development by organizing information for LLMs, generating specifications and questions, or presenting working artifacts. COSPEC combines the facilitator role from JAD with example-based specification from SbE. The LLM presents requirements as concrete scenarios and records the content reviewed and approved by the client in a specification. Instead of writing or reviewing the entire specification, clients refine requirements by checking whether the presented behavior matches their intentions and requesting revisions.

SDD and COSPEC both formalize requirements in specifications and use them as the basis for implementation and verification. Tools supporting SDD [13,14] ask clients to review specifications and plans directly, whereas COSPEC presents scenario behavior for client review. Clients can thus contribute to requirements decisions by checking whether the demonstrated behavior matches their intentions and requesting revisions without reviewing the entire specification themselves.

LLMREI, AISD, and COSPEC all refine requirements through client participation, but they differ in how requirements are expressed and checked. In LLMREI, clients answer LLM questions to describe desired behavior and conditions [17]. In AISD, they review and revise use cases before implementation and check actual behavior through system testing afterward [18]. COSPEC differs from LLMREI in that clients review behavior presented through prototypes rather than describe the desired behavior. It differs from AISD in that clients review prototype behavior during requirements elicitation, and the LLM incorporates their revision requests and approvals into the specification.

AI-based prototyping tools and COSPEC both allow clients to refine requirements by checking working artifacts and requesting revisions. The prototyping tools reviewed above develop artifacts by modifying interfaces and behavior in response to feedback [22,23,24]. COSPEC obtains client review and approval of scenarios presented through prototypes. It differs from these tools by defining a process for using those approved scenarios to construct a specification that serves as the basis for implementation and verification.

COSPEC’s distinction therefore lies in its defined process of repeatedly presenting scenarios, obtaining client review and revision requests, and recording approved content in a specification. From the requirements elicitation stage onward, the LLM facilitator presents scenario behavior through prototypes. Clients judge whether each scenario matches their intentions and request revisions as needed. The LLM incorporates their feedback and requests into the scenario and records approved scenarios in the specification. Repeating this process refines requirements and builds the specification used for implementation and verification.

The next section explains the theoretical rationale and design principles underlying COSPEC’s iterative process.

3. Materials and Methods

This section explains the theoretical rationale and design principles underlying COSPEC, followed by its development process and evaluation methods.

3.1. Rationale for the Framework Design

Section 1 defined context co-construction as the process through which the client and the LLM align their understanding and jointly establish the context needed for development. This process aims to bring the two participants’ understanding of the requirements into sufficient alignment. Clark and Brennan [25] describe the interaction through which participants establish mutual understanding as grounding. A conversational contribution comprises two phases: presentation and acceptance. (In grounding, acceptance indicates that the presented content has been understood. It is distinct from product acceptance in the COSPEC process.) Repair may occur when evidence of understanding is insufficient or a misunderstanding becomes apparent. On this basis, we structure context co-construction as repeated interactions involving presentation, acceptance, and repair.

Interactions in vibe coding can also be mapped to presentation, acceptance, and repair in grounding. The LLM presents an artifact generated from the client’s prompt. The client can review whether it matches their intentions, decide whether to accept it, and request revisions when discrepancies arise. However, responsibility for initiating and directing these checks and revisions remains with the client. Clients must identify the decisions and assumptions to be reviewed within artifacts containing decisions in which they did not participate. They must also identify departures from their intentions and specify what needs to change. The conceptual model in Section 2.1 suggests that concentrating this work on the client may lead to skipped review. Opportunities to detect discrepancies and request revisions may then be missed, yet the LLM can continue development. Artifacts may consequently be presented and accepted repeatedly without either party checking and aligning their understanding. We regard this dependence on voluntary client review, together with the ability to continue development when review is skipped, as a structural vulnerability of vibe coding.

To avoid relying solely on voluntary client review, the party performing development also needs to support requirements refinement and review. To frame this support as a division of responsibilities, we draw on the acquirer–supplier relationship in ISO/IEC/IEEE 12207:2017 [26]. The acquirer obtains a software product or service, and the supplier develops and delivers it. We do not adopt the entire process; we map the client to the acquirer and the LLM to the supplier.

In conventional development, the development organization, acting as the supplier, has supported the acquirer in refining and reviewing requirements. Acquirers may find it difficult to express their needs clearly without assistance. Examples of such support include analysts eliciting needs through interviews or workshops and presenting prototypes to prompt acquirer responses. However, this support requires skilled professionals’ time and incurs costs, which may limit its availability in some development settings. When support is insufficient, acquirers must perform much of the work of expressing and reviewing their needs themselves.

In the development setting considered here, the LLM acts as the supplier. Repeated LLM generation still requires computation and time, but the cost of additional iterations may be lower than that of having a skilled professional perform the same work each time. The LLM can therefore be tasked repeatedly with generating and presenting examples and eliciting needs from client responses. This paper delegates to the LLM supplier some of the work of generating and structuring content that can otherwise remain with the acquirer in human-led development.

Delegating a role to an LLM does not, however, guarantee reliable execution of the process. Kolt [27] applies theories concerning human agents to AI agents, explaining that instructions cannot anticipate every situation and that agents therefore interpret instructions and exercise discretion. Tomašev et al. [28] likewise view delegation as defining authority, responsibility, and role boundaries, as well as allocating tasks. They therefore argue for distinguishing tasks that AI should perform from decisions that require human judgment. In this paper, the LLM generates examples and writes specifications, while the client retains responsibility for judging whether the presented behavior matches their intentions. To maintain this distinction, the system prompt specifies process rules, input and output formats, and approval conditions.

Even if the supplier follows its instructions, whether clients can refine requirements simply by examining examples and requesting revisions is a separate question. As Polanyi [29] observes, “we can know more than we can tell.” Clients may have expectations of a product without being able to express them as concrete requirements, a gap recognized in requirements engineering [30]. For example, a client may have an overall goal for a business application yet find it difficult to specify in advance how data should be categorized, aggregated, or displayed. Given a concrete example, however, the client can compare its behavior with their intentions and explain the differences, revealing details they could not express beforehand. Nonaka and Takeuchi’s SECI model [31] calls the conversion of tacit knowledge into explicit knowledge externalization. We use client responses to examples to support this process. The design assumption is that the supplier can create opportunities for clients to express tacit knowledge, not that responses alone will reveal every requirement.

The preceding discussion provides the rationale for the proposed delegation structure. We position the LLM as the supplier and assign it the work of expressing requirements through examples and organizing them into specifications. Process rules and approval conditions are specified in the system prompt, and a grounding loop gives clients opportunities to examine examples and request revisions. The process is designed to refine requirements progressively through these interactions. The next section explains the design principles and the combination of JAD and SbE used to implement them.

3.2. Design Principles

We apply the following five design principles to implement the delegation structure described in Section 3.1 as a development process.

• Delegation of requirements elicitation: The LLM expresses and presents requirements as concrete examples and organizes them into specifications; the client checks the proposed content and requests revisions.
• Responses to concrete examples: Clients confirm behavior and request revisions in response to concrete examples, rather than being required to articulate requirements independently.
• Procedural integration of the grounding loop: Presentation, acceptance, and repair are defined as part of the development process, repeatedly providing opportunities for clients to check proposals and request revisions.
• Rule-based control: The system prompt specifies how the LLM should facilitate the process and when approval is required, directing it to interact according to the defined procedure.
• Specification of approved scenarios: Scenarios approved by the client are preserved in a specification for implementation and product acceptance testing, rather than being left only in the conversation history.

The framework adopts Joint Application Development (JAD) and Specification by Example (SbE) to implement these principles. Table 2 summarizes the elements used for each principle.

Table 2. Methodological basis and implementation of the design principles.

Design Principle	Methodological Basis	Implementation in COSPEC
Delegation of requirements elicitation	JAD facilitator and scribe	The LLM generates examples and writes specifications; the client provides judgments
Responses to concrete examples	Concrete examples in SbE	Prototypes serve as the basis for judgment
Procedural integration of the grounding loop	JAD workshop cycle	Repeated presentation of examples, client review, correction of discrepancies, and presentation of revised examples
Rule-based control	Facilitation rules	The system prompt specifies facilitation behavior and approval conditions
Specification of approved scenarios	SbE and GWT	Approved scenarios are recorded as GWT specifications

JAD is a workshop-based methodology in which stakeholders jointly define requirements. Among the roles described by Wood and Silver [32], we focus on three that distribute the work of requirements elicitation. A neutral facilitator structures questions and leads the discussion. Participants with domain knowledge respond to questions and proposals, while a scribe documents the results. This division separates support for expressing needs, judgment, and documentation. The repeated presentation-and-response structure of the workshop provides a basis for incorporating the grounding loop into the process.

The framework uses this JAD role structure to delegate requirements elicitation to the LLM and elicit client responses. The LLM acts as facilitator and scribe, and the client acts as participant. Just as a JAD facilitator uses questions and proposals to help participants express their needs, the LLM in COSPEC presents prototypes to help clients express their intentions. Clients refine requirements by approving, rejecting, or selecting among the proposed prototypes.

The LLM facilitator should use concrete examples to help clients express requirements clearly, because ambiguous requirements can create discrepancies between client expectations and the product and lead to rework [30]. The framework therefore draws on Adzic’s SbE approach [33]. SbE uses concrete examples to establish agreement on requirements and develops them into executable specifications for implementation and verification. Even detailed textual examples, however, may leave room for different interpretations of how behavior unfolds. COSPEC presents examples as working prototypes so that clients can examine the behavior directly. By interacting with a prototype and comparing its results with their intentions, clients can express previously unarticulated requirements and request revisions. The approved scenarios are then recorded in a specification so that implementation and verification follow the same criteria.

A consistent format is needed to preserve approved scenarios as specifications. The Given–When–Then (GWT) pattern, proposed by North [34] as a scenario template for Behavior-Driven Development (BDD), comprises an initial state (Given), an action (When), and an expected outcome (Then). For example, creating an item and assigning it to a category can be expressed as follows: “Given a category has been registered, when the user clicks the add button to create an item and selects that category, then the item appears in the category’s list.” Separating conditions, actions, and outcomes makes it easier to map each scenario to verifiable behavior and convert it into an automated test. The framework records approved scenarios internally as GWT specifications, providing a common basis for implementation and verification.

COSPEC combines JAD’s division of roles with SbE’s example-based specification. The LLM facilitator presents scenario behavior through a prototype, and the client checks each scenario against their intentions, requesting revisions or approving it. When the client requests a revision, the LLM modifies and presents the prototype again. Once the client approves the scenario, the LLM records it as a GWT specification. Repeated presentation, acceptance, and repair allow clients to communicate their needs and participate in requirements refinement by responding to examples.

When clients participate by responding to examples, it is necessary to consider whether those responses make a substantive contribution to requirements decisions. In COSPEC, client responses determine how examples are revised and which scenarios enter the specification. If a client requests changes to behavior that differs from their intentions, the LLM revises the example accordingly. If the client selects an alternative or adds a condition, the LLM refines the example to reflect that choice or condition. A proposed scenario also requires client approval before it is included in the specification. Client responses thus provide the basis for the LLM’s revisions and specification writing. In this sense, clients contribute to requirements co-construction through their responses to examples.

The next section defines the COSPEC framework and its four-stage cycle, which implement these principles as a concrete development process.

3.3. The COSPEC Process

Section 3.2 established the integration of repeated presentation, acceptance, and repair into development as a design principle. COSPEC applies this principle to requirements elicitation and review of the implemented software, organizing the development cycle into four stages.

• Stage 1—Facilitation: Elicit requirements through three substages: goal exploration, the SbE response loop, and edge case exploration.
• Stage 2—Development: Design and implement the system based on approved GWT specifications.
• Stage 3—Verification: Verify the implementation through GWT-based acceptance tests and internal tests.
• Stage 4—Acceptance: Present the implementation to the client through a guided review and request product acceptance.

Clients participate in Stage 1 to refine requirements and in Stage 4 to review the implementation and approve product acceptance. In Stage 1, the LLM acts as a JAD facilitator, presenting prototypes, guiding review, and explaining assumptions and alternatives. In Stages 2 and 3, it acts as an implementer, independently carrying out design, coding, and testing based on the approved specification. In Stage 4, it returns to the facilitator role, presents the implementation through a guided review, and requests product acceptance. Client approval is required to move from Stage 1 to Stage 2.

After product acceptance in Stage 4, the cycle enters a waiting state. A client change request initiates the next cycle. Subsequent cycles address changed requirements and their impact on existing artifacts, following the same facilitation principles and procedures. Figure 1 summarizes the overall COSPEC process.

Figure 1. The four-stage COSPEC cycle: facilitation, development, verification, and acceptance. Blue stages involve the client, whereas green stages are performed independently by the LLM. The dot on the arrow indicates client approval to move from Stage 1 to Stage 2. GWT specifications provide the basis for implementation in the development stage and the acceptance criteria in the verification stage; they are not presented directly to the client. Facilitation comprises goal exploration, the SbE response loop, and edge case exploration. Both the SbE response loop and edge case exploration repeat the same sequence of presentation, response classification, and specification recording. During edge case exploration, behavior that is difficult to observe directly is presented through time-accelerated simulations or textual scenarios, followed by the same response classification and specification recording procedure.

3.3.1. Stage 1: Facilitation

In Stage 1, clients refine requirements by examining and responding to proposed content. This stage comprises goal exploration, the SbE response loop, and edge case exploration. Goal exploration establishes the purpose of development. The SbE response loop establishes functional flows through responses to prototypes. Edge case exploration defines behavior outside the main successful flow, or happy path. Each substage builds on the results of the preceding one.

Goal Exploration

Goal exploration establishes the business objective. It clarifies what the client seeks to achieve through the requested functionality or solution, setting the direction for subsequent requirements refinement. The facilitator helps the client explain the purpose of development through questions such as “What should be different from now once this is complete?” It then presents its understanding of the goal and asks whether that reflects the client’s intended direction, inviting corrections where needed. The facilitator records the confirmed goal using the client’s own wording as far as possible and avoids unnecessary technical terminology. It then identifies the interface type, such as web, mobile, or command-line interface (CLI), to determine how to prototype the software.

The SbE Response Loop

The SbE response loop is COSPEC’s core mechanism for refining requirements through client responses to prototypes. The facilitator (1) presents a working prototype, (2) collects and classifies the client’s response, and (3) records the approved scenario as a GWT specification. Prototype presentation and response review are repeated for each scenario, and approved scenarios are recorded in the specification. Once a scenario has been reviewed, the process moves to the next, progressively refining the requirements.

The first activity is prototype presentation. The facilitator provides instructions alongside the prototype to explain how to use it and what to check. It asks the client to try the behavior directly, for example: “Here is the first flow. Please try [specific action].” Guidance is needed because the prototype alone may not make clear what the client should examine, allowing relevant behavior to go unreviewed. These instructions create opportunities to check each behavior and request revisions. The facilitator also discloses the assumptions made when constructing the prototype. For example, when presenting a medical records screen, it might say: “I organized the records by date and title. Please also check whether this arrangement works for you.” This allows clients to review arrangements they did not specify and identify departures from their intentions.

The second activity is response collection and classification. The facilitator classifies client responses into four types. Table 3 summarizes the action taken for each type. A response indicating that the scenario matches the client’s intentions, such as “Yes, that’s right,” is classified as approval. A response indicating that the behavior itself differs from what the client wants, such as “This isn’t what I wanted,” is classified as a requirements mismatch. If the intended behavior is correct but does not work properly in the prototype, the response is classified as an implementation error. A response indicating difficulty in judging what behavior would be appropriate, such as “I’m not sure,” is classified as uncertainty.

Table 3. Client response types and their effects on the process.

Client Response	Facilitator Action	Effect on the Specification
Approval	Move to the next scenario	Create or confirm
Requirements mismatch	Revise or add a scenario	Revise
Implementation error	Correct the prototype and request another check	No change
Uncertainty	Present two or three alternatives	Defer until an alternative is selected

The facilitator handles negative responses by distinguishing requirements mismatches from implementation errors. For a requirements mismatch, it changes the scenario’s behavior or adds a new scenario and updates the prototype accordingly. For an implementation error, it preserves the intended scenario behavior, corrects only the prototype error, and asks the client to check the same behavior again. If the distinction is unclear, it asks: “Is the behavior itself different from what you want, or is it simply not working correctly?” For uncertainty, the facilitator presents two or three alternative prototypes. To support comparison, it varies only the part requiring a decision and keeps the rest unchanged. If the client proposes another alternative, the facilitator prototypes it and requests another review.

In the third activity, the facilitator records scenarios that the client has checked and approved through the prototype as GWT specifications. These specifications are internal artifacts for implementation and verification and are not presented to the client. Reviewing a written specification would require the client to reinterpret the described behavior, potentially introducing an understanding different from that established through the prototype. COSPEC instead asks clients to check and approve scenarios through prototypes and assigns the recording of approved scenarios to the LLM.

Edge Case Exploration

Edge case exploration begins after all normal scenarios have been approved through the SbE response loop. Exploring edge cases before normal scenarios are established would require related edge cases to be revisited whenever those scenarios change. The facilitator initially explores four types of edge cases: no data to display, extremely large or small amounts of data, network failures or invalid input, and behavior that changes over time. These categories provide a starting point and do not cover every edge case that may arise in a particular domain.

The facilitator presents edge cases through prototypes, asks the client to check them, and classifies the responses. Time-accelerated prototypes can be used when changes over time need to be examined. Textual descriptions are kept to a minimum and used only for edge cases that cannot be simulated through prototypes. In such cases, the reason for using text rather than a prototype is recorded in the conversation log.

After edge case exploration is complete, the facilitator proposes moving to Stage 2. The process advances if the client approves. Otherwise, the transition is deferred. If the client requests additional changes, the facilitator revises the relevant scenarios and asks the client to check them again. Once the changes have been incorporated, it again requests approval to move to Stage 2.

3.3.2. Stage 2: Development

Stage 2 covers design and implementation based on the GWT specification. Prototype code from Stage 1 is neither consulted nor reused as a basis for implementation. This rule is intended to preserve approved requirements while reducing the risk that technical debt in exploratory code carries over into the final implementation.

During Stage 2, the LLM creates and preserves design decision records, scenario-to-code mappings, and test code. The design decision records document the chosen designs, their rationale, and alternatives considered but not adopted. Scenario-to-code mappings identify where each scenario is implemented and help determine the scope of later changes. Test code covers acceptance tests based on the GWT specification and internal unit and integration tests; these are executed in Stage 3 to verify the implementation. The records and tests support subsequent changes and help recover the project structure and design rationale after the LLM’s context has been reset.

3.3.3. Stage 3: Verification

Stage 3 verifies the implementation by executing the tests written in Stage 2. Acceptance tests check whether the implementation satisfies the GWT specification. Unit and integration tests check the behavior of individual modules and their interactions. Passing these tests does not, however, guarantee the overall internal quality of the implementation. Once all tests pass, the process moves to Stage 4.

The full test suite is also rerun in cycles initiated by change requests to check for errors in both modified and existing functionality. If verification fails, the process returns to Stage 2 to correct the implementation while preserving the GWT specification, after which the full test suite is rerun.

3.3.4. Stage 4: Acceptance

In Stage 4, the facilitator presents the implemented software to the client. It reports that all acceptance, unit, and integration tests have passed and requests acceptance of the software as a whole. Client acceptance completes the cycle.

If the client declines acceptance, the facilitator identifies the reason and compares the current implementation with the GWT specification. A mismatch between the specification and implementation is classified as an implementation error. If the implementation matches the specification but satisfying the request would require changing the specification, it is classified as a requirements change. The facilitator explains its classification and rationale to the client before taking further action. For an implementation error, the implementation is corrected in Stage 2 and verified in Stage 3 before acceptance is requested again. For a requirements change, the request is recorded for the next cycle, and acceptance of the current software is requested again.

3.3.5. Repeating the Cycle and Handling Changes

Clients may identify additional requirements or needed changes while reviewing the implementation. COSPEC addresses these requests in a new cycle. After acceptance completes the current cycle, the next cycle begins from requests recorded during acceptance or change requests submitted afterward.

In Stage 1 of a subsequent cycle, goals are established from the change requests. The facilitator uses design decision records and scenario-to-code mappings to analyze the impact on existing scenarios. It presents the affected scope through a prototype and asks the client to check it. Once the client approves that scope, the SbE response loop and edge case exploration are applied to scenarios to be modified or added.

In Stage 2 of a subsequent cycle, the existing code is modified based on the revised GWT specification, while implementations of scenarios outside the change scope are preserved. In Stage 3, the full test suite is rerun to verify both the changes and existing functionality. Once all tests pass, Stage 4 reports completion of verification, presents the implemented software, and requests acceptance of the product as a whole.

3.3.6. Process Control and Scope

COSPEC specifies prohibited actions in the system prompt to reduce deviations from the process. Table 4 lists these actions and the corresponding instructions. The prohibitions fall into two groups. The first maintains boundaries between stages by prohibiting (1) implementation of unapproved scenarios, (2) production of the final implementation in Stage 1, and (3) consultation or reuse of prototype code as a basis for Stage 2 implementation. These rules are intended to reduce the likelihood of implementing content the client has not checked or beginning implementation before requirements exploration is complete. Prototype code is also separated from implementation code to prevent technical debt in exploratory code from carrying over into the final implementation.

Table 4. Prohibited actions and corresponding instructions.

Prohibited Action	Corresponding Instruction	Instruction File
Implementing unapproved scenarios	Do not implement based on unapproved scenarios	CLAUDE.md
Prematurely producing the final implementation in Stage 1	Do not do final implementation in Phase 1 (exploratory prototypes are allowed)	CLAUDE.md
Consulting or reusing prototype code as a basis for Stage 2 implementation	Do not reference, copy, adapt, or reuse Phase 1 prototype code as a basis for Phase 2 implementation. Carry approved behaviour forward through the approved scenarios’ GWT specifications.	CLAUDE.md/.claude/development.md/.claude/principles.md
Leaving assumptions implicit	Do not handle assumptions implicitly	CLAUDE.md
Using technical terms unnecessary for the current judgment	Do not ask the client questions in technical terms	CLAUDE.md
Showing GWT specifications to the client	Do not show GWT/Gherkin to the client	CLAUDE.md

The second group preserves the intended form of participation, in which clients review and respond to proposed scenarios and assumptions. It prohibits (4) leaving assumptions unstated, (5) using technical terms unnecessary for the client’s judgment, and (6) presenting GWT specifications to the client. Disclosing assumptions gives clients opportunities to check whether they match their intentions and request revisions. The other two rules maintain the division of responsibilities: clients check scenarios through prototypes, and the LLM records approved scenarios in the specification. If client feedback or log review reveals a violation, the review procedure for the affected scenario is repeated.

Finally, COSPEC’s requirements scope is limited to functional requirements. Non-functional requirements (NFRs) encompass diverse quality attributes, including performance, security, reliability, and usability. Requirements concerning some aspects of usability can be refined through prototype interaction, but not all quality attributes can be elicited and verified in the same way. Addressing functional scenarios and multiple quality attributes together may also broaden the scope of exploration and make it harder to focus on refining functional requirements. This paper therefore focuses on functional requirements elicitation. Problems that prevent use of the prototype are corrected in response to feedback, while other NFRs are recorded in a separate backlog. Prioritization, approval, and verification of that backlog fall outside COSPEC’s scope and are left to the organization’s separate quality management process.

3.4. Evaluation Objective and Experimental Design

This section describes the experimental design and setup used to address the research question. The experiment examines whether COSPEC allows clients to participate in requirements co-construction through repeated responses without writing or reviewing the entire specification themselves. SDD was selected for comparison to examine differences from an approach based on direct specification review. Vibe coding, the starting point of this paper, was also included to compare COSPEC’s interaction patterns with those of an approach without a dedicated co-construction process. We used GitHub GitHub Spec Kit (GitHub, Inc., San Francisco, CA, USA) for SDD because its provided skills can be executed by LLM agents following prompt instructions, making it suitable for the automated setup.

The development task was held constant to compare interactions across methods. We selected a user interface-based application of a scale manageable within a single experiment, with principal features that could be demonstrated through HTML prototypes. The task was to develop a bookmark management tool based on the open-source application Linkding [35]. A reference specification was prepared in advance from Linkding’s public documentation. It represented the hypothetical client’s requirements and served as the common basis for evaluation. All three methods began development from the same prompt.

The experiment uses an automated environment in which LLM agents interact. The Director assumes the client role, and the Maker develops the software. The Broker relays messages and review materials between them, and the Judge evaluates each run. The Director, Maker, and Judge are LLM roles; the Broker is a program that manages execution. Figure 2 summarizes the environment.

Figure 2. Execution environment for the automated exploratory evaluation. The Maker, Director, and Judge are LLM roles. The Broker relays dialogue verbatim and forwards the paths of review materials stored in a shared directory and registered application URLs to the Director. Dashed lines indicate isolated containers. For coverage evaluation, the Judge compares the implementation with the reference specification. For co-construction counts, it compares interaction logs with the reference specification to assess whether the client role identified discrepancies.

• The Maker develops software based on the Director’s requests and responses. It receives instructions for the assigned method but does not receive the reference specification. Its reasoning level is set to Low, Medium, or High.
• The Director receives the reference specification and acts as the client. It responds to the Maker’s proposals and questions under either a satisficing or a diligent engagement policy. Its reasoning level is fixed at Medium.
• The Broker automatically relays messages and review materials between the Maker and Director. It neither modifies nor generates Director responses. It forwards material paths and application URLs with the messages and manages the progress and termination of each run.
• The Judge evaluates implementation coverage and co-construction counts in separate executions after each run. It compares the implementation with the reference specification to assess implementation coverage and compares interaction logs with the reference specification to assess co-construction counts. Its reasoning level is fixed at High.

In COSPEC, all files in the prototypes/ directory are copied to the shared directory at every round, including files remaining from earlier rounds. Files are not selected based on their content. In SDD, specification and planning documents from the specs/ directory are forwarded. In all conditions, a registered application URL is relayed; when the interface can be captured, screenshots and text are also saved. The Director can review materials at the supplied paths or access the application URL.

The experimental factors are the Director’s engagement policy and the Maker’s reasoning level. Two engagement conditions, satisficing and diligent, represent patterns that may occur among human clients. The satisficing condition draws on Simon’s concept of stopping the search once an acceptable alternative is found [9,10]. Under this condition, the Director accepts proposed functionality if it serves the main intended purpose, even when details of behavior or conditions differ from expectations. Under the diligent condition, the Director compares proposals with expected behavior and conditions and requests revisions by explicitly describing discrepancies or omissions it identifies. Instructions direct the Director to respond according to the assigned policy. Vibe coding uses the satisficing condition, while SDD and COSPEC each use both conditions. Table 5 lists the five experimental conditions formed by combining method and engagement policy.

Table 5. Combinations of method and engagement policy.

Identifier	Method	Engagement Policy
VC	Vibe coding	Satisficing
SD-S	SDD	Satisficing
CO-S	COSPEC	Satisficing
SD-D	SDD	Diligent
CO-D	COSPEC	Diligent

The Maker’s reasoning level is set to Low, Medium, or High to examine how interaction and requirements co-construction vary with this setting. Claude and Codex are used for the Maker and Director, with their role assignments crossed. For each model pairing, the Maker’s reasoning level varies while the Director’s remains fixed at Medium. Table 6 lists the model and reasoning-level combinations. Reasoning levels use the settings provided by each service; identical labels do not imply equivalent computation or reasoning ability across models.

Table 6. Model and reasoning-level combinations for the Maker and Director.

Maker	Maker Reasoning Level	Director	Director Reasoning Level
Claude	Low	Codex	Medium
Claude	Medium	Codex	Medium
Claude	High	Codex	Medium
Codex	Low	Claude	Medium
Codex	Medium	Claude	Medium
Codex	High	Claude	Medium

Note: Claude uses claude-opus-4-8, and Codex uses gpt-5.6-sol.

Combining the conditions in Table 5 with the model configurations in Table 6 yielded 30 combinations. Each was executed five times, for a total of 150 runs. Execution order was randomized within each repetition. Every run started in a fresh container to prevent conversations and artifacts from earlier runs from affecting subsequent runs.

A run extends from the common initial prompt to final acceptance of the software as a whole. Each run was limited to 80 rounds, with a timeout of 180 min per Maker or Director model call. When accepting the software, the Director includes a final acceptance tag (<FINAL_ACCEPTED>) in its response. The Broker ends the run when it detects this tag after the final implementation has been presented. COSPEC runs end at acceptance of the first cycle; requests to add or change requirements during acceptance are recorded for the next cycle.

After each run, the Judges evaluate implementation coverage and co-construction counts. Claude and Codex both serve as Judges, with their reasoning levels fixed at High. Each evaluates the same materials under the same criteria in executions separate from the Maker and Director. Implementation coverage is assessed by comparing the final implementation with the reference specification, without providing interaction logs. Co-construction counts are assessed by comparing interaction logs with the reference specification.

3.5. Metrics and Analysis

This section defines the metrics and their calculation. The main metrics are the discrepancy-related co-construction count, requirements coverage through co-construction, and implementation coverage.

The discrepancy-related co-construction count N_g includes only decisions in which the Director explicitly requests correction of, or accepts, content that differs from the reference specification. The unit of analysis is an item in the presented content that can be judged independently. The count is restricted in this way because approval alone does not reveal what the Director contributed to a requirements decision. Decisions about content that already conforms to the reference specification are excluded. Opportunities for a contribution to be counted therefore depend on how much discrepant content is presented. We consequently examine the discrepancy recognition rate alongside the co-construction count.

Responses to content that differs from the reference specification fall into three categories. (1) A revision request is classified as a corrective contribution. (2) Acceptance that explicitly acknowledges the difference is classified as explicit acceptance of a discrepancy. (3) Acceptance that does not identify the difference is classified as acceptance without mentioning the discrepancy. The respective decision counts are denoted by N_c, N_a, and N_m. The discrepancy-related co-construction count is the sum of corrective contributions and explicit acceptances, N_g = N_c + N_a. The discrepancy recognition rate divides this sum by the total across the three categories, N_g/(N_g + N_m), and is not calculated when the denominator is zero.

Requirement coverage through co-construction C_g is the proportion of reference requirements for which discrepancy-related co-construction occurred at least once. Whereas the co-construction count measures the frequency of judgments, this metric measures the scope of requirements involved. Letting R_g denote the number of such requirements and R the total number of reference requirements, coverage is calculated as C_g = R_g/R. Each requirement is counted once even if co-construction occurs multiple times for it. Requirements not discussed in the conversation remain in the denominator. Coverage is calculated separately for the 22 core requirements and the 10 extended requirements.

Even a high co-construction count may reflect contributions concentrated on only a few requirements. We therefore compare requirements coverage through co-construction to examine how the scope of contributions varies by engagement policy and method. Statistical tests were conducted to assess the comparisons while accounting for variation across repeated runs. This was an exploratory analysis performed after inspecting the experimental results. Table 7 lists the factors compared and held constant.

Table 7. Comparisons of requirements coverage through co-construction.

Comparison	Factor Compared	Factors Held Constant
CO-D vs. CO-S	Director engagement policy	Method (COSPEC), model pairing, Maker reasoning level
SD-D vs. SD-S	Director engagement policy	Method (SDD), model pairing, Maker reasoning level
CO-S vs. SD-S	Method	Engagement policy (satisficing), model pairing, Maker reasoning level
CO-D vs. SD-D	Method	Engagement policy (diligent), model pairing, Maker reasoning level

Note: Each comparison pairs runs within the same repetition that match on the factors held constant.

Each comparison in Table 7 comprises 30 pairs of runs. Differences in mean coverage between the two conditions are assessed using exact, two-sided paired permutation tests. Core and extended requirements coverage are tested separately, as are assessments by the Claude Judge and the Codex Judge. This yields four tests per comparison and 16 tests overall. Holm correction is applied across all 16 tests, with an adjusted significance threshold of 0.05.

Implementation coverage C_i measures the extent to which the final implementation satisfies the functional requirements in the reference specification. Each requirement is classified as implemented, partially implemented, or not implemented and assigned a score of 1, 0.5, or 0, respectively. Letting s_j denote the score for each requirement and R the total number of reference requirements, coverage is calculated as $C_i=\left({\displaystyle {\sum }_{j=1}^R}{s}_j\right)/R$. It is calculated separately for the 22 core requirements and the 10 extended requirements. Additional functionality not included in the reference specification is excluded from the evaluation.

Implementation coverage can help identify omitted or partially satisfied functional requirements within the reference scope. However, it does not measure the completeness of the reference specification itself or overall software quality, including performance, security, and reliability. Whether co-construction improves software quality also requires a separate evaluation.

To examine interaction frequency and text volume, we use four auxiliary metrics: response units, cumulative input characters, text volume per response turn, and total text volume. Table 8 defines these metrics.

Table 8. Auxiliary metrics for interaction frequency and text volume.

Auxiliary Metric	Definition
Response units	Number of natural-language response messages sent by the Director
Cumulative input characters	Total characters in Director responses, excluding the final acceptance tag
Text volume per response turn	Amount of counted text presented before a Director response
Total text volume	Cumulative amount of counted text presented throughout a run

Text volume counts the characters in the Maker’s guidance messages. For SDD, it also includes characters in specification and planning documents provided for review. When the same document is sent again, it is counted again as text presented at that response point. Prototype HTML, images, and the contents of implementation files are excluded.

4. Results

4.1. Data and Analysis Objective

A total of 150 runs were conducted under the conditions in Table 5 and the model configurations in Table 6. All runs reached final acceptance by the Director within the specified round and per-call time limits. Conversation logs, artifacts, and Judge assessments from these runs were used as the analysis data. The supporting materials, including run-level data, detailed summary statistics, and analysis scripts, are available in the Zenodo archive described in the Data Availability Statement sections.

The analysis examines whether the Director participated in requirements co-construction through its responses without writing or reviewing the entire specification. Dialogue and artifact examples illustrate this participation, while co-construction metrics characterize the frequency and scope of contributions. Implementation coverage is used to assess how well the final artifacts satisfy the reference requirements.

4.2. Requirements Co-Construction Through Repeated Responses

This section uses dialogue and GWT specification examples to examine how repeated Director responses contributed to requirements co-construction. Response counts and text volumes then characterize the interactions, and discrepancy-related co-construction counts indicate how frequently these contributions occurred in each experimental condition.

Table 9 reproduces the dialogue from rounds 4–5 of the facilitation stage in the first CO-D run verbatim. In round 4, the Maker presented a prototype for reviewing information retrieved from a link before saving it. The Director agreed with the flow but noted that the title and description could not be edited directly. It requested the ability to edit both before and after saving. In round 5, the Maker presented behavior that allowed the title and description to be edited while preserving the other retrieved information. The Director confirmed that this distinction matched its intentions. The Maker presented behavior for review and revised the prototype in response, while the Director decided which information should be editable and when.

Table 9. Dialogue excerpts from the CO-D facilitation stage (first run).

Round	Message
4 (Maker)	Open the prototype at http://maker:4001 (accessed on 9 October 2026). Paste https://fortelabs.com/blog/basboverview/ (accessed on 9 October 2026) into the web-address field and select Add link. You should see the title, description, site name, icon, and image gathered for review before anything is saved. I’ve assumed that adding begins from one prominent field at the top and that gathered details are previewed before saving. Please also check whether that approach feels right. The expected saved state is captured in prototypes/SCN-001-saved.png, but for now stop at the preview and tell me what you think.
4 (Director)	This feels right, and I like it. One field at the top where I paste and hit “Add link,” then it shows me what it found before saving—that’s exactly the kind of flow I was hoping for. And it did pull in all the things I care about: the title, the little description, the site name and its icon, and a picture. Seeing those laid out means I can actually recognize the link, which is the whole point. One thing I noticed on that “Here’s what we found” step: it’s showing me the details, but I can’t touch them. Sometimes the title a page gives itself is clunky or too long, or the description isn’t quite what I’d want to remember it by. So on that review step, before I hit save, I’d want to be able to fix up the title or the description myself. And ideally I could still tweak them later too, after it’s saved, if I change my mind. Otherwise, yes—this direction is spot on.
5 (Maker)	Reload http://maker:4001 (accessed on 9 October 2026), add the same sample link, then change its title on the review step to “My PARA reference.” Stop before saving and tell me whether editing the gathered details there feels right. I’ve assumed the title and description are directly editable in place, while the site name, icon, and picture remain automatically supplied. Please check whether that division is right. The completed result is captured in prototypes/SCN-001-edited-and-saved.png.
5 (Director)	Yes, this is exactly right. On the review step the title and description are both mine to change—I can type right over them—while the site name, its icon, and the picture stay as the app pulled them in. That split makes sense to me: the words are the part I’d want to make my own, and the rest is stuff the app is better off fetching automatically. I made the title “My PARA reference” and it stuck on the saved card. That’s the behavior I was hoping for. This one feels good.

Note: Table 9 and Table 10 present dialogue and specifications from the same run. This run used Codex (OpenAI, San Francisco, CA, USA) as the Maker and Claude (Anthropic, San Francisco, CA, USA) as the Director, with reasoning levels set to Low and Medium, respectively. The address http://maker:4001 was accessible only within the experimental environment during the run. It is retained as part of the original dialogue and is not a public URL.

The revision request in Table 9 was incorporated into the pre-save review scenario (SCN-001) and the post-save editing scenario (SCN-002). These two scenarios elaborated reference requirement REF-BM-03, which requires the retrieved title and description to be editable both before and after saving. Table 10 reproduces excerpts from the GWT specifications written by the Maker in the same run. Both scenarios specify that the revised title and description should be saved while automatically retrieved site information and images remain unchanged. Comparing the scenario-to-code mapping with the implementation confirmed that edits made before and after saving were reflected in the bookmark card. In this example, the Director participated in requirements decisions through revision requests and acceptance. The Maker formalized those decisions in GWT specifications and incorporated them into the implementation.

Table 10. Excerpts from CO-D GWT specifications (first run).

Scenario	GWT Specification
SCN-001 Edit before saving	Scenario: Revise the personal wording and save the bookmark Given the gathered bookmark details are open for review. When the person changes the title and description and saves the bookmark. Then a bookmark card is added to the collection. And the card shows the revised title and description. And the automatically supplied site name, site icon, and picture remain associated with it.
SCN-002 Edit after saving	Scenario: Save revised bookmark details Given a saved bookmark’s details are open for editing. When the person revises the title or description and saves the changes. Then the bookmark card shows the revised wording. And its automatically supplied site identity and picture remain unchanged.

Table 11 summarizes the scale and distribution of text interactions by condition. Under both engagement policies, COSPEC elicited more responses and more cumulative input characters than SDD. In COSPEC, the Director repeatedly received relatively small amounts of text; in SDD, it received text less often but in larger amounts at each response point. Because the counts include repeatedly delivered SDD specification and planning documents but exclude prototype HTML and images, these results should be interpreted as differences in the text included in the measurement.

Table 11. Text interaction metrics by condition.

Condition	Response Units	Cumulative Input Characters	Total Text Volume	Text Volume per Response Turn (Median/Maximum)
VC	2.03	1101	1809	1091/1244
SD-S	4.43	1780	169,530	41,993/57,867
CO-S	28.23	9873	17,307	840/1336
SD-D	6.73	5372	380,203	61,189/95,010
CO-D	36.20	22,279	27,638	935/1535

Note: Values are means across 30 runs per condition. The last column reports the means of the per-run medians and maxima. Total text volume for SD-S and SD-D includes all characters in specification and planning documents delivered at each response point; documents presented repeatedly are counted each time. Response units are rounded to two decimal places, and character counts to whole numbers.

Table 12 reports response units by condition and discrepancy-related co-construction counts N_g by Judge. Under diligent engagement, the mean N_g was 17.73 for CO-D and 15.80 for SD-D according to the Claude Judge, and 22.37 and 20.83, respectively, according to the Codex Judge. Under satisficing engagement, both Judges also reported higher means for CO-S than for SD-S and VC. Both Judges identified N_g ≥ 1 in all 30 runs of SD-D and CO-D, in 29 runs of CO-S, and in 19 runs of VC. For SD-S, the Claude Judge identified 24 such runs and the Codex Judge identified 25. These results indicate how often discrepancy-related co-construction occurred and in how many runs it was observed in each condition.

Table 12. Response units by condition and discrepancy-related co-construction counts by Judge.

Condition	Response Units	Response Unit Range	Discrepancy-Related Co-Construction Count (Claude Judge)	Discrepancy-Related Co-Construction Count (Codex Judge)
VC	2.03 ± 1.30	1–6	2.40 ± 3.89	3.50 ± 5.10
SD-S	4.43 ± 0.68	3–5	2.07 ± 1.87	3.07 ± 2.48
CO-S	28.23 ± 15.77	10–66	5.50 ± 5.45	6.53 ± 6.28
SD-D	6.73 ± 1.95	5–12	15.80 ± 7.42	20.83 ± 8.71
CO-D	36.20 ± 14.65	18–74	17.73 ± 8.10	22.37 ± 8.98

Note: Values are means ± sample standard deviations across 30 runs per condition. Response units count Director messages over an entire run, whereas discrepancy-related co-construction counts reflect decisions identified by each Judge. Because one response can contain multiple decisions, the co-construction count can exceed the number of response units.

4.3. Co-Construction and Implementation Results Across Experimental Conditions

This section examines how requirement coverage through co-construction C_g and implementation coverage C_i vary by Director engagement policy and method.

Table 13 summarizes how the Director responded to proposals that differed from the reference specification, by experimental condition and Judge. The co-construction count and discrepancy recognition rate characterize these response patterns. For both SDD and COSPEC, the discrepancy recognition rate was higher under diligent than under satisficing engagement, indicating response differences consistent with the engagement instructions.

Table 13. Discrepancy response categories and recognition rates by condition and Judge.

Judge	Condition	Corrective Contributions Nc	Explicit Acceptance of Discrepancies Na	Acceptance Without Mentioning Discrepancies Nm	Discrepancy Recognition Rate (%)
Claude	VC	72	0	61	51.95 ± 44.30
Claude	SD-S	47	15	124	37.86 ± 27.00
Claude	CO-S	151	14	143	52.27 ± 28.48
Claude	SD-D	453	21	17	94.90 ± 8.30
Claude	CO-D	509	23	73	86.71 ± 23.84
Codex	VC	98	7	105	39.68 ± 33.56
Codex	SD-S	59	33	230	34.84 ± 26.15
Codex	CO-S	159	37	352	37.95 ± 26.64
Codex	SD-D	581	44	53	90.72 ± 11.46
Codex	CO-D	621	50	130	82.27 ± 17.99

Note: Counts are totals across 30 runs per condition. The co-construction counts in Table 12 are per-run means of the sum of corrective contributions and explicit acceptances of discrepancies. Discrepancy recognition rates are means ± sample standard deviations of the per-run ratios (N_c + N_a)/(N_c + N_a + N_m). All 30 runs were included in the rate calculation for every condition and Judge.

Table 14 reports the means and standard deviations of requirements coverage through co-construction C_g by condition. Co-construction was observed for some requirements even in VC. Under satisficing engagement, CO-S had higher mean coverage than both VC and SD-S for core and extended requirements.

Table 14. Requirements coverage through co-construction by condition and Judge.

Condition	Core (%) Claude Judge	Core (%) Codex Judge	Extended (%) Claude Judge	Extended (%) Codex Judge
VC	13.03 ± 16.57	11.52 ± 14.01	11.67 ± 27.93	11.67 ± 25.61
SD-S	12.73 ± 11.10	11.52 ± 10.59	10.67 ± 17.01	10.33 ± 16.71
CO-S	22.88 ± 18.66	22.73 ± 16.80	16.33 ± 20.59	14.67 ± 18.33
SD-D	63.33 ± 18.49	64.85 ± 22.07	76.00 ± 29.55	75.33 ± 30.03
CO-D	57.27 ± 19.82	59.85 ± 17.47	64.67 ± 33.81	66.67 ± 32.94

Note: Values are means ± sample standard deviations across 30 runs per condition.

Table 15 reports mean differences in requirements coverage through co-construction C_g by engagement policy and method, together with Holm-adjusted p-values. For both SDD and COSPEC, mean coverage was higher under diligent than it was under satisficing engagement, with statistically significant differences for both core and extended requirements (p < 0.001).

Table 15. Mean differences and statistical comparisons of requirements coverage through co-construction by engagement policy and method.

Comparison	Requirements	Judge	Mean Difference (Percentage Points)	Holm-Adjusted p-Value
CO-D−CO-S	Core	Claude	+34.39	<0.001
CO-D−CO-S	Core	Codex	+37.12	<0.001
CO-D−CO-S	Extended	Claude	+48.33	<0.001
CO-D−CO-S	Extended	Codex	+52.00	<0.001
SD-D−SD-S	Core	Claude	+50.61	<0.001
SD-D−SD-S	Core	Codex	+53.33	<0.001
SD-D−SD-S	Extended	Claude	+65.33	<0.001
SD-D−SD-S	Extended	Codex	+65.00	<0.001
CO-S−SD-S	Core	Claude	+10.15	0.073
CO-S−SD-S	Core	Codex	+11.21	0.020
CO-S−SD-S	Extended	Claude	+5.67	0.471
CO-S−SD-S	Extended	Codex	+4.33	0.471
CO-D−SD-D	Core	Claude	−6.06	0.223
CO-D−SD-D	Core	Codex	−5.00	0.223
CO-D−SD-D	Extended	Claude	−11.33	0.272
CO-D−SD-D	Extended	Codex	−8.67	0.333

Note: Mean differences are calculated as the mean coverage of the first condition minus that of the second. The p-values are adjusted across all 16 tests using the Holm procedure described in Section 3.5.

In comparisons between methods under satisficing engagement, CO-S had higher mean coverage than SD-S. After Holm correction, however, the difference was significant only for core requirements assessed by the Codex Judge (p = 0.020). Under diligent engagement, SD-D had higher mean coverage than CO-D, but the differences were not significant for either requirement category or Judge. Nonsignificant results do not imply equivalence between the methods.

Table 16 reports requirements coverage through co-construction C_g by Maker reasoning level. Differences across reasoning levels were examined descriptively. Neither SDD nor COSPEC showed a consistent increase in coverage as the reasoning level increased.

Table 16. Requirements coverage through co-construction by Maker reasoning level.

Condition	Maker Reasoning Level	Core (%) Claude Judge	Core (%) Codex Judge	Extended (%) Claude Judge	Extended (%) Codex Judge
SD-S	Low	17.73 ± 13.96	15.45 ± 12.16	8.00 ± 17.51	8.00 ± 17.51
SD-S	Medium	12.27 ± 9.59	11.82 ± 11.78	17.00 ± 21.63	16.00 ± 21.19
SD-S	High	8.18 ± 7.67	7.27 ± 6.14	7.00 ± 9.49	7.00 ± 9.49
SD-D	Low	64.09 ± 18.36	67.73 ± 24.66	67.00 ± 38.89	68.00 ± 39.67
SD-D	Medium	63.64 ± 22.68	61.36 ± 23.79	82.00 ± 21.50	82.00 ± 23.48
SD-D	High	62.27 ± 15.75	65.45 ± 19.31	79.00 ± 26.44	76.00 ± 25.91
CO-S	Low	19.55 ± 21.00	18.64 ± 19.92	11.00 ± 15.24	11.00 ± 15.24
CO-S	Medium	28.64 ± 23.48	27.73 ± 18.49	29.00 ± 26.85	24.00 ± 23.66
CO-S	High	20.45 ± 8.64	21.82 ± 11.09	9.00 ± 11.97	9.00 ± 11.97
CO-D	Low	56.82 ± 22.29	61.36 ± 16.35	70.00 ± 31.27	72.00 ± 31.20
CO-D	Medium	53.64 ± 20.75	55.91 ± 19.64	60.00 ± 41.37	62.00 ± 40.77
CO-D	High	61.36 ± 17.44	62.27 ± 17.41	64.00 ± 30.62	66.00 ± 28.36

Note: Values are means ± sample standard deviations across 10 runs, comprising five runs for each of the two model pairings. The Director’s reasoning level was fixed at Medium. Maker reasoning levels refer to service-specific settings; identical labels do not imply equivalent reasoning ability across models.

Table 17 reports implementation coverage C_i by condition and Judge. For both SDD and COSPEC, mean implementation coverage was higher under diligent than it was under satisficing engagement. Under diligent engagement, SD-D had higher mean coverage than CO-D; under satisficing engagement, CO-S had higher mean coverage than SD-S and VC. These patterns held for both core and extended requirements. Nevertheless, not all reference requirements were implemented even in artifacts that received final acceptance from the Director. Because the Director may accept proposals that differ from the reference specification, implementation coverage should be interpreted separately from Director approval.

Table 17. Implementation coverage by condition and Judge.

Judge	Condition	Core Requirements Coverage (%)	Extended Requirements Coverage (%)
Claude	VC	53.03 ± 17.72	18.00 ± 28.06
Claude	SD-S	48.56 ± 8.78	11.67 ± 16.31
Claude	CO-S	63.03 ± 13.86	25.67 ± 20.87
Claude	SD-D	93.18 ± 7.96	71.67 ± 30.58
Claude	CO-D	86.52 ± 14.51	62.67 ± 38.32
Codex	VC	51.82 ± 16.27	17.33 ± 27.44
Codex	SD-S	46.74 ± 8.60	11.67 ± 15.72
Codex	CO-S	61.06 ± 13.07	25.67 ± 20.63
Codex	SD-D	90.38 ± 9.08	70.50 ± 30.52
Codex	CO-D	85.08 ± 14.75	60.83 ± 37.07

Note: Values are means ± sample standard deviations across 30 runs per condition. Requirements assessed by each Judge as implemented, partially implemented, or not implemented were assigned scores of 1, 0.5, or 0, respectively. Per-run coverage was calculated separately for the 22 core requirements and the 10 extended requirements.

Overall, both SDD and COSPEC showed a broader scope of requirements co-construction and higher mean implementation coverage under diligent engagement. The direction of the difference in requirements coverage through co-construction between methods depended on the engagement policy, and statistically significant differences were limited to particular requirement categories and Judge assessments.

4.4. Agreement and Assessment Patterns Between Judges

To characterize Judge assessments, this section examines requirement-level agreement and assessment patterns by Maker model. Agreement is assessed by comparing implementation status and recognition of co-construction contributions for the same reference requirement within the same run. Across 150 runs, the 22 core and 10 extended requirements yielded 4800 paired assessments. Agreement rates and Cohen’s κ were calculated separately by condition to account for differences in the distributions of assessment categories across conditions.

The comparison of implementation status examines whether the two Judges assessed the degree of requirement fulfilment in the same way. We compared the implemented, partially implemented, and not implemented classifications used to calculate implementation coverage. For example, two assessments of partially implemented for the same requirement were counted as agreement, whereas an implemented assessment from one Judge and a partially implemented assessment from the other were counted as disagreement.

The comparison of co-construction contributions examines which requirements the two Judges recognized as receiving a contribution from the Director. A requirement was classified as having a contribution if a Judge linked it to at least one corrective contribution or explicit acceptance of a discrepancy. All other requirements were classified as having no recorded contribution. For example, both Judges recognized a corrective contribution for the requirement associated with the request to edit information before and after saving in Table 9, so this was counted as agreement. Even when multiple decisions were linked to the same requirement, only the presence or absence of a contribution was compared. This comparison therefore examines the assessments underlying requirements coverage through co-construction, rather than individual decision counts or response types.

The agreement rate is the proportion of paired assessments for which the two Judges assigned the same classification. However, this rate may be high when assessments are concentrated in a particular category. We therefore also calculated Cohen’s κ, which adjusts for chance agreement expected from each Judge’s distribution of classifications. A κ of 1 indicates complete agreement, whereas 0 indicates agreement at the level expected by chance.

Table 18 summarizes requirement-level agreement between Judges by condition. Cohen’s κ ranged from 0.844 to 0.938 for implementation status and from 0.794 to 0.886 for recognition of co-construction contributions. These results suggest that the two Judges largely agreed on implementation status and recognition of co-construction contributions for individual requirements, although the degree of agreement varied across conditions.

Table 18. Requirement-level agreement between Judges by condition.

Condition	Paired Assessments	Implementation Agreement (%)	Cohen’s κ	Co-Construction Contribution Agreement (%)	Cohen’s κ
VC	960	94.79	0.910	95.62	0.794
SD-S	960	94.79	0.911	96.77	0.843
CO-S	960	96.15	0.938	94.38	0.828
SD-D	960	95.00	0.844	95.00	0.886
CO-D	960	96.04	0.904	92.81	0.849
All	4800	95.35	0.920	94.92	0.888

Note: Values combine core and extended requirements. Having no recorded co-construction contribution means that the Judge’s record linked neither a corrective contribution nor an explicit acceptance of a discrepancy to that requirement; it does not refer exclusively to acceptance without mentioning the discrepancy.

We examined whether assessment patterns differed according to whether the Judge and Maker belonged to the same model family. We compared differences between the two Judges’ assessments of the same runs, grouped by Maker model. For each run, the Codex Judge’s value was subtracted from the Claude Judge’s value, and the differences were averaged across the 75 runs for each Maker. Table 19 summarizes assessment patterns by Maker model as mean differences in implementation coverage, requirements coverage through co-construction, and co-construction counts.

Table 19. Mean differences between Judge assessments by Maker model.

Metric	Claude Maker	Codex Maker
Core implementation coverage	+1.12 pp	+2.58 pp
Extended implementation coverage	+0.80 pp	+0.67 pp
Core requirements coverage through co-construction	−0.61 pp	+0.12 pp
Extended requirements coverage through co-construction	+0.13 pp	+0.13 pp
Co-construction count	−2.96	−2.16

Note: Positive values indicate higher assessments by the Claude Judge, and negative values indicate higher assessments by the Codex Judge. The 75 runs for each Maker were equally distributed across experimental conditions and reasoning levels. Coverage differences are expressed in percentage points (pp).

The Claude Judge assigned higher mean implementation coverage regardless of the Maker model, whereas the Codex Judge counted more co-construction decisions. Mean differences in requirements coverage through co-construction were within 0.61 percentage points for both core and extended requirements. For implementation coverage and co-construction counts, the magnitude of the difference between Judges varied by Maker model, but the Judge assigning higher values remained the same. This indicates a tendency for the direction of each Judge’s assessments to remain consistent across Maker models.

5. Discussion

5.1. Division of Responsibilities for Requirements Co-Construction

The results in Section 4 show that the Director can contribute to co-construction by judging proposed behavior and conditions while the Maker refines the requirements. In the example in Table 9 and Table 10, the Director specified which information should be editable and when, and the Maker incorporated those requests into the prototype and GWT specifications. Repeated responses and discrepancy-related co-construction were also observed across the runs. These observations support the feasibility of a process that assigns scenario preparation and specification writing to the LLM while leaving judgments about acceptance and revision to the client.

Table 13 and Table 14 show higher discrepancy recognition rates and a broader scope of requirements co-construction under diligent engagement for both SDD and COSPEC. Differences in requirements coverage through co-construction between engagement policies were also significant in the exploratory tests in Table 15. This indicates that response differences consistent with the engagement instructions were associated with the scope of co-construction. Together with the example above, these findings show the intended division of responsibilities: the Maker organized material for review, and the Director provided judgments in response.

These results suggest that COSPEC could serve as a process for translating client judgments into concrete requirements. In an existing development workflow, the facilitation stage of COSPEC could be applied before design and implementation. The LLM would present prototypes and points to review, asking the client to request revisions or give approval. The development team could use the resulting scenarios and GWT specifications as a basis for design, implementation, and verification. When combined with SDD, these artifacts could inform specification drafting and refinement. Linking client feedback and approval records to the specifications would also allow the team to trace the basis for requirements decisions during subsequent development.

5.2. Limitations

The evaluation used a single bookmark management task, so whether the same interaction patterns occur in other tasks remains to be examined. Presentation medium and procedure also varied together across conditions. The results therefore compare the methods as a whole and cannot isolate the effect of prototype presentation alone.

The Director in this evaluation was an LLM supplied with a reference specification and engagement instructions. The satisficing and diligent conditions simulated engagement patterns that may occur among human clients; they did not reproduce human behavior directly. In particular, the Director received requirements explicitly through the reference specification, unlike human clients who must recognize and articulate tacit expectations. The researcher-authored reference specification and engagement instructions, as well as the models and prompt configurations, may also have influenced responses. The results should therefore be interpreted as evidence that interaction and co-construction occurred in the configured environment. Sustained participation by human clients requires human evaluation.

In evaluating co-construction, the Judge identifies individual decisions in the dialogue, classifies Director responses, and links them to reference requirements. Although Table 18 shows that assessments largely agreed at the requirement level, agreement on the identification of individual decisions and response types was not assessed. Even when both Judges recognize co-construction for the same requirement, they may rely on different dialogue evidence or count different numbers of decisions. Moreover, because the same models are used for generation and evaluation, agreement between Judges may still reflect shared biases.

Comparative results should be interpreted within the scope of the tools and engagement instructions used in this experiment. SDD was represented by GitHub Spec Kit, so the results cannot be generalized to all SDD tools, which may use different procedures and review practices. The VC Director also received satisficing instructions that required it to request clarification or revision when the proposed content could not clearly achieve the main purpose of the functionality. This condition therefore differs from uncritical acceptance of generated outputs. Such responses may have affected co-construction and implementation coverage.

COSPEC’s process rules are conveyed through the system prompt, and their execution depends on the LLM following instructions. Specifying approval conditions and prohibited actions does not technically prevent deviations from the process.

5.3. Future Work

Future work should examine whether repeated responses by human clients lead to the articulation of tacit expectations and the refinement of requirements. It could also investigate how client engagement and LLM facilitation relate to the scope of co-construction. Evaluation should be extended to diverse tasks and models, and assessments by independent evaluators should be compared with those of the LLM Judges to examine agreement and cases of disagreement.

The framework could be extended to change tasks and non-functional requirements. For change tasks, existing scenarios and GWT specifications could be used to refine the requirements to be changed and identify their impact. This would allow evaluation of whether the implementation can be modified while preserving existing behavior. For non-functional requirements, future work should distinguish quality attributes whose requirements can be refined through prototypes from those requiring other elicitation methods. This distinction could inform ways to elicit and connect requirements for different quality attributes through separate procedures while maintaining the focus on functional scenario exploration.

To support compliance with process rules, an external program could check the current stage and approval records and permit advancement only when the transition conditions have been met.

6. Conclusions

This paper addressed the problem of requirement decisions being incorporated into software without client review. We proposed COSPEC, a specification elicitation framework designed to involve clients in context co-construction without requiring them to write or review the entire specification. The LLM presents scenarios through prototypes, incorporates client revision requests, and records approved scenarios as GWT specifications. The client judges the proposed scenarios and accepts the software. The resulting specification provides the basis for implementation and verification.

In an automated exploratory evaluation with LLMs acting as the Maker and Director, we observed requirement co-construction through repeated Director responses. Dialogue and artifact examples showed revision requests and acceptance being reflected in scenarios and GWT specifications and carried through to implementation. For both SDD and COSPEC, co-construction covered a broader range of requirements under diligent engagement. These examples and results are consistent with the intended division of responsibilities: the Maker organizes material for review and formalizes responses in specifications, while the Director provides judgments.

COSPEC contributes an iterative interaction process that incorporates client judgments into development while assigning scenario preparation and specification writing to the LLM. This paper demonstrated the feasibility of that process in an automated environment. Future evaluations should examine whether human clients express their expectations and sustain participation in co-construction. The usefulness of the resulting specifications should also be investigated across diverse tasks and change scenarios.