Pith. sign in

REVIEW 5 major objections 7 minor 44 references

MLScent A tool for Anti-pattern detection in ML projects

T0 review · 5 major / 7 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read MLScent finds ML code smells at 87.5% agreement

desk verdict A genuinely useful ML smell detector with an evaluation that does not yet support its accuracy claims; worth serious revision. read the letter →

arxiv 2502.18466 v1 pith:JL32CC7B submitted 2025-01-30 cs.SE cs.AI

Karthik Shivashankar , Antonio Martini This is my paper · ORCID
classification cs.SEcs.AI
keywords MLcodesmellsstaticanalysisabstractsyntaxtreeanti-patterndetectiontechnicaldebtmachinelearningprojectsPythonquality
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

MLScent is a static-analysis tool built to find code smells that are specific to machine learning projects rather than generic Python issues. The paper claims that its 76 detectors, working on Python abstract syntax trees, identify these anti-patterns accurately: 87.5% agreement with developer annotations and an F1 score of 0.933 across 72 ground-truth entries in seven real projects. The same tool, run over 43 popular GitHub ML repositories, reports that framework-agnostic smells such as array creation inefficiency and missing axis specification dominate. If accurate, the tool gives ML practitioners a way to catch data leakage, poor data splitting, and reproducibility problems that general-purpose linters miss.

What carries the argument

The central mechanism is Abstract Syntax Tree (AST) analysis using the Astroid library: MLScent parses Python code into an AST, identifies which ML framework is in use, and applies the matching set of pattern-matching detectors. There are 76 detectors total, split across TensorFlow (13), General ML (16), PyTorch (12), Hugging Face (10), Scikit-learn (9), Pandas (8), and NumPy (8). A representative detector, chain indexing in Pandas, fires when the AST contains nested Subscript nodes representing accesses like df['column']['row']. The AST-based design is what lets the tool recognise framework-specific constructions that generic linters ignore.

What would settle it

Run a blind study in which new ML developers, who have not seen MLScent's detector list, independently annotate the same 72 code snippets; if their agreement with MLScent falls substantially below the reported 87.5% (for example, F1 below 0.7), the central accuracy claim is not reproducible. A simpler check is to compute confidence intervals for the 72-entry metrics, which are currently reported as point values with no uncertainty.

Watch

Extended reading notes

Core claim

The paper introduces MLScent and argues that it accurately detects ML-specific anti-patterns across real-world Python projects. It reports an overall agreement rate of 87.50% with manually annotated ground truth, a recall of 0.875, an F1-score of 0.933 and an F2-score of 0.897 across 72 ground-truth entries from 7 ML projects. Framework-level results range from perfect agreement for Hugging Face (100%) to lower agreement for NumPy (75%), and a scan of 43 high-star GitHub ML repositories found 31,033 general ML issues, 17,634 NumPy issues, and thousands of Pandas, TensorFlow, and PyTorch issues. The paper interprets these numbers as evidence that MLScent is a practical, comprehensive checker for ML code quality that existing generic tools cannot provide.

Load-bearing premise

The accuracy numbers rest on 72 ground-truth annotations made by developers who were told in advance which ML-specific smells the tool targets; if that briefing shaped their labels, the agreement rate measures a shared vocabulary rather than independent detection quality.

Editorial extensions

If this is right

  • ML teams can run MLScent in CI to catch data leakage, improper train-test splits, and hardcoded hyperparameters before they invalidate model evaluation.
  • The prevalence scan gives a first large-scale baseline: array creation efficiency (10,795) and missing axis specification (5,996) are the most frequent smells in popular ML projects.
  • The modular detector architecture means new frameworks and smells can be added as best practices evolve, keeping the tool current with the ML ecosystem.
  • The reported F1 of 0.933 suggests that, for the seven annotated projects, the tool's detections mostly align with developer judgment, making its output actionable rather than noisy.

Reading between the lines

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

  • The ground-truth annotators were briefed on the tool's target smells before labelling, so the 87.5% agreement may partly measure shared terminology; an independent blind labelling by experts who have not seen the detector list would test this.
  • Because the tool is static and AST-based, it cannot detect smells that only appear at runtime or through data flow, such as actual data leakage by shared scalers; the reported numbers should be read as coverage of syntactic patterns, not of all correctness risks.
  • The prevalence results mix performance hints (array creation efficiency) with correctness smells (randomness control); treating all 76 detector outputs as equally severe could overstate technical debt in real projects.
  • A direct head-to-head against SonarQube, PMD, or mllint on the same 43 repositories would clarify how much of the detection is genuinely ML-specific rather than a rediscovery of general code issues.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 7 minor

Summary. The paper presents MLScent, a static-analysis tool for detecting ML-specific anti-patterns and code smells in Python projects. The tool implements 76 detectors across TensorFlow, PyTorch, Scikit-learn, Hugging Face, Pandas, NumPy, and a general ML category. The authors report an evaluation based on 72 ground-truth entries annotated by seven developers from seven ML projects, achieving an agreement rate of 87.50%, recall 0.875, F1-score 0.933, and F2-score 0.897, plus a small user study (N=7) on perceived usefulness. They also report a prevalence analysis over 43 GitHub repositories, finding tens of thousands of detector hits across the supported frameworks.

Significance. A validated ML-specific code smell detector would be a useful contribution, and the paper's replication package (documentation, source code, Zenodo archive) is a concrete strength. The tool addresses a real gap: general-purpose linters and data-validation tools do not cover framework-specific ML anti-patterns. However, the significance of the contribution currently rests on an evaluation whose ground truth is not independent of the detector taxonomy, whose headline metric is incomplete (no precision), and whose prevalence counts are unvalidated detector hits. The paper's central claim of 'high accuracy' is therefore not yet established by the reported evidence.

major comments (5)
  1. [IV.A.1, III.A] The ground-truth annotation process is not independent of MLScent's detector taxonomy. The seven developers were 'provided with detailed information about the types of ML-specific code smells we were targeting' before annotating, and those target types are the same smell catalog from which the detectors were built. Agreement between MLScent and annotations primed by that catalog demonstrates that developers can recognize the predefined patterns, not that MLScent detects true smells in unguided practice. A valid evaluation needs an independent ground truth: for example, annotations elicited without exposing annotators to the detector list, or a separately curated benchmark from a different source. This issue directly affects the headline claim of high accuracy.
  2. [Table IV, IV.A.2] Precision is never reported, yet the reported F1=0.933 and recall=0.875 algebraically imply precision of approximately 0.999 (since F1 = 2PR/(P+R)). For a static analyzer on real-world code such a value is surprising and must be shown explicitly, together with the confusion matrix and per-framework precision values. Without this, the text's assertion that 'F1-score (0.933) indicates that the tool provides reliable detection capabilities while minimizing false alarms' is unsupported.
  3. [IV.A.2, Table V] The user study uses the same seven developers who created the ground-truth annotations after being briefed on the target smell types. Their later ratings of tool usefulness and smell detection therefore compound the dependency described above and cannot be treated as an independent qualitative evaluation. The paper should recruit separate practitioners for the usability study, or at minimum explicitly discuss and control for this shared-participant bias.
  4. [IV.D, Tables VII-IX] The prevalence figures (for example, 31,033 General ML issues, 10,795 Array Creation Efficiency instances) are raw detector hits, not verified anti-patterns. Without a validated false-positive rate on these repositories or a sample-based verification of a subset of hits, these numbers cannot support the RQ4 conclusion about the 'prevalence and distribution of different types of ML anti-patterns.' The paper should either verify a sample of these hits or clearly label Table VII as unvalidated detector counts.
  5. [II.A, IV.A] No existing tool is run as a baseline. The paper argues that tools like mllint lack framework-specific analysis and positions MLScent as a more complete solution, but the evaluation never compares MLScent against mllint or another accessible baseline on the same projects. Adding even a small comparative experiment would substantially strengthen the relative-advantage claims.
minor comments (7)
  1. [IV.A.1] The annotation instructions are not described beyond 'detailed information about the types of ML-specific code smells we were targeting.' The paper should include the exact checklist or taxonomy given to annotators, and should report inter-annotator agreement (e.g., Cohen's kappa) to assess the reliability of the ground truth.
  2. [IV.A, IV.A.2] The text states that the study comprised 72 total ground truth entries and 39 unique anti-pattern types, while Table VI lists counts that sum to 72 across five framework categories. The relationship between 'entries,' 'unique types,' and the per-framework counts in Table VI should be clarified.
  3. [IV.A.1] The manuscript says 'For each detected smell, we categorized it as true positive, false positive, or false negative based on manual verification by ML experts' but does not state who these experts were or whether they were the same developers. This should be specified, along with the exact annotation procedure.
  4. [Table V, IV.A.2] With N=7, the survey results are descriptive at best; the paper should avoid interpreting small differences in means (e.g., 3.29 vs 3.43) as meaningful findings and should provide the full response distribution rather than only summary statistics.
  5. [V.B, IV.A.2] The discussion acknowledges false positives as a limitation, but the evaluation does not quantify them. Reporting precision in Table VI would directly address this acknowledged concern.
  6. [III.G] The illustrative code snippet for chain-indexing detection only checks nested Subscript nodes at the top level of a parsed module; this is a simplification that does not reflect how the real detector handles nested expressions. The example should be labeled as a simplified illustration or aligned with the actual implementation.
  7. [Index Terms] There is a typo in the Index Terms: 'Anit-patterns' should be 'Anti-patterns.'

Circularity Check

1 steps flagged · score 4.0 of 10

The ground-truth annotations are primed with the same ML-smell taxonomy MLScent implements, so the reported agreement measures shared definitions rather than independent detection quality.

  1. fitted input called prediction [Section III-A (detector construction) and Section IV-A.1 (ground-truth annotation briefing)]
    "The detectors in MLScent were built from scratch based on comprehensive analysis of ML anti-patterns and code smells documented in prior research. ... Before they began annotating, we provided the developers with detailed information about the types of ML-specific code smells we were targeting."

    The detector definitions and the ground-truth annotation instructions come from the same source: MLScent's detectors are implemented from prior ML smell catalogs, and the annotators are briefed with 'the types of ML-specific code smells we were targeting.' The 72 ground-truth labels are therefore not an independent reference; they are produced by developers primed to recognize the same taxonomy the detector implements. The reported agreement rate, recall, and F1 then measure consistency between two applications of the same smell taxonomy, not detection quality against an external ground truth. Because this evaluation is the only quantitative support for the headline claim of 'high accuracy,' a central part of the result reduces to shared definition rather than independent validation.

full rationale

The paper's central quantitative claim rests on Section IV-A.1, where annotators are told in advance what ML-specific smell types MLScent targets, while Section III-A states the detectors were built from the same prior smell catalogs. This creates genuine partial circularity: the ground truth is not independent of the tool's taxonomy. However, the developers annotated their own real code, so the evaluation is not a mathematical identity and retains some independent empirical content; the degree of circularity is therefore moderate rather than total. The user-study ratings (Section IV-A.2) come from the same seven participants, compounding the non-independence but not by itself a circular derivation. Separately, and not as circularity, Table IV reports F1 = 0.933 and recall = 0.875 without precision; these values algebraically force precision near 1.0, which is implausible for a static analyzer and should have been reported explicitly. The RQ4 prevalence counts in Table VII are unvalidated detector hits rather than verified anti-patterns. Overall, the 87.5% agreement is better interpreted as evidence that annotators can recognize the same patterns MLScent was built to find, so a score of 4 reflects partial circularity while acknowledging the independent anchoring provided by developer judgment on their own code.

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

The paper adds a tool and empirical data, but the central accuracy claim rests on prior smell catalogs, the sufficiency of AST-only static analysis, and the validity of a small primed expert annotation study. No numerical free parameters are fitted; the 76 hand-written detectors are the method under evaluation, not fitted constants.

assumptions (4)
  • domain assumption The smell definitions in Sculley et al., Zhang et al., and van Oort et al. are valid and sufficiently complete descriptions of ML anti-patterns.
    Section III-A says detectors were 'built from scratch based on comprehensive analysis' of these sources; if the catalogs are incomplete or wrong, MLScent inherits the error.
  • domain assumption AST-based static analysis with astroid can reliably identify framework-specific ML anti-patterns from source structure alone.
    Section III-F and III-G rely on AST pattern matching and inference; this excludes runtime and data-dependent smells, an acknowledged construct validity threat in Section VI.
  • ad hoc to paper Developer annotations, elicited after briefing the developers on the target smell types, constitute an unbiased ground truth.
    Section IV-A.1 describes this protocol; all classification metrics depend on it, and the briefing may inflate agreement.
  • domain assumption The 43-repository corpus (Python-first, at least 2000 stars, recently active) is representative of real-world ML projects.
    Section IV.B and Section VI state this selection; prevalence counts in Table VII are generalized from this sample.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MLScent A tool for Anti-pattern detection in ML projects." pith.science (2026). https://pith.science/paper/JL32CC7B

@misc{pith2026250218466,
  author       = {Pith},
  title        = {Pith review of: MLScent A tool for Anti-pattern detection in ML projects},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JL32CC7B}},
  note         = {Machine review of arXiv:2502.18466}
}
read the original abstract

Machine learning (ML) codebases face unprecedented challenges in maintaining code quality and sustainability as their complexity grows exponentially. While traditional code smell detection tools exist, they fail to address ML-specific issues that can significantly impact model performance, reproducibility, and maintainability. This paper introduces MLScent, a novel static analysis tool that leverages sophisticated Abstract Syntax Tree (AST) analysis to detect anti-patterns and code smells specific to ML projects. MLScent implements 76 distinct detectors across major ML frameworks including TensorFlow (13 detectors), PyTorch (12 detectors), Scikit-learn (9 detectors), and Hugging Face (10 detectors), along with data science libraries like Pandas and NumPy (8 detectors each). The tool's architecture also integrates general ML smell detection (16 detectors), and specialized analysis for data preprocessing and model training workflows. Our evaluation demonstrates MLScent's effectiveness through both quantitative classification metrics and qualitative assessment via user studies feedback with ML practitioners. Results show high accuracy in identifying framework-specific anti-patterns, data handling issues, and general ML code smells across real-world projects.

Figures

Figures reproduced from arXiv: 2502.18466 by the authors.

Figure 1
Figure 1. MLScent: Core Components engineering practices and the unique requirements of ML development [41]. Current tools like Great Expectations [36] and Pandas Pro￾filing [39], while useful for specific data quality aspects, do not address the broader spectrum of ML-specific code smells. This gap is particularly noteworthy given the limited research into ML-specific code smells, with most existing studies focusing on conve… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

44 extracted references · 39 canonical work pages

  1. [14]

    An extended systematic literature review on provision of evidence for safety certi- fication,

    S. Nair, J. L. de la Vara, M. Sabetzadeh, and D. Falessi, “An extended systematic literature review on provision of evidence for safety certi- fication,” Information and Software Technology , vol. 126, p. 106357, 2020

    work page 2020

  2. [37]

    Developments in mlflow: A system to accelerate the machine learning lifecycle,

    A. Chen, A. Chow, A. Davidson, A. DCunha, A. Ghodsi, S. A. Hong, A. Konwinski, C. Mewald, S. Murching, T. Nykodym, P. Ogilvie, M. Parkhe, A. Singh, F. Xie, M. Zaharia, R. Zang, J. Zheng, and C. Zumar, “Developments in mlflow: A system to accelerate the machine learning lifecycle,” Proceedings of the ACM SIGMOD International Conference on Management of Data , 2020

    work page 2020

  3. [1]

    Gartner survey shows 37 percent of organiza- tions have implemented ai in some form,

    Gartner, “Gartner survey shows 37 percent of organiza- tions have implemented ai in some form,” 2020. [On- line]. Available: https://www.gartner.com/en/newsroom/press-releases/ 2019-01-21-gartner-survey-shows-37-percent-of-organizations-have

    work page 2020

  4. [2]

    Artificial intelligence in healthcare market,

    MarketsandMarkets, “Artificial intelligence in healthcare market,”

    work page

  5. [3]

    Software engineering for machine learning: A case study,

    S. Amershi, A. Begel, C. Bird, R. DeLine, H. Gall, E. Kamar, N. Na- gappan, B. Nushi, and T. Zimmermann, “Software engineering for machine learning: A case study,” in 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). IEEE, 2019, pp. 291–300

    work page 2019

  6. [4]

    Challenges in using machine learning to support software engineering

    O. T. Borges, J. M. C. Couto, D. D. Ruiz, and R. Prikladnicki, “Challenges in using machine learning to support software engineering.” in ICEIS (2), 2021, pp. 224–231

    work page 2021

  7. [5]

    When Code Smells Meet ML: On the Lifecycle of ML-specific Code Smells in ML-enabled Systems

    G. Recupito, G. Giordano, F. Ferrucci, D. Di Nucci, and F. Palomba, “When code smells meet ml: On the lifecycle of ml-specific code smells in ml-enabled systems,” arXiv preprint arXiv:2403.08311 , 2024

    work page Pith review arXiv 2024

  8. [6]

    An empirical study of refactorings and technical debt in machine learning systems,

    Y . Tang, R. Khatchadourian, M. Bagherzadeh, R. Singh, A. Stewart, and A. Raja, “An empirical study of refactorings and technical debt in machine learning systems,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) , 2021, pp. 238–250

    work page 2021

Show all 44 references
  1. [7]

    Hidden technical debt in machine learning systems,

    D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V . Chaudhary, M. Young, J.-F. Crespo, and D. Dennison, “Hidden technical debt in machine learning systems,” in Advances in neural information processing systems , 2015, pp. 2503–2511

    2015

  2. [8]

    The ml test score: A rubric for ml production readiness and technical debt reduction,

    E. Breck, S. Cai, E. Nielsen, M. Salib, and D. Sculley, “The ml test score: A rubric for ml production readiness and technical debt reduction,” in 2017 IEEE International Conference on Big Data (Big Data) . IEEE, 2017, pp. 1123–1132

    2017

  3. [9]

    23 shades of self-admitted technical debt: an empirical study on machine learning software,

    D. OBrien, S. Biswas, S. Imtiaz, R. Abdalkareem, E. Shihab, and H. Rajan, “23 shades of self-admitted technical debt: an empirical study on machine learning software,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundation...

    2022

  4. [10]

    Challenges in machine learning application development: an industrial experience report,

    M. S. Rahman, F. Khomh, E. Rivera, Y .-G. Gu ´eh´eneuc, and B. Lehnert, “Challenges in machine learning application development: an industrial experience report,” in Proceedings of the 1st Workshop on Software Engineering for Responsible AI , 2022, pp. 21–28

    2022

  5. [11]

    Machine learning techniques for code smell detection: A systematic literature review and meta-analysis,

    M. I. Azeem, F. Palomba, L. Shi, and Q. Wang, “Machine learning techniques for code smell detection: A systematic literature review and meta-analysis,” Information and Software Technology, vol. 108, pp. 115– 138, 2019

    2019

  6. [12]

    Code smells for machine learning applications,

    H. Zhang, L. Cruz, and A. Van Deursen, “Code smells for machine learning applications,” in Proceedings of the 1st international conference on AI engineering: software engineering for AI , 2022, pp. 217–228

    2022

  7. [13]

    The prevalence of code smells in machine learning projects,

    B. van Oort, L. Cruz, M. Aniche, and A. van Deursen, “The prevalence of code smells in machine learning projects,” in 2021 IEEE/ACM 1st Workshop on AI Engineering - Software Engineering for AI (WAIN) , 2021, pp. 1–8

    2021

  8. [15]

    Machine learning test- ing: Survey, landscapes and horizons,

    J. M. Zhang, M. Harman, L. Ma, and Y . Liu, “Machine learning test- ing: Survey, landscapes and horizons,” IEEE Transactions on Software Engineering, vol. 48, no. 1, pp. 1–36, 2020

    2020

  9. [16]

    Detecting bad smells with machine learning algorithms: an empirical study,

    D. Cruz, A. Santana, and E. Figueiredo, “Detecting bad smells with machine learning algorithms: an empirical study,” in Proceedings of the 3rd International Conference on Technical Debt , ser. TechDebt ’20. New York, NY , USA: Association for Computing Machinery, 2020, p. 31–4...

    2020

  10. [17]

    Machine learning for techni- cal debt identification,

    D. Tsoukalas, N. Mittas, A. Chatzigeorgiou, D. Kehagias, A. Ampat- zoglou, T. Amanatidis, and L. Angelis, “Machine learning for techni- cal debt identification,” IEEE Transactions on Software Engineering , vol. 48, no. 12, pp. 4892–4906, 2022

    2022

  11. [18]

    A survey on machine learning techniques applied to source code,

    T. Sharma, M. Kechagia, S. Georgiou, R. Tiwari, I. Vats, H. Moazen, and F. Sarro, “A survey on machine learning techniques applied to source code,” Journal of Systems and Software , vol. 209, p. 111934, 2024

    2024

  12. [19]

    Machine learning for source code vulnerability detection: What works and what isn’t there yet,

    T. Marjanov, I. Pashchenko, and F. Massacci, “Machine learning for source code vulnerability detection: What works and what isn’t there yet,” IEEE Security Privacy , vol. PP, pp. 2–18, 09 2022

    2022

  13. [20]

    Empirical analysis of hidden technical debt patterns in machine learning software,

    M. Alahdab and G. C ¸ alıklı, “Empirical analysis of hidden technical debt patterns in machine learning software,” in Product-Focused Software Process Improvement: 20th International Conference, PROFES 2019, Barcelona, Spain, November 27–29, 2019, Proceedings 20 . Springer, 20...

    2019

  14. [21]

    Fowler, Refactoring: Improving the Design of Existing Code

    M. Fowler, Refactoring: Improving the Design of Existing Code . Addison-Wesley Professional, 1999

    1999

  15. [22]

    Exploring the impact of inter-smell re- lations on software maintainability: An empirical study,

    A. Yamashita and L. Moonen, “Exploring the impact of inter-smell re- lations on software maintainability: An empirical study,” in Proceedings of the 2013 International Conference on Software Engineering , 2013, pp. 682–691

    2013

  16. [23]

    Detecting code smells using deep learning,

    A. K. Das, S. Yadav, and S. Dhal, “Detecting code smells using deep learning,” in TENCON 2019 - 2019 IEEE Region 10 Conference (TENCON), 2019, pp. 2081–2086

    2019

  17. [24]

    SonarQube,

    “SonarQube,” https://www.sonarqube.org/, accessed: 2024-11-06

    2024

  18. [25]

    “PMD,” https://pmd.github.io/, accessed: 2024-11-06

    2024

  19. [26]

    Deep learning anti- patterns from code metrics history,

    A. Barbez, F. Khomh, and Y .-G. Gu ´eh´eneuc, “Deep learning anti- patterns from code metrics history,” in 2019 IEEE International Con- ference on Software Maintenance and Evolution (ICSME) , 2019, pp. 114–124

    2019

  20. [27]

    An experience report on using code smells detection tools,

    F. A. Fontana, E. Mariani, A. Mornioli, R. Sormani, and A. Tonello, “An experience report on using code smells detection tools,” in 2012 IEEE Fourth International Conference on Software Testing, Verification and Validation. IEEE, 2012, pp. 450–457

    2012

  21. [28]

    Hidden technical debt in machine learning systems,

    D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V . Chaudhary, M. Young, J.-F. Crespo, and D. Dennison, “Hidden technical debt in machine learning systems,” in Advances in Neural Information Processing Systems , vol. 28, 2015

    2015

  22. [29]

    Machine learning: The high interest credit card of technical debt,

    D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V . Chaudhary, and M. Young, “Machine learning: The high interest credit card of technical debt,” in SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop) , 2014

    2014

  23. [30]

    Practice-based col- lection of bad smells in machine learning projects,

    H. Takeuchi, H. Kaiya, H. Nakagawa, and S. Ogata, “Practice-based col- lection of bad smells in machine learning projects,” Procedia Computer Science, vol. 225, pp. 517–526, 2023

    2023

  24. [31]

    Machine learning architecture and design patterns,

    H. Washizaki, H. Uchida, F. Khomh, and Y .-G. Gu ´eh´eneuc, “Machine learning architecture and design patterns,” IEEE Software , vol. 8, p. 2020, 2020

    2020

  25. [32]

    Project smells: experiences in analysing the software quality of ml projects with mllint,

    B. van Oort, L. Cruz, B. Loni, and A. van Deursen, “Project smells: experiences in analysing the software quality of ml projects with mllint,” Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems , 2022

    2022

  26. [33]

    Data linter,

    “Data linter,” https://pypi.org/project/data-linter/, accessed: 2024-11-06

    2024

  27. [34]

    Datalab,

    “Datalab,” https://github.com/datalab-dev/datalab, accessed: 2024-11- 06

    2024

  28. [35]

    Deepchecks: Continuous validation for ai & ml: Testing, ci & monitoring,

    Deepchecks, “Deepchecks: Continuous validation for ai & ml: Testing, ci & monitoring,” accessed: 2024-11-06

    2024

  29. [36]

    Great expectations,

    “Great expectations,” https://greatexpectations.io/, accessed: 2024-11-06

    2024

  30. [38]

    Dvc: Open-source version control system for machine learning projects,

    “Dvc: Open-source version control system for machine learning projects,” https://dvc.org/, accessed: 2024-11-06

    2024

  31. [39]

    Pandas profiling,

    “Pandas profiling,” https://github.com/pandas-profiling/pandas-profiling, accessed: 2024-11-06

    2024

  32. [40]

    A review on machine- learning based code smell detection techniques in object-oriented soft- ware system (s),

    A. Kaur, S. Jain, S. Goel, and G. Dhiman, “A review on machine- learning based code smell detection techniques in object-oriented soft- ware system (s),” Recent Advances in Electrical & Electronic Engineer- ing (Formerly Recent Patents on Electrical & Electronic Engineering) ,...

    2021

  33. [41]

    Snorkel: Rapid training data creation with weak supervision,

    A. Ratner et al. , “Snorkel: Rapid training data creation with weak supervision,” arXiv preprint arXiv:1711.10160 , 2017

    2017 arXiv

  34. [42]

    Mlcq: Industry-relevant code smell data set,

    L. Madeyski and T. Lewowski, “Mlcq: Industry-relevant code smell data set,” in Proceedings of the 24th International Conference on Evaluation and Assessment in Software Engineering , 2020, pp. 342–347

    2020

  35. [43]

    Detecting code smells using machine learning techniques: Are we there yet?

    D. Di Nucci, F. Palomba, D. A. Tamburri, A. Serebrenik, and A. De Lu- cia, “Detecting code smells using machine learning techniques: Are we there yet?” in 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER) , 2018, pp. 612–621

    2018

  36. [2021]

    Available: https://www.marketsandmarkets.com/ Market-Reports/artificial-intelligence-healthcare-market-54679303.html

    [Online]. Available: https://www.marketsandmarkets.com/ Market-Reports/artificial-intelligence-healthcare-market-54679303.html

Pith tools

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