Pith. sign in

REVIEW 4 major objections 5 minor 28 references

The Patchwork Problem in LLM-Generated Code

T0 review · 4 major / 5 minor · reviewed 2026-07-13 · grok-4.5

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

Pith's one-line read LLM-generated code that compiles and passes tests still fails structurally in ways standard CI never catches.

desk verdict Solid SE paper that names a real CI blind spot, ships a usable taxonomy and hybrid detectors, and shows most of these failures evade standard gates—with the main soft spot being RCF/CCV labeling via iterative refinement rather than full independent audit. read the letter →

arxiv 2607.08981 v1 pith:SFXZB4V2 submitted 2026-07-09 cs.SE cs.AI

Viraaji Mothukuri , Reza M. Parizi This is my paper
classification cs.SEcs.AI
keywords LLMcodegenerationstructuralcoherencestaticanalysisgraphinvariantsqualityneuralsynthesispatchworkproblemrepository-levelverification
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 names and formalizes the patchwork problem: LLM-generated patches that look correct in isolation but violate repository-wide consistency constraints on imports, dependencies, configuration, schemas, resources, control flow, and routing. The authors define structural coherence as graph invariants over eight repository artifact graphs and give an eight-category failure taxonomy that separates defects characteristic of LLM generation from defects merely amplified by it. They then build a hybrid verifier that reuses mature static analyzers where those tools already excel and adds purpose-built detectors for the cross-cutting invariants that current toolchains miss, reporting only provable constraint violations with localized evidence. Across 336 generations from two frontier models under four prompting regimes, 65 of 67 detected structural failures (97 percent) evade type checking, tests, and SAST entirely, and the two models produce qualitatively different failure profiles. External checks on 43 real AI-generated repositories show the same classes of failure in 81 percent of projects, confirming the problem is not an artifact of the lab setup.

What carries the argument

Structural coherence as consistency invariants over eight repository graphs (import, call, dependency, configuration, schema, resource, control-flow, routing), paired with a hybrid verification framework that delegates language-local checks to existing analyzers and runs purpose-built detectors for cross-graph constraint violations.

What would settle it

An independent, exhaustive manual audit of every RCF and CCV finding in the 336-generation corpus that shows a large fraction are false positives, collapsing the claimed 97 percent unique-detection rate against type checking, tests, and SAST.

Watch

Extended reading notes

Core claim

The central claim is that structural incoherence is a first-class, systematically detectable failure mode of LLM-generated code: most such failures are invisible to type checkers, test suites, and SAST, they concentrate on cross-cutting tasks, and their category distributions diverge between models, so model-agnostic CI is insufficient.

Load-bearing premise

That the high-count categories labeled by iterative pipeline refinement rather than exhaustive independent manual audit of every finding truly count only real constraint violations and do not inflate the evasion rates.

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.

Referee Report

4 major / 5 minor

Summary. The paper defines the patchwork problem: LLM-generated patches that are locally valid (compile, type-check, pass local tests) yet violate repository-scale structural invariants spanning imports, dependencies, configuration, schemas, resources, control flow, and routing. It contributes (1) an eight-category taxonomy (SRF, PIA, DHI, BCI, RCF, CFC, CCV, SSR) formalized as consistency invariants over eight repository graphs; (2) a hybrid verification framework that delegates symbol/signature analysis to mature tools (mypy, tsc, pylint, ESLint) and deploys purpose-built detectors for cross-cutting invariants, with explicit algorithms; and (3) an empirical study of 336 generations from GPT-4o and Claude 3.5 Sonnet under four prompting strategies on 60 tasks from 10 production repositories, plus external validation on 43 real AI-generated repositories. The headline results are that 65 of 67 controlled findings (97%) evade type checking, tests, and SAST, that failure profiles diverge qualitatively between models (χ²=25.1, p=2.73×10⁻⁷), and that 81.4% of external repositories exhibit the same failure classes.

Significance. If the results hold, the paper identifies a concrete, under-served failure mode that standard CI pipelines systematically miss, at a moment when LLM-assisted coding is entering production workflows. The taxonomy and hybrid architecture are practically useful: they separate LLM-specific defects (e.g., DHI) from amplified ones, match detectors to invariant class rather than reimplementing mature analyses, and emit localized evidence traces rather than opaque scores. Strengths that should be credited include public release of code, pipelines, and datasets [19]; explicit detection algorithms (Algorithms 1–7); exhaustive manual verification of the 20 BCI/DHI/PIA/SRF findings as provable constraint violations; and external validation that CFC appears in real AI-generated code even when controlled frontier generation does not elicit it. The model-divergence observation challenges model-agnostic mitigation and is a genuine contribution if the labeling is sound. The work is timely for software engineering and AI-for-code venues.

major comments (4)
  1. [§5.1–5.2, Table 5] §5.1–5.2 and Table 5: The central quantitative claim that 65/67 findings (97%) evade all baselines rests on treating every framework finding as a true positive. BCI/DHI/PIA/SRF (N=20) were exhaustively manually verified as provable constraint violations, but RCF (29) and CCV (18)—70% of findings—have precision established only by “iterative pipeline refinement that systematically eliminated false positive patterns,” with Table 5 reporting “Refined” rather than a measured precision. Because the same detectors generate and refine the labels, residual false positives (e.g., incomplete exception modeling in Algorithm 4 return-path analysis, or optional/aliased schema fields in Algorithm 5) would inflate both N and the unique-evasion rate. The manually verified minority already shows complete baseline evasion, so the qualitative existence claim is secure; the headline 97% figure and “vast maj
  2. [§5.2, Figure 3] §5.2 Model Comparison and Figure 3: The χ² test for distributional independence (χ²=25.1, p=2.73×10⁻⁷) and the claim that “failure patterns diverge qualitatively between models in ways that challenge model-agnostic mitigation” inherit the same labeling risk for the high-count classes: all 18 CCV findings are attributed exclusively to GPT-4o and 22 of 29 RCF findings to Claude. If a non-trivial fraction of RCF/CCV are residual false positives, the model-specific profiles and the policy implication weaken. Either re-run the χ² on the manually verified subset alone, or complete independent labeling of RCF/CCV before asserting model-aware mitigation as a practical consequence.
  3. [§5.1, Table 6, Figure 4] §5.1 Experimental Setup: The design is partially unbalanced (24 early tasks GPT-4o under P1/P2 only; 192 GPT-4o vs 144 Claude generations; P1/P2 N=96 vs P3/P4 N=72). While denominators are noted, Table 6 and the prompt-sensitivity discussion compare raw counts across unequal cells without normalization or confidence intervals. For L3 incidence (44.6% vs 13–16% for L1/L2), report per-generation rates with appropriate denominators and, if possible, a simple significance test so that the cross-cutting-task claim is not driven by cell imbalance or the RCF/CCV labeling issue above.
  4. [§3, Algorithm 7, Table 2, §5.2] §3 Taxonomy and Algorithm 7 (SSR): SSR is defined as a first-class category and given a majority-rule detector (≥90% guard coverage, cluster size ≥4, destructive methods only), yet it produces zero findings in both controlled and external evaluations. The paper attributes this to framework-level auth in vibe-coded projects, which is plausible, but then the category’s inclusion in the “eight-category” contribution and in Table 2’s “Amplified / Yes / Yes” evasion profile is not empirically supported by this study. Either demonstrate SSR on a corpus with per-route guards, narrow the claim to the six categories that fire, or move SSR to a “defined but not elicited” discussion so the taxonomy is not oversold relative to the evidence.
minor comments (5)
  1. [Figure 1] Figure 1 is described with heavily corrupted/spaced text in the manuscript source (e.g., “G e n e r a t e d C o d”, “P h a n t o m I n t e r n a l”), which makes the pipeline overview hard to read. Please regenerate a clean figure.
  2. [Table 1, §2] Table 1 “Work Focus Gap” column is useful but several entries are very brief; a short sentence on how the present invariants differ from Code Property Graphs [8] beyond “single-file” would help readers who know CPG well.
  3. [Algorithm 2, §3 DHI] Algorithm 2 notes the import-name vs distribution-name mismatch for PyPI (yaml/PyYAML, cv2/opencv-python) but does not report how often this heuristic fired or was filtered in the 336 generations. A one-sentence sensitivity note would strengthen DHI claims.
  4. [Abstract, §1] The abstract and §1 use “the vast majority” and “97%” interchangeably; once RCF/CCV precision is audited, align the abstract wording with the verified subset if the full 97% cannot be retained.
  5. [References] References [13] and [12] carry 2026 dates and venue details that look provisional; verify final bibliographic data before camera-ready.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: empirical measurements of external model outputs against independently stated graph invariants and external baselines.

full rationale

This is an empirical software-engineering paper, not a derivation that claims first-principles prediction from fitted parameters. Structural failures are defined by explicit consistency invariants over repository graphs (import, call, dependency, config, schema, resource, CFG, routing) before any detector is run; detectors then check those constraints against concrete repository state (e.g., env keys absent from .env/config, packages absent from PyPI/npm, CFG paths missing declared returns, routes lacking sibling auth guards). The central quantitative claims—67 findings of which 65 evade type checking, tests, and SAST; model divergence χ²=25.1; 81.4% incidence on 43 external AI-generated repos—are measurements of GPT-4o/Claude outputs and third-party repositories against those fixed invariants and against independent baselines (mypy/tsc, test suites, bandit/semgrep, regex). Ground-truth labeling for BCI/DHI/PIA/SRF is exhaustive manual verification of provable violations; RCF/CCV use iterative refinement against the same formal invariants. That refinement is a precision-methodology concern (possible residual FPs), not circularity: the target quantities are not defined as detector outputs, nor fitted then re-predicted. Self-reference is limited to releasing artifacts [19]; no load-bearing uniqueness theorem, ansatz, or prior-author result is imported to force the claims. No step reduces by construction to its inputs.

Assumptions & free parameters 5 free parameters · 5 assumptions · 3 invented entities

This is an empirical systems paper, not a first-principles derivation. Load-bearing content is mostly domain assumptions about what counts as a structural failure, detector design thresholds, and corpus construction choices. Free parameters are operational thresholds in detectors and experimental controls, not physics-style fitted constants. Invented entities are conceptual (the named problem and taxonomy categories), not physical objects; they have independent handles via the detectors and external repos.

free parameters (5)
  • SSR majority-rule guard coverage threshold
    Algorithm 7 flags missing guards only when a dominant guard covers ≥90% of routes in a cluster of size ≥4; these cutoffs are chosen by the authors and control SSR sensitivity.
  • SSR cluster size minimum
    Clusters with |C| < 4 are ignored; chosen design parameter that helps explain zero SSR findings in both controlled and vibe-coded corpora.
  • LLM temperature
    Both models run at temperature zero; generation stochasticity is suppressed by design choice.
  • Prompting context sizes (P1–P4)
    P2 uses 2–5 local files, P3 ~10 retrieved files, P4 5–15 oracle files; these hand-chosen context budgets shape failure counts in Table 6.
  • Repository selection thresholds
    Curated repos require ≥50 files, ≥10K LOC, >50% type annotations, >60% test coverage; selection criteria that define the evaluation population.
assumptions (5)
  • domain assumption Structural failures are violations of consistency invariants over repository graphs and are verifiable by static analysis without execution.
    Section 3 definition of the patchwork problem; excludes dynamic/runtime-only defects from the taxonomy.
  • domain assumption Mature static analyzers (mypy, tsc, pylint, ESLint) correctly capture language semantics for symbol resolution and signature compatibility, so delegation is preferable to reimplementation.
    Section 4 architecture philosophy; underpins hybrid design.
  • domain assumption For PyPI, import name corresponds to distribution name for the majority of packages (with known exceptions such as yaml/PyYAML).
    Section 3 DHI discussion; affects dependency hallucination classification accuracy.
  • ad hoc to paper A finding that is a reachable path missing a declared return, a non-resolving path literal, or an access to an undeclared config key is a provable constraint violation rather than a heuristic smell.
    Stated throughout Algorithms 1–4 and the precision-first design claim; defines what counts as a true positive.
  • standard math Standard graph and program-analysis constructions (AST import graphs, CFGs, call graphs via pycg/ts-morph) are adequate substrates for the stated invariants.
    Table 3 and Section 4 graph construction; standard SE tooling assumptions.
invented entities (3)
  • The patchwork problem independent evidence
    purpose: Name and frame the class of locally valid but globally incoherent LLM-generated patches that evade standard CI.
    Introduced in abstract and Section 1 as the paper’s organizing concept; operationalized via the taxonomy and detectors rather than postulated as a physical object.
  • Eight-category structural failure taxonomy (SRF, PIA, DHI, BCI, RCF, CFC, CCV, SSR) independent evidence
    purpose: Partition structural defects by graph invariants and LLM amplification profile for targeted detection.
    Section 3 and Table 2; categories are definitional but each is tied to checkable invariants and empirical counts.
  • Hybrid multi-graph verification framework with purpose-built cross-graph detectors independent evidence
    purpose: Detect constraint violations underserved by existing type checkers, tests, and SAST.
    Section 4 and Algorithms 1–7; the system is an engineered artifact, not an unobserved natural entity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Patchwork Problem in LLM-Generated Code." pith.science (2026). https://pith.science/paper/SFXZB4V2

@misc{pith2026260708981,
  author       = {Pith},
  title        = {Pith review of: The Patchwork Problem in LLM-Generated Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SFXZB4V2}},
  note         = {Machine review of arXiv:2607.08981}
}
read the original abstract

LLM-generated code often compiles, passes tests, and appears correct, yet breaks once deployed. The root cause is frequently structural rather than logical. A generated endpoint references configuration keys never declared in the project, an import targets a package that does not exist in any registry, or a new route omits the authentication guard applied to every sibling endpoint. Each patch is locally valid but globally incoherent, and standard CI toolchains rarely surface these failures. As LLM-powered coding tools see widespread adoption, this blind spot poses a growing risk to software quality. We call this the \textbf{patchwork problem}. This paper formalizes structural coherence as consistency invariants over graph representations of repository artifacts, including import, call, dependency, configuration, schema, resource, control-flow, and routing graphs, and introduces an eight-category failure taxonomy distinguishing defects specific to LLM generation from those merely amplified by it. We present a hybrid verification framework that delegates to mature static analysis tools where they already excel and deploys purpose-built detectors for cross-cutting invariants underserved by existing toolchains, targeting provable constraint violations rather than heuristic pattern matching. Empirical evaluation across two frontier models under four prompting strategies reveals that the vast majority of structural failures evade type checking, testing, and SAST entirely, and that failure patterns diverge qualitatively between models in ways that challenge model-agnostic mitigation strategies. External validation on real-world AI-generated repositories confirms that these failures are not artifacts of controlled experimentation but are prevalent wherever LLMs write code with minimal human oversight.

Figures

Figures reproduced from arXiv: 2607.08981 by the authors.

Figure 1
Figure 1. Overview of the Proposed Framework [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Graph-to-category mapping configuration space. Arithmetic expressions and safe access patterns with explicit defaults are excluded at extraction time. Every reported finding represents a configuration access that will produce a runtime crash if the variable is absent. Dependency Hallucination Detection (DHI): Algorithm 2 validates that all external imports reference packages declared in the project’s dependency mani… view at source ↗
Figure 4
Figure 4. Failure category composition by task complexity level. CI integration and developer review workflows, providing actionable diagnostics rather than opaque pass/fail signals. 6 Conclusion This work formalized the patchwork problem in LLM-generated code through a graph-based failure taxonomy and a hybrid verification framework combining mature static analysis tools with purpose-built detectors. Across controlled genera… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

28 extracted references · 1 linked inside Pith

  1. [19]

    Source code of the paper: The patchwork problem in llm-generated code

    V. Mothukuri, “Source code of the paper: The patchwork problem in llm-generated code.” https: //github.com/decentralizedsciencelab/Patch Work.git, 2026. Source code, evaluation pipelines, detection configurations, and datasets

    2026

  2. [1]

    A survey on large language models for code generation,

    J. Jiang, F. Wang, J. Shen, S. Kim, and S. Kim, “A survey on large language models for code generation,” ACM Transactions on Software Engineering and Methodology, vol. 35, p. 1–72, Jan. 2026

    2026

  3. [2]

    Evaluating large language models trained on code,

    M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. de Oliveira Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman, A. Ray, R. Puri, G. Krueger, M. Petrov, H. Khlaaf, G. Sastry, P. Mishkin, B. Chan, S. Gray, N. Ryder, M. Pavlov, A. Power, L. Kaiser, M. Bavarian, C. Winter, P. Tillet, F. P. Such, D. Cummings, M. Plappert, F. Chantzis, E. Barnes, A. Herb...

    2021

  4. [3]

    Competition-level code generation with alphacode,

    Y. Li, D. Choi, J. Chung, N. Kushman, J. Schrittwieser, R. Leblond, T. Eccles, J. Keeling, F. Gimeno, A. Dal Lago, T. Hubert, P. Choy, C. de Masson d’Autume, I. Babuschkin, X. Chen, P.-S. Huang, J. Welbl, S. Gowal, A. Cherepanov, J. Molloy, D. J. Mankowitz, E. Sutherland Robson, P. Kohli, N. de Freitas, K. Kavukcuoglu, and O. Vinyals, “Competition-level c...

    2022

  5. [4]

    Program synthesis with large language models,

    J. Austin, A. Odena, M. Nye, M. Bosma, H. Michalewski, D. Dohan, E. Jiang, C. Cai, M. Terry, Q. Le, and C. Sutton, “Program synthesis with large language models,” 2021

    2021

  6. [5]

    SWE-bench: Can language models resolve real-world github issues?,

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. R. Narasimhan, “SWE-bench: Can language models resolve real-world github issues?,” inThe Twelfth International Conference on Learning Representations, 2024

    2024

  7. [6]

    Llm hallucinations in practical code generation: Phenomena, mechanism, and mitigation,

    Z. Zhang, C. Wang, Y. Wang, E. Shi, Y. Ma, W. Zhong, J. Chen, M. Mao, and Z. Zheng, “Llm hallucinations in practical code generation: Phenomena, mechanism, and mitigation,” Proceedings of the ACM on Software Engineering, vol. 2, no. ISSTA, pp. 481–503, 2025

    2025

  8. [7]

    Repobench: Benchmarking repository-level code auto-completion systems,

    T. Liu, C. Xu, and J. McAuley, “Repobench: Benchmarking repository-level code auto-completion systems,” inInternational Conference on Learning Representations, vol. 2024, pp. 47832–47850, 2024

    2024

Show all 28 references
  1. [8]

    Modeling and discovering vulnerabilities with code property graphs,

    F. Yamaguchi, N. Golde, D. Arp, and K. Rieck, “Modeling and discovering vulnerabilities with code property graphs,” in2014 IEEE symposium on security and privacy, pp. 590–604, IEEE, 2014

    2014

  2. [9]

    We have a package for you! a comprehensive analysis of package hallucinations by code generating {LLMs},

    J. Spracklen, R. Wijewickrama, A. N. Sakib, A. Maiti, and B. Viswanath, “We have a package for you! a comprehensive analysis of package hallucinations by code generating {LLMs},” in34th USENIX Security Symposium (USENIX Security 25), pp. 3687–3706, 2025

    2025

  3. [10]

    Evocodebench: An evolving code generation benchmark aligned with real-world code repositories,

    J. Li, G. Li, X. Zhang, Y. Dong, and Z. Jin, “Evocodebench: An evolving code generation benchmark aligned with real-world code repositories,” 2024

    2024

  4. [11]

    Baxbench: Can LLMs generate correct and secure backends?,

    M. Vero, N. M¨ undler, V. Chibotaru, V. Raychev, M. Baader, N. Jovanovi´ c, J. He, and M. Vechev, “Baxbench: Can LLMs generate correct and secure backends?,” inForty-second International Conference on Machine Learning, 2025

    2025

  5. [12]

    Secrepobench: Benchmarking code agents for secure code completion in real-world repositories,

    C. Shen, C. Dilgren, P. Chiniya, L. Griffith, Y. Ding, and Y. Chen, “Secrepobench: Benchmarking code agents for secure code completion in real-world repositories,” 2026

    2026

  6. [13]

    SecureVibeBench: Benchmarking secure vibe coding of AI agents via reconstructing vulnerability-introducing scenarios,

    J. Chen, H. Huang, Y. Lyu, J. An, J. Shi, C. Yang, T. Zhang, H. Tian, Y. Li, Z. Li, X. Zhou, X. Hu, and D. Lo, “SecureVibeBench: Benchmarking secure vibe coding of AI agents via reconstructing vulnerability-introducing scenarios,” inProceedings of the 64th Annual Meeting of th...

    2026

  7. [14]

    Swe-agent: Agent-computer interfaces enable automated software engineering,

    J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated software engineering,” 2024

    2024

  8. [15]

    Code-mvp: Learning to represent source code from multiple views with contrastive pre-training,

    X. Wang, Y. Wang, Y. Wan, J. Wang, P. Zhou, L. Li, H. Wu, and J. Liu, “Code-mvp: Learning to represent source code from multiple views with contrastive pre-training,” inFindings of the Association for Computational Linguistics: NAACL 2022, 2022

    2022

  9. [16]

    Galla: Graph aligned large language models for improved source code understanding,

    Z. Zhang, H. Yu, S. Li, P. Di, J. Li, and R. Wang, “Galla: Graph aligned large language models for improved source code understanding,” inProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL 2025), 2025

    2025

  10. [17]

    Constrained decoding for secure code generation,

    Y. Fu, E. Baker, Y. Ding, and Y. Chen, “Constrained decoding for secure code generation,” 2024

    2024

  11. [18]

    Safegenbench: A benchmark framework for security vulnerability detection in llm-generated code,

    X. Li, J. Ding, C. Peng, B. Zhao, X. Gao, H. Gao, and X. Gu, “Safegenbench: A benchmark framework for security vulnerability detection in llm-generated code,”arXiv preprint arXiv:2506.05692, 2025

    2025 arXiv

  12. [20]

    hypertropher-app

    wowashuwow, “hypertropher-app.” https://gith ub.com/wowashuwow/hypertropher-app, 2025

    2025

  13. [21]

    VoiceTradeWithSchwab

    BSalita, “VoiceTradeWithSchwab.” https://gith ub.com/BSalita/VoiceTradeWithSchwab, 2025

    2025

  14. [22]

    Django: The web framework for perfectionists with deadlines

    Django Software Foundation, “Django: The web framework for perfectionists with deadlines.” https: //www.djangoproject.com, 2024. Version 5.0

    2024

  15. [23]

    FastAPI: Modern, fast (high-performance) web framework for building APIs 10 with Python

    S. Ram´ ırez, “FastAPI: Modern, fast (high-performance) web framework for building APIs 10 with Python.” https://fastapi.tiangolo.com ,

  16. [24]

    Express: Fast, unopinionated, minimalist web framework for Node.js

    OpenJS Foundation, “Express: Fast, unopinionated, minimalist web framework for Node.js.” https:// expressjs.com, 2024. Version 4.x

    2024

  17. [25]

    Next.js: The React framework for the web

    Vercel, “Next.js: The React framework for the web.” https://nextjs.org, 2024. Version 14

    2024

  18. [26]

    mypy: Optional static typing for Python

    mypy, “mypy: Optional static typing for Python.” https://mypy-lang.org, 2024. Version 1.8

    2024

  19. [27]

    Bandit: A tool designed to find common security issues in Python code

    PyCQA, “Bandit: A tool designed to find common security issues in Python code.” https://bandit.r eadthedocs.io, 2024. Version 1.7

    2024

  20. [28]

    Semgrep: Lightweight static analysis for many languages

    Semgrep, Inc., “Semgrep: Lightweight static analysis for many languages.” https://semgrep.dev, 2024. Open-source edition. 11

    2024

Pith tools

Reviewed July 13, 2026 · model on record in the stance chip above.