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

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.

• The paper demonstrates that traditional in-code variability can be replaced by a specification-centric regeneration approach leveraging LLM synthesis to produce custom binaries.
• It formalizes VbR with key properties—zero dead code, complete traceability, and flexible binding times—validated through a Unix wc product family case study.
• The study highlights practical benefits like reduced technical debt and focused evolution, while noting challenges in LLM nondeterminism and manual verification.

Formal Analysis of Variability by Regeneration in Vibe Coding

Motivation and Background

Vibe coding, characterized by LLM-driven program synthesis from natural language prompts, constitutes a paradigm shift for software engineering. Traditional software product line (SPL) engineering relies on explicit, in-artifact variability mechanisms: feature models, variation points, conditional compilation, and runtime configuration. These mechanisms enable systematic customization, reuse, and configurability across product families [apel2013feature] [clements2001software]. The paper identifies that in vibe coding, these mechanisms are absent; all variability is resolved at "generation time," the moment the LLM emits the code. Empirical analysis across 10 vibe coded C/C++ repositories demonstrates a marked reduction in runtime and compile-time variability relative to classical configurable systems—often approaching zero (cf. exploratory comparison against x264 and GNU wc).

This phenomenon raises fundamental questions for SPL practice: adapting vibe coded systems entails regenerating a bespoke artifact, not configuring or extending an existing code base. Rather than treating this lack of in-code variability as a deficiency, the paper frames it as an opportunity for a new engineering paradigm.

Variability by Regeneration (VbR): Approach and Formalization

VbR proposes a radical rethinking of product-line derivation. Instead of embedding variability and selection mechanisms in code, the entire product family is defined declaratively as a specification. The LLM acts as an overview engine, generating a dedicated binary for each variant, with a dispatcher routing user requests to the appropriate executable. The pipeline comprises:

• Specification $\mathcal{S}$: Declares features, types, constraints, and variant configurations (including binding times).
• Generation Function $G$: Maps $\mathcal{S}$, a variant configuration $v_j$, a prompt template, and a LLM $\mathfrak{L}$ to an artifact $A_j$. Each generated artifact embodies exactly the requested features, aligned with explicit type and constraint rules.
• Variant Dispatcher $D$: Manages a manifest mapping variants to capabilities and binary paths, and implements dispatch logic based on user request semantics.

Three key formal properties are central:

• Zero Dead Code (Prop. 1): Excluded features yield no code—even behind conditional guards.
• Traceability Completeness (Prop. 2): Every included feature maps to at least one source location; code features and specification features are bijectively mapped.
• Binding Time Flexibility (Prop. 3): Each feature's binding time can be independently annotated per variant, enabling generation time, runtime, or other bindings.

In contrast to classical SPLs—which derive products from pre-existing code assets with embedded variability—VbR synthesizes each variant anew, maintaining only the declarative specification and eschewing code-level reuse.

Figure 1: The VbR pipeline instantiated for the wc product family.

Practical Demonstration: wc Product Family

The VbR pipeline is demonstrated via the Unix wc utility, leveraging a YAML specification for features (counts, constraints) and three variant configurations (minimal, standard, extended). The generation function uses Claude Opus 4 as the LLM and a hand-authored prompt template to synthesize each variant as a dedicated binary, annotated for feature traceability. The dispatcher parses invocation semantics and routes to the matching binary automatically, decoupling user interaction from platform variability (see Figure 1).

Key points:

• Feature addition/removal is a one-line specification change, triggering regeneration only for affected variants.
• Full traceability is provided via code annotations.
• Manual verification of zero dead code, traceability, and binding time is enforced in the pipeline (not by LLM guarantees).

Discussion: Implications and Limitations

Theoretical Implications

VbR moves SPL variability entirely into the declarative specification, resulting in artifacts devoid of internal configuration surfaces. This inverts the classical SPL cost structure: generation is cheap, and each artifact is singularly focused and free of dead code. This shift is notable for traceability and reproducibility; bug fixes and feature additions correspond to localized specification changes and targeted regeneration. However, in-artifact reuse is intentionally sacrificed—distinct variants may implement identical features differently; cross-variant propagation of bug fixes or optimizations is not automatic.

Practical Implications

• Reduced Technical Debt: Regenerated artifacts contain only the required code paths, mitigating traditional concerns of dead code and unused features.
• Specification-Centric Evolution: Version control and evolution are concentrated in the specification, not code assets.
• Dispatcher Overhead: User requests are transparently handled, but scaling to tens or hundreds of variants may raise operational overheads.
• Quality Assurance: Non-determinism in LLM synthesis introduces risks of inconsistent outputs, subtle defects, and absence of formal guarantees. Automated gates mitigate but do not eliminate this.

Limitations

• Model Trust: LLM output is subject to nondeterminism and may diverge from specification intent.
• Lack of Code Reuse: For large variant spaces, fix propagation is manual.
• Manual Verification: Current property verification (dead code, traceability, binding time) is not automated.
• Scope: Demonstration limited to a small product family; scalability, cost, and generalization are open research questions.

Related Work

VbR is distinct from prior approaches that use LLMs to assist variability implementation [acher2023programming], reengineer variants into SPLs [acher2023reengineering] [stumpfle2025llm], or automate management of existing variability-intensive systems [greiner2024vision]. Unlike these, VbR eliminates variation points entirely, focusing on specification-driven synthesis. Existing work on LLM-generated code addresses correctness and vulnerability, but does not analyze architectural variability.

Conclusion

VbR redefines SPL engineering for LLM-centric software development by relocating variability from code artifacts to declarative specifications, with synthesis and dispatch taking the place of traditional configuration and selection. Strong formal guarantees (zero dead code, traceability completeness, binding time flexibility) align the pipeline with specification-centric evolution. The approach is practically viable for systems with manageable variant spaces and aligns with emergent vibe coding workflows. Challenging open questions include scaling, automated verification, model consistency, and code reuse. As LLM-driven software generation becomes ubiquitous, paradigm shifts in variability management—such as VbR—will reshape both the theory and practice of product line engineering.