Paper deep dive

Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration

Xhevahire Tërnava

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 34

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%

Last extracted: 6/21/2026, 3:28:27 AM

Summary

The paper introduces 'Variability by Regeneration' (VbR), a new software product line approach designed for the 'vibe coding' paradigm where LLMs generate entire programs from natural language. The authors observe that AI-generated (vibe coded) software typically exhibits near-zero in-artifact variability, with all decisions resolved at 'generation time'. VbR embraces this by managing variability through a declarative specification (features, types, and constraints) rather than in the code itself. The VbR pipeline consists of a specification, a generation function (using an LLM as a derivation engine), and a variant dispatcher. The authors demonstrate this approach using a 'wc' (word count) product family, where each variant is a purpose-built, zero-variability binary, and a dispatcher routes user requests to the appropriate version.

Entities (7)

Generation Time · binding-time · 100%LLM · technology · 100%Specification · component · 100%Variability by Regeneration · approach · 100%Variant Dispatcher · component · 100%Vibe Coding · paradigm · 100%wc product family · software-product-family · 100%

Relation Signals (4)

Variability by Regeneration → consistsof → Specification

confidence 100% · VbR consists of three components: (i) a specification S... (ii) a generation function G... (iii) a variant dispatcher D

Variability by Regeneration → uses → LLM

confidence 100% · the first product-line approach in which the LLM acts as the derivation engine

Vibe Coding → characterizedby → Generation Time

confidence 90% · All variability decisions are resolved at a single new binding time, generation time, the moment the LLM produces the source code.

Variant Dispatcher → routesto → wc product family

confidence 90% · a variant dispatcher transparently routes user requests to the matching binary. ... demonstrate its full pipeline on a wc product family.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:In vibe coding, an emerging AI-driven paradigm, an LLM generates an entire program from a natural language prompt, but what happens to the variability that traditional software engineering carefully builds into code? To answer this question, we conducted an exploratory analysis on 10 vibe coded C/C++ projects, which suggests that there is near-zero in-artifact variability, i.e., at compile and runtime. All variability decisions are resolved at a single new binding time, generation time, the moment the LLM produces the source code. Rather than treating this as a defect to fix, we propose Variability by Regeneration (VbR), to our knowledge the first product-line approach in which the LLM acts as the derivation engine, generating a purpose-built, free of dead code binary for each variant from a declarative specification, while a variant dispatcher transparently routes user requests to the matching binary. We formalise VbR, contrast it with classical SPL derivation, and demonstrate its full pipeline on a wc product family. For SPL engineering, variability in AI-generated software belongs in the specification, not in the code.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

33,749 characters extracted from source content.

Expand or collapse full text

11institutetext: LTCI, Télécom Paris, Institut Polytechnique de Paris, Palaiseau, France 11email: xhevahire.ternava@telecom-paris.fr Where Did the Variability Go? From Vibe Coding to Product Lines by Regeneration Xhevahire Tërnava Abstract In vibe coding, an emerging AI-driven paradigm, an LLM generates an entire program from a natural language prompt, but what happens to the variability that traditional software engineering carefully builds into code? To answer this question, we conducted an exploratory analysis on 10 vibe coded C/C++ projects, which suggests that there is near-zero in-artifact variability, i.e., at compile and runtime. All variability decisions are resolved at a single new binding time, generation time, the moment the LLM produces the source code. Rather than treating this as a defect to fix, we propose Variability by Regeneration (VbR), to our knowledge the first product-line approach in which the LLM acts as the derivation engine, generating a purpose-built, free of dead code binary for each variant from a declarative specification, while a variant dispatcher transparently routes user requests to the matching binary. We formalise VbR, contrast it with classical SPL derivation, and demonstrate its full pipeline on a wc product family. For SPL engineering, variability in AI-generated software belongs in the specification, not in the code. 1 Introduction The ability to configure, extend, and customise a software system for different contexts, what is known in the literature as software variability, is a central concern of software engineering [10]. Over four decades, the field has built a rich set of approaches and tools to implement and manage variability systematically, e.g., feature models [22], variation points, as embeded choices in code [14], and product derivation mechanisms [32]. Across these techniques, one principle has been constant, namely variability should be planned and in-artifact, realised through explicit mechanisms that make configuration and evolution tractable. A recent shift in how software is produced is challenging this principle. In February 2025, Karpathy coined the term “vibe coding” to describe an ongoing development approach in which users describe their intent in natural language and delegate implementation entirely to an AI tool, such as Cursor, Claude, or Copilot [23]. The approach has spread rapidly, motivated by speed and accessibility [15], reframing the developer’s role from implementer to intent mediator [28]. Yet, no study has examined what happens to variability when a system is vibe coded, from the perspective of software product line (SPL) engineering. Our starting observation, detailed in Section˜2, is that vibe coded systems tend to exhibit near zero in-artifact variability at every binding time. All variability decisions are effectively frozen at what we call generation time, i.e., the moment the LLM produces the source code. Rather than viewing this absence of variability as a problem to fix, for instance by teaching LLMs to emit #ifdef guards, we propose Variability by Regeneration (VbR), an approach that embraces zero-variability code [41] as the intended output and manages variability entirely outside the code artefact. In VbR, the developer declares a product family, i.e., features, variant configurations, and binding times, in a single specification. Then, an LLM generates a purpose-built binary for each software variant, and a dispatcher transparently routes user requests to the matching binary. This paper contributes VbR, a formally defined product-line approach that, to our knowledge, is the first designed for AI-generated software, using the LLM as the derivation engine and introducing generation time as a new binding time, together with a replication package 111Replication package: https://doi.org/10.5281/zenodo.20730698 containing the complete application pipeline of VbR on the wc product family, and the data of our exploratory analysis. VbR is admittedly a controversial proposal, but one worth discussing, and we are explicit about the limitations (cf. Section˜3.4) that currently bound it. Section˜2 provides background and motivation, Section˜3 introduces and formalises VbR, Section˜4 presents related work, and Section˜5 concludes. 2 Background and Motivation Vibe Coding as a Paradigm Shift. While most AI-assisted development keeps the human in the authoring loop, vibe coding [23] is qualitatively different. The LLM replaces the entire act of programming, as the user simply describes a system in natural language and receives a complete, runnable program. Since early 2025, thousands of self-identified vibe coded repositories have appeared on GitHub [15, 17], and empirical studies report that practitioners treat the resulting code as disposable, to be accepted or regenerated rather than maintained [9, 31]. Although only about 15% of professional developers currently practise vibe coding [34], the code it produces is already deployed as real software [15, 36, 43]. The Variability Gap. A growing body of work assesses the quality of AI-generated code, identifying overlooked reuse opportunities [19], unnecessary functions [42], elevated defect rates [11], and hidden technical debt [29, 31], but always at the granularity of individual programs, functions, or files. None has examined a property that is fundamental at the system level, namely software variability, realised in traditionally engineered systems through explicit mechanisms at well-defined binding times (e.g., preprocessor directives at compile time, component substitution at link time, CLI options at runtime [4, 7, 37, 39]), the very mechanisms that transform an individual program into a product family [10]. If vibe coded systems lack them entirely, then every generated program is a single-purpose artefact and adapting it means regenerating from scratch, i.e., clone-and-own at industrial scale, the very anti-pattern SPL engineering was designed to prevent. A Motivating Observation. This paper thus starts from a question not posed before: does vibe coded software retain any in-artifact variability, or does the act of generation eliminate it? To probe it, we conducted an exploratory analysis of 10 vibe coded C/C++ projects from GitHub, spanning seven domains and two orders of magnitude in size (201 to 14,077 LoC), compared against x264, a long-lived configurable C system of 70,964 LoC [24, 27, 38]. The contrast is evident. While x264 exposes 184 CLI options and references 117 distinct preprocessor variables across 2,201 conditional-compilation directives, the 10 vibe coded projects collectively expose only 45 CLI options (median 0, with 6 of 10 exposing none) and reference just 27 preprocessor variables, none of which represents designed variability (all are incidental platform checks, math-constant fallbacks, or vendored library internals). Nor does project size explain the gap, e.g., GNU wc, roughly 800 LoC, exposes 8 CLI options and multiple conditional-compilation paths [16, 26], despite being smaller than 80% of our 10 vibe coded subjects. This whole exploratory analysis is available in our replication package. Generation Time: A New Binding Time. Traditionally, variability decisions are resolved progressively along a binding-time pipeline, from feature selection at specification time through compilation and linking to CLI options at runtime, and the delivered product retains runtime variability [7]. Based on our exploratory analysis, this pipeline collapses into a single moment we call generation time, at which, unless the developer specifies otherwise, the LLM resolves all variability decisions, yielding a fixed, single-purpose binary with no variability mechanisms (e.g., no #ifdef and no getopt()). Understanding what this means for engineering AI-generated software that practitioners can configure, reuse, and extend is the central goal of this work. 3 Variability by Regeneration (VbR) 3.1 Regenerate, Do Not Configure As motivated in Section˜2, vibe coded systems tend to have zero variability in the code artifact. We embrace this and manage variability entirely outside the codebase. In traditional software engineering, variability is expensive to implement but cheap to exploit, i.e., an organisation invests upfront effort building a shared asset base with variation points [4, 10], then derives tailored products cheaply from it. AI code generation inverts this cost structure, where generation is cheap (from the developer’s perspective), but the resulting code is already hard for humans to understand and maintain [11], and layering variation points on top makes it even harder. Instead of generating one configurable system, we therefore propose to generate many variant-specific systems, each with zero internal variability [41], and dispatch the one that fits the user’s current context, an approach we call Variability by Regeneration (VbR). In VbR, the core artefact of the product family is a feature specification, a generation pipeline, and a dispatch mechanism, so each variant is a freshly generated, purpose-built artefact containing only the code paths it needs. This design aligns with the emerging practice where tools such as Claude Code and Cursor treat persistent specification files (CLAUDE.md, .cursor/rules) as the primary artefact driving generation [3, 12]. VbR generalises this idea from rules for a single product to a specification for a family of software variants. 3.2 A Formal Description of VbR VbR consists of three components: (i) a specification S declaring features, their types and constraints, and the variant configurations; (i) a generation function G synthesising a code artefact per variant; and (i) a variant dispatcher D routing user requests to the appropriate variant. Definition 1(VbR Specification) A VbR product family is defined by a specification =⟨F,τ,,⟩S= F,τ,V,C , where F=f1,…,fnF=\f_1,…,f_n\ is a finite set of features; τ:F→bool,enum,int,stringτ:F→\bool,enum,int,string\ assigns a type to each feature; =v1,…,vmV=\v_1,…,v_m\ is a finite set of variant configurations; and ⊆F×requires,excludes×FC F×\requires,excludes\× F is a set of cross-feature constraints. Each variant configuration vj∈v_j is a partial function vj:F⇀v_j:F , with Val the union of all value domains of τ, assigning to each included feature a value. Features absent from dom(vj)dom(v_j) are excluded and generate no code. A configuration vjv_j is valid if it is (1) well-typed, (2) constraint-closed, i.e., if faf_a requires fbf_b and fa∈dom(vj)f_a (v_j), then fb∈dom(vj)f_b (v_j), and (3) conflict-free, i.e., if faf_a excludes fbf_b, they cannot both be in dom(vj)dom(v_j). Definition 2(Generation Function) Beyond the specification S, VbR relies on two additional inputs: a prompt template Π (encoding generation rules, coding conventions, and an annotation format for traceability) and a language model L (i.e., LLM). A generation function is a mapping G:×Π×→AG:S×V× × L→ A that takes a specification, a valid configuration vjv_j, a prompt template, and a language model, and produces a code artefact (a compilable software variant) AjA_j. Note that vjv_j is a variant configuration, while Aj=G(,vj,Π,)A_j=G(S,v_j, , L) is the code artefact generated from it, equipped with a traceability relation j⊆F×Loc(Aj)T_j F×Loc(A_j) recording which source locations implement each included feature. Unlike classical variant derivation, the generation function G takes no pre-existing code asset base as input, i.e., in the VbR approach, a variant is synthesised, not selected. Definition 3(Variant Dispatcher) Given the code artefacts A1,…,Am\A_1,…,A_m\ generated from the variant configurations in S, a variant dispatcher is a pair D=⟨ℳ,δ⟩D= ,δ , where ℳ:→Caps×PathM:V ×Path is a manifest mapping each variant configuration to its capability set (i.e., the features in dom(vj)dom(v_j)) and its binary path, and δ:Request→δ:Request is a dispatch function that maps a user’s feature request to the variant whose capabilities best match the request. By default, each artefact AjA_j has zero internal variability (Prop. 1), i.e., it exposes no configuration surface. Consequently, adapting the system means selecting a different artefact, so dispatch operates between programs, not within a program. The following 3 properties are generation pipeline contracts, not guarantees the LLM provides on its own. The pipeline checks each one on every artefact AjA_j, via static checks over the traceability relation jT_j and a gate that compiles and tests the artefact. Any artefact violating a contract is rejected and regenerated, so the properties hold by construction of the pipeline, not by trust in the model. Property 1(Zero Dead Code) For every valid configuration vjv_j and feature f∈Ff∈ F, if f is not included in vjv_j, then it is not present in AjA_j, i.e., f∉dom(vj)⟹∄ℓ∈Loc(Aj):(f,ℓ)∈jf (v_j) \, (A_j):(f, ) _j. That is, excluded features produce no code in the generated artefact AjA_j, not even dead code behind unreachable guards. Property 2(Traceability Completeness) For any valid configuration vjv_j and included feature f∈dom(vj)f (v_j), there must be at least one source code location in AjA_j that implements f: f∈dom(vj)⟹∃ℓ∈Loc(Aj):(f,ℓ)∈jf (v_j) ∃\, (A_j):(f, ) _j. Together with Prop. 1, this guarantees a bijective correspondence between specification and code. Every specified feature f is in the code, and nothing in the code is without a specified f, a mapping that both the dispatcher and evolution rely on. Property 3(Binding Time Flexibility) Let =gen,compile,link,…,rtBT=\gen,compile,link,…,rt\ be the set of binding times, from generation time to runtime. Each variant configuration vjv_j may be extended with a binding annotation, that assigns a binding time to each included feature, i.e., βj:dom(vj)→ _j:dom(v_j) . When βj _j is omitted, the default βj(f)=gen _j(f)=gen applies, i.e., the variant is a fixed, zero-variability product. Then, the same feature f may have βj(f)=gen _j(f)=gen in one variant and βk(f)=rt _k(f)=rt in another. In classical SPL, binding time is a consequence of the chosen implementation mechanism, whereas in VbR it is a design decision per feature per variant, declared in the specification S and enforced by the generator G. Contrast with Classical SPL. In the standard SPL framework, a product line is a triple (,,d)(FM,A,d), i.e., a feature model FM defining valid configurations, an asset base A of implementation artefacts with embedded variation points, and a derivation function d:2F×→Pd:2^F×A→ P that selects and composes artefacts into a product. Crucially, A pre-exists, i.e., every variation point and every feature interaction is encoded in the asset base before any product is derived. VbR, in contrast, has no asset base. The specification S is the only persistent artefact, and code is a regenerated by-product of G. This is why we deliberately call the result a product family rather than a product line. Products are not derived from a shared asset base, with no guarantee of code-level commonality across variants. In short, classical SPL maintains code and derives products by selection, whereas VbR maintains only the specification and derives products by synthesis. Fig.˜1 illustrates the VbR pipeline end-to-end, instantiated next on a concrete example. Figure 1: The VbR pipeline instantiated for the wc product family. 3.3 Instantiating VbR: The wc Product Family To demonstrate VbR, we use the Unix wc (word count) utility [16], simple to show in full yet rich on variability. Its implementation is in the replication package.222The vbr-demo/ directory of the replication package. Specification. The top of Fig.˜1 shows the specification S (Def.˜1), a single YAML file (wc.v1.yaml) declaring the feature space F, constraints C, and all variant configurations V. The wc family has six features, four booleans and two enums, with one constraint (longest_line requires count_lines). wc.v1.yaml and the prompt template generate_variant.md are the only two files written by hand. Configuration and Binding Times. The three variant configurations are defined in the same YAML file, each as a partial function vjv_j (Def.˜1) that selects feature values and assigns binding times. The configuration boxes in Fig.˜1 show the key design decisions. By convention, every feature, included or not, is explicitly listed per variant (Prop. 1). Hence, an excluded feature is set to false (e.g., count_words: false in wc-minimal), signalling the generator to produce no code for it. As for the feature constraints, they are checked by a YAML-parsing script before the LLM is invoked. Binding times are chosen per variant (Prop. 3). For instance, the count_lines in wc-standard is bound at runtime (b=rtb=rt) and exposed as -l, whereas in wc-minimal it is bound at generation time (b=genb=gen), meaning that it is always enabled, requiring no flag parser. Generation. For each variant, the generation function G (Def.˜2) feeds the specification S (wc.v1.yaml), the configuration vjv_j (e.g., wc-minimal), and the prompt template Π (generate_variant.md) to an LLM (Claude Opus 4 here) and obtains a self-contained wc.c file per variant. Each variant includes only the features its configuration specifies, with no dead code, where binding is at generation time, and runtime variation points only where late binding is requested (e.g., wc-standard). The generator also emits @feature annotations tracing every code element back to its feature (Prop. 2), shown as dashed arrows in Fig.˜1. Variant Dispatch. After generation and compilation, the family consists of three standalone binaries, which the variant dispatcher D=⟨ℳ,δ⟩D= ,δ (Def.˜3) exposes as a single wc command. Its two components are specific to the wc family: the manifest ℳM (manifest.yaml) which encodes priority-ordered dispatch rules mapping usage patterns to binaries, and the dispatch function δ, a shell script (dispatch.sh), parses the user’s command line, evaluates the rules top-down, and exec()s the matching binary. For example: ⬇ $echo "hello world" | wc # dispatches to wc-minimal $wc -l -w report.txt # dispatches to wc-standard The user never names a variant. The dispatcher infers it from the flags and input mode. This inverts BusyBox’s [6] bundling of many utilities into one binary. 3.4 Discussion: Evolution, Applicability, and Limitations VbR targets the developer profile that vibe coding attracts [15, 23], i.e., practitioners who generate entire programs from prompts, bridging this workflow with the disciplined variability management a product family requires [4, 32]. Evolution Through Specification Change. Adding or removing a feature is a one line change in the specification, in which case only the affected variant will be regenerated. In our demonstration, enabling longest_line in wc-standard required a single edit to wc.v1.yaml (blue dashed arrow in Fig.˜1). Prop. 1 guarantees the regenerated variant contains zero dead code, the @feature annotations (Prop. 2) identify which code locations a change affects, the specification, versioned in a VCS, serves as the evolution log, and a compilation and test gate, with per-feature acceptance tests optionally declared in S, checks each regeneration for regressions. For larger variants, VbR also envisions an anchored regeneration mode (purple dash-dot arrows in Fig.˜1), where the existing variant code plus the specification diff yield a targeted update rather than a full rewrite. When the specification is pinned to a version and the model is held fixed, this mode also handles bug fixing, since a fix becomes a localized and reproducible regeneration of the affected variant rather than a fresh synthesis, so unrelated code does not drift. This mode was not exercised for the illustrative wc product family. Limitations. VbR inherits the limitations of its generator (G). Namely, LLM output is non-deterministic and may introduce subtle bugs or insecure idioms [11], and it offers no formal correctness guarantee. Prompt safety rules and post-generation analysis and test gates mitigate but do not eliminate this. Secondly, VbR sacrifices code reuse across variants, as two variants including the same feature may receive different implementations [29], a deliberate trade-off for smaller, focused binaries, but a bug fix in one variant does not automatically propagate. Thirdly, our evaluation is limited to one small product family. Scaling to tens of variants, and measuring generation cost, LLM consistency, and dispatcher overhead, remain open. Finally, verification of the three VbR properties is currently manual. Automating it in the pipeline is necessary for production use. 4 Related Work Variability is a central concern in SPL engineering [4, 32], studied through many aspects, such as preprocessor usage in C/C++ systems [25], industrial modelling practices [5], binding-time taxonomies [7, 13, 37], and traceability techniques [21, 40]. Whether AI generated code exhibits these patterns has, to our knowledge, not been systematically studied, as we did in the exploratory study. LLM-generated code has been studied e.g., for functional quality [8], security vulnerabilities [30], and recurring bugs [20]. These works address correctness, whereas we examine architectural variability, a design-level property they do not capture. On the other hand, vibe coding [23] has attracted growing empirical investigation [9, 15, 28, 31]. We complement these works by examining its variability implications and responding with a constructive, product-line approach. Acher et.al., [1] showed that LLM-based assistants help implement variability mechanisms, whereas VbR removes them altogether. Stümpfle et.al., [35] and Acher et.al., [2] used LLMs to re-engineer cloned variants into an SPL, the reverse direction of VbR. Both assume a single variable code base as the end-state. Greiner et.al., [18] envisioned GAI-assisted automation in variability-intensive systems. VbR is a concrete instantiation of it, but eliminates variability mechanisms rather than automating their management. Zine et.al., [44] applied LLMs to co-evolve configurable systems when features change. In VbR, this means updating the specification and regenerating. Sonkin and Tudose [33] proposed regeneration-and-rollback workflows, but for single-program automation with no notion of features. In contrast, VbR generates zero-variable systems where each variant contains exactly the code it needs, managing the family through a shared specification and serving each variant through a dispatcher. 5 Conclusion and Future Work Vibe coding moves variability out of the code and into the prompt. Rather than treating this as a problem to fix, we proposed and formalised Variability by Regeneration (VbR), to our knowledge the first product line approach designed for AI-generated software. In VbR, variability lives in a declarative specification, and each variant is a freshly generated, purpose-built binary with no dead code (i.e., no variability branches) and full traceability, as we demonstrated on a real (wc) product family with six features and three variants. Central to VbR is generation time, the new binding time at which the LLM resolves every variability decision before any source code exists, a shift our exploratory analysis of 10 vibe coded projects suggests is already common in practice. Future Work. Our immediate next step is an empirical study of in-artifact variability in vibe coded systems, across more languages and domains. We then plan to scale VbR to tens of variants, automate property verification, and develop anchored regeneration to cut generation cost and support in-artifact reuse. As vibe coding becomes more common, variability moves from the artefact to the specification. VbR is a first step towards PLs built entirely on that shift. References [1] M. Acher, J. A. G. Duarte, and J. Jézéquel (2023) On programming variability with large language model-based assistant. In Proc. SPLC, p. 8–14. External Links: Document Cited by: §4. [2] M. Acher and J. Martinez (2023) Generative AI for reengineering variants into software product lines: an experience report. In Proc. SPLC, p. 57–66. External Links: Document Cited by: §4. [3] Anthropic (2025) How Claude remembers your project: CLAUDE.md files. Note: Claude Code Documentation External Links: Link Cited by: §3.1. [4] S. Apel, D. Batory, C. Kästner, and G. Saake (2013) Feature-oriented software product lines: concepts and implementation. Springer. External Links: Document Cited by: §2, §3.1, §3.4, §4. [5] T. Berger, D. Nair, R. Rublack, J. M. Atlee, K. Czarnecki, and A. Wąsowski (2014) Three cases of feature-based variability modeling in industry. p. 302–319. External Links: Document Cited by: §4. [6] BusyBox (2024) BusyBox: the Swiss army knife of embedded Linux. Note: Online software External Links: Link Cited by: §3.3. [7] R. Capilla and J. Bosch (2013) Binding time and evolution. In Systems and Software Variability Management: Concepts, Tools and Experiences, R. Capilla, J. Bosch, and K. C. Kang (Eds.), p. 57–73. External Links: Document Cited by: §2, §2, §4. [8] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. de Oliveira Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman, et al. (2021) Evaluating large language models trained on code. External Links: 2107.03374, Document Cited by: §4. [9] Y. Chou, B. Jiang, Y. W. Chen, M. Weng, V. Jackson, T. Zimmermann, and J. A. Jones (2026) Building software by rolling the dice: A qualitative study of vibe coding. In Proc. ESEC/FSE, External Links: Document Cited by: §2, §4. [10] P. Clements and L. Northrop (2001) Software product lines: practices and patterns. Addison-Wesley. External Links: ISBN 978-0-201-70332-0 Cited by: §1, §2, §3.1. [11] D. Cotroneo, C. Improta, and P. Liguori (2025) Human-written vs. AI-generated code: A large-scale study of defects, vulnerabilities, and complexity. In Proc. ISSRE, p. 252–263. External Links: Document Cited by: §2, §3.1, §3.4. [12] Cursor Inc. (2025) Rules: system-level instructions for Agent. Note: Cursor Documentation External Links: Link Cited by: §3.1. [13] K. Czarnecki and U. W. Eisenecker (2000) Generative programming: methods, tools, and applications. Addison-Wesley. External Links: ISBN 978-0-201-30977-5 Cited by: §4. [14] K. Czarnecki, P. Grünbacher, R. Rabiser, K. Schmid, and A. Wąsowski (2012) Cool features and tough decisions: A comparison of variability modeling approaches. In Proc. 6th International Workshop on Variability Modelling of Software-Intensive Systems (VaMoS), p. 173–182. External Links: Document Cited by: §1. [15] A. Fawzy, A. Tahir, and K. Blincoe (2025) Vibe coding in practice: motivations, challenges, and a future outlook–a grey literature review. External Links: 2510.00328, Document Cited by: §1, §2, §3.4, §4. [16] Free Software Foundation (2026) GNU coreutils: core GNU utilities. Free Software Foundation. Note: Version 9.10 External Links: Link Cited by: §2, §3.3. [17] GitHub (2025) Octoverse: a new developer joins GitHub every second as AI leads TypeScrip to#1. Note: Accessed: 2025-12-11. September 2024–August 2025 data External Links: Link Cited by: §2. [18] S. Greiner, K. Schmid, T. Berger, S. Krieter, and K. Meixner (2024) Generative AI and software variability–A research vision. In Proc. VaMoS, p. 71–76. External Links: Document Cited by: §4. [19] H. Huang, P. Jaisri, S. Shimizu, L. Chen, S. Nakashima, and G. Rodríguez-Pérez (2026) More code, less reuse: investigating code quality and reviewer sentiment towards AI-generated pull requests. In Proc. MSR, Note: To appear External Links: Document Cited by: §2. [20] K. Jesse, T. Ahmed, P. T. Devanbu, and E. Morgan (2023) Large language models and simple, stupid bugs. In Proc. MSR, p. 563–575. External Links: Document Cited by: §4. [21] W. Ji, T. Berger, M. Antkiewicz, and K. Czarnecki (2015) Maintaining feature traceability with embedded annotations. In Proc. SPLC, p. 61–70. External Links: Document Cited by: §4. [22] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson (1990) Feature-oriented domain analysis (FODA) feasibility study. Technical report Technical Report CMU/SEI-90-TR-021, Software Engineering Institute. External Links: Document Cited by: §1. [23] A. Karpathy (2025-02) Vibe coding. Note: X (Twitter) External Links: Link Cited by: §1, §2, §3.4, §4. [24] L. Lesoil, M. Acher, A. Blouin, and J. Jézéquel (2021) The interaction between inputs and configurations fed to software systems: an empirical study. CoRR abs/2112.07279. Note: Journal reference: Journal of Systems and Software, 2023 External Links: 2112.07279, Document Cited by: §2. [25] J. Liebig, S. Apel, C. Lengauer, C. Kästner, and M. Schulze (2010) An analysis of the variability in forty preprocessor-based software product lines. In Proc. ICSE, p. 105–114. External Links: Document Cited by: §4. [26] D. Luu (2020) The growth of command line options, 1979–present. Note: https://danluu.com/cli-complexity/ Cited by: §2. [27] L. Merritt and R. Vanam (2006) X264: A high performance H.264/AVC encoder. Note: Online software External Links: Link Cited by: §2. [28] C. Meske, T. Hermanns, E. von der Weiden, K. Loser, and T. Berger (2025) Vibe coding as a reconfiguration of intent mediation in software development: definition, implications, and research agenda. IEEE Access 13, p. 213242–213259. External Links: Document Cited by: §1, §4. [29] T. Mikkonen and A. Taivalsaari (2025) Software reuse in the generative AI era: from cargo cult towards systematic practices. In Proc. Internetware, p. 541–544. External Links: Document Cited by: §2, §3.4. [30] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri (2022) Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions. In Proc. IEEE Symposium on Security and Privacy (SP), p. 754–768. External Links: Document Cited by: §4. [31] V. Pimenova, S. Fakhoury, C. Bird, M. Storey, and M. Endres (2025) Good vibrations? A qualitative study of co-creation, communication, flow, and trust in vibe coding. External Links: 2509.12491, Document Cited by: §2, §2, §4. [32] K. Pohl, G. Böckle, and F. J. van der Linden (2005) Software product line engineering: foundations, principles, and techniques. Springer. External Links: Document Cited by: §1, §3.4, §4. [33] V. Sonkin and C. Tudose (2025) Beyond snippet assistance: A workflow-centric framework for end-to-end AI-driven code generation. Computers 14 (3), p. 94. External Links: Document Cited by: §4. [34] Stack Overflow (2025) Stack overflow developer survey 2025. Note: Online49,000+ responses from 177 countries External Links: Link Cited by: §2. [35] C. Stümpfle, S. Atray, N. Jazdi, and M. Weyrich (2025) Large language model assisted transformation of software variants into a software product line. In Proc. ICSR, p. 12–20. External Links: Document Cited by: §4. [36] Superultra Inc. (2025) Superwhisper: AI voice-to-text for macOS, Windows, and iOS. Note: https://superwhisper.com/ Cited by: §2. [37] M. Svahnberg, J. van Gurp, and J. Bosch (2005) A taxonomy of variability realization techniques. Software—Practice and Experience 35 (8), p. 705–754. External Links: Document Cited by: §2, §4. [38] X. Tërnava, M. Acher, and B. Combemale (2023) Specialization of run-time configuration space at compile-time: an exploratory study. In SAC SE Symposium, Note: HAL Id: hal-03916459 Cited by: §2. [39] X. Tërnava and P. Collet (2017) On the diversity of capturing variability at the implementation level. In Proc. SPLC (Volume B), p. 81–88. External Links: Document Cited by: §2. [40] X. Tërnava and P. Collet (2017) Tracing imperfectly modular variability in software product line implementation. In Proc. ICSR, p. 112–120. External Links: Document Cited by: §4. [41] X. Tërnava, G. A. Randrianaina, L. Lesoil, and M. Acher (2025) Small yet configurable: unveiling null variability in software. Note: HAL preprintHAL Id: hal-05097580 External Links: Link Cited by: §1, §3.1. [42] K. Watanabe, T. Shirai, Y. Kashiwa, and H. Iida (2026) What to cut? Predicting unnecessary methods in agentic code generation. External Links: 2602.17091, Document Cited by: §2. [43] P. Yang (2025-03) Vibe coding a zombie survival FPS with Cursor + Sonnet 3.7 + Superwhisper. Note: X (Twitter) External Links: Link Cited by: §2. [44] M. Zine, C. Quinton, and R. Rouvoy (2025) LLM-based co-evolution of configurable software systems. In Proc. SPLC, p. 27–38. External Links: Document Cited by: §4.

Instant research discovery