🤖 AI

AI-Assisted Help-Seeking Trajectories in Programming Education from an SRL-Informed Perspective

This study analyzes AI-assisted help-seeking trajectories in introductory programming courses using an SRL-informed framework, revealing that while students predominantly use AI for reactive troubleshooting rather than self-regulated problem-solving, these interaction patterns significantly influence the number of code submissions required despite not directly affecting task scores.

Original authors: Boxuan Ma, Huiyong Li, Gen Li, Li Chen, Atsushi Shimada, Shin'ichi Konomi

Published 2026-06-23

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Boxuan Ma, Huiyong Li, Gen Li, Li Chen, Atsushi Shimada, Shin'ichi Konomi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are learning to cook a complex new dish. You have a recipe, but you keep burning the garlic, adding too much salt, or forgetting a step. In the past, you might have had to wait for a chef to walk by and help you, or you might have felt too embarrassed to ask.

Now, imagine you have a super-fast, super-knowledgeable sous-chef (Generative AI) sitting right next to you. You can whisper a question, and they instantly tell you how to fix the burnt garlic or how to chop the onions.

This paper is a study of how 71 university students used this "AI sous-chef" while learning to cook (program) in Python. The researchers weren't just counting how many times students asked for help; they wanted to see the story of how the help-seeking happened. Did the students plan ahead? Did they get stuck in a loop of fixing small mistakes? Or did they just ask for the whole recipe and copy it?

Here is the breakdown of their findings using simple analogies:

1. The Main Discovery: The "Firefighter" vs. The "Architect"

The researchers found that most students treated the AI like a firefighter rather than an architect.

The Firefighter (Reactive): Students mostly used the AI after something went wrong. They wrote code, it broke, and they asked, "Why is this red error message here?" or "Fix this line."
The Architect (Proactive): Very few students used the AI to plan before they started. They rarely asked, "What's the best way to structure this?" or "Can you explain this concept so I understand it better?"
The Metaphor: It's like most students waited until the house was on fire to call the AI, rather than calling the AI to help them design a fire-proof house in the first place.

2. The Five "Help-Seeking Habits" (Trajectories)

The researchers grouped the students' interactions into five distinct patterns, like different ways people navigate a maze:

The "One-Shot" (The Quick Fix): The student asks one question, gets an answer, and moves on.
- Analogy: You ask, "How do I tie a shoe?" The AI shows you, and you tie it. Done.
- Finding: This was the most common habit (over half the time). Interestingly, sometimes this was just a quick fix, but sometimes it was a smart student asking, "Is there a better way to tie this shoe?" (which is a good thing!).
The "Debugging Persistence" (The Stuck Loop): The student gets stuck on a small error and keeps asking the AI to fix it over and over again without changing their approach.
- Analogy: You are trying to open a jar. You ask the AI, "How do I open this?" The AI says, "Turn the lid." You try, it fails. You ask again, "It still won't open!" The AI says, "Turn it harder." You try again. You do this 10 times.
- Finding: These students were the most "expensive" in terms of effort. They submitted their code more than twice as many times as the "One-Shot" students to get the same result. They were stuck in a cycle of trial-and-error, relying on the AI to do the thinking for them.
The "Conceptual Framing" (The Planner): The student asks about the rules or concepts before writing any code.
- Analogy: Before cooking, you ask, "What does 'simmer' mean?" or "How do I chop an onion safely?" Then you cook.
- Finding: These students were efficient. They understood the basics first, so they made fewer mistakes later.
The "Performance-Oriented" (The Task Master): The student jumps straight into building the solution, asking the AI to write code or fix specific parts to get the job done fast.
- Analogy: You say, "Make me a sandwich," and the AI builds it. You just check if it tastes right.
- Finding: This was efficient for getting the grade, but the researchers worried the student might not have learned how to make the sandwich themselves.
The "Mode-Shifting" (The Flexible Learner): The student starts with one type of help (like fixing an error) but then realizes they don't understand the concept, so they switch to asking for an explanation, and then goes back to fixing.
- Analogy: You try to fix the jar, get stuck, ask "Why is this jar so hard to open?" (concept), get an answer, and then try again.
- Finding: This was rare, but it showed the most "self-regulated" learning—adapting the strategy when things didn't work.

3. The Big Surprise: Grades vs. Effort

You might think that the students who used the AI the "smartest" (the Planners or the Flexible Learners) got the best grades.

The Reality: Everyone got roughly the same grade. Because the computer grading system allowed students to submit their code over and over until it worked, almost everyone eventually got the points.
The Real Difference: The difference was in how much work they did to get there.
- The "Stuck Loop" (Debugging Persistence) students had to submit their code 12 times on average.
- The "One-Shot" students only had to submit 5 times on average.
- The Lesson: The AI helped everyone pass, but for some students, it became a crutch that made the process much longer and more frustrating.

4. What Does This Mean?

The paper concludes that it's not about if students use AI, but how they use it.

If a student uses AI just to patch up errors repeatedly (like a mechanic who only tightens a loose bolt over and over without fixing the engine), they might pass the class, but they aren't learning to drive the car.
If a student uses AI to understand the rules, plan their steps, and check their work, they are using it as a true learning partner.

The Takeaway: The "educational value" of AI isn't in the final grade (which was the same for everyone); it's in the journey. The study suggests that we need to teach students not just how to ask the AI for answers, but how to use it to plan, understand, and reflect, rather than just using it to fix broken code in a panic.

Technical Summary: AI-Assisted Help-Seeking Trajectories in Programming Education from an SRL-Informed Perspective

1. Problem Statement

In introductory programming education, novice learners frequently encounter deep uncertainty regarding syntax, control flow, and error diagnosis. Traditional support mechanisms (e.g., office hours, forums) often fail to provide timely, individualized assistance, leading to shallow understanding and underdeveloped problem-solving skills. While Generative AI (specifically Large Language Models) offers a scalable solution by providing instant, personalized support, it introduces pedagogical risks. There is a concern that students may "offload" problem-solving steps to AI, engaging in "metacognitive laziness" where they rely on the tool for reasoning rather than developing their own regulatory skills.

Existing research has largely focused on the frequency of AI use, the correctness of generated code, or general usability. However, there is a significant gap in understanding how student–AI help-seeking unfolds over time. Specifically, little is known about the sequential structure of these interactions (trajectories) and whether they reflect self-regulated learning (SRL) processes (planning, monitoring, reflection) or reactive troubleshooting. This study addresses the need to move beyond static usage metrics to analyze the dynamic, turn-by-turn evolution of help-seeking behavior in AI-supported programming tasks.

2. Methodology

2.1 Context and Participants

The study was conducted in an introductory undergraduate Python programming course at a national university in Japan, spanning two offerings (Summer 2024 and Summer 2025).

Participants: 166 first-year students were enrolled. The final analytic sample consisted of 71 students who generated at least five prompts during the course.
Course Structure: The course included 14 lessons with 57 programming tasks covering variables, strings, functions, conditionals, and loops.
AI Tool: Students had access to a custom web-based interface connected to GPT-4o for real-time interaction. All conversations were logged.

2.2 Data Sources

The analysis integrated two complementary trace data sources:

Automated Assessment Submissions: 17,190 code submissions from 71 students (linked to 57 tasks) via the CodeRunner plugin. These logs provided task scores (0–5 based on test cases passed) and the number of submission attempts.
Student–AI Dialogue Logs: 1,290 task-specific prompts extracted from 635 dialogue sessions. Prompts unrelated to course tasks or submitted outside exercise periods were excluded.

2.3 Analytical Framework and Coding

The study employed an SRL-informed analytical framework (Figure 1) to interpret help-seeking behaviors.

Coding Scheme: Prompts were coded into 10 fine-grained categories grouped into four main functional roles:
- Conceptual: Clarifying concepts, syntax, or requirements (e.g., Concept Question, Problem Understanding).
- Implementation: Constructing solutions or generating code (e.g., Code Generation, Implementation Question).
- Debugging: Interpreting errors, correcting code, or verifying output (e.g., Error Interpretation, Code Correction).
- Reflective: Explaining working code or seeking optimization (e.g., Code Explanation, Code Optimization).
Reliability: Two researchers achieved 92.7% inter-rater agreement ( $\kappa = .88$ ) through consensus coding.
Trajectory Analysis:
- Sequential Analysis: Lag sequential analysis and Sankey diagrams were used to examine transitions between prompt categories across turns.
- Attempt-Level Taxonomy: A rule-based taxonomy was developed to classify entire task-specific sessions into five trajectory patterns:
  1. One-shot: Single prompt.
  2. Debugging-Persistence: Three or more consecutive debugging prompts.
  3. Conceptual-Framing: Sessions beginning with conceptual help.
  4. Performance-Oriented: Sessions consisting only of implementation and debugging help.
  5. Mode-Shifting: Sessions involving shifts across different help-seeking modes (e.g., debugging to conceptual).

2.4 Performance Metrics

Programming performance was evaluated using two metrics:

Task Score: The final score achieved (0–5).
Process Cost: The number of code submissions required to reach a solution.

3. Key Results

3.1 Distribution of Help-Seeking Prompts

Dominance of Debugging: Debugging was the most frequent category, accounting for 67.0% of all prompts. Error Interpretation (EI) and Code Correction (CC) were the most common specific codes.
Scarcity of Reflection: Reflective help accounted for only 1.6% of prompts. Conceptual and Implementation help comprised 14.6% and 16.8%, respectively.
Reactive Nature: The data suggests students primarily used AI as a reactive aid for immediate troubleshooting rather than for planned, self-regulated problem-solving.

3.2 Sequential Patterns and Trajectories

Stagnation in Debugging: Sequential analysis revealed that students often remained within the Debugging category. Self-transitions in Debugging were significantly elevated ( $z = 6.1$ ), while cross-category transitions (e.g., Conceptual $\to$ Debugging) were often suppressed.
Trajectory Patterns:
- One-shot (53.1%): The most common pattern, dominated by single debugging requests.
- Performance-Oriented (19.2%): Multi-turn interactions focused solely on implementation and debugging.
- Debugging-Persistence (12.6%): Sessions with sustained, repeated debugging attempts.
- Conceptual-Framing (9.0%) and Mode-Shifting (6.1%) were less common.

3.3 Association with Performance

Task Scores: There was no significant difference in task scores across the five trajectory patterns ( $p = .950$ ). Most students achieved high scores regardless of their interaction pattern, likely due to the ability to submit multiple times.
Code Submissions (Process Cost): Significant differences were found in the number of code submissions ( $p < .001$ $p < .001$ ).
- Debugging-Persistence required the highest number of submissions (Mean = 11.90), significantly more than One-shot (Mean = 4.82) or Conceptual-Framing (Mean = 5.91).
- One-shot and Conceptual-Framing patterns were associated with lower process costs.
Robustness: The higher submission count for Debugging-Persistence held true for both easy and hard tasks, indicating the pattern itself, rather than task difficulty, drove the increased process cost.

3.4 Case Illustrations

Qualitative cases illustrated the SRL implications of these patterns:

Debugging-Persistence: Students often engaged in a "trial-and-repair" loop over minor formatting issues without diagnosing the underlying rule.
Conceptual-Framing: Students clarified concepts before coding, leading to efficient verification.
Mode-Shifting: Students successfully shifted from debugging to conceptual questions, demonstrating flexible regulation.
One-shot: While often reactive, some single prompts were used for reflective optimization (e.g., asking for alternative implementations).

4. Key Contributions

SRL-Informed Analytical Framework: The study introduces a framework that links prompt-level codes to conceptual, implementation, debugging, and reflective support, interpreting these through the lens of Self-Regulated Learning.
Identification of Trajectory Patterns: It moves beyond aggregate usage statistics to identify five distinct, recurring help-seeking trajectories (One-shot, Debugging-Persistence, Conceptual-Framing, Performance-Oriented, Mode-Shifting).
Process vs. Outcome Distinction: The research demonstrates that while AI-supported trajectories do not significantly impact final task scores (due to multiple submission opportunities), they vary substantially in process cost (number of submissions).
Evidence of Reactive vs. Regulated Use: The findings provide empirical evidence that many students use AI for reactive troubleshooting (stuck in debugging loops) rather than for planned, self-regulated problem-solving, highlighting a specific risk of "metacognitive laziness."

5. Significance and Claims

The paper claims that the educational significance of AI support in programming lies not merely in whether or how often students use AI, but in how their help-seeking trajectories develop during problem-solving.

Reframing AI Use: The study argues that high task scores do not necessarily indicate effective learning or efficient problem-solving. A student who completes a task via a "Debugging-Persistence" trajectory (high process cost, reactive) may have a different learning experience than one who uses "Conceptual-Framing" (lower process cost, planning-oriented).
Pedagogical Implications: The authors suggest that educational interventions should focus on the structure of interactions. AI systems and instructors should aim to detect and interrupt "repair-oriented loops" (Debugging-Persistence) by prompting conceptual reflection or self-explanation, rather than simply providing the next correction.
Modest Scope: The authors acknowledge limitations, noting that the study was conducted in a single introductory course and that the analysis relies on trace data (prompts and submissions) rather than direct measures of internal cognitive states. They do not claim that specific trajectory patterns cause better learning outcomes, but rather that they represent distinct regulatory structures with different associated process costs.

In conclusion, the paper posits that supporting students in moving beyond repeated debugging requests toward conceptual clarification and self-explanation is crucial for aligning AI-assisted programming support with the goals of self-regulated learning.