Navigating Pitfalls: Evaluating LLMs in Machine Learning Programming Education

Hind Zantout; Manuel Maarek; Michael A. Lones; Smitha Kumar

REVIEW 4 major objections 5 minor 51 references

Navigating Pitfalls: Evaluating LLMs in Machine Learning Programming Education

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Across four code LLMs tested on 20 machine-learning code pitfalls, none identified more than half of the errors, with information-leakage mistakes almost always missed.

desk verdict First measurement of LLMs on ML-pitfall identification; the qualitative pattern is believable, but the 'below 50%' headline overreaches one code sample per pitfall and a password-protected repo. read the letter →

arxiv 2505.18220 v1 pith:7HIDKX5Y submitted 2025-05-23 cs.CY cs.AI

Smitha Kumar , Michael A. Lones , Manuel Maarek , Hind Zantout This is my paper · ORCID

classification cs.CYcs.AI

keywords largelanguagemodelsautomatedfeedbackgenerationmachinelearningpitfallscomputerscienceeducationinformationleakagecodeLLMsGitHubCopilotrecallevaluation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper asks whether current code-generating large language models can be trusted to support machine learning education, specifically whether they can spot common pitfalls in ML code and give useful feedback. On a set of 20 pitfalls embedded in Python samples, all four tested models — CodeQwen, DeepSeek Coder, Code Llama, and GitHub Copilot — had mean recall below 50%: 30%, 37%, 35%, and 50% respectively. The models were strongest on basic evaluation errors such as not using a test set or relying on accuracy with imbalanced data, and weakest on early-pipeline information leakage such as scaling, feature selection, augmentation, and imputation before the train/test split, which were almost always missed. When a pitfall was spotted, the responses almost always included an explanation of the mistake and usually guidance on how to fix it, suggesting useful feedback is not the bottleneck. The paper concludes that pretrained LLMs in their current state are not reliable enough to support advanced ML courses or the transition to practice.

What carries the argument

The evaluation rests on a catalogue of 20 machine-learning pitfalls (PF 01–PF 20) organised by pipeline stage, each instantiated as a single Python code sample generated by a commercial LLM (Gemini) and checked by a human expert, with pitfall ground truth defined by the authors. The measurement is recall@5: each open model was prompted five times at each of five temperature settings (25 responses per pitfall) and Copilot five times (temperature fixed), and a response counted as a true positive only if it identified the target pitfall; feedback quality was then coded using the knowledge-of-mistake (KM) and knowledge-of-how-to-proceed (KH) categories from the feedback literature. This recall-only evaluation deliberately ignores false positives, since failing to spot a real issue was judged the more dangerous failure mode for learners.

What would settle it

Take each of the 20 pitfalls, write 10 or more independently authored code samples per pitfall (by different LLMs and human programmers), and rerun the same prompt and recall protocol; if any model's mean recall across the expanded set exceeds 50%, or if human expert agreement on the expected pitfall for many samples is low, the paper's central claim about LLM capability fails.

Watch

Extended reading notes

Core claim

The central finding is that none of the evaluated LLMs identified issues in machine-learning code more than half the time, with mean recall of 30% for CodeQwen, 37% for DeepSeek Coder, 35% for Code Llama, and 50% for Copilot across 20 pitfalls. Information-leakage errors concentrated in the early data-preprocessing stage — feature selection before splitting (PF 04), augmentation before splitting (PF 05), imputation before splitting (PF 19), subject overlap (PF 06), and foundation-model contamination (PF 11) — were largely invisible to all models, with recall near zero; no model identified PF 11 (foundation leak) or PF 18 (no baseline) at all. Basic evaluation-stage pitfalls, in contrast, were caught reliably, with PF 16 (accuracy on imbalanced data) and PF 20 (single metric) reaching 89–90% mean recall. The paper also finds that when models do identify a pitfall, the generated feedback essentially always includes knowledge of the mistake and usually guidance on how to proceed, and that the performance gap between the open models and the much larger closed Copilot was relatively small.

Load-bearing premise

The load-bearing premise is that a single Gemini-generated code sample per pitfall fairly represents that pitfall class and that the target pitfall is the main problem a reviewer would identify; if the samples are atypically easy or hard, the recall rates and the under-50% conclusion do not generalise.

Editorial extensions

If this is right

Current pretrained LLMs should not be relied on as sole or primary feedback providers in advanced ML courses, because they miss the majority of pitfalls and almost all information-leakage errors.
Open models such as DeepSeek Coder are a plausible local alternative to commercial services in education, since their lower recall came with more variable responses that sometimes caught errors Copilot missed, at a fraction of the model size.
When an LLM does spot a pitfall, its response is likely to include both an explanation of the mistake and suggestions for how to fix it, so the weakness is detection, not feedback quality.
Prompt engineering and in-context guidance (e.g., telling the model to check for leakage before splitting) are natural next steps, since the authors note that pretrained behavior encodes these pitfalls from training data.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Because only one code sample per pitfall was used, the reported recall rates are probably noisy: a different sample for, say, PF 04 could plausibly raise or lower recall by tens of percentage points, so the precise ordering of the models should not be over-read.
The near-total blindness to leakage-before-split errors suggests that educational tools should pair LLM feedback with deterministic static checks for train/test contamination, rather than relying on the model alone.
The zero recall on foundation-model contamination implies that LLM-based code review is currently unsafe precisely where modern ML practice is moving — fine-tuning and prompting large pretrained models on common benchmarks.
A testable extension would be to give the same prompts with an explicit checklist of the 20 pitfalls; if recall rises sharply, then the limitation is in retrieval of relevant knowledge, not in the model's ability to reason about code.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know. This is the first systematic measurement I've seen of LLMs identifying ML pitfalls in code, and the qualitative finding is probably right: all four models catch the easy evaluation-stage errors (no test set, accuracy on imbalanced data) and largely miss the information-leakage pitfalls in preprocessing. Second, the headline recall numbers are shakier than the "below 50%" conclusion admits, because each pitfall is represented by one code sample.

The genuinely new pieces: the 20-pitfall catalogue anchored in Skripchuk, Zimmermann, Kapoor, and the Lones guide; the semi-synthetic generation setup; the open/closed comparison. The KM/KH feedback analysis earns its place — when these models do spot a pitfall, the feedback usually includes both an explanation and guidance on how to proceed. The observation that Copilot's fixed low temperature produces all-or-nothing recall while the open models are variable but occasionally right is worth keeping.

Soft spots, in size order. (1) The unit of generalization is the code sample, not the pitfall class, and there is exactly one sample per pitfall. Limitation (iv) concedes this, but the consequence is unquantified: the aggregate means are averages over 20 samples, and at that effective sample size the confidence intervals for the open models reach toward 50%. The data do not establish "none of the LLMs exceeds 50%" at the precision the conclusion implies. (2) The generation process kept samples that exhibited the target pitfall but never checked whether they contained additional errors. A model that flags a different genuine error in a multi-error sample is scored as a false negative. That would systematically depress recall, particularly for the leak pitfalls, which often co-occur with a missing train/test split. The stress-test note's "artifact" framing is too strong, though: the cross-model consistency — near-zero recall on PF04, PF05, PF11, PF18 across all four models, high recall on PF01, PF02, PF16, PF20 across all four — suggests the pattern is real even if the exact figures are noisy. (3) False positives are unmeasured. The exclusion is argued, but a model that hallucinates errors is a real hazard for learners. (4) The repository, advertised as a replication contribution, is password-protected. That undercuts the contribution. (5) Minor: single-coder annotation without cross-coding, tolerable given how objective the coding is.

The audience is computing-education researchers, AI-in-education people, and ML educators deciding whether to trust AI tutors. Net: the direction is likely right — pretrained LLMs are not yet reliable ML-pitfall tutors — and the limitations section is candid. But the Section 6 claim overreaches the evidence. This deserves a serious referee, not a desk reject; a referee should require data release, more samples per pitfall, and a check for multi-error samples or an analysis that accounts for them.

Referee Report

4 major / 5 minor

Summary. The paper reports an empirical evaluation of four LLMs (GitHub Copilot, CodeQwen, DeepSeek Coder, and Code Llama) on the task of identifying 20 common machine learning pitfalls in Python code samples, together with an analysis of whether the models' feedback provides knowledge of the mistake (KM) and knowledge of how to proceed (KH). The authors generated one semi-synthetic code sample per pitfall using Google Gemini, prompted each model with the samples, and measured recall of the target pitfall. They find that all models identify on average fewer than 50% of the pitfalls, with particularly poor performance on information-leakage and early-pipeline pitfalls, and that the open models perform close to Copilot despite being much smaller. They conclude that pretrained LLMs are not yet reliable enough to support advanced ML education, while noting that when pitfalls are identified, the generated feedback is mostly useful. The paper also releases a repository of prompts, code samples, and responses.

Significance. If the result holds, the paper addresses an important and understudied question: whether LLM-based assistants can support the transition from ML theory to practice, where errors such as data leakage have serious consequences. The evaluation targets a carefully chosen catalogue of pitfalls grounded in prior work on ML errors, uses a semisynthetic generation approach previously validated in computing education, and includes open models as well as a commercial baseline. The publicly claimed release of the dataset and scripts, the multi-temperature sampling for open models, and the explicit coding of feedback types are all strengths. However, the headline quantitative claim is strongly restricted by the single-sample-per-pitfall design and the recall-only scoring, as detailed below. The paper is therefore best read as a preliminary benchmark rather than a definitive comparative assessment, and the conclusions need to be softened and better quantified.

major comments (4)

[Section 6, Table 3] The headline claim that 'none of the LLMs were capable of identifying issues within code more than 50% of the time' is not statistically established by the reported data. Section 3.2 states that only one code sample was produced for each pitfall, and Limitation (iv) acknowledges this, so the per-model means in Table 3 are averages over 20 pitfall-level items. Treating each pitfall as a Bernoulli-like trial, the 95% confidence interval for Copilot's 50% mean is approximately 27%–73%, and the intervals for the open models' 30%, 37%, and 35% means all overlap 50%. The conclusion should be rephrased with confidence intervals or supported by multiple independent samples per pitfall; otherwise the statement that all models fall below 50% is not supported by the evidence.
[Section 3.5, RQ1] The study measures recall only and explicitly excludes false positives and true negatives. Because RQ1 asks how reliably LLMs identify pitfalls, and the conclusions state that LLMs 'cannot reliably support ML education,' a model that flags many issues, including spurious ones, could achieve high recall while being unreliable in practice. A recall-only metric cannot distinguish a careful detector from a promiscuous one. The authors should either report precision or otherwise measure false-positive behavior, or substantially weaken the reliability language and frame the contribution as a recall-limited evaluation.
[Section 3.2, Table 3] The single-sample-per-pitfall design creates a potential construct-validity confound because the generation process only required that each sample exhibit the target pitfall, not that it be free of other pitfalls. If a sample contains an additional genuine error and an LLM identifies that non-target error, the response is coded as a false negative even though it found a real issue in the code. This could systematically depress the reported recall, especially for early-pipeline pitfalls such as PF03–PF05 and PF19, where missing train/test splits often co-occur with the target leakage. The authors should verify or assert single-pitfall purity, allow credit for any valid identified error, or report an analysis of non-target errors detected by the models.
[Section 3.5, Section 4.1.1] The comparison between Copilot and the open models is confounded by unequal sampling and uncontrolled temperature. Open models were prompted 25 times per pitfall (5 repeats at each of 5 temperatures), while Copilot was prompted only 5 times per pitfall, and Table 3 aggregates recall over these different denominators. Because Copilot's temperature is not configurable and is presumably near zero, its all-or-nothing pattern in Table 3 is not directly comparable to the open models' aggregate recall. This weakens the conclusion in Section 4.1.1 that the open-vs-closed gap is 'relatively small.' Reporting temperature-specific results for the open models or using an equitable sampling scheme would make the comparison interpretable.

minor comments (5)

[Figure 2] The caption of Figure 2 uses 'accuracy@5' while the text and other figure captions use 'recall@5'; the terminology should be aligned.
[Section 3.4] The printed prompt example contains typos that should be corrected before publication: 'from sklearn.etrics' and 'from sklearn.linear model' should be proper import statements, and the code formatting should be consistent.
[Section 4.1.3, Section 4.1.1] Section 4.1.3 refers to 'FP 14' where it should say 'PF 14,' and Section 4.1.1 describes 'the first five of these (ranks 1–4)' and 'the last seven in the table (ranks 11 onward),' which is numerically inconsistent with the 20 rows in Table 3; the rank groupings should be stated consistently.
[Data availability] The abstract and introduction state that the dataset and scripts are 'publicly shared,' but the Data availability declaration says the repository is 'password protected to prevent its usage in training large language models.' Please clarify how readers can obtain access, since a password-protected repository is not public in the usual sense and the stated reproducibility contribution depends on this access.
[Section 3.5] The evaluation of KM and KH feedback was conducted by a single author, with the ground truth formulated by co-authors; the authors note this is an objective task, but a second coder or an inter-rater reliability statistic would strengthen confidence in the qualitative feedback categories.

Circularity Check

0 steps flagged · score 1.0 of 10

Empirical benchmark with no derivation chain; the 'below 50%' claim is a measured outcome, not a consequence of the paper's assumptions. No significant circularity found.

full rationale

The paper's central claim is an empirical measurement: four LLMs were prompted with 20 code samples and responses were scored against an expert ground truth. No quantity is fitted to the outcome and then renamed as a prediction; recall is computed directly from the responses using Equation (1). The pitfall catalogue is grounded in external prior work (Kapoor et al. 2024; Skripchuk et al. 2022; Zimmermann et al. 2024) as well as Lones (2024), which is a self-citation by a co-author but functions only as a source of pitfall definitions, not as evidence for the recall rates. The sample-generation rule ('Only solutions which exhibited the relevant pitfall were kept') selects for the presence of the target error, which is a prerequisite for measuring recall and does not preordain whether the LLMs will identify it. The acknowledged single-sample-per-pitfall design (Limitation iv) and the author-conducted response coding are validity threats that could affect generalizability, but they do not make the conclusion equivalent to the inputs by construction. There is no self-definitional reduction, no fitted input presented as a prediction, and no load-bearing uniqueness theorem. The main conclusion is an empirical result that could have gone the other way, so circularity score is minimal.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The benchmark has no fitted model parameters. The central claim rests on the representativeness of the pitfall catalogue and of the Gemini-generated samples, and on the choice to measure recall without false positives. The ground truth is externally sourced but author-coded. Temperature values are an experimental sweep rather than fitted parameters.

free parameters (1)

Temperature sweep for open models = 0.3, 0.5, 0.7, 0.8, 1.0
Chosen by the authors; mean recall is averaged over these values and over 5 repeats, so the reported rates depend on this sweep. The authors show no single temperature is consistently best.

assumptions (4)

domain assumption The 20-pitfall catalogue (PF01-PF20) is representative of common ML errors in education and practice.
Section 3.1 derives the catalogue from Kapoor et al. 2024, Lones 2024, Skripchuk et al. 2022, and Zimmermann et al. 2024; the rankings and conclusions about 'common pitfalls' are only as valid as this catalogue.
domain assumption Gemini-generated semisynthetic code samples are a fair proxy for university student ML code.
Section 3.2 justifies this by reference to Leinonen et al.'s validation of synthetic buggy code in a different context; no direct comparison to actual student ML submissions is provided, and one sample is used per pitfall.
domain assumption Recall without false positives is an appropriate measure of LLM reliability for this educational scenario.
Section 3.5 explicitly excludes false positives and true negatives; if LLMs invent issues or give misleading feedback, the reliability of the tools is overstated relative to the recall metric.
domain assumption Single-author coding of KM and KH feedback is reliable without inter-rater agreement.
Section 3.5 states the first author conducted the evaluation and that cross-coding is not required; feedback categorization involves judgment, so this assumption could introduce bias.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Navigating Pitfalls: Evaluating LLMs in Machine Learning Programming Education." pith.science (2026). https://pith.science/paper/7HIDKX5Y

@misc{pith2026250518220,
  author       = {Pith},
  title        = {Pith review of: Navigating Pitfalls: Evaluating LLMs in Machine Learning Programming Education},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7HIDKX5Y}},
  note         = {Machine review of arXiv:2505.18220}
}

read the original abstract

The rapid advancement of Large Language Models (LLMs) has opened new avenues in education. This study examines the use of LLMs in supporting learning in machine learning education; in particular, it focuses on the ability of LLMs to identify common errors of practice (pitfalls) in machine learning code, and their ability to provide feedback that can guide learning. Using a portfolio of code samples, we consider four different LLMs: one closed model and three open models. Whilst the most basic pitfalls are readily identified by all models, many common pitfalls are not. They particularly struggle to identify pitfalls in the early stages of the ML pipeline, especially those which can lead to information leaks, a major source of failure within applied ML projects. They also exhibit limited success at identifying pitfalls around model selection, which is a concept that students often struggle with when first transitioning from theory to practice. This questions the use of current LLMs to support machine learning education, and also raises important questions about their use by novice practitioners. Nevertheless, when LLMs successfully identify pitfalls in code, they do provide feedback that includes advice on how to proceed, emphasising their potential role in guiding learners. We also compare the capability of closed and open LLM models, and find that the gap is relatively small given the large difference in model sizes. This presents an opportunity to deploy, and potentially customise, smaller more efficient LLM models within education, avoiding risks around cost and data sharing associated with commercial models.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

51 extracted references · 16 canonical work pages

[1]

Sut- ton, C

Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., . . . Sut- ton, C. (2021).Program synthesis with large language models.Retrieved from https://arxiv.org/abs/2108.07732

arXiv 2021
[3]

Burtsev, M., Reeves, M., Job, A. (2024). The working limitations of large language models.MIT Sloan Management Review,65(2), 8–10, Retrieved from https://sloanreview.mit.edu/article/the-working-limitations-of- large-language-models/

work page 2024
[4]

Cambaz, D., & Zhang, X. (2024). Use of ai-driven code generation models in teaching and learning programming: a systematic literature review.Proceedings of the 55th acm technical symposium on computer science education v. 1(p. 172–178). New York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/3626252.3630958

arXiv 2024
[5]

Cheng, L., Li, X., Bing, L. (2023). Is GPT-4 a good data analyst? H. Bouamor, J. Pino, & K. Bali (Eds.),Findings of the association for computational linguistics: EMNLP 2023, singapore, december 6-10, 2023(pp. 9496–9514). Association for Computational Linguistics. Retrieved from https://doi.org/10.18653/v1/2023.findings-emnlp.637

work page doi:10.18653/v1/2023.findings-emnlp.637 2023
[6]

what are they not telling me?

Cinca, R., Costanza, E., Musolesi, M., Alebri, M. (2025). “what are they not telling me?” learning machine learning: Understanding the challenges for novices.Inter- national Journal of Human-Computer Studies,196, 103438, https://doi.org/ 10.1016/j.ijhcs.2024.103438 CodeLlama (2024).codellama/CodeLlama-34b-Instruct-hf·Hugging Face — huggingface.co.https://...

arXiv 2025
[7]

Cooper, R.G. (2024). Why AI projects fail: Lessons from new product development. IEEE Engineering Management Review,52(4), 15–21, https://doi.org/10.1109/ EMR.2024.3419268 DeepSeek (2024).deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct·Hugging Face — huggingface.co.https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Lite -Instruct. ([Accessed 26-10-2024])

work page arXiv 2024
[8]

Denny, P., Luxton-Reilly, A., Tempero, E. (2012). All syntax errors are not equal.Proceedings of the 17th acm annual conference on innovation and technology in computer science education(pp. 75–80). Retrieved from https://doi.org/10.1145/2325296.2325318 23

arXiv 2012
[9]

Denny, P., MacNeil, S., Savelka, J., Porter, L., Luxton-Reilly, A. (2024). Desirable characteristics for ai teaching assistants in programming education.Proceed- ings of the 2024 on innovation and technology in computer science education v. 1(p. 408–414). New York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/364921...

arXiv 2024

Show all 51 references

[10]

Ermakova, T., Blume, J., Fabian, B., Fomenko, E., Berlin, M., Hauswirth, M. (2021). Beyond the hype: Why do data-driven projects fail?54th hawaii international conference on system sciences, HICSS(pp. 1–10). ScholarSpace. Retrieved from https://hdl.handle.net/10125/71237

2021
[11]

Ettles, A., Luxton-Reilly, A., Denny, P. (2018). Common logic errors made by novice programmers.Proceedings of the 20th australasian computing education confer- ence(pp. 83–89). Retrieved from https://doi.org/10.1145/3160489.3160493 GitHub (2024).GitHub Copilot·Your AI pair pr...

2018
[12]

Zilles, C. (2008). Identifying important and difficult concepts in introductory computing courses using a delphi process.Proceedings of the 39th sigcse tech- nical symposium on computer science education(pp. 256–260). Retrieved from https://doi.org/10.1145/1352322.1352226

2008
[13]

Yacef, K

Gramoli, V., Charleston, M., Jeffries, B., Koprinska, I., McGrane, M., Radu, A., . . . Yacef, K. (2016). Mining autograding data in computer science educa- tion.Proceedings of the australasian computer science week multiconference. New York, NY, USA: Association for Computing ...

2016
[14]

Gulwani, S., Radiˇ cek, I., Zuleger, F. (2018). Automated clustering and program repair for introductory programming assignments.ACM SIGPLAN Notices,53(4), 465–480, https://doi.org/10.1145/3192366.3192387

2018
[15]

Hellas, A., Leinonen, J., Sarsa, S., Koutcheme, C., Kujanp¨ a¨ a, L., Sorva, J. (2023). Exploring the responses of large language models to beginner programmers’ help requests. K. Fisler, P. Denny, D. Franklin, & M. Hamilton (Eds.),Proceedings of the 2023 ACM conference on int...

2023
[16]

Hewamalage, H., Ackermann, K., Bergmeir, C. (2023). Forecast evaluation for data scientists: common pitfalls and best practices.Data Min. Knowl. Discov.,37(2), 788–832, https://doi.org/10.1007/S10618-022-00894-5 24 Hugging Face (2024).Big Code Models Leaderboard - a Hugging Fa...

2023 doi
[17]

(2024).A survey on large language models for code generation.Retrieved from https://arxiv.org/abs/2406.00515

Jiang, J., Wang, F., Shen, J., Kim, S., Kim, S. (2024).A survey on large language models for code generation.Retrieved from https://arxiv.org/abs/2406.00515

2024 arXiv
[18]

(2024, 2024/10/23)

Narayanan, A. (2024, 2024/10/23). Reforms: Consensus-based recommenda- tions for machine-learning-based science.Science Advances,10(18), eadk3452, https://doi.org/10.1126/sciadv.adk3452

2024 doi
[19]

Kapoor, S., & Narayanan, A. (2023). Leakage and the reproducibility crisis in machine- learning-based science.Patterns,4(9), 100804, https://doi.org/https://doi.org/ 10.1016/j.patter.2023.100804

2023
[20]

Kasneci, G

Kasneci, E., Sessler, K., K¨ uchemann, S., Bannert, M., Dementieva, D., Fischer, F., . . . Kasneci, G. (2023). Chatgpt for good? on opportunities and challenges of large language models for education.Learning and Individual Differences,103, 102274, https://doi.org/https://doi....

2023
[21]

Keuning, H., Jeuring, J., Heeren, B. (2018). A systematic literature review of auto- mated feedback generation for programming exercises.ACM Transactions on Computing Education (TOCE),19(1), 1–43, https://doi.org/10.1145/3231711

2018 doi
[22]

(2024).Llm- itation is the sincerest form of data: Generating synthetic buggy code submissions for computing education.Retrieved from https://arxiv.org/abs/2411.10455

Leinonen, J., Denny, P., Kiljunen, O., MacNeil, S., Sarsa, S., Hellas, A. (2024).Llm- itation is the sincerest form of data: Generating synthetic buggy code submissions for computing education.Retrieved from https://arxiv.org/abs/2411.10455

2024 arXiv
[23]

Liao, T., Taori, R., Raji, D., Schmidt, L. (2021). Are we learning yet? A meta review of evaluation failures across machine learning. J. Vanschoren & S. Yeung (Eds.),Proceedings of the neural information processing sys- tems track on datasets and benchmarks 1, neurips datasets...

2021
[24]

Huang, G

Liu, K., Liu, Y., Chen, Z., Zhang, J.M., Han, Y., Ma, Y., . . . Huang, G. (2024). Llm-powered test case generation for detecting tricky bugs.Retrieved from https://arxiv.org/abs/2404.10304 25

2024 arXiv
[25]

(2024, Oct 11)

Lones, M.A. (2024, Oct 11). Avoiding common machine learning pitfalls.Patterns, 5(10), , https://doi.org/10.1016/j.patter.2024.101046

2024
[26]

Lyu, W., Wang, Y., Chung, T.R., Sun, Y., Zhang, Y. (2024). Evaluating the effective- ness of llms in introductory computer science education: A semester-long field study.Proceedings of the eleventh acm conference on learning @ scale(p. 63–74). New York, NY, USA: Association fo...

2024
[27]

Leinonen, J

MacNeil, S., Tran, A., Hellas, A., Kim, J., Sarsa, S., Denny, P., . . . Leinonen, J. (2023). Experiences from using code explanations generated by large lan- guage models in a web software development e-book.Proceedings of the 54th acm technical symposium on computer science e...

2023
[28]

Nahar, N., Zhang, H., Lewis, G.A., Zhou, S., K¨ astner, C. (2023). A meta- summary of challenges in building products with ML components - col- lecting experiences from 4758+ practitioners.2nd IEEE/ACM interna- tional conference on AI engineering - software engineering for ai,...

2023
[29]

Narciss, S. (2008). Feedback strategies for interactive learning tasks.Handbook of research on educational communications and technology(pp. 125–143). Routledge. Retrieved from https://www.taylorfrancis.com/chapters/edit/10.4324/9780203880869- 13/feedback-strategies-interactiv...

2008 doi
[30]

Naveed, H., Khan, A.U., Qiu, S., Saqib, M., Anwar, S., Usman, M., . . . Mian, A. (2024).A comprehensive overview of large language models.Retrieved from https://arxiv.org/abs/2307.06435

2024 arXiv
[31]

Nejjar, M., Zacharias, L., Stiehle, F., Weber, I. (2025). Llms for science: Usage for code generation and data analysis.J. Softw. Evol. Process.,37(1), , https:// doi.org/10.1002/SMR.2723 Ollama (2024).Ollama.Retrieved from https://ollama.com/ ([Accessed 26-10-2024]) OpenAI (2...

2025 doi
[32]

(2023).Generating high-precision feedback for programming syntax errors using large language models.Retrieved from https://arxiv.org/abs/2302.04662 26

Phung, T., Cambronero, J., Gulwani, S., Kohn, T., Majumdar, R., Singla, A., Soares, G. (2023).Generating high-precision feedback for programming syntax errors using large language models.Retrieved from https://arxiv.org/abs/2302.04662 26

2023 arXiv
[33]

Savelka, J. (2023). Transformed by transformers: Navigating the ai coding revo- lution for computing education: An iticse working group conducted by humans. Proceedings of the 2023 conference on innovation and technology in computer science education v. 2(p. 561–562). New York...

2023
[34]

Savelka, J. (2023). The robots are here: Navigating the generative ai revo- lution in computing education.Proceedings of the 2023 working group reports on innovation and technology in computer science education(p. 108–159). New York, NY, USA: Association for Computing Machiner...

2023
[35]

It’s Weird That it Knows What I Want

Prather, J., Reeves, B.N., Denny, P., Becker, B.A., Leinonen, J., Luxton-Reilly, A., . . . Santos, E.A. (2023). “It’s Weird That it Knows What I Want”: Usability and interactions with Copilot for novice programmers.ACM Transactions on Computer-Human Interaction,31(1), 1–31, ht...

2023 doi
[36]

Price, T.W., Dong, Y., Zhi, R., Paaßen, B., Lytle, N., Catet´ e, V., Barnes, T. (2019). A comparison of the quality of data-driven programming hint genera- tion algorithms.International Journal of Artificial Intelligence in Education, 29, 368–395, https://doi.org/10.1007/s4059...

2019 doi
[37]

Raschka, S., Patterson, J., Nolet, C. (2020). Machine learning in python: Main devel- opments and technology trends in data science, machine learning, and artificial intelligence.Information,11(4), , https://doi.org/10.3390/info11040193

2020 doi
[38]

Ribeiro, F. (2023). Large language models for automated program repair.Compan- ion proceedings of the 2023 acm sigplan international conference on systems, programming, languages, and applications: Software for humanity(p. 7–9). New York, NY, USA: Association for Computing Mac...

2023
[39]

Skripchuk, J., Shi, Y., Price, T. (2022). Identifying common errors in open- ended machine learning projects.Proceedings of the 53rd acm technical symposium on computer science education - volume 1(p. 216–222). New

2022
[40]

Retrieved from https://doi.org/10.1145/3478431.3499397 27 S Kumar, S., Adam Lones, M., Maarek, M., Zantout, H

York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/3478431.3499397 27 S Kumar, S., Adam Lones, M., Maarek, M., Zantout, H. (2024). Investigating the proficiency of large language models in formative feedback generation for student progra...

2024
[41]

(2023).An analysis of the automatic bug fixing performance of chatgpt.Retrieved from https://arxiv.org/abs/2301.08653

Sobania, D., Briesch, M., Hanna, C., Petke, J. (2023).An analysis of the automatic bug fixing performance of chatgpt.Retrieved from https://arxiv.org/abs/2301.08653

2023 arXiv
[42]

Sulmont, E., Patitsas, E., Cooperstock, J.R. (2019). Can you teach me to machine learn?Proceedings of the 50th acm technical symposium on computer science edu- cation(p. 948–954). New York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/32...

2019
[43]

Tambon, F., Dakhel, A.M., Nikanjam, A., Khomh, F., Desmarais, M.C., Antoniol, G. (2025). Bugs in large language models generated code: an empirical study. Empir. Softw. Eng.,30(3), 65, https://doi.org/10.1007/S10664-025-10614-4

2025 doi
[44]

(2024, January)

Tu, X., Zou, J., Su, W., Zhang, L. (2024, January). What Should Data Science Education Do With Large Language Models?Harvard Data Science Review, 6(1), , https://doi.org/10.1162/99608f92.bff007ab (Publisher: The MIT Press)

2024 doi
[45]

Weizenbaum, J. (1966). Eliza—a computer program for the study of natural language communication between man and machine.Communications of the ACM,9(1), 36–45, https://doi.org/10.1145/365153.365168

1966
[46]

Wermelinger, M. (2023). Using github copilot to solve simple programming problems. Proceedings of the 54th acm technical symposium on computer science education v. 1(pp. 172–178). Retrieved from https://doi.org/10.1145/3545945.3569830

2023
[47]

Xia, C.S., Wei, Y., Zhang, L. (2023). Automated program repair in the era of large pre-trained language models.Proceedings of the 45th international con- ference on software engineering(p. 1482–1494). IEEE Press. Retrieved from https://doi.org/10.1109/ICSE48619.2023.00129

2023
[48]

Yi, J., Ahmed, U.Z., Karkare, A., Tan, S.H., Roychoudhury, A. (2017). A feasibility study of using automated program repair for introductory programming assignments.Proceedings of the 2017 11th joint meeting on foundations of software engineering(pp. 740–751). Retrieved from h...

2017
[49]

(2022).Repairing bugs in python assignments using large language models

Zhang, J., Cambronero, J., Gulwani, S., Le, V., Piskac, R., Soares, G., Verbruggen, G. (2022).Repairing bugs in python assignments using large language models. 28 Retrieved from https://arxiv.org/abs/2209.14876

2022 arXiv
[50]

Wen, J.- R

Zhao, W.X., Zhou, K., Li, J., Tang, T., Wang, X., Hou, Y., . . . Wen, J.- R. (2024).A survey of large language models.Retrieved from https://arxiv.org/abs/2303.18223

2024 arXiv
[51]

Zimmermann, R.M., Allin, S., Zhang, L. (2024). Common errors in machine learning projects: A second look.Proceedings of the 23rd koli calling international conference on computing education research.New

2024
[52]

Retrieved from https://doi.org/10.1145/3631802.3631808 29

York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/3631802.3631808 29

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Sut- ton, C

Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., . . . Sut- ton, C. (2021).Program synthesis with large language models.Retrieved from https://arxiv.org/abs/2108.07732

arXiv 2021

[2] [3]

Burtsev, M., Reeves, M., Job, A. (2024). The working limitations of large language models.MIT Sloan Management Review,65(2), 8–10, Retrieved from https://sloanreview.mit.edu/article/the-working-limitations-of- large-language-models/

work page 2024

[3] [4]

Cambaz, D., & Zhang, X. (2024). Use of ai-driven code generation models in teaching and learning programming: a systematic literature review.Proceedings of the 55th acm technical symposium on computer science education v. 1(p. 172–178). New York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/3626252.3630958

arXiv 2024

[4] [5]

Cheng, L., Li, X., Bing, L. (2023). Is GPT-4 a good data analyst? H. Bouamor, J. Pino, & K. Bali (Eds.),Findings of the association for computational linguistics: EMNLP 2023, singapore, december 6-10, 2023(pp. 9496–9514). Association for Computational Linguistics. Retrieved from https://doi.org/10.18653/v1/2023.findings-emnlp.637

work page doi:10.18653/v1/2023.findings-emnlp.637 2023

[5] [6]

what are they not telling me?

Cinca, R., Costanza, E., Musolesi, M., Alebri, M. (2025). “what are they not telling me?” learning machine learning: Understanding the challenges for novices.Inter- national Journal of Human-Computer Studies,196, 103438, https://doi.org/ 10.1016/j.ijhcs.2024.103438 CodeLlama (2024).codellama/CodeLlama-34b-Instruct-hf·Hugging Face — huggingface.co.https://...

arXiv 2025

[6] [7]

Cooper, R.G. (2024). Why AI projects fail: Lessons from new product development. IEEE Engineering Management Review,52(4), 15–21, https://doi.org/10.1109/ EMR.2024.3419268 DeepSeek (2024).deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct·Hugging Face — huggingface.co.https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Lite -Instruct. ([Accessed 26-10-2024])

work page arXiv 2024

[7] [8]

Denny, P., Luxton-Reilly, A., Tempero, E. (2012). All syntax errors are not equal.Proceedings of the 17th acm annual conference on innovation and technology in computer science education(pp. 75–80). Retrieved from https://doi.org/10.1145/2325296.2325318 23

arXiv 2012

[8] [9]

Denny, P., MacNeil, S., Savelka, J., Porter, L., Luxton-Reilly, A. (2024). Desirable characteristics for ai teaching assistants in programming education.Proceed- ings of the 2024 on innovation and technology in computer science education v. 1(p. 408–414). New York, NY, USA: Association for Computing Machinery. Retrieved from https://doi.org/10.1145/364921...

arXiv 2024