💻 computer science

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

This paper proposes "Variability by Regeneration" (VbR), a novel software product line approach where an LLM acts as a derivation engine to generate purpose-built, dead-code-free binaries at generation time based on declarative specifications, effectively shifting variability management from the code itself to the specification in the era of AI-driven "vibe coding."

Original authors: Xhevahire Tërnava

Published 2026-06-19

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Xhevahire Tërnava

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Problem: The "Magic" Code That Can't Change

Imagine you hire a super-talented chef (an AI) to cook you a meal. You tell them, "I want a spicy pasta." They instantly cook a perfect, steaming plate of spicy pasta.

Now, imagine you want to change your mind and say, "Actually, make it mild." In traditional cooking, you would just ask the chef to adjust the spices. But in this new style of cooking (called "Vibe Coding"), the chef doesn't just adjust the spices; they throw the whole plate away and cook a brand new plate from scratch based on your new request.

The problem is that the first plate of spicy pasta is now useless to you. You can't turn it into mild pasta. It's a "single-purpose" artifact. If you want a different version of the software, you have to ask the AI to generate a completely new file every time.

The Discovery: Where Did the "Options" Go?

The researchers looked at 10 different software projects created this way. They found something surprising: The "options" disappeared.

In old-school software, the code is like a Swiss Army knife. It has a blade, a screwdriver, and a corkscrew all built in. You just flip the switch (a setting) to use the tool you need. The code contains all the tools, even the ones you aren't using right now.

But in "Vibe Coding," the AI doesn't build a Swiss Army knife. It builds a single-purpose tool.

If you asked for a knife, the AI builds a knife.
If you asked for a screwdriver, the AI builds a screwdriver.
The "knife" version has no screwdriver parts inside it, and the "screwdriver" version has no knife parts.

The researchers call this "near-zero variability." All the decisions about what the software is are made the exact moment the AI writes the code. Once the code is written, it's frozen. There are no switches left to flip.

The Solution: "Variability by Regeneration" (VbR)

Instead of trying to force the AI to build a giant, complex Swiss Army knife (which makes the code messy and hard to understand), the authors propose a new way to handle this called Variability by Regeneration (VbR).

Think of it like a Custom Suit Shop vs. a Department Store.

The Old Way (Department Store): You buy a suit that has extra fabric sewn in, buttons you don't need, and pockets you'll never use, just so you can "configure" it later. It's heavy and full of dead weight.
The VbR Way (Custom Suit Shop): You have a Master Blueprint (a specification).
1. You tell the shop: "I need a suit for a wedding."
2. The AI (the tailor) looks at the blueprint and instantly sews a perfect, lightweight suit just for that wedding. It has no extra fabric.
3. Later, you say, "I need a suit for a beach party."
4. The AI doesn't try to cut the wedding suit down. It looks at the blueprint again and sews a brand new, perfect beach suit.

In this system, the "variability" (the ability to have different suits) doesn't live in the clothes themselves. It lives in the Blueprint.

How It Works in Practice

The paper demonstrates this with a classic computer tool called wc (which counts words in a file).

The Blueprint: The developer writes one simple file (a YAML file) that lists all the possible features: "Count lines," "Count words," "Count characters," etc.
The Generation: When a user wants a specific version (e.g., "I just want to count lines"), the AI reads the blueprint, sees that request, and generates a tiny, super-fast program that only does that one thing.
The Dispatcher (The Waiter): Since the AI made three different programs (one for lines, one for words, one for everything), how does the computer know which one to run?
- The researchers built a "Waiter" (a dispatcher).
- You type a command. The Waiter looks at your command, checks the menu (the manifest), and instantly runs the specific program that matches your request.
- You, the user, never see the different programs. You just see one tool that magically changes its behavior.

Why This Matters

The authors argue that we shouldn't try to fix "Vibe Coding" by forcing the AI to put "switches" back into the code. That defeats the purpose of the new technology.

Instead, we should accept that the code is meant to be disposable and specific.

Old Way: Keep one big, messy code file with all the options hidden inside.
New Way (VbR): Keep one clean specification file (the rules), and let the AI generate a fresh, perfect, "dead-code-free" program every time you need a different version.

Summary

The paper claims that in the age of AI coding, we have lost the ability to "tweak" a single program. Instead, the AI creates a new program for every need. The authors propose we embrace this by treating the rules (specification) as the permanent master, and the code as a temporary, perfect product that is regenerated whenever the rules change. It's not about fixing the code; it's about regenerating the right code for the right job.

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

1. Problem Statement

The paper addresses a fundamental shift in software engineering caused by "vibe coding," an emerging paradigm where Large Language Models (LLMs) generate entire programs from natural language prompts. While traditional Software Product Line (SPL) engineering relies on in-artifact variability—explicit mechanisms (e.g., #ifdef, feature models, runtime flags) embedded within the code to support configuration and evolution—vibe coding appears to eliminate these mechanisms.

The authors identify a "Variability Gap":

Observation: In vibe-coded systems, variability decisions are effectively "frozen" at generation time (the moment the LLM produces the source code).
Consequence: The resulting artifacts exhibit near-zero in-artifact variability. There are no preprocessor guards, few command-line interface (CLI) options, and no runtime configuration points.
Risk: Without explicit variability mechanisms, adapting a vibe-coded system requires regenerating the entire codebase from scratch for every new configuration. This leads to an industrial-scale "clone-and-own" anti-pattern, undermining the core principles of SPL engineering which aim to manage variability systematically through shared assets.

2. Methodology

The paper employs a mixed-method approach combining exploratory empirical analysis with a formal proposal of a new engineering paradigm.

Exploratory Analysis

The authors conducted an analysis of 10 vibe-coded C/C++ projects from GitHub, spanning seven domains and sizes ranging from 201 to 14,077 Lines of Code (LoC).

Comparison: These were compared against x264, a long-lived, traditionally engineered configurable C system (70,964 LoC).
Metrics: The study measured the presence of CLI options and preprocessor variables used for designed variability.
Findings:
- x264: Exposed 184 CLI options and 117 distinct preprocessor variables across 2,201 conditional-compilation directives.
- Vibe-coded projects: Collectively exposed only 45 CLI options (median of 0; 6 out of 10 had none) and referenced only 27 preprocessor variables. Crucially, none of the variables in the vibe-coded projects represented designed variability; they were incidental (e.g., platform checks, math constants).
- Conclusion: The "pipeline" of binding times (from specification to runtime) collapses into a single generation time in vibe coding.

Proposed Solution: Variability by Regeneration (VbR)

Rather than attempting to force LLMs to emit traditional variability mechanisms (e.g., teaching them to write #ifdef), the authors propose embracing the zero-variability nature of the output. They introduce Variability by Regeneration (VbR), a product-line approach where variability is managed entirely outside the code artifact.

3. Key Contributions and Technical Framework

The VbR Paradigm

VbR inverts the traditional cost structure of variability. Instead of building a shared asset base with variation points (expensive to implement, cheap to exploit), VbR treats generation as cheap and manages variability by synthesizing distinct, purpose-built binaries for each variant.

The framework consists of three formal components:

Specification ( $S$ ): A declarative file (e.g., YAML) defining:
- A set of features ( $F$ ) with types and constraints.
- A set of variant configurations ( $V$ ), where each configuration is a partial function assigning values to features.
- Binding time annotations per feature per variant (e.g., binding a feature at generation time vs. runtime).
Generation Function ( $G$ ): An LLM-driven process that takes the specification and a specific variant configuration to synthesize a code artifact ( $A_j$ $A_{j}$ ).
- Zero Dead Code: Excluded features generate no code.
- Traceability: The generator produces annotations (e.g., @feature) linking code locations back to the specification.
- No Asset Base: Unlike classical SPL, there is no pre-existing code base; the code is synthesized from scratch for each variant.
Variant Dispatcher ( $D$ ): A mechanism that routes user requests to the correct pre-compiled binary.
- It uses a manifest mapping usage patterns (e.g., specific CLI flags or input modes) to the corresponding binary.
- The user interacts with a single command (e.g., wc), while the dispatcher transparently selects the appropriate variant (e.g., wc-minimal, wc-standard).

Formal Properties

The paper defines three "contracts" for the generation pipeline, enforced via static checks and testing gates rather than trusting the LLM alone:

Property 1 (Zero Dead Code): If a feature is excluded in the configuration, it must not appear in the generated artifact.
Property 2 (Traceability Completeness): Every included feature must have a corresponding code location, and every code location must map to a specified feature.
Property 3 (Binding Time Flexibility): Binding times (generation, compile, link, runtime) are design decisions declared in the specification, not consequences of implementation mechanisms.

Case Study: The `wc` Product Family

The authors instantiated VbR on the Unix wc (word count) utility:

Specification: Defined 6 features (e.g., count_lines, longest_line) and 3 variants (wc-minimal, wc-standard, wc-analytics).
Generation: Used an LLM (Claude Opus 4) to generate three distinct C files.
- wc-minimal: 11 lines, 0 variation points, fixed to stdin.
- wc-standard: 75 lines, 3 runtime variation points (flags -l, -w, -c).
- wc-analytics: 107 lines, recursive processing, JSON output.
Dispatch: A shell script parsed user input and executed the matching binary. For example, piping input (echo "hello" | wc) routed to the minimal binary, while using flags (wc -l -w) routed to the standard binary.

4. Results and Limitations

Results: The wc demonstration successfully showed that a product family can be maintained via a single specification file, with variants regenerated on demand. Evolution (e.g., adding the longest_line feature) required only a specification edit, triggering a targeted regeneration of the affected variant.
Limitations:
- Non-determinism: LLM outputs are not formally correct; bugs or insecure idioms may be introduced.
- Code Reuse: VbR sacrifices code reuse across variants. Two variants with the same feature may have different implementations, meaning bug fixes do not automatically propagate.
- Scalability: The evaluation was limited to one small product family. Scaling to tens of variants and measuring generation costs remain open questions.
- Verification: Currently, the verification of VbR properties (zero dead code, traceability) is manual; automation is required for production use.

5. Significance and Claims

The paper claims to present the first product-line approach designed specifically for AI-generated software. Its primary significance lies in reframing the "loss" of variability in vibe coding not as a defect to be fixed, but as a new engineering opportunity.

Shift in Binding Time: The authors argue that generation time has become a dominant binding time in AI-driven development, resolving variability decisions before source code exists.
Separation of Concerns: VbR posits that in AI-generated software, variability belongs in the specification, not in the code.
New Derivation Model: It contrasts with classical SPL (which selects and composes from a shared asset base) by proposing a model where products are synthesized from a specification, with the LLM acting as the derivation engine.

The authors conclude that as vibe coding becomes more prevalent, the engineering focus must shift from managing variability within artifacts to managing the specification and regeneration pipeline that produces them.