Evaluating Real Full-Stack Delivery in Open-Source LLMs: From Benchmarks to Runnable Systems

1. Beyond Benchmarks: Why “What It Can Actually Deliver” Matters More

When a new model is released, benchmark leaderboards are usually the first thing people discuss. Scores across reasoning, software engineering, terminal coding, and general evaluation do reflect relative model capability. But for developers on the ground, the deciding question is far more practical: if you hand the model a task, can it deliver something that runs and can be verified?

This article sets benchmarks aside and focuses on delivery. We use a consistent prompt structure to drive model agents through three complete site builds: a booking website for a commercial spaceflight company, a science communication site for a deep-sea research institute, and a showcase page for a luxury fragrance brand. We then examine the output quality layer by layer. These three cases were chosen because they map to three distinct capability combinations: business logic and data persistence, structured presentation of scientific content, and high-fidelity visual and layout control. Together, they cover most of the main challenges in enterprise front-end delivery.

2. Method: How a Single Prompt Drives Full-Stack Output

2.1 Structuring the Prompt

To get deliverable results, a prompt cannot be an open-ended instruction like “build me a website.” In practice, a more effective approach is to organize constraints by layer:

[Role]           You are a full-stack engineer and visual designer
[Business goal]  Build a brand website for a client in the XX industry
[Information architecture]  Hero section / narrative section / functional section / footer
[Interaction requirements]  Seat selection, date filtering, form validation
[Data requirements]  Booking record persistence, per-flight capacity limit, automatic locking
[Visual direction]  Color, typography, motion rhythm, asset style
[Delivery format]  Runnable full-stack project with front end and back end

The value of this format is that it separates aesthetics from engineering into individually verifiable items. The model can align with each item during generation, and reviewers can verify each one during acceptance. This avoids the classic problem of a beautiful page with buttons that do not work.

2.2 Where Visuals and Code Couple

One easily overlooked detail is the strong coupling between visual assets and interactive components. For example, a cabin selection diagram must be an interactive vector graphic. Each seat must be an independently clickable element linked to back-end inventory state. This means the model cannot simply generate a good-looking image. It must generate a structured graphic with identifiers, states, and event bindings. This is the key dividing line between a demo page and a deliverable system.

3. Case One: Commercial Spaceflight Website — A Full-Stack Litmus Test

3.1 Hero Section and Narrative Layer

The hero section uses a full-screen video background simulating a cabin-window view. The Earth’s arc rotates slowly, with a cool glow along the atmosphere’s edge. A floating flight-data panel in the lower right uses a monospace font to list orbital altitude, velocity, and remaining launch window. In the upper left, a breathing status indicator conveys that the system is live. These elements may look like visual decoration, but they carry the sense of professionalism: the monospace font suggests instrument readouts, and the breathing animation suggests a real-time system.

Scrolling down reveals a timeline-driven flight narrative, from ground preparation 60 minutes before launch through orbital insertion, high-G phases, weightlessness, and splashdown recovery. Each stage includes a key metric and a scene image. This timeline-plus-milestone structure is a common pattern for process-oriented industries such as aerospace, healthcare, and manufacturing, and it is highly reusable.

3.2 Back-End Logic: The Part That Actually Runs

The core of the booking system is not in the interface but in its constraints. In this case, the rules include:

• Dates must be filterable, showing only flights with available seats.
• The seat map must reflect inventory in real time, with occupied seats unavailable.
• Each flight has a fixed seat limit. Once full, the flight is automatically locked and new bookings are rejected.
• Passenger information must be written to persistent storage and survive a page refresh.

Implementation typically requires using the seat number as a primary key with a uniqueness constraint, handling concurrent seat selection with transactions or atomic operations, and using a database unique index as a backstop against overselling. Pseudocode:

function reserve(flightId, seatId, passenger):
    begin transaction
        if count(flightId) >= CAPACITY: raise FlightFull
        if exists(flightId, seatId):   raise SeatOccupied
        insert(flightId, seatId, passenger)
    commit
    return BookingSuccess

Whether the model can independently produce an implementation with transaction boundaries and uniqueness constraints is a hard indicator of genuine full-stack capability. A solution with working front-end interactions but in-memory back-end variables is demo-grade output and has no delivery value.

4. Case Two: Deep-Sea Research Site — Structuring Scientific Content

The second case shifts the difficulty from logic to information organization. The hero shot descends vertically from the surface. At the waterline, the frame separates into layers, with a gradient from light blue to deep blue, and two small warm lights in the distance indicate the submersible’s position. This kind of transition requires a high level of visual description precision. The prompt must explicitly specify layer separation, gradient direction, and light source positions.

The content layer requires parameter cards for three submersibles, with details down to propulsion type and observation window size. Six deep-sea species each occupy a full screen. A field notes section contains three articles attributed to three contributors with different roles. The engineering value here lies in presentation consistency across structured data: the same fields must align across different cards, with consistent units, precision, and field order. Otherwise the page looks chaotic.

From an engineering perspective, this type of site is best implemented as a data-driven view. Species, equipment, and articles are abstracted into data collections, and the view layer renders them uniformly. Later content additions then require only data changes rather than template changes. If the model adopts this structure on its own, it demonstrates a basic awareness of maintainability.

5. Case Three: Luxury Brand Showcase — A Stress Test for Visual Fidelity

The third case is almost purely a test of aesthetic control. An amber perfume bottle sits on a marble surface. The liquid inside rotates slowly, with light passing through the glass to form caustic textures. The brand name is overlaid on the bottle in a serif typeface. Achieving this effect requires simultaneous control of material, lighting, typography, and layout.

The key conclusion is that the success of visual tasks often depends on how precisely the prompt describes physical correctness. Saying “premium feel” will not produce caustics. You must describe the light source angle, medium refraction, and surface roughness as actionable visual parameters. This points to a broader lesson: translating subjective aesthetics into objective, executable descriptions is a core skill when working with these capabilities.

6. Capability Boundaries and a Verification Checklist

Across the three cases, a practical evaluation framework emerges:

1. Runnability: Is the back end truly persistent rather than simulated in memory? Are capacity limits enforced under concurrency?
2. Consistency: Are fields of the same type aligned? Are design specifications applied consistently across all pages?
3. Maintainability: Does it use a data-driven structure? Are components reusable?
4. Accessibility: Do interactive elements have semantic labels and keyboard-accessible paths? Can animations be disabled?
5. Security and compliance: Does the form include input validation and server-side revalidation? Are internal error details exposed?

It is important to recognize that these capabilities are good at rapidly producing structure and first drafts. Production environments still require human engineers to add authentication, rate limiting, logging, monitoring, and error tracking. The reasonable positioning is as an efficient first-version generator and structural drafting tool, not as a final deliverable that can bypass review.

7. Conclusion

The gap between “scores well” and “can do the job” is not measured in benchmark points. It is measured by engineering closure: whether data persists, whether constraints hold, whether visuals and interactions couple correctly, and whether the output can be maintained. The three cases point to the same answer: when prompts express business rules and visual parameters in a structured way, model agents are already capable of independently completing the full chain from brand visuals to a runnable back end. For developers, the real competitive edge is no longer whether you can call such capabilities, but whether you can break down requirements into constraints the model can execute precisely.