The Role of LLMs in Collaborative Software Design

1. Problem Statement

While Large Language Models (LLMs) have been extensively studied for solo software development tasks (e.g., code generation), there is a significant gap in understanding how LLMs influence collaborative group work in software engineering, specifically software design.

• The Gap: Existing research focuses on single designers using LLMs for modeling or specific tasks. It is unclear how pairs of professionals interact with LLMs when working together, how they manage shared context, and whether LLMs aid or hinder the collaborative design process (e.g., shared understanding vs. context drift).
• The Challenge: Software design is inherently collaborative, involving trade-offs, abstraction, and human-centric decision-making. The introduction of an AI agent into this dynamic raises questions about workflow integration, reliance levels, and the preservation of human agency.

2. Methodology

The authors conducted an exploratory, laboratory-based study involving 18 pairs (36 participants) of software professionals.

• Participants: Diverse mix of engineers, architects, and product managers with 1–20+ years of experience. Most had prior LLM experience, though only a few had used them specifically for software design.
• Task: Pairs were tasked with designing a mobile application for university bicycle parking based on a provided Product Requirements Document (PRD).
• Environment:
  • Remote collaboration via Zoom (with one exception of co-located pairs).
  • LLM Tool: A custom wrapper using the ChatGPT 3.5 Turbo API, designed to mimic a standard chat interface. Crucially, the tool allowed each partner to invoke the LLM independently (separate instances) or share a single instance.
  • Duration: 90 minutes per session.
• Data Collection:
  • Screen recordings and audio of design sessions.
  • Logs of all LLM prompts and responses.
  • Final design documents.
  • Post-task exit interviews.
• Analysis: A mixed-method qualitative approach using abductive coding for session logs and recordings, and inductive thematic analysis for interview transcripts.

3. Key Contributions

The study identifies four primary contributions regarding human-LLM collaboration in design:

1. Collaboration Patterns: A taxonomy of how pairs physically and logically interact with the LLM (Shared vs. Separate instances).
2. Roles of the LLM: A framework categorizing how designers perceive and utilize the LLM's function (Non-use, Information Source, Generator, Producer).
3. Interaction Dynamics: Insights into how designers scrutinize, verify, and iterate on LLM outputs, highlighting the "straw man" nature of AI responses.
4. Tool Implications: Recommendations for future AI-backed design tools to support divergent thinking and mitigate cognitive biases like anchoring.

4. Key Results & Findings

A. Collaboration Patterns (RQ1)

Three distinct patterns of joint LLM use emerged:

• Shared Instance: One partner acts as the "driver" (entering prompts) while the other observes or co-crafts. This facilitated shared understanding and acted similarly to pair programming.
• Separate Instances (Co-working): Partners used their own LLM windows simultaneously. While this allowed for parallel exploration, it frequently led to "context drift" where the two designers' understanding of the design diverged because the LLMs received different contexts or generated different outputs.
• Separate Instances (Independent Work): Pairs split tasks (e.g., one doing APIs, the other data models). This required significant manual coordination to align the separate design artifacts.

B. Roles of the LLM (RQ2)

Designers assigned the LLM one of four roles, independent of their collaboration pattern:

1. No Role (DNU): Two pairs avoided the LLM due to distrust, lack of perceived benefit, or confidence in their own abilities.
2. Information Source (IS): Used as a knowledge bank (e.g., asking about APIs or database types) to fill knowledge gaps. Designers retained full control over the design logic.
3. Generator (GE): The LLM was used to create specific artifacts (e.g., data models, UML diagrams) which served as a starting point for human refinement.
4. Producer (PD): Three pairs used the LLM to generate the entire design document, with humans acting primarily as prompt engineers and editors.

C. Interpretation and Action (RQ3)

• Scrutiny & Verification: Designers did not blindly trust LLM outputs. They actively verified responses against the PRD, existing designs, or external tools (e.g., visualizing PlantUML code).
• Iterative Refinement: The LLM output was treated as a "straw man" to be debated. Pairs frequently engaged in prompt-review-revise cycles to correct errors or add constraints.
• Anchoring Effect: A significant finding was that early, appealing LLM suggestions sometimes curtailed exploration. Once a pair accepted an initial LLM-generated structure, they were less likely to explore alternative solutions, leading to early convergence.
• Insight Generation: Reviewing LLM responses often triggered reflection, helping designers identify omissions or realize they could reuse existing solutions (e.g., Google Maps API) rather than reinventing the wheel.

D. Perceptions (RQ4)

• Trust: Participants expressed concern about hallucinations and the need for human verification.
• Confidence: Using the LLM provided a "sanity check" and reduced stress by helping identify unknowns.
• Human Partnership: Participants valued the human partner for providing insights that prevented the LLM from going "astray" based on incorrect assumptions.
• Suitability: LLMs were seen as suitable for "spike" work, high-level design, and greenfield projects, but less efficient for complex, detailed implementation where human judgment is critical.

5. Significance and Implications

• Human-Centricity: The study reinforces that in software design, human expertise remains central. The LLM acts as a catalyst or boundary object, but the designers drive the decision-making, evaluation, and final synthesis.
• Tool Design Recommendations: Future tools for collaborative design should:
  • Support forking to allow parallel exploration of different LLM-generated paths with subsequent merging.
  • Highlight context drift when partners use separate instances to aid coordination.
  • Provide mechanisms to overcome anchoring bias (e.g., forcing the exploration of alternatives before accepting a first draft).
• Research Impact: This work shifts the focus from "Can LLMs write code?" to "How do LLMs change the social and cognitive dynamics of design teams?" It highlights that while LLMs accelerate certain aspects, they introduce new coordination challenges that must be managed to preserve design quality and creativity.