Pith. sign in

REVIEW 3 major objections 4 minor 29 references

Software Reuse in the Generative AI Era: From Cargo Cult Towards AI Native Software Engineering

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Generative AI extends opportunistic software reuse to the point where developers may not understand the code they ship.

desk verdict A clearly argued position paper that frames generative AI reuse as cargo cult programming; the 'has arrived' claim outstrips the anecdotal evidence, but the framing and agenda are useful. read the letter →

arxiv 2506.17937 v1 pith:4SIRGBCC submitted 2025-06-22 cs.SE cs.AI

Tommi Mikkonen , Antero Taivalsaari This is my paper
classification cs.SEcs.AI
keywords AInativesoftwareengineeringgenerativereusecargocultdevelopmentopportunisticpromptgeneratedcodequalityresearchagenda
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

Software reuse has gone from manual library search to opportunistic assembly of open-source components, and this paper argues that AI-generated code is the next stop on the same continuum. The authors' central claim is that current AI-assisted development is a form of cargo cult reuse—code included ritualistically without understanding—because developers increasingly trust an opaque system's output without knowing its provenance or side effects. Because generated code can be an unverifiable amalgamation of training-data fragments, the familiar 'tip of the iceberg' reuse model has reached an extreme in which developers may write none of the code themselves. The authors therefore declare that 'AI native software engineering' has arrived and needs systematic practices for evaluating, integrating, governing, and maintaining generated artifacts, and they offer a research agenda of open questions toward that end.

What carries the argument

The paper's load-bearing object is a conceptual analogy between AI-generated code and two older reuse metaphors: the 'iceberg' model, in which only a small, developer-written portion of a system is visible and understood while the bulk is inherited from elsewhere, and 'cargo cult' development, the ritual inclusion of code or structures without real understanding. These analogies do the work of connecting generative AI to established reuse research, letting the authors claim that familiar problems—provenance, trust, quality, maintenance—now appear in extreme form. The paper also uses the established category of 'opportunistic reuse' as the continuum on which AI-assisted development sits, and it draws on an earlier analysis of generative reuse as a reference point for what a systematic version would need.

What would settle it

A large-scale measurement study of real development teams would settle the premise: log the AI-generated code accepted into repositories, the fraction of that code reviewed or modified by humans, and the defect rate of that code. If most AI output is heavily reviewed or limited to trivial scaffolding, the cargo-cult characterization of current practice would not hold.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is a reclassification: generative AI-based reuse should be understood as a continuation of opportunistic reuse rather than a brand-new discipline. The authors argue that for decades developers have built systems like icebergs, where the visible tip is code they wrote and understood while the submerged mass is external components of uncertain origin; with AI assistants, even the tip can be machine-generated and poorly understood. They call this the ultimate form of the 'tip of the iceberg' model and a variant of cargo cult development, since reliance on an unknown oracle replaces comprehension of the artifact. From this they conclude that AI native software engineering has arrived, that it will significantly shape how software is created in the future, and that the community must turn generative reuse from a let's-see-what-the-AI-produces activity into a systematic, governable practice.

Load-bearing premise

The paper assumes that developers are already relying on AI-generated code at scale and accepting it without adequate understanding; if real-world adoption is slower, more careful, or confined to low-stakes tasks, the urgency of its proposed research agenda weakens.

Editorial extensions

If this is right

  • Code review and testing will have to treat AI output as untrusted third-party code, with provenance checks and license scanning built into the pipeline.
  • Developer training and hiring should shift from authoring code toward verifying, debugging, and integrating code, because generated artifacts may not follow human development patterns.
  • The traditional goal of systematic reuse becomes harder, not easier, when generated subsystems lack stable boundaries and readable structure; the field will need new modularity and documentation conventions for AI output.
  • Organizations adopting AI-assisted development will need governance policies—review thresholds, acceptance criteria, and copyright safeguards—equivalent to those used for institutional reuse.
  • The paper's list of open questions functions as a research agenda: realistic limits of prompt engineering, ways to comprehend generated code, and standards for production use.

Reading between the lines

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

  • Beyond the paper, the framing predicts that a developer's ability to explain and modify generated code will become a stronger predictor of system quality than their ability to write code from scratch.
  • Beyond the paper, the cargo-cult analogy suggests a measurable hypothesis: developers' confidence in AI output will outpace their actual comprehension, testable by asking them to find injected defects in generated code they believe they have reviewed.
  • Beyond the paper, existing tools for opportunistic reuse, such as dependency scanning, provenance tracking, and lock files, could be adapted to AI generation as a practical first step toward the systematic practice the paper calls for.
  • Beyond the paper, the concern about monolithic AI output implies that future AI coding tools should be designed to emit modular, documented artifacts with explicit subsystem boundaries, making verification feasible.
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

3 major / 4 minor

Summary. This position paper argues that AI-assisted code generation constitutes a new form of software reuse, which the authors characterize as a continuation of opportunistic reuse and as a variant of cargo cult development. The paper reviews the evolution of software reuse, introduces the notion of "AI native software engineering," raises a set of questions about quality, trust, licensing, and maintainability, and concludes with a call to action for the software engineering community. The central claims are that AI-generated code is already widely adopted, that developers often trust it without adequate understanding, and that this represents the "ultimate form" of the iceberg reuse model. The paper is a qualitative, essay-style contribution with no empirical datasets or formal derivations.

Significance. If the central empirical premise holds—namely, that AI-generated code is now pervasive and is being integrated without adequate understanding—the paper would provide a timely reframing of software reuse research and a useful agenda for future work. The authors make a plausible connection between historical reuse discourse and current practice, and they raise several concrete questions (evaluation of generated code, subsystem structure, copyright, long-term maintenance) that are likely to matter for the field. The paper is clearly written and well anchored in the reuse literature, and it makes good use of prior work on iceberg reuse and opportunistic design. However, the significance is conditional: the urgency of the call to action depends on an empirical premise that the paper does not demonstrate. As a position paper, it is a reasonable starting point, but the load-bearing claim of "arrival" needs more systematic support or a clearer framing as a hypothesis.

major comments (3)
  1. [Section 4, Section 5] The central empirical premise—that AI native software development has arrived and that developers place trust in AI-generated code without adequate understanding—is supported only by anecdote and analogy. The only direct evidence is the sentence in Section 4 about the authors' project experience over the past 1 1/2 years, followed by "it is very likely that the general approach is here to stay." The cited external works (e.g., [7], [18], [26]) are not summarized with any data, and the paper explicitly acknowledges in Section 4 that "it is still unclear what the long-term impact of AI native software reuse will be," only to assert in Section 5 that "AI native software development has arrived." This is load-bearing because the entire call to action rests on the claim that unreflective trust in AI-generated code is already prevalent. If developers actually validate, test, or reject AI output at high rates, the cargo cult framing loses its basis. The manuscript should either provide systematic evidence (e.g., adoption statistics, survey data, or case studies) or recast the "arrival" claim as a testable hypothesis and separate the normative concern from the empirical assertion.
  2. [Section 1 vs. Section 4] There is an internal tension about whether developers are capable of evaluating AI-generated code. Section 1 states that "developers must be capable enough to judge the quality and suitability of the artificially generated code," and Section 4 similarly says that "developers using AI-generated code must be skillful enough to distinguish and evaluate the quality of the generated artifacts" and that "merely blindly trusting whatever was automatically generated cannot be an acceptable approach." Yet the abstract and Sections 2 and 5 characterize current practice as one in which "developers place their trust" on AI-generated code and describe it as cargo cult development. The paper does not specify which behavior is typical—careful evaluation or blind trust—nor does it present evidence for either. This ambiguity weakens the central analogy. The authors should distinguish between the recommended practice (which they describe) and the observed practice (which they assert), and provide some basis for the latter.
  3. [Section 4, cargo cult analogy] The cargo cult analogy is imprecise as stated. In classic cargo cult programming (e.g., Feynman [8], Lippert [19]), developers include code they do not understand because they are imitating a ritual, without any evaluation of the artifact. In AI-assisted generative reuse, the developer may not understand the internals of the AI system but can still evaluate the generated code's behavior, tests, and suitability. The paper itself acknowledges this possibility in Section 4, yet repeatedly asserts that AI-assisted reuse is "conceptually not all that different" from cargo cult development. This is a conceptual overreach unless the paper shows that typical developers skip behavioral evaluation. The analogy would be stronger if it were framed as a risk or tendency rather than as a characterization of current practice, or if it were tied to concrete evidence about how developers actually treat AI-generated output.
minor comments (4)
  1. [Section 3] The definition of "AI native software development" is broad and overlaps with terms like "AI-assisted development" and "AI-driven development" without drawing clear boundaries; a brief comparison of these terms would help.
  2. [Section 4, question list] The list of questions forms the proposed research agenda, but the paper does not prioritize these questions or suggest methods (e.g., empirical studies, controlled experiments, or theoretical analyses) for addressing them; adding a short paragraph on methodology would strengthen the call to action.
  3. [Throughout] Several of the key references supporting the empirical premise are the authors' own prior works (e.g., [21], [22], [27]), which is acceptable in a position paper, but the argument would be more persuasive if it cited independent adoption or quality data from industry surveys or third-party studies.
  4. [Abstract] The abstract states as fact that "developers place their trust on code that has been generated by artificial intelligence," which is the same unsupported empirical claim noted in the major comments; the abstract should be softened or matched with evidence in the body.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the paper's central claims are qualitative analogies built on the authors' prior conceptual work, not derivations that reduce to their own assumptions.

full rationale

The paper is a position/vision essay rather than a formal derivation. Its central claims—that AI-assisted generative reuse is an extension of opportunistic reuse, that it resembles cargo cult development, and that "AI native software development has arrived"—are supported by analogy and argument, not by equations or fitted parameters. The authors do cite their own prior work on the "tip of the iceberg" reuse model [27] and opportunistic software reuse [21], and these concepts are used to frame the discussion. However, the paper re-articulates and applies those concepts to the new setting instead of treating them as unverified premises that logically force the conclusion. The empirical premise that developers are increasingly using AI tools is supported mainly by anecdote and external surveys, which is an evidentiary weakness rather than a circular step. There is no instance where a parameter is fitted to data and then presented as a prediction, no self-citation is used as a uniqueness argument to forbid alternatives, and no known result is merely renamed. The self-citations are present but not load-bearing in the sense required for circularity: the argument could stand or fall on the plausibility of the analogies and on external evidence. Accordingly, the paper is not circular in a way that would warrant a score above 2; the minor self-citation reliance accounts for the low nonzero score.

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

The paper makes no quantitative claims and fits no parameters. Its central argument rests on three domain assumptions: that generative AI output counts as reuse, that developer trust mirrors cargo cult behavior, and that the risks warrant a dedicated research agenda. The only invented entity is the concept label 'AI native software engineering', which has no independent empirical handle.

assumptions (3)
  • domain assumption Generative AI output is a form of software reuse because it reuses fragments of training data.
    The entire framing depends on viewing LLM-generated code as reuse of previously created artifacts, which is asserted in Section 3 rather than demonstrated empirically.
  • domain assumption Developers placing trust in AI-generated code is analogous to cargo cult programming.
    The behavioral premise is supported by analogy and anecdote, not by observational or experimental evidence, as stated in Sections 1 and 4.
  • domain assumption AI-generated code introduces significant quality, copyright, security, and maintenance risks that require a research agenda.
    The call to action presumes these risks are substantial, but the paper provides no systematic risk assessment or empirical failure data, only references and arguments.
invented entities (1)
  • AI native software engineering
    purpose: A named discipline or research direction for studying and systematizing AI-assisted software creation.
    Introduced as a term of art in Sections 3 and 5. It is a conceptual label, not an entity with a falsifiable handle outside the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Software Reuse in the Generative AI Era: From Cargo Cult Towards AI Native Software Engineering." pith.science (2026). https://pith.science/paper/4SIRGBCC

@misc{pith2026250617937,
  author       = {Pith},
  title        = {Pith review of: Software Reuse in the Generative AI Era: From Cargo Cult Towards AI Native Software Engineering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4SIRGBCC}},
  note         = {Machine review of arXiv:2506.17937}
}
read the original abstract

Software development is currently under a paradigm shift in which artificial intelligence and generative software reuse are taking the center stage in software creation. Consequently, earlier software reuse practices and methods are rapidly being replaced by AI-assisted approaches in which developers place their trust on code that has been generated by artificial intelligence. This is leading to a new form of software reuse that is conceptually not all that different from cargo cult development. In this paper we discuss the implications of AI-assisted generative software reuse in the context of emerging "AI native" software engineering, bring forth relevant questions, and define a tentative research agenda and call to action for tackling some of the central issues associated with this approach.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 27 canonical work pages

  1. [7]

    Ai-driven development is here: Should you worry? IEEE Software, 39(2):106–110, 2022

    Neil A Ernst and Gabriele Bavota. Ai-driven development is here: Should you worry? IEEE Software, 39(2):106–110, 2022

    work page 2022

  2. [18]

    SheetCopilot: Bringing software productivity to the next level through large language models

    Hongxin Li, Jingran Su, Yuntao Chen, Qing Li, and Zhao-Xiang Zhang. SheetCopilot: Bringing software productivity to the next level through large language models. Advances in Neural Information Processing Sys- tems, 36, 2024. 8

    work page 2024

  3. [26]

    Programming with ai: Evaluating chatgpt, gemini, alphacode, and github copilot for program- mers

    Md Kamrul Siam, Huanying Gu, and Jerry Q Cheng. Programming with ai: Evaluating chatgpt, gemini, alphacode, and github copilot for program- mers. arXiv preprint arXiv:2411.09224 , 2024

    arXiv 2024

  4. [8]

    Cargo cult science

    Richard P Feynman. Cargo cult science. In The Art and Science of Analog Circuit Design, pages 55–61. Elsevier, 1998

    work page 1998

  5. [19]

    Syntax, Semantics, Micronesian Cults and Novice Program- mers, 2004

    Eric Lippert. Syntax, Semantics, Micronesian Cults and Novice Program- mers, 2004. Accessed: 2018-04-22

    work page 2004

  6. [1]

    A perspective of generative reuse

    Ted Biggerstaff. A perspective of generative reuse. Annals of Software Engineering, 5:169–226, 01 1998. 7

    work page 1998

  7. [2]

    Reusability Framework, Assessment and Directions

    Ted Biggerstaff and Charles Richter. Reusability Framework, Assessment and Directions. IEEE Software, 4(2):41–49, 1987

    work page 1987

  8. [3]

    A reusability-based software development environment

    Jingwen Cheng. A reusability-based software development environment. SIGSOFT Softw. Eng. Notes , 19(2):57–62, April 1994

    work page 1994

Show all 29 references
  1. [4]

    Software Product Lines

    Paul Clements and Linda Northrop. Software Product Lines . Addison- Wesley, 2002

    2002

  2. [5]

    State of npm 2023, 2023

    Sandworm Developers. State of npm 2023, 2023

    2023

  3. [6]

    Generative ai for software practitioners

    Christof Ebert and Panos Louridas. Generative ai for software practitioners. IEEE Software, 40(4):30–38, 2023

    2023

  4. [9]

    Software reuse research: Status and future

    William B Frakes and Kyo Kang. Software reuse research: Status and future. IEEE Transactions on Software Engineering , 31(7):529–536, 2005

    2005

  5. [10]

    Testing and Quality Assurance for Component-Based Software

    Jerry Gao, H-SJ Tsao, and Ye Wu. Testing and Quality Assurance for Component-Based Software. Artech House, 2003

    2003

  6. [11]

    Hacking, Mashing, Gluing: Understanding Opportunistic Design

    Bj¨ orn Hartmann, Scott Doorley, and Scott R Klemmer. Hacking, Mashing, Gluing: Understanding Opportunistic Design. IEEE Pervasive Computing, 7(3):46–54, 2008

    2008

  7. [12]

    Reusability in programming: A survey of the state of the art

    T Capers Jones. Reusability in programming: A survey of the state of the art. IEEE Transactions on Software Engineering , (5):488–494, 1984

    1984

  8. [13]

    3d gaussian splatting for real-time radiance field rendering

    Bernhard Kerbl, Georgios Kopanas, Thomas Leimk¨ uhler, and George Dret- takis. 3d gaussian splatting for real-time radiance field rendering. ACM Transactions on Graphics, 42(4), July 2023

    2023

  9. [14]

    Software reuse: Survey and research directions

    Yongbeom Kim and Edward A Stohr. Software reuse: Survey and research directions. Journal of Management Information Systems , 14(4):113–147, 1998

    1998

  10. [15]

    Software reuse

    Charles W Krueger. Software reuse. ACM Computing Surveys (CSUR) , 24(2):131–183, 1992

    1992

  11. [16]

    Software Engineering with Reuseable Designs and Code

    Robert G Lanergan and Charles A Grasso. Software Engineering with Reuseable Designs and Code. IEEE Transactions on Software Engineering, (5):498–501, 1984

    1984

  12. [17]

    Manfred Lenz, Hans Albrecht Schmid, and Peter F. Wolf. Software reuse through building blocks. IEEE Software, 4(4):34–42, 1987

    1987

  13. [20]

    Cargo cults in information systems development: A definition and an analytical framework

    Tanja Elina M¨ aki-Runsas, Kai Wistrand, and Fredrik Karlsson. Cargo cults in information systems development: A definition and an analytical framework. In Advances in Information Systems Development: Designing Digitalization, pages 35–53. Springer, 2019

    2019

  14. [21]

    On opportunistic software reuse

    Niko M¨ akitalo, Antero Taivalsaari, Arto Kiviluoto, Tommi Mikkonen, and Rafael Capilla. On opportunistic software reuse. Computing, 102:2385– 2408, 2020

    2020

  15. [22]

    The Mashware Challenge: Bridg- ing the Gap Between Web Development and Software Engineering

    Tommi Mikkonen and Antero Taivalsaari. The Mashware Challenge: Bridg- ing the Gap Between Web Development and Software Engineering. In Pro- ceedings of the FSE/SDP Workshop on the Future of Software Engineering Research, pages 245–250. ACM, 2010

    2010

  16. [23]

    Reusing software: Issues and re- search directions

    Hafedh Mili, Fatma Mili, and Ali Mili. Reusing software: Issues and re- search directions. IEEE transactions on Software Engineering , 21(6):528– 562, 1995

    1995

  17. [24]

    Naur and B

    P. Naur and B. Randell. Software Engineering: Report of a Conference Sponsored by the NATO Science Committee (Garmisch, Germany, Oct 7- 11, 1968) . NATO Scientific Affairs Division, Brussels, 1969

    1968

  18. [25]

    Why Software Reuse has Failed and How to Make It Work for You

    Douglas C Schmidt. Why Software Reuse has Failed and How to Make It Work for You. C++ Report, 11(1):1999, 1999

    1999

  19. [27]

    Programming the tip of the iceberg: Software reuse in the 21st century

    Antero Taivalsaari, Tommi Mikkonen, and Niko M¨ akitalo. Programming the tip of the iceberg: Software reuse in the 21st century. In 2019 45th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), pages 108–112. IEEE, 2019

    2019

  20. [28]

    Quality modeling for software product lines

    Adam Trendowicz, Teade Punter, et al. Quality modeling for software product lines. In Proceedings of the 7th ECOOP workshop on quantitative approaches in object-oriented software engineering , 2003

    2003

  21. [29]

    ChatGPT as a software development bot: A project-based study

    Muhammad Waseem, Teerath Das, Aakash Ahmad, Peng Liang, Mahdi Fahmideh, and Tommi Mikkonen. ChatGPT as a software development bot: A project-based study. In International Conference on Evaluation of Novel Approaches to Software Engineering . SCITEPRESS-Science and Technology P...

    2024

Pith tools

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