Sycophancy, the tendency of LLM-based chatbots to express excessive agreement with their users, even when inappropriate, is emerging as a significant risk in human-AI interactions. However, the extent to which this affects human-LLM collaboration in complex problem-solving tasks is not well quantified, especially among novices who are prone to misconceptions. We created two LLM chatbots, one with high sycophancy and one with low sycophancy, and conducted a within-subjects experiment (n = 24) in the context of debugging machine learning models to investigate the effect of sycophancy on users’ mental models, workflows, reliance behaviors, and perceptions of the chatbots. Our findings show that users of the high sycophancy chatbot were less likely to correct their misconceptions and spent more time over-relying on unhelpful LLM responses, leading them to significantly worse performance in the task. Despite these impaired outcomes, a majority of users were unable to detect the presence of excessive sycophancy.

Timely, personalized feedback is essential for students learning programming. LLM-powered tools like ChatGPT offer instant support, but reveal direct answers with code, which may hinder deep conceptual engagement. We developed CodeAid, an LLM-powered programming assistant delivering helpful, technically correct responses, without revealing code solutions. CodeAid answers conceptual questions, generates pseudo-code with line-by-line explanations, and annotates student’s incorrect code with fix suggestions. We deployed CodeAid in a programming class of 700 students for a 12-week semester. A thematic analysis of 8,000 usages of CodeAid was performed, further enriched by weekly surveys, and 22 student interviews. We then interviewed eight programming educators to gain further insights. Our findings reveal four design considerations for future educational AI assistants: D1) exploiting AI’s unique benefits; D2) simplifying query formulation while promoting cognitive engagement; D3) avoiding direct responses while encouraging motivated learning; and D4) maintaining transparency and control for students to asses and steer AI responses.

LLM-powered tools like ChatGPT Data Analysis, have the potential to help users tackle the challenging task of data analysis programming, which requires expertise in data processing, programming, and statistics. However, our formative study (n=15) uncovered serious challenges in verifying AI-generated results and steering the AI (i.e., guiding the AI system to produce the desired output). We developed two contrasting approaches to address these challenges. The first (Stepwise) decomposes the problem into step-by-step subgoals with pairs of editable assumptions and code until task completion, while the second (Phasewise) decomposes the entire problem into three editable, logical phases: structured input/output assumptions, execution plan, and code. A controlled, within-subjects experiment (n=18) compared these systems against a conversational baseline. Users reported significantly greater control with the Stepwise and Phasewise systems, and found intervention, correction, and verification easier, compared to the baseline. The results suggest design guidelines and trade-offs for AI-assisted data analysis tools.

AI code generators like OpenAI Codex have the potential to assist novice programmers by generating code from natural language descriptions, however, over-reliance might negatively impact learning and retention. To explore the implications that AI code generators have on introductory programming, we conducted a controlled experiment with 69 novices (ages 10-17). Learners worked on 45 Python code-authoring tasks, for which half of the learners had access to Codex, each followed by a code-modification task. Our results show that using Codex significantly increased code-authoring performance (1.15x increased completion rate and 1.8x higher scores) while not decreasing performance on manual code-modification tasks. Additionally, learners with access to Codex during the training phase performed slightly better on the evaluation post-tests conducted one week later, although this difference did not reach statistical significance. Of interest, learners with higher Scratch pre-test scores performed significantly better on retention post-tests, if they had prior access to Codex.

Transitioning from block-based programming environments to text-based programming environments can be challenging as it requires students to learn new programming language concepts. In this paper, we identify and classify the issues encountered when transitioning from block-based to text-based programming. In particular, we investigate differences that emerge in learners when using a structured editor compared to an unstructured editor. We followed 26 high school students (ages 12-16; M=14 years) as they transitioned from Scratch to Python in three phases: (i) learning Scratch, (ii) transitioning from Scratch to Python using either a structured or unstructured editor, and (iii) evaluating Python coding skills using an unstructured editor. We identify 27 distinct types of issues and show that learners who used a structured editor during the transition phase had 4.6x less syntax issues and 1.9x less data-type issues compared to those who did not. When these learners switched to an unstructured editor for evaluation, they kept a lower rate on data-type issues but faced 4x more syntax errors.

Transitioning from block-based programming environments to conventional text-based programming languages is a challenge faced by many learners as they progress in their computer science education. In this paper, we introduce CodeStruct, a new intermediary programming environment for novices designed to support children who have prior experience with block-based programming to ease the eventual transition to text-based programming. We describe the development of CodeStruct and its key design features. We then present the results from a two-week long programming class with 26 high school students (ages 12-16; M=14 years) investigating how CodeStruct supported learners in transitioning from Scratch to Python. Our findings reveal how learners used the scaffolds designed into CodeStruct to support their transition from blocks to text, and that transitioning to CodeStruct reduced completion time (1.98x) and help requests (4.63x) when compared to transitioning directly to Python. Finally, learners that used CodeStruct, performed equally well (and slightly better in 10/16 programming activities) in their final transition to fully text-based Python programming.

Wearable construction toolkits have shown promise in broadening participation in computing and empowering users to create personally meaningful computational designs. However, these kits present a high barrier of entry for some users, particularly young children (K-6). In this paper, we introduce MakerWear, a new wearable construction kit for children that uses a tangible, modular approach to wearable creation. We describe our participatory design process, the iterative development of MakerWear, and results from single- and multi-session workshops with 32 children (ages 5-12; M=8.3 years). Our findings reveal how children engage in wearable design, what they make (and want to make), and what challenges they face. As a secondary analysis, we also explore age-related differences.

The Maker movement has encouraged more people to start working with electronics and embedded processors. A key challenge in developing and debugging custom embedded systems is understanding their behavior, particularly at the boundary between hardware and software. Existing tools such as step debuggers and logic analyzers only focus on software or hardware, respectively. This paper presents a new development environment designed to illuminate the boundary between embedded code and circuits. Bifröst automatically instruments and captures the progress of the user's code, variable values, and the electrical and bus activity occurring at the interface between the processor and the circuit it operates in. This data is displayed in a linked visualization that allows navigation through time and program execution, enabling comparisons between variables in code and signals in circuits. Automatic checks can detect low-level hardware configuration and protocol issues, while user-authored checks can test particular application semantics. In an exploratory study with ten participants, we investigated how Bifröst influences debugging workflows.

Electronic textile (e-textile) toolkits have been successful in broadening participation in STEAM-related activities, in expanding perceptions of computing, and in engaging users in creative, expressive, and meaningful digital-physical design. While a range of well-designed e-textile toolkits exist (e.g., LilyPad), they cater primarily to adults and older children and have a high barrier of entry for some users. We are investigating new approaches to support younger children (K-4) in the creative design, play, and customization of e-textiles and wearables without requiring the creation of code. This demo paper presents one such example of ongoing work: MakerShoe, an e-textile platform for designing shoe-based interactive wearable experiences. We discuss our two participatory design sessions as well as our initial prototype, which uses single-function magnetically attachable electronic modules to support circuit creation and the design of responsive, interactive behaviors.