Extending LLM-based support for software engineers with ADHD

I. INTRODUCTION

• Existing ADHD-oriented tools do not address software development tasks, and LLM programming assistants do not account for neurodivergent developers’ needs.Tether 2.0 extends an existing open-source ADHD support system with planning, coding, debugging, and review support.Source: §I · p. 1
• Tether 2.0 combines structured interaction modes, persistent memory, activity-aware support, and workflow-specific assistance to support continuity across development tasks.The study uses an engineering research approach centered on system design and evaluation.Source: §I · p. 1
• Workflow-aware assistance supports task initiation, decomposition, and re-engagement while reducing cognitive overhead, based on expert feedback and hands-on use by a software engineer with ADHD.The evaluation used descriptive statistics and thematic analysis.Source: §I · p. 2

II. BACKGROUND

• The paper contributes a framing of ADHD characteristics and technological support approaches, particularly in software engineering contexts.These concepts are introduced in the background section.Source: §II · p. 2

A. ADHD in the Workplace Implications

• ADHD is associated with executive-function difficulties and software engineers with ADHD report challenges with attention, task initiation, completion, planning, and self-regulation.Interruptions, context switching, synchronous communication, and long multi-stage tasks shape these challenges; existing support is often informal and not integrated into development workflows.Source: A. ADHD in the Workplace Implications · p. 2

B. Digital Tools for ADHD Support

• ADHD digital tools support attention and task management through external scaffolds, but are mainly designed for educational or therapeutic contexts rather than complex professional software work.Approaches include structured guidance, feedback, distraction management, and re-engagement prompts.Source: B. Digital Tools for ADHD Support · p. 2

C. Tether: LLM-Based Support for Software Engineers with ADHD

• The original Tether combines activity monitoring, a chatbot, retrieval-augmented generation, and gamification, but focuses more on attention and re-engagement than structured development activities.Its validation was preliminary and did not include target-user studies; its modular design offered a foundation for more workflow-oriented support.Source: C. Tether: LLM-Based Support for… · pp. 2–3

III. METHOD

• Tether 2.0 extends an existing open-source system with explicit support for planning, implementation, debugging, and review, addressing the original system’s lack of structured guidance across multi-step development activities.Evaluation combined expert surveys, hands-on use by a software engineer with ADHD, and a follow-up semi-structured interview.Source: §III · p. 3

1) System Overview and Architecture:

• The local-first desktop application combines an Electron and React frontend, Flask backend, SQLite conversation storage, and FAISS retrieval, while sending only model calls externally.Gemini 2.5 Flash and Google embedding-001 are used for language generation and retrieval embeddings; Figure 1 depicts the frontend, backend, storage, retrieval, and LLM components.Source: 1) System Overview and Architecture · p. 3, Figure 1 · p. 3

2) Activity Monitoring and Context Summarization:

• Activity signals are aggregated into structured summaries of recent work patterns and added to the system prompt, so responses can reflect context beyond the current message.The system captures active-window changes, applications, window titles, and idle-state transitions; summarized signals include task switching and uninterrupted focus periods.Source: 2) Activity Monitoring and Context… · p. 3

3) Structured Workflow Design:

• Four specialized modes—Planner, Builder, Detective, and Reviewer—support planning, implementation, debugging, and review while sharing a session history.The modes use distinct system prompts; Planner clarifies project goals, scope, and technical decisions before generating a time-bounded implementation checklist.Source: 3) Structured Workflow Design · pp. 3–4
• Builder encourages incremental implementation, Detective offers guided questioning or direct fixes, and Reviewer supports verification, lightweight tests and documentation, refactoring, and lessons learned.These modes support development from implementation through completion and reflection.Source: 3) Structured Workflow Design · p. 4

4) Retrieval, Memory, and Checklist Persistence:

• The system retrieves ADHD-related reference material and stores conversations by interaction mode, while shared session history lets planning inform later implementation, debugging, and review.Planner-generated task lists persist as structured checklists that can be revisited and updated over time.Source: 4) Retrieval, Memory, and Checklist… · p. 4
• The cited passage states that persistence allows the system to function as a longitudinal workflow scaffold, one that preserves context across multiple stages of software development.Figure 3 shows a structured checklist example generated by Planner mode to support task decomposition and progress tracking.Source: Figure 3 · p. 4, 4) Retrieval, Memory, and Checklist… · p. 5

B. Tool Evaluation

• Expert surveys were combined with hands-on use and interview feedback to assess Tether 2.0 from expert and end-user perspectives.The evaluation focused on utility, workflow fit, and domain relevance.Source: B. Tool Evaluation · p. 5

1) Survey-Based Evaluation:

• Survey recruitment expanded beyond software engineers with ADHD to include experts in ADHD and software engineering after recruiting the intended users proved challenging.Purposive and snowball sampling targeted clinicians and ADHD-focused researchers, software engineering researchers studying ADHD, and researchers with broader ADHD expertise.Source: 1) Survey-Based Evaluation · p. 5
• The study-specific survey combined open-ended questions with five-point Likert items covering support goals, adoption likelihood, and potential distraction risk.The instrument was pilot-tested with two software engineering students, leading to minor wording refinements.Source: 1) Survey-Based Evaluation · p. 5, Table I · p. 5

2) Interview-Based Feedback:

• One software engineer with ADHD used Tether 2.0 in their own environment for approximately two weeks before a semi-structured interview lasting about 25 minutes.The interview explored experience, workflow fit, perceived benefits, and possible improvements.Source: 2) Interview-Based Feedback · p. 5

3) Data Analysis:

• Open-ended survey responses and interview transcripts were coded thematically, while Likert-scale responses were summarized with descriptive statistics, including means.Thematic analysis focused on ADHD-related software engineering challenges such as task initiation, sustained focus, re-engagement, and completion.Source: 3) Data Analysis · p. 6

4) Ethical Considerations:

• The study received institutional research ethics board approval, and participants gave informed consent before data collection.Procedures included participant anonymity, secure data handling, and responsible reporting.Source: 4) Ethical Considerations · p. 6

A. Tether 2.0 User Workflow in Practice

• Tether 2.0 provides Planner, Builder, Detective, and Reviewer modules, with a typical workflow moving from planning through implementation and debugging to review.Developers can enter any module at any time, and conversations, activity summaries, and checklists remain available across sessions.Source: A. Tether 2.0 User Workflow in Practice · p. 6
• Planner clarifies requirements, constraints, and implementation choices, then decomposes the task into a structured checklist of actionable steps.Developers use Builder to work through that checklist with explanations, code examples, setup assistance, and implementation guidance tied to the overall plan.Source: A. Tether 2.0 User Workflow in Practice · p. 6
• Detective either guides a structured debugging process or suggests likely causes and fixes, after which development can continue in Builder.Source: A. Tether 2.0 User Workflow in Practice · p. 6
• Reviewer supports verification, lightweight testing, documentation, code review, and identifying remaining tasks before completion.Source: A. Tether 2.0 User Workflow in Practice · p. 6
• After an interruption, preserved conversations, activity summaries, and checklists let developers receive recaps and suggested next steps when returning to a task.The modules share context to support task decomposition, progression, and re-engagement across the development process.Source: A. Tether 2.0 User Workflow in Practice · p. 6

B. Tether 2.0 Evaluation

• The 16-person evaluation sample spanned software engineering, healthcare and psychology, computing and HCI, and industry or early-career practice.It included two participants with disclosed ADHD and 14 without disclosed ADHD.Source: B. Tether 2.0 Evaluation · pp. 6–7

1) Scale-Based Evaluation:

• 4.00 for task decomposition, 3.81 for task initiation, and 3.75 for cognitive overwhelm reduction were the highest perceived-support ratings.Re-engagement after distraction received 3.63; sustained focus and task completion each received 3.31.Source: 1) Scale-Based Evaluation · p. 7
• Distraction risk (mean = 3.19) slightly exceeded adoption likelihood (mean = 3.13), while ratings overall favored early-stage structuring over sustained engagement and completion.The authors note that the trade-off may affect willingness to adopt the tool in everyday workflows.Source: 1) Scale-Based Evaluation · p. 7

2) Qualitative Evaluation:

• Participants described task initiation and decomposition as benefits, including turning large or abstract work into manageable steps and supporting re-engagement through reminders and workflow tracking.They also perceived reduced cognitive burden during early development stages.Source: 2) Qualitative Evaluation · p. 7
• Participants raised risks of added distraction or cognitive load and of over-reliance on automated suggestions, particularly affecting junior developers’ learning.Source: 2) Qualitative Evaluation · p. 7
• Participants described task chunking, structured workflows, notifications, and idle detection as mechanisms for scaffolding interaction and re-engagement over time.Source: 2) Qualitative Evaluation · p. 7
• Perceived usefulness depended on experience, work environment, and individual ADHD preferences; participants noted possible risks for junior developers and settings with excessive interruptions.One participant emphasized that ADHD is individual and that what works for one person may not work for another.Source: 2) Qualitative Evaluation · pp. 7–8
• After two weeks of use, the participant with ADHD reported help with task initiation, decomposition, awareness of productivity patterns, and returning to work after losing focus.The participant identified the planner as most valuable and also suggested stronger activity monitoring; this account contrasted with more moderate expert ratings for completion and sustained focus.Source: 1) Scale-Based Evaluation · p. 7, 2) Qualitative Evaluation · p. 8

• The discussion situates the findings within existing literature.Source: §V · p. 8
• It outlines implications for research and practice.Source: §V · p. 8
• It addresses threats to validity.Source: §V · p. 8

A. Comparing Results with the Literature

• Evaluation supports task initiation, decomposition, and reduced cognitive overwhelm, while sustained focus and task completion receive more moderate support.Source: A. Comparing Results with the Literature · p. 8
• Tether 2.0 embeds planning, implementation, debugging, and review in one workflow; its value centers on decomposition, reasoning, and guided progression rather than direct answers.Source: A. Comparing Results with the Literature · p. 8
• The ADHD engineer reported positive experiences with sustained focus, completion, and adoption, unlike knowledgeable participants’ more moderate expectations.Source: A. Comparing Results with the Literature · pp. 8–9
• Effectiveness varies with work environment, developer experience, and integration with existing tools, and differs across work stages and conditions.Source: A. Comparing Results with the Literature · p. 9

B. Implications

• The work advances neurodiversity-informed tool design and calls for studying these systems as socio-technical interventions, including reliance calibration and longer-term skill development.Source: B. Implications · p. 9
• Development tools should fit existing environments, minimize added interaction demands, and adapt to individual preferences and work conditions.Source: B. Implications · p. 9

C. Threats to Validity

• The preliminary evaluation does not establish long-term effectiveness in real-world development settings, particularly under typical industry conditions.Much feedback came from demonstrations and short-term interactions rather than sustained use amid interruptions, deadlines, and team coordination.Source: C. Threats to Validity · p. 9
• The study measures perceived utility and workflow fit rather than productivity, learning, or well-being, so positive perceptions do not establish long-term benefits.Source: C. Threats to Validity · p. 9
• The small, purposively selected participant pool limits generalization, and LLM responses or attention-support features may mismatch user needs or add cognitive overhead.Source: C. Threats to Validity · p. 9

VI. CONCLUSIONS

• The conclusion assigns requirement clarification and decomposition to Planner, incremental coding to Builder, guided reasoning or suggestions to Detective, and validation, testing, and documentation to Reviewer.Source: §VI · p. 9
• Future work will test the system through longer-term in-situ deployment with larger, more diverse populations and longitudinal, outcome-based evaluation.Source: §VI · p. 9