Are We SOLID Yet? An Empirical Study on Prompting LLMs to Detect Design Principle Violations

Anil Koyuncu; Ar\c{c}in \"Ulk\"u Erg\"uzen; Fatih Pehlivan; Mayasah Lami; Sahand Moslemi Yengejeh

REVIEW 4 major objections 5 minor 29 references

Are We SOLID Yet? An Empirical Study on Prompting LLMs to Detect Design Principle Violations

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

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

Pith's one-line read Across 240 validated code snippets and four prompt strategies, LLM detection of SOLID violations is model-, prompt-, principle-, and language-dependent, with GPT-4o Mini leading on most principles but no strategy universally best.

desk verdict Useful first benchmark of LLMs on SOLID detection, but the 'decisive' model ranking is under-supported by unblinded manual labeling and a same-family dataset confound. read the letter →

arxiv 2509.03093 v1 pith:W4HQJRQM submitted 2025-09-03 cs.SE cs.AI

Fatih Pehlivan , Arçin Ülkü Ergüzen , Sahand Moslemi Yengejeh , Mayasah Lami , Anil Koyuncu This is my paper

classification cs.SEcs.AI

keywords SOLIDprinciplesdesignprincipleviolationslargelanguagemodelspromptengineeringbenchmarkdatasetcodequalityanalysismulti-languageempiricalsoftware

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

This paper tries to establish the first systematic, reproducible picture of how well large language models detect violations of the five SOLID design principles. It builds a 240-sample benchmark spanning Java, Python, C#, and Kotlin, and runs four LLMs under four prompt strategies. The headline result is a clear model hierarchy—GPT-4o Mini on top, then Qwen2.5-Coder, with CodeLlama and DeepSeek far behind—and an equally clear finding that prompt design changes outcomes as much as model choice does. The point matters because if LLMs are to serve as design reviewers, their accuracy on principled code analysis needs to be known per principle, per language, and per complexity level rather than averaged into a single score.

What carries the argument

The load-bearing artifact is a purpose-built dataset of 240 manually validated code snippets, 20 scenarios times three difficulty levels times four languages, each with violating and refactored versions. Around it the paper wraps four prompt strategies—DEFAULT zero-shot, EXAMPLE with one-line hints, SMELL two-step smell-to-principle reasoning, ENSEMBLE five-principle scoring with justification—and a JSON-output classification pipeline that required manual relabeling of 37% of the 3,840 responses. The design lets accuracy and F1 be decomposed by model, prompt, principle, language, and complexity.

What would settle it

Replace the dataset's generated examples with equivalent snippets drawn from real open-source projects, keep the same prompts and models, label them blinded, and recompute the model-prompt F1 table; if GPT-4o Mini's lead and the EXAMPLE-over-SMELL ordering do not reproduce, the reported hierarchy is an artifact of the benchmark's construction.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that SOLID-violation detection is not one capability but a bundle of model-prompt-principle interactions. GPT-4o Mini achieves F1 99.7 on SRP but falls to low scores on DIP; the ENSEMBLE prompt raises OCP detection to 75.7 while the two-step SMELL prompt collapses on OCP and LSP; C# and Java are detected far better than Python; and every model's accuracy drops sharply as code complexity rises. The authors offer this as evidence that effective AI-driven design analysis needs to pair the right model with the right prompt for the specific design context, not to look for a single best system.

Load-bearing premise

Everything rests on the correctness and neutrality of the reference labels: the 240 snippets were produced from a single model family's output and refined by two authors, and a third of all model responses were hand-labeled, so if those labels or relabels favor one model or prompt, the comparative rankings shift.

Editorial extensions

If this is right

No single model-prompt combination is best across all five SOLID principles; tooling should route different detection tasks to different configurations.
Direct, context-rich prompts (EXAMPLE) help on nuanced principles like DIP and LSP, while an indirect two-step SMELL prompt consistently hurts, so prompt design should avoid abstract reasoning chains for this task.
Detection is reliably better in statically typed languages (C# and Java) than in Python, suggesting that type structure provides signals LLMs can read.
Complexity is the largest cross-cutting factor: accuracy on OCP falls from 64.8 on easy samples to 18.0 on hard ones, which sets a realistic ceiling for detection in real code.
The dataset and replication package establish a baseline for future benchmarks of design-aware code generation and refactoring, not just detection.

Reading between the lines

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

A fair cross-family test would regenerate the benchmark from independently written code, since the examples come from the same model family as the reported winner; if the lead shrinks, part of the ranking reflects dataset provenance rather than design understanding.
The strong drop on 'hard' samples implies that on real industrial code, where incidental complexity is higher, even the best configuration will miss many violations; deployment should pair LLM flags with static-analysis or human review rather than treat the model as a verdict.
A direct extension is to score the refactored versions the dataset already contains: if detection accuracy varies by prompt and language, repair quality probably does too, giving a concrete test of the paper's refactoring follow-up.
Reported per-principle F1 scores should be read with the 37% manual relabeling in mind; a blinded relabeling study could show how much of the ranking depends on how output deviations were resolved.

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

Colleague,

This is a genuinely useful first empirical benchmark of LLMs for SOLID violation detection, but the headline result—GPT-4o Mini decisively outperforming the others—rests on shakier ground than the abstract lets on. The dataset is a real contribution: 240 snippets across five principles, four languages, three difficulty levels, with both violating and clean versions, plus a replication package with prompts, outputs, and scripts. That alone makes the paper worth a look for anyone building AI-assisted code review. The systematic comparison of four models and four prompt strategies is also well executed: no single prompt wins everywhere, ENSEMBLE helps OCP, EXAMPLE helps DIP, and complexity sharply degrades accuracy. These findings are plausible and useful.

The soft spots are exactly where the reader's report lands. The biggest one is the manual relabeling: 1,431 of 3,840 responses (37%) were reviewed and relabeled by the authors, with no blinding, no randomization, no inter-annotator agreement. The paper calls this 'rigorous' but gives no evidence. If the authors unconsciously favored outputs that matched their expectations—say, GPT-4o Mini's responses because they look more coherent—the reported F1 gaps (SRP 99.7 vs 55.6) could shrink or grow. Second, the dataset was generated by prompting gpt-4o, so GPT-4o Mini, from the same family, may have an unfair advantage due to shared style or tokenization. This is a confound, not a fatal flaw, but it undercuts the 'decisive' hierarchy. Third, all results come from a single temperature-0 run, with no confidence intervals or significance tests. Some of the between-model or between-prompt differences might be noise.

None of this sinks the paper, but it should temper the claims. The authors are honest about limitations in the conclusion, and the replication package is a plus. I'd send this to peer review—it's a solid dataset and a clear research question, and the weaknesses are fixable with blinding, inter-annotator agreement, contamination checks, and some basic statistics. For readers, I'd treat the model ranking as preliminary and focus on the dataset and the qualitative findings about prompt-language interactions.

Referee Report

4 major / 5 minor

Summary. The paper presents an empirical benchmark for detecting SOLID design-principle violations in code using four LLMs (CodeLlama-70B, DeepSeekCoder-33B, Qwen2.5-Coder-32B, GPT-4o Mini), four programming languages (Java, Python, Kotlin, C#), and four prompt strategies (DEFAULT, EXAMPLE, SMELL, ENSEMBLE). The authors construct a new dataset of 240 manually validated code snippets spanning all five SOLID principles at three difficulty levels, report accuracy/F1 per model, prompt, language, and complexity, and conclude that GPT-4o Mini decisively outperforms the others, that no single prompt strategy is universally best, and that detection accuracy degrades sharply with code complexity. A replication package is provided.

Significance. The study addresses a relevant and under-explored question: whether current LLMs can reliably detect semantic design flaws such as SOLID violations. Its strengths include a multi-language, multi-model, multi-prompt design, a publicly available replication package with raw outputs, and an explicit acknowledgment of limitations. If the reported rankings and prompt-by-principle interactions were statistically and methodologically secure, the benchmark would be a useful reference point for developers and researchers. However, the central quantitative claims—especially the 'decisive' superiority of GPT-4o Mini—rest on a labeling process that lacks blinding and inter-annotator reliability evidence, and on point estimates without confidence intervals or significance tests. These issues are fixable but currently prevent the strongest conclusions from being empirically secure.

major comments (4)

[III-C] The manual relabeling of 1,431 of 3,840 responses (37%) is load-bearing for every accuracy/F1 figure in Section IV and for the abstract's claim that GPT-4o Mini 'decisively outperforms' others. No blinding, no independent second labeler, no inter-annotator agreement (e.g., Cohen's kappa), and no sensitivity analysis are reported. Because the labels are used to compute Figure 3a and all subsequent conclusions, systematic bias in this step—even unconscious—could directly produce the observed model hierarchy. Please report a blind or at least independent re-labeling of a random sample, quantify agreement, and show that the main ordering is unchanged when only regex-derived labels are used.
[III-E and IV-A] All experiments are single temperature-0 runs, and the paper reports F1/accuracy point estimates without any confidence intervals, bootstrap intervals, or significance tests. For example, Section IV-A states that Qwen is a 'clear second' with DIP F1=10.8 and that CodeLlama is 'weak' with ISP F1=13.6, but the 240-sample size makes such differences potentially within sampling noise. Similarly, Section IV-B's 'dramatic impact' and 'no single strategy is universally best' are based on differences like ENSEMBLE's OCP F1=75.7 versus DEFAULT's OCP value, with no statistical support. Please add uncertainty quantification (e.g., bootstrap over snippets) and tests appropriate for paired classifications (e.g., McNemar) for at least the headline comparisons.
[III-A] The dataset is generated by prompting OpenAI's gpt-4o, and the top performer is GPT-4o Mini from the same organization. The paper does not test for contamination or family-specific stylistic cues that could inflate OpenAI-family performance. This is a design confound rather than misconduct, but it directly affects the 'decisive' ranking claim. Please add a contamination check (e.g., see whether GPT-4o Mini's predictions are unusually confident on gpt-4o-generated examples), generate a small external validation set using another source, or at least show examples and analyze whether any surface patterns correlate with the generating model.
[III-D and Eq. (1)] The task is a six-way classification (five principles plus 'No Violation'), but Eq. (1) defines binary F1. It is unclear whether F1 is macro-averaged over the six classes, micro-averaged, or computed one-vs-rest for each principle; the text reports per-principle F1 but never states the averaging procedure. In addition, the dataset description is ambiguous: the contributions say the dataset 'provides both violating and refactored code versions,' but the total of 240 samples and per-principle class support are not specified. Without per-class confusion matrices and class counts, the numeric F1 values in Figures 3 and 4 cannot be interpreted. Please report the exact class distribution and the averaging method, and include confusion matrices for at least the headline comparisons.

minor comments (5)

[III-A] The description of dataset validation is grammatically tangled ('One author refined outputs... A second author independently verified...'). Please clarify how many authors were involved and whether they were blind to the intended violation label.
[II, Figure 2] The text says difficulty labels 'correlate strongly' with character count and cyclomatic complexity, but no correlation coefficients are reported. Please provide the actual values or a brief quantitative summary.
[III-B] The EXAMPLE prompt embeds one illustrative line per principle. Please confirm whether these examples were taken from the test scenarios; if any overlap exists, few-shot memorization could confound the prompt comparison.
[IV-C] Figure 4b is described by reporting SRP scores for C# and Java, but the figure uses average accuracy across all principles. Label the axes and clarify what is plotted to avoid confusion.
[Abstract] The abstract says 'yet even struggles' without an explicit subject; also 'decisively outperforming' is stronger than the 'emerging results' language in the body. Softening the abstract to match the statistical evidence would improve accuracy.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an empirical benchmark with no derivation chain; the gpt-4o-generated dataset and manual relabeling are validity threats, not definitional or fitting-based circularity.

full rationale

This paper makes no formal derivation claim; it reports measurements of LLM accuracy on a constructed benchmark. There is no equation whose output is fixed by its input, no fitted parameter later renamed as a prediction, and no load-bearing self-citation. The closest concerns are (1) dataset generation by OpenAI's gpt-4o, which may advantage the same-family GPT-4o Mini, and (2) manual relabeling of 37% of outputs without reported inter-annotator agreement. Both are threats to external/internal validity and could affect the ranking, but they do not reduce the reported result to its inputs by construction: the ground-truth labels are fixed before model inference, and the model outputs are not used to define the labels. The paper explicitly acknowledges the synthetic-dataset limitation (Section V), which further indicates the authors do not claim the benchmark is equivalent to real-world code. No self-citations are present; references to prior work (e.g., Martin's SOLID principles, CoT papers) are background context. Therefore the circularity score is 0.

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

The paper introduces no new theoretical entities, forces, or conserved quantities. Its central result depends on author-constructed labels and proxies, not on a derived model, so the ledger captures the main design choices and domain assumptions rather than fitted model parameters.

free parameters (2)

Difficulty level assignments (easy/moderate/hard) = 3 levels, thresholds by character count and cyclomatic complexity
Used as the independent variable for complexity analysis; assignment is author-made and thresholds are not specified, so the difficulty axis cannot be independently reconstructed.
20 violation scenarios (4 per principle) = 20 scenarios
Dataset coverage is limited to these author-selected canonical patterns; no coverage argument beyond foundational literature is provided.

assumptions (4)

domain assumption A code snippet has a single correct label among five SOLID violations or no violation, inferable from the snippet alone.
Used throughout; the model is asked to output one most violated principle, and ground truth is assigned per snippet in Section III-A.
domain assumption Character count and cyclomatic complexity are valid proxies for difficulty.
Section III-A says labels correlate strongly with both, but no correlation statistics are reported.
domain assumption Temperature 0 sampling yields outputs that can be treated as deterministic for evaluation.
Section III-E sets temperature 0; no repeated runs or variance analysis is provided.
standard math Standard six-class metrics computed as accuracy and F1 per principle give valid comparisons without significance testing.
Section III-D defines metrics; no confidence intervals or hypothesis tests are reported.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Are We SOLID Yet? An Empirical Study on Prompting LLMs to Detect Design Principle Violations." pith.science (2026). https://pith.science/paper/W4HQJRQM

@misc{pith2026250903093,
  author       = {Pith},
  title        = {Pith review of: Are We SOLID Yet? An Empirical Study on Prompting LLMs to Detect Design Principle Violations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W4HQJRQM}},
  note         = {Machine review of arXiv:2509.03093}
}

read the original abstract

Traditional static analysis methods struggle to detect semantic design flaws, such as violations of the SOLID principles, which require a strong understanding of object-oriented design patterns and principles. Existing solutions typically focus on individual SOLID principles or specific programming languages, leaving a gap in the ability to detect violations across all five principles in multi-language codebases. This paper presents a new approach: a methodology that leverages tailored prompt engineering to assess LLMs on their ability to detect SOLID violations across multiple languages. We present a benchmark of four leading LLMs-CodeLlama, DeepSeekCoder, QwenCoder, and GPT-4o Mini-on their ability to detect violations of all five SOLID principles. For this evaluation, we construct a new benchmark dataset of 240 manually validated code examples. Using this dataset, we test four distinct prompt strategies inspired by established zero-shot, few-shot, and chain-of-thought techniques to systematically measure their impact on detection accuracy. Our emerging results reveal a stark hierarchy among models, with GPT-4o Mini decisively outperforming others, yet even struggles with challenging principles like DIP. Crucially, we show that prompt strategy has a dramatic impact, but no single strategy is universally best; for instance, a deliberative ENSEMBLE prompt excels at OCP detection while a hint-based EXAMPLE prompt is superior for DIP violations. Across all experiments, detection accuracy is heavily influenced by language characteristics and degrades sharply with increasing code complexity. These initial findings demonstrate that effective, AI-driven design analysis requires not a single best model, but a tailored approach that matches the right model and prompt to the specific design context, highlighting the potential of LLMs to support maintainability through AI-assisted code analysis.

Figures

Figures reproduced from arXiv: 2509.03093 by the authors.

**Figure 1.** Overview of the approach an LLM via a tailored prompt to predict a potential SOLID violation. A. Dataset Construction and Validation A key challenge in this domain is the absence of a public benchmark for SOLID violations. To address this, we construct a new dataset covering all five principles across four languages: Java, Python, Kotlin, and C#. Our creation process follows a hybrid methodology that combines LLM-b… view at source ↗

**Figure 3.** F1 scores of SOLID violation detection across a) LLM [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

**Figure 2.** Code characteristics (character count, cyclomatic com [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 20 canonical work pages

[1]

Applying the single responsibility principle in industry: modularity ben- efits and trade-offs,

A. Ampatzoglou, A.-A. Tsintzira, E.-M. Arvanitou, A. Chatzigeorgiou, I. Stamelos, A. Moga, R. Heb, O. Matei, N. Tsiridis, and D. Kehagias, “Applying the single responsibility principle in industry: modularity ben- efits and trade-offs,” inProceedings of the 23rd International Conference on Evaluation and Assessment in Software Engineering , 2019, pp. 347– 352

work page 2019
[2]

An experimental evaluation of the effect of solid principles to microsoft vs code metrics,

O. Turan and ¨O. ¨O. Tanrı¨over, “An experimental evaluation of the effect of solid principles to microsoft vs code metrics,” AJIT-e: Academic Journal of Information Technology , vol. 9, no. 34, pp. 7–24, 2018

work page 2018
[3]

Automated Verification of Open/Closed Principle: A Code Analysis Approach,

G. Roy, M. M, and B. A. Jacob, “Automated Verification of Open/Closed Principle: A Code Analysis Approach,” in 2024 5th International Conference for Emerging Technology (INCET) , May 2024, pp. 1–7

work page 2024
[4]

Refactoring Legacy Code Using Cleaning Up Cycles: An Experience Report,

A. V . Girjoaba and A. Capiluppi, “Refactoring Legacy Code Using Cleaning Up Cycles: An Experience Report,” in2024 IEEE International Conference on Software Maintenance and Evolution (ICSME) , Oct. 2024, pp. 753–764

work page 2024
[5]

Applying solid principles for the refactoring of legacy code: An experience report,

I. Yanakiev, B.-M. Lazar, and A. Capiluppi, “Applying solid principles for the refactoring of legacy code: An experience report,” Journal of Systems and Software , vol. 220, p. 112254, 2025

work page 2025
[6]

Benchmarking llm for code smells detec- tion: Openai gpt-4.0 vs deepseek-v3,

A. R. Sadik and S. Govind, “Benchmarking llm for code smells detec- tion: Openai gpt-4.0 vs deepseek-v3,” arXiv preprint arXiv:2504.16027, 2025

arXiv 2025
[7]

The Use of Large Language Model in Code Review Automation: An Examination of Enforcing SOLID Principles,

G. F. Martins, E. C. M. Firmino, and V . P. De Mello, “The Use of Large Language Model in Code Review Automation: An Examination of Enforcing SOLID Principles,” in Artificial Intelligence in HCI , H. Degen and S. Ntoa, Eds. Cham: Springer Nature Switzerland, 2024, pp. 86–97

work page 2024
[8]

Code llama: Open foundation models for code,

B. Rozi `ere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remez, J. Rapin, A. Kozhevnikov, I. Evtimov, J. Bitton, M. Bhatt, C. C. Ferrer, A. Grattafiori, W. Xiong, A. D ´efossez, J. Copet, F. Azhar, H. Touvron, L. Martin, N. Usunier, T. Scialom, and G. Synnaeve, “Code llama: Open foundation models for code,” 20...

arXiv 2024

Show all 29 references

[9]

Deepseek-coder: When the large language model meets programming – the rise of code intelligence,

D. Guo, Q. Zhu, D. Yang, Z. Xie, K. Dong, W. Zhang, G. Chen, X. Bi, Y . Wu, Y . K. Li, F. Luo, Y . Xiong, and W. Liang, “Deepseek-coder: When the large language model meets programming – the rise of code intelligence,” 2024. [Online]. Available: https://arxiv.org/abs/2401.14196

2024 arXiv
[10]

Qwen2.5 technical report,

Qwen, :, A. Yang, B. Yang, B. Zhang, B. Hui, B. Zheng, B. Yu, C. Li, D. Liu, F. Huang, H. Wei, H. Lin, J. Yang, J. Tu, J. Zhang, J. Yang, J. Yang, J. Zhou, J. Lin, K. Dang, K. Lu, K. Bao, K. Yang, L. Yu, M. Li, M. Xue, P. Zhang, Q. Zhu, R. Men, R. Lin, T. Li, T. Tang, T. Xia, ...
[11]

Gpt-4o: Openai’s new omni model,

OpenAI, “Gpt-4o: Openai’s new omni model,” https://openai.com/index/ gpt-4o, 2024, accessed:2025-05-16

2024
[12]

Software Metrics Proposal for Con- formity Checking of Class Diagram to SOLID Design Principles,

I. Oktafiani and B. Hendradjaya, “Software Metrics Proposal for Con- formity Checking of Class Diagram to SOLID Design Principles,” in 2018 5th International Conference on Data and Software Engineering (ICoDSE), Nov. 2018, pp. 1–6

2018
[13]

An approach to class diagrams verifica- tion according to SOLID design principles,

E. Chebanyuk and K. Markov, “An approach to class diagrams verifica- tion according to SOLID design principles,” in 2016 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD), Feb. 2016, pp. 435–441

2016
[14]

Sonarqube - continuous code quality,

S. SA, “Sonarqube - continuous code quality,” https://www.sonarsource. com/products/sonarqube/, 2024, accessed: 2025-05-16

2024
[15]

Codacy - automated code review and quality monitoring,

I. Codacy, “Codacy - automated code review and quality monitoring,” https://www.codacy.com/, 2024, accessed: 2025-05-16

2024
[16]

A few billion lines of code later: using static analysis to find bugs in the real world,

A. Bessey, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, C. Henri- Gros, A. Kamsky, S. McPeak, and D. Engler, “A few billion lines of code later: using static analysis to find bugs in the real world,” Communications of the ACM , vol. 53, no. 2, pp. 66–75, 2010

2010
[17]

Why don’t software developers use static analysis tools to find bugs?

B. Johnson, Y . Song, E. Murphy-Hill, and R. Bowdidge, “Why don’t software developers use static analysis tools to find bugs?” in 2013 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 672–681

2013
[18]

Snyk code (formerly deepcode),

S. Ltd., “Snyk code (formerly deepcode),” https://snyk.io/product/ snyk-code/, 2024, accessed: 2025-05-16

2024
[19]

Amazon codeguru reviewer,

I. Amazon Web Services, “Amazon codeguru reviewer,” https://aws. amazon.com/codeguru/, 2024, accessed: 2025-05-16

2024
[20]

Static code analysis in the ai era: An in-depth exploration of the concept, function, and potential of intelligent code analysis agents,

G. Fan, X. Xie, X. Zheng, Y . Liang, and P. Di, “Static code analysis in the ai era: An in-depth exploration of the concept, function, and potential of intelligent code analysis agents,” arXiv preprint arXiv:2310.08837 , 2023

2023 arXiv
[21]

ismell: Assembling llms with expert toolsets for code smell detection and refactoring,

D. Wu, F. Mu, L. Shi, Z. Guo, K. Liu, W. Zhuang, Y . Zhong, and L. Zhang, “ismell: Assembling llms with expert toolsets for code smell detection and refactoring,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 1345–1357

2024
[22]

Chatgpt prompt patterns for improving code quality, refactoring, requirements elicitation, and software design,

J. White, S. Hays, Q. Fu, J. Spencer-Smith, and D. C. Schmidt, “Chatgpt prompt patterns for improving code quality, refactoring, requirements elicitation, and software design,” in Generative ai for effective software development. Springer, 2024, pp. 71–108

2024
[23]

Investigating the Impact of SOLID Design Principles on Machine Learning Code Understanding,

R. Cabral, M. Kalinowski, M. T. Baldassarre, H. Villamizar, T. Es- covedo, and H. Lopes, “Investigating the Impact of SOLID Design Principles on Machine Learning Code Understanding,” in Proceedings of the IEEE/ACM 3rd International Conference on AI Engineering - Software Engin...

2024
[24]

Insights on the Use of Software Design Principles in Machine Learning Pipelines,

L. L ´opez, C. G ´omez, and C. Ayala, “Insights on the Use of Software Design Principles in Machine Learning Pipelines,” in Product-Focused Software Process Improvement, D. Pfahl, J. Gonzalez Huerta, J. Kl¨under, and H. Anwar, Eds. Cham: Springer Nature Switzerland, 2025, pp. 139–155

2025
[25]

Design principles and design patterns,

R. C. Martin, “Design principles and design patterns,” Object Mentor , vol. 1, no. 34, p. 597, 2000

2000
[26]

Large lan- guage models are zero-shot reasoners,

T. Kojima, S. S. Gu, M. Reid, Y . Matsuo, and Y . Iwasawa, “Large lan- guage models are zero-shot reasoners,” Advances in neural information processing systems, vol. 35, pp. 22 199–22 213, 2022

2022
[27]

Language mod- els are few-shot learners,

T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell et al., “Language mod- els are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020

1901
[28]

Chain-of-thought prompting elicits reasoning in large language models,

J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V . Le, D. Zhou et al. , “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems , vol. 35, pp. 24 824–24 837, 2022

2022
[2025]

Available: https://arxiv.org/abs/2412.15115

[Online]. Available: https://arxiv.org/abs/2412.15115

arXiv

Pith tools

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

[1] [1]

Applying the single responsibility principle in industry: modularity ben- efits and trade-offs,

A. Ampatzoglou, A.-A. Tsintzira, E.-M. Arvanitou, A. Chatzigeorgiou, I. Stamelos, A. Moga, R. Heb, O. Matei, N. Tsiridis, and D. Kehagias, “Applying the single responsibility principle in industry: modularity ben- efits and trade-offs,” inProceedings of the 23rd International Conference on Evaluation and Assessment in Software Engineering , 2019, pp. 347– 352

work page 2019

[2] [2]

An experimental evaluation of the effect of solid principles to microsoft vs code metrics,

O. Turan and ¨O. ¨O. Tanrı¨over, “An experimental evaluation of the effect of solid principles to microsoft vs code metrics,” AJIT-e: Academic Journal of Information Technology , vol. 9, no. 34, pp. 7–24, 2018

work page 2018

[3] [3]

Automated Verification of Open/Closed Principle: A Code Analysis Approach,

G. Roy, M. M, and B. A. Jacob, “Automated Verification of Open/Closed Principle: A Code Analysis Approach,” in 2024 5th International Conference for Emerging Technology (INCET) , May 2024, pp. 1–7

work page 2024

[4] [4]

Refactoring Legacy Code Using Cleaning Up Cycles: An Experience Report,

A. V . Girjoaba and A. Capiluppi, “Refactoring Legacy Code Using Cleaning Up Cycles: An Experience Report,” in2024 IEEE International Conference on Software Maintenance and Evolution (ICSME) , Oct. 2024, pp. 753–764

work page 2024

[5] [5]

Applying solid principles for the refactoring of legacy code: An experience report,

I. Yanakiev, B.-M. Lazar, and A. Capiluppi, “Applying solid principles for the refactoring of legacy code: An experience report,” Journal of Systems and Software , vol. 220, p. 112254, 2025

work page 2025

[6] [6]

Benchmarking llm for code smells detec- tion: Openai gpt-4.0 vs deepseek-v3,

A. R. Sadik and S. Govind, “Benchmarking llm for code smells detec- tion: Openai gpt-4.0 vs deepseek-v3,” arXiv preprint arXiv:2504.16027, 2025

arXiv 2025

[7] [7]

The Use of Large Language Model in Code Review Automation: An Examination of Enforcing SOLID Principles,

G. F. Martins, E. C. M. Firmino, and V . P. De Mello, “The Use of Large Language Model in Code Review Automation: An Examination of Enforcing SOLID Principles,” in Artificial Intelligence in HCI , H. Degen and S. Ntoa, Eds. Cham: Springer Nature Switzerland, 2024, pp. 86–97

work page 2024

[8] [8]

Code llama: Open foundation models for code,

B. Rozi `ere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remez, J. Rapin, A. Kozhevnikov, I. Evtimov, J. Bitton, M. Bhatt, C. C. Ferrer, A. Grattafiori, W. Xiong, A. D ´efossez, J. Copet, F. Azhar, H. Touvron, L. Martin, N. Usunier, T. Scialom, and G. Synnaeve, “Code llama: Open foundation models for code,” 20...

arXiv 2024