On the Future of Software Reuse in the Era of AI Native Software Engineering

Antero Taivalsaari; Cesare Pautasso; Tommi Mikkonen

REVIEW 3 major objections 5 minor 55 references

On the Future of Software Reuse in the Era of AI Native Software Engineering

T0 review · 3 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 This paper argues that generative AI-based software reuse is a new form of cargo cult development, where developers trust code with unknown origins and inner workings, and sets out a research agenda for the shift.

desk verdict A readable, honest agenda piece, but the cargo-cult thesis is the authors' own prior work and the 80/20 rule is explicitly informal; worth reviewing after tightening citations. read the letter →

arxiv 2508.19834 v1 pith:EHW4UUOH submitted 2025-08-27 cs.SE

Antero Taivalsaari , Tommi Mikkonen , Cesare Pautasso This is my paper · ORCID

classification cs.SE

keywords softwarereusegenerativeAInativeengineeringcargocultprogrammingprompthallucinationresearchagendaslopsquatting

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that the rise of AI-native software engineering has replaced human selection of reusable components with AI-generated code, a practice it calls generative reuse. Because large language models are stochastic and cannot distinguish truth from falsehood, generated code can be convincingly wrong, and developers often cannot understand why it works or fails. This makes the practice analogous to cargo cult programming: ritual inclusion of code without genuine comprehension. The paper argues that this shift carries unresolved risks for quality, maintainability, security, and copyright, and that the field needs systematic methods instead of ad hoc acceptance. Its core contribution is a research agenda framed around the limits of prompt engineering and the feasibility of turning generative reuse into an engineering discipline.

What carries the argument

The paper's load-bearing concept is the cargo cult development analogy: the ritual inclusion of code or program structures without understanding their purpose, risks, or side effects. It connects classic opportunistic reuse—where developers blindly adopt third-party components—to generative reuse, where the component assembler is an AI oracle with unknown internals. A second mechanism is the '80/20 rule' heuristic, which the authors use to characterize prompt engineering: AI can readily satisfy about 80% of requirements, but finalizing the remaining 20% consumes about 80% of development time. This heuristic, though admitted to be unscientific, frames the paper's argument that systematic meth

What would settle it

A controlled study in which developers using AI-generated code are given access to automated formal verification or runtime assertions, and the verified generated code achieves a defect rate no higher than human-written code across a diverse set of tasks, would undermine the claim that generated code is inherently unreliable. Alternatively, if a widely used LLM, when asked for scientific references or library names, produces zero hallucinated or fabricated items over a large, pre-registered test set, the 'cannot decide true and false' premise would be directly falsified.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that AI-assisted software reuse is a genuinely new form of reuse—generative reuse—in which code is composed by an AI that has learned patterns from vast training datasets, rather than selected by a developer from known components. Because the AI's inner workings are a sealed mystery box and because LLMs cannot determine what is true, the generated code may be plausible yet incorrect, and developers cannot fully audit it. This, the paper argues, qualifies as a new form of cargo cult development. The paper supports this with a history of reuse, a summary of contradictory productivity studies, and a list of risks including hallucination, slopsquatt

Load-bearing premise

The central claim collapses if large language models can, in practice, reliably determine what is true and what is false when generating code—or if human oversight can be made effective enough that the cargo cult analogy no longer holds; the paper explicitly relies on the stochastic-parrot characterization, and it also admits the 80/20 rule is based on informal observation, not scientific study.

Editorial extensions

If this is right

If generative reuse is a new form of cargo cult development, software engineering needs explicit verification, review, and testing practices for AI-generated code before it can be used in production systems.
Hallucinated library names and deprecated API assumptions in generated code create a new class of supply-chain vulnerabilities, such as slopsquatting, that do not require compromising existing packages.
Because generated code is derived from training-data fragments, developers and organizations face heightened copyright and licensing risks that current detection tools may not fully cover.
Contradictory productivity evidence—some studies show large gains, others show slowdowns—implies that the net effect of AI tools depends heavily on task type and developer experience, so blanket adoption decisions are premature.
The research agenda suggests that whether prompt engineering can replace requirements specification is an open empirical question, and that the industry may be moving toward agentic coding without resolving it.

Reading between the lines

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

A testable extension of the cargo cult analogy is that code-review effort for AI-generated code should scale with the proportion of code the developer did not write and cannot explain; studies of review time per line could confirm or refute this.
If the 80/20 heuristic generalizes, then the practical bottleneck of AI-native development is not generation but finalization; this predicts that investments in debugging and integration tooling will matter more than improvements in prompt engineering.
The paper's central premise implies that any LLM architecture with verifiable grounding, formal reasoning, or self-checking would, if effective, weaken the analogy by giving generated code known provenance and explainable behavior.
The slopsquatting concern extends beyond code: hallucinated names in generated configuration files, dependencies, or documentation could be exploited similarly in infrastructure-as-code and DevOps pipelines.

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

First, the honest take: this paper's core claim—that generative AI reuse is a new kind of cargo cult—is not new. The same authors made it in their 2025 Internetware paper [35], and this manuscript leans heavily on that earlier work. What this version adds is a wider frame: a brief history of reuse, a list of claimed benefits and limitations, and a concrete research agenda. That agenda is the most useful part. The questions about prompt limits, maintainability of generated code, certification, and supply-chain attacks (including the 'slopsquatting' idea) are well chosen and worth a reading group's time. The paper is also honest in important places. The 80/20 heuristic is explicitly flagged as not based on scientific study. The productivity evidence is presented both ways—26% and 58% gains versus a 19% slowdown—without cherry-picking. That is more balanced than most of this literature. The soft spots are real but not fatal. Several load-bearing factual claims have no citations: hallucination rates of 1–3% to nearly 80%, the US data-center energy figures, and the claim about prompt engineering replacing requirements. The 1–80% range is so wide it cannot support a uniform conclusion, and the stochastic-parrot premise is contested. The paper never draws a categorical boundary: if classic opportunistic reuse is already 'cargo cult,' as the intro says, then what exactly makes generative reuse a new form rather than a more convenient version of the old one? The authors gesture at the difference—trust in an unknown oracle versus trust in a known artifact—but they don't develop it. On balance, this is a creditable position piece. It does not break new empirical ground, but it consolidates and agenda-sets. With added citations and one paragraph distinguishing generative reuse from classic opaque dependencies, it would be solid. I'd send it to peer review—not because the thesis is jarring, but because the field needs this conversation in a citable place. A good referee would ask for those missing citations and the boundary argument, not a rewrite.

Referee Report

3 major / 5 minor

Summary. The paper is a position/vision statement arguing that the widespread adoption of AI assistants for code generation constitutes a new form of generative software reuse, and that this development is a distinct kind of cargo cult development relative to classic opportunistic reuse. It traces the history of software reuse from the 1960s through the open-source/package-manager era, characterizes AI native software engineering and prompt/vibe coding, summarizes claimed benefits and challenges (especially hallucination), reviews recent productivity studies with both positive and negative results, and proposes a research agenda of open questions. The central claim is that developers are increasingly trusting code generated by an opaque 'oracle', with unresolved implications for quality, maintainability, copyright, security, and the long-term skills of developers.

Significance. If the position is accepted, the paper offers a timely framing and a useful inventory of open questions for the software engineering community. Its strengths include a concise historical synthesis of reuse, a balanced treatment of recent field experiments (Cui et al.'s 26% gain, Peng et al.'s 58% gain, and Becker et al.'s 19% slowdown), and the identification of specific new failure modes such as slopsquatting, hallucinated library imports, and flat code structure from regenerated snippets. The authors are also honest about the anecdotal status of their own 80/20 heuristic and about contradictory evidence. However, the central cargo cult analogy rests on an empirical reliability gap that is asserted more than it is established, and the paper does not draw a sharp categorical boundary between generative reuse and the already-opaque third-party reuse it describes. These issues are load-bearing and need to be addressed before the paper's main claim can be considered fully supported.

major comments (3)

[§4.2] The sentence 'According to studies, hallucination rates with current AI development tools range from 1-3% to nearly 80% depending on the intended use case and domain' is uncited and too broad to carry the argument. This range spans two orders of magnitude and does not distinguish reference hallucination, code generation, or other tasks. Since the cargo cult characterization in §1 depends on AI-generated code being systematically unreliable in a way that human oversight cannot easily resolve, the paper should either cite specific studies and scope the claim precisely, or replace it with a more cautious, sourced statement about known categories of LLM failure. As written, the reader cannot verify the premise that hallucination is 'built-in' to a degree that makes generated code fundamentally different from prior reuse artifacts.
[§5] The 80/20 heuristic ('systems can relatively easily propose code ... for meeting roughly 80% of the requirements ... finalizing the remaining ~20% ... can easily end up consuming ~80% of the development time') is explicitly admitted to be 'not based on any truly scientific empirical studies'. Yet the paper presents it as a key observation and ties it to one of the 'biggest research themes'. Because the authors themselves flag the absence of empirical support, the text should clearly label this as an anecdotal hypothesis and state what evidence would be needed to validate it. Otherwise the heuristic functions as an unsupported axiom in an otherwise experience-based argument.
[§4.2] The paper first states that classic opportunistic reuse already 'bears the imprint of cargo cult development' and later claims that generative reuse 'can be viewed as a new form of cargo cult development'. The categorical difference is not established. The only distinction offered is that generative reuse places trust in an external oracle whose inner workings are unknown, while classic reuse trusts artifacts that have 'already been known to work in other contexts'. But the paper's own description of classic reuse emphasizes that developers include components with little knowledge of technical details or quality. To make the 'new form' claim load-bearing, the authors should identify a concrete, testable difference—e.g., non-repeatability of outputs, hallucinated package names, inability to inspect provenance, or the combination of generated code with automatically imported libraries—and

minor comments (5)

[§1] Typo: 'millenium' should be 'millennium'.
[§4.3] Typo: 'correctless' should be 'correctness'.
[§7] Typo: 'We took at look at' should be 'We took a look at'.
[References] Reference [1] lists 'MPDI Computers Journal'; the publisher name should be 'MDPI'.
[§5] The word 'luculent' is unusual and may confuse readers; consider using 'clear' or 'unambiguous' alone.

Circularity Check

0 steps flagged · score 2.0 of 10

Position paper with self-citations but no circular derivation; central cargo-cult analogy is argued, not fitted.

full rationale

The paper is an opinion/research-agenda piece that makes no equation-level predictions. Its central claim (generative reuse as a new form of cargo cult development) is supported by an explicit analogy: developers trust code from an opaque AI oracle, much like cargo-cult programmers reuse code without understanding. This is argued in Section 1 with external anchors (Feynman, Lippert) rather than derived from the paper's own definitions or fitted data. The authors cite their own earlier work for the opportunistic-reuse background (e.g., [48], [34], [31]) and for the claim that junior developers may trust AI blindly ([35]); these are supporting citations and the claim is independently restated in the same paper, so they are not load-bearing circular steps. The 80/20 observation in Section 5 is explicitly admitted to be non-scientific ('we have not yet performed any truly scientific empirical studies on actual percentages'), so it is not a fitted parameter masquerading as a prediction. Hallucination discussion cites Bender et al. and does not depend on the authors' own results. No self-definitional, uniqueness-imported, or ansatz-smuggling pattern is present. A score of 2 reflects the presence of several self-citations and an anecdotal heuristic, but no circular derivation.

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

The paper introduces no new entities in the ontological sense; terms like 'AI Native Software Engineering' and 'slopsquatting' are naming and synthesis of existing phenomena. The 80/20 heuristic is a hand-set informal observation, not a derived quantity. The main axioms are domain assumptions about LLM behavior and adoption rates, one of which is supported only by the authors' own prior citation.

free parameters (1)

80/20 rule = 80% of requirements manageable by AI; remaining 20% consumes roughly 80% of development time
Hand-chosen informal heuristic with no empirical grounding. The authors admit in Section 4.3: 'we have not yet performed any truly scientific empirical studies on actual percentages.'

assumptions (3)

domain assumption LLMs are stochastic parrots that cannot determine what is true or false in generated content.
Load-bearing for the cargo cult framing and the emphasis on hallucination risk. Stated in Section 4.2, Notes on hallucination, citing [3], but this characterization is contested in the LLM literature.
domain assumption AI-generated code already constitutes the majority of new software code in many settings.
Supports the urgency of the research agenda. Stated in Section 3 with citation [35], which is the authors' own prior work, rather than independent adoption data.
ad hoc to paper Hallucination rates in AI coding tools range from 1-3% to nearly 80% depending on the use case and domain.
Presented as established fact but stated without any citation in Section 4.2, Notes on hallucination. The broad range makes it unfalsifiable as presented.

how reviews work

0 comments

Cite this review

Pith. "Pith review of On the Future of Software Reuse in the Era of AI Native Software Engineering." pith.science (2026). https://pith.science/paper/EHW4UUOH

@misc{pith2026250819834,
  author       = {Pith},
  title        = {Pith review of: On the Future of Software Reuse in the Era of AI Native Software Engineering},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EHW4UUOH}},
  note         = {Machine review of arXiv:2508.19834}
}

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. Earlier opportunistic software reuse practices and organic software development methods are rapidly being replaced by "AI Native" 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, bring forth relevant questions, and define a research agenda for tackling the central issues associated with this emerging approach.

Figures

Figures reproduced from arXiv: 2508.19834 by the authors.

**Figure 1.** Simplified History of Software Reuse and NPM over three million packages (!) – most of them with a permissive open source MIT license5 . Coincidentally, while all the programming features on the World Wide Web – such as the introduction of the JavaScript programming language in the mid1990s – were largely an afterthought [47,46], the evolution of the World Wide Web also led to the Software as a Service (SaaS) model… view at source ↗

**Figure 2.** From Classic Opportunistic Software Reuse to AI Assisted Generative Software Reuse Before diving further in AI native development practices, it should be noted that generative reuse is by no means an entirely new concept. There are existing survey papers from over twenty-five years ago, e.g., by Biggerstaff [5], and roots of this approach can be traced back to 1980s. In his paper, Biggerstaff analyzed success facto… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 48 canonical work pages

[35]

Software Reuse in the Generative AI Era: From Cargo Cult Towards Systematic Practices

Tommi Mikkonen and Antero Taivalsaari. Software Reuse in the Generative AI Era: From Cargo Cult Towards Systematic Practices. InProceedings of the 16th International Conference on Internetware (Internetware’25, Trondheim, Norway, June 20-22). ACM, 2025

work page 2025
[1]

The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis

Manal Alanazi, Ben Soh, Halima Samra, and Alice Li. The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis. MPDI Computers Journal , 14(5), 2025

work page 2025
[2]

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Joel Becker, Nate Rush, Beth Barnes, and David Rein. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv preprint, arXiv:2507.09089v2, 2025

arXiv 2025
[3]

Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell

Emily M. Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? In Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency, FAccT’21, page 610–623. ACM, 2021

work page 2021
[4]

T. J. Biggerstaff and C. Richter. Reusability Framework, Assessment and Direc- tions. IEEE Software, 4(2):41–49, 1987

work page 1987
[5]

A Perspective of Generative Reuse.Annals of Software Engineer- ing, 5(1):169–226, January 1998

Ted Biggerstaff. A Perspective of Generative Reuse.Annals of Software Engineer- ing, 5(1):169–226, January 1998

work page 1998
[6]

Xlibris, 2015

Ahmed Bouzid and David Rennyson.The Art of SaaS: A Primer on the Funda- mentals of Building and Running a Successful SaaS Business . Xlibris, 2015

work page 2015
[7]

Generative AI at Work

Erik Brynjolfsson, Danielle Li, and Lindsey Raymond. Generative AI at Work. The Quarterly Journal of Economics , 140(2):889–942, 02 2025

work page 2025

Show all 55 references

[8]

Proceedings of the Workshop on Reusability in Programming (Newport, Rhode Island, September 7-9)

ITT Programming (Company). Proceedings of the Workshop on Reusability in Programming (Newport, Rhode Island, September 7-9) . 1983

1983
[9]

Overview of Generative Software Development

Krzysztof Czarnecki. Overview of Generative Software Development. In Inter- national Workshop on Unconventional Programming Paradigms , pages 326–341. Springer, 2004

2004
[10]

Generative Programming: Methods, Techniques, and Applications

Krzysztof Czarnecki and Ulrich Eisenecker. Generative Programming: Methods, Techniques, and Applications. Addison-Wesley Professional, 2000

2000
[11]

Generative AI for Software Practitioners

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

2023
[12]

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

2022
[13]

Cargo Cult Science

Richard P Feynman. Cargo Cult Science. InThe Art and Science of Analog Circuit Design, pages 55–61. Elsevier, 1998

1998
[14]

Gupta, Taylor Berg- Kirkpatrick, and Earlence Fernandes

Xiaohan Fu, Shuheng Li, Zihan Wang, Yihao Liu, Rajesh K. Gupta, Taylor Berg- Kirkpatrick, and Earlence Fernandes. Imprompter: Tricking LLM Agents into Improper Tool Use. arXiv preprint arXiv:2410.14923, 2024

2024 arXiv
[15]

Artech House, 2003

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

2003
[16]

Hacking, Mashing, Glu- ing: Understanding Opportunistic Design.IEEE Pervasive Computing, 7(3):46–54, 2008

Björn Hartmann, Scott Doorley, and Scott R Klemmer. Hacking, Mashing, Glu- ing: Understanding Opportunistic Design.IEEE Pervasive Computing, 7(3):46–54, 2008

2008
[17]

Hassan, Saman A

Hassan B. Hassan, Saman A. Barakat, and Qusay I. Sarhan. Survey on Serverless Computing. Journal of Cloud Computing , 10(1):39, Jul 2021

2021
[18]

T. C. Jones. Reusability in Programming: A Survey of the State of the Art.IEEE Transactions on Software Engineering , SE-10(5):488–494, 1984

1984
[19]

Generative AI for Code Generation: Software Reuse Impli- cations

Georgia M Kapitsaki. Generative AI for Code Generation: Software Reuse Impli- cations. In International Conference on Software and Software Reuse , pages 37–47. Springer, 2024

2024
[20]

3D Gaussian Splatting for Real-Time Radiance Field Rendering.ACM Transactions on Graphics, 42(4), July 2023

BernhardKerbl,GeorgiosKopanas,ThomasLeimkühler,andGeorgeDrettakis. 3D Gaussian Splatting for Real-Time Radiance Field Rendering.ACM Transactions on Graphics, 42(4), July 2023

2023
[21]

The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers

Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, and Tobias Salz. The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. SSRN preprint #4945566, June 2025

2025
[22]

Software Reuse: Survey and Research Di- rections

Yongbeom Kim and Edward A Stohr. Software Reuse: Survey and Research Di- rections. Journal of Management Information Systems , 14(4):113–147, 1998

1998
[23]

Software Reuse

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

1992
[24]

R. G. Lanergan and C. A. Grasso. Software Engineering with Reuseable Designs and Code. IEEE Transactions on Software Engineering , SE-10(5):498–501, 1984

1984
[25]

Lentz, H

M. Lentz, H. A. Schmid, and P. F. Wolf. Software Reuse Through Building Blocks. IEEE Software, 4(4):34–42, 1987

1987
[26]

CambridgeUniversity Press, 03 2022

Andreas Lindholm, Niklas Wahlström, Fredrik Lindsten, and Thomas Schön.Ma- chine Learning: A First Course for Engineers and Scientists . CambridgeUniversity Press, 03 2022

2022
[27]

Syntax, Semantics, Micronesian Cults and Novice Program- mers

Eric Lippert. Syntax, Semantics, Micronesian Cults and Novice Program- mers. Available at https://blogs.msdn.microsoft.com/ericlippert/2004/03/ 01/syntax-semantics-micronesian-cults-and-novice-programmers/ , 2004. Accessed: 2025-04-22

2004
[28]

Liskov, A

B.H. Liskov, A. Snyder, R. Atkinson, and C. Schaffert. Abstraction Mechanisms in CLU. Communications of the ACM , 20(8):564–576, Aug 1977

1977
[29]

Jailbreaking ChatGPT via Prompt Engineering: An Empirical Study

Yi Liu, Gelei Deng, Zhengzi Xu, Yuekang Li, Yaowen Zheng, Ying Zhang, Lida Zhao, Tianwei Zhang, Kailong Wang, and Yang Liu. Jailbreaking ChatGPT via Prompt Engineering: An Empirical Study. arXiv preprint arXiv:2305.13860, 2024

2024 arXiv
[30]

Cargo Cults in Information Systems Development: A Definition and an Analytical Framework

Tanja Elina Mäki-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
[31]

On Opportunistic Software Reuse.Computing, 102(10):2385–2408, 2020

Niko Mäkitalo, Antero Taivalsaari, Arto Kiviluoto, Tommi Mikkonen, and Rafael Capilla. On Opportunistic Software Reuse.Computing, 102(10):2385–2408, 2020

2020
[32]

Mass Produced Software Components

Malcolm Douglas McIlroy. Mass Produced Software Components. In Naur and Randell (eds): Software Engineering: Report of Conference Sponsored by the NATO Science Committee, Garmisch, Germany, Oct 7-11, 1968 , pages 79–85

1968
[33]

The Mashware Challenge: Bridging the Gap Between Web Development and Software Engineering

Tommi Mikkonen and Antero Taivalsaari. The Mashware Challenge: Bridging the Gap Between Web Development and Software Engineering. InProceedings of the FSE/SDP Workshop on the Future of Software Engineering Research , pages 245–
[34]

Software Reuse in the Era of Oppor- tunistic Design

Tommi Mikkonen and Antero Taivalsaari. Software Reuse in the Era of Oppor- tunistic Design. IEEE Software, 36(3):105–111, 2019

2019
[36]

Copy and Paste Redeemed (T)

Krishna Narasimhan and Christoph Reichenbach. Copy and Paste Redeemed (T). In 2015 30th IEEE/ACM International Conference on Automated Software Engi- neering (ASE), pages 630–640. IEEE, 2015

2015
[37]

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
[38]

Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence.Science, 381(6654):187–192, 2023

Shakked Noy and Whitney Zhang. Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence.Science, 381(6654):187–192, 2023

2023
[39]

D.L. Parnas. A Technique for Software Module Specification with Examples.Com- munications of the ACM , 15(5):330–336, May 1972

1972
[40]

D.L. Parnas. On the Criteria to be Used in Decomposing Systems into Modules. Communications of the ACM , 15(12):1053–1058, Dec 1972

1972
[41]

D.L. Parnas. Designing Software for Ease of Extension and Contraction. IEEE Transactions on Software Engineering , SE-5(2):128–137, Mar 1979

1979
[42]

The Impact of AI on Developer Productivity: Evidence from GitHub Copilot

Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv preprint, arXiv:2302.06590, 02 2023

2023 arXiv
[43]

The Prompt Report: A System- atic Survey of Prompt Engineering Techniques

Sander Schulhoff, Michael Ilie, Nishant Balepur, Konstantine Kahadze, Amanda Liu, Chenglei Si, Yinheng Li, Aayush Gupta et al. The Prompt Report: A System- atic Survey of Prompt Engineering Techniques. arXiv preprint, arXiv:2406.06608, 2025

2025 arXiv
[44]

Roumeliotis, and Manoj Karkee

Ranjan Sapkota, Konstantinos I. Roumeliotis, and Manoj Karkee. Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI. arXiv preprint, arXiv:2505.19443, 2025

2025 arXiv
[45]

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
[46]

Objects in the Cloud May be Closer Than They Appear: Towards a Taxonomy of Web-based Software

Antero Taivalsaari and Tommi Mikkonen. Objects in the Cloud May be Closer Than They Appear: Towards a Taxonomy of Web-based Software. In13th IEEE International Symposium on Web Systems Evolution (WSE) , pages 59–64, 2011

2011
[47]

The Death of Binary Software: End User Software Moves to the Web

Antero Taivalsaari, Tommi Mikkonen, Matti Anttonen, and Arto Salminen. The Death of Binary Software: End User Software Moves to the Web. InNinth Interna- tional Conference on Creating, Connecting and Collaborating through Computing , pages 17–23, 2011

2011
[48]

Programming the Tip of the Iceberg: Software Reuse in the 21st Century

Antero Taivalsaari, Tommi Mikkonen, and Niko Mäkitalo. Programming the Tip of the Iceberg: Software Reuse in the 21st Century. InProceedings of the 45th Eu- romicro Conference on Software Engineering and Advanced Applications (SEAA) , pages 108–112. IEEE, 2019

2019
[49]

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
[50]

Turning Software into a Service

Mark Turner, David Budgen, and Pearl Brereton. Turning Software into a Service. Computer, 36(10):38–44, 2003

2003
[51]

Glassman

Priyan Vaithilingam, Tianyi Zhang, and Elena L. Glassman. Expectation vs. Ex- perience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models. In Extended Abstracts of the 2022 CHI Conference on Human Factors in Computing Systems , CHI EA’22, New Y...

2022
[52]

Prompt Engineering: a Methodology for Optimizing Interactions with AI-Language Models in the Field of Engineering

Juan Velásquez-Henao, Carlos Franco, and Lorena Cadavid. Prompt Engineering: a Methodology for Optimizing Interactions with AI-Language Models in the Field of Engineering. DYNA, 90:9–17, 11 2023

2023
[53]

LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-based Code Completion

Chong Wang, Kaifeng Huang, Jian Zhang, Yebo Feng, Lyuye Zhang, Yang Liu, and Xin Peng. LLMs Meet Library Evolution: Evaluating Deprecated API Usage in LLM-based Code Completion. arXiv preprint, arXiv:2406.09834, 2025

2025 arXiv
[54]

Waseem, T

M. Waseem, T. Das, A. Ahmad, P. Liang, M. Fahmideh, and T. Mikkonen. Chat- GPT as a Software Development Bot: A Project-Based Study. InInternational Conference on Evaluation of Novel Approaches to Software Engineering , 2024

2024
[55]

S.N. Zilles. Procedural Encapsulation: a Linguistic Protection Technique. ACM SIGPLAN Notices, 8(9):142–146, Sep 1973

1973

Pith tools

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

[1] [35]

Software Reuse in the Generative AI Era: From Cargo Cult Towards Systematic Practices

Tommi Mikkonen and Antero Taivalsaari. Software Reuse in the Generative AI Era: From Cargo Cult Towards Systematic Practices. InProceedings of the 16th International Conference on Internetware (Internetware’25, Trondheim, Norway, June 20-22). ACM, 2025

work page 2025

[2] [1]

The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis

Manal Alanazi, Ben Soh, Halima Samra, and Alice Li. The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis. MPDI Computers Journal , 14(5), 2025

work page 2025

[3] [2]

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Joel Becker, Nate Rush, Beth Barnes, and David Rein. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv preprint, arXiv:2507.09089v2, 2025

arXiv 2025

[4] [3]

Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell

Emily M. Bender, Timnit Gebru, Angelina McMillan-Major, and Shmargaret Shmitchell. On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? In Proceedings of the 2021 ACM Conference on Fairness, Accountability, and Transparency, FAccT’21, page 610–623. ACM, 2021

work page 2021

[5] [4]

T. J. Biggerstaff and C. Richter. Reusability Framework, Assessment and Direc- tions. IEEE Software, 4(2):41–49, 1987

work page 1987

[6] [5]

A Perspective of Generative Reuse.Annals of Software Engineer- ing, 5(1):169–226, January 1998

Ted Biggerstaff. A Perspective of Generative Reuse.Annals of Software Engineer- ing, 5(1):169–226, January 1998

work page 1998

[7] [6]

Xlibris, 2015

Ahmed Bouzid and David Rennyson.The Art of SaaS: A Primer on the Funda- mentals of Building and Running a Successful SaaS Business . Xlibris, 2015

work page 2015

[8] [7]

Generative AI at Work

Erik Brynjolfsson, Danielle Li, and Lindsey Raymond. Generative AI at Work. The Quarterly Journal of Economics , 140(2):889–942, 02 2025

work page 2025