Full-Stack Delivery with LLM Agents: From a Single Prompt to a Runnable Website

1. Background: Beyond Benchmark Scores, the Real Question Is “What Can It Actually Deliver?”

Whenever a new generation of large language models is released, benchmark scores tend to dominate the conversation: reasoning benchmarks, coding benchmarks, terminal operation benchmarks, and so on. These metrics do reflect a model’s fundamental capabilities to some extent. But for developers, the decision to bring a model into a production workflow usually comes down to a more practical question: What kind of output can it actually deliver?

This article does not focus on benchmark performance. Instead, it takes an engineering perspective to examine a capability that is drawing increasing attention—the full-stack delivery capability of LLM agents. Full-stack delivery here means that a model can produce not just a visually appealing static page, but also interactive frontend components, working backend logic, persistent data storage, and a consistent brand identity across the entire project. To illustrate this, we use three site-building tasks with different themes and walk through the full process of requirement breakdown, prompt design, architecture selection, and implementation details.

It is worth noting that this article discusses general technical capabilities and engineering methods rather than recommending any specific platform or product.

2. Breaking Down the Full-Stack Delivery Capability Model

Before diving into implementation, it is important to clarify what “full-stack delivery” includes. A runnable, demonstrable, and deliverable site requires coordination across at least four layers:

1. Visual and Brand Layer: color systems, font selection, motion rhythm, and information hierarchy.
2. Interaction Layer: routing, form validation, component state management, and interactive vector graphics such as SVG.
3. Business Logic Layer: booking, seat selection, inventory deduction, concurrency control, and other real business rules.
4. Data Persistence Layer: storing and querying reservation records, enforcing capacity limits, and locking states.

In a traditional development process, these four layers are typically handled by different roles. In an agent-driven workflow, the model needs to keep all four layers consistent within a single task. That is exactly what makes full-stack delivery difficult—and valuable. The following three cases illustrate this in detail.

3. Case 1: Commercial Spaceflight Site—From Visual Storytelling to a Working Booking System

3.1 Requirements and Prompt Structure

The first task was to build the official website of a low Earth orbit travel company. The core functional requirements included spacecraft seat selection and flight booking. The prompt was organized into four sections: brand positioning, visual tone, feature list, and data constraints.

Role: You are a full-stack engineer and visual designer.
Brand: A low Earth orbit travel company positioned in premium commercial spaceflight.
Visual tone: Deep space black background, fluorescent cyan accent color, monospace fonts for flight parameters.
Features:
  1) Full-screen video background on the hero section, simulating the view from a spacecraft window;
  2) A vertical timeline driving the flight process narrative;
  3) Cabin selection using an interactive SVG seat map;
  4) A flight booking form with persistent data storage.
Constraints: Each flight has a maximum of 6 seats. The flight is automatically locked when fully booked.

The value of this structured prompt is that it places aesthetic requirements and engineering constraints in the same specification, preventing the model from focusing only on visuals while ignoring business rules.

3.2 Hero Section Visuals and Motion Implementation

The hero section uses a full-screen video as its background, simulating the view through a spacecraft window: Earth’s curved surface rotates slowly, with a faint blue glow along the edge of the atmosphere. In the lower right corner, a flight data panel uses a monospace font to display orbital altitude, velocity, remaining time, and other key parameters. In the upper left corner, a small fluorescent cyan dot pulses slowly to indicate system online status.

The key point for this type of atmospheric motion is restraint. Breathing animations typically work best with a period of 2 to 4 seconds, and the opacity change should stay within a moderate range to avoid distracting from the main content. This can be implemented with pure CSS:

@keyframes breathe {
  0%, 100% { opacity: 0.4; }
  50%      { opacity: 1; }
}
.status-dot {
  animation: breathe 3s ease-in-out infinite;
}

3.3 Timeline Narrative and Information Architecture

Scrolling down reveals a vertical timeline that divides the flight into several stages: ground preparation, ascent, zero gravity, re-entry, and splashdown recovery. Each stage includes a scene illustration, a key data point highlighted in orange such as g-force or duration, and a short description.

From an information architecture perspective, this is a classic linear narrative plus data anchor structure. The timeline establishes a sense of sequence, while the orange data points create memorable reference points. For implementation, a semantic ordered list combined with sticky positioning is recommended so that stage titles remain visible during scrolling.

3.4 Engineering Details of the Seat Selection and Booking System

This is the most substantial part of the case. The seat map is drawn with SVG, where each seat is a clickable graphic element. Clicking toggles the selected state, while already booked seats render as disabled. The backend needs to handle several core concerns:

• Capacity constraint: each flight has a fixed capacity of 6 seats and is locked once sold out;
• Concurrency safety: seat submissions require atomic validation to prevent overselling;
• Persistence: reservation records are written to storage and survive page refreshes;
• Form validation: passenger information, date, and seat must all be present before submission.

A simplified server-side validation flow looks like this:

def book_seat(flight_id, seat_no, passenger):
    with store.transaction() as tx:
        booked = tx.query_seats(flight_id)
        if seat_no in booked:
            raise SeatTakenError(seat_no)
        if len(booked) >= 6:
            raise FlightFullError(flight_id)
        tx.insert_booking(flight_id, seat_no, passenger)
    return {"status": "confirmed", "seat": seat_no}

The key point is to return “seat already taken” and “flight full” as two distinct error semantics so that the frontend can provide differentiated feedback. This is a detail that many demo pages overlook but real business scenarios must handle.

4. Case 2: Deep-Sea Research Institute Site—Split-Screen Motion and Information Density Control

The second task was the official website of a deep-sea research institute. The prompt structure followed the same four-section format, with only the brand and content assets changed.

4.1 Hero Motion and Split-Screen Transition

The hero section is designed as a vertical descent from the ocean surface. At the moment the camera crosses the waterline, the screen splits in two: the upper half shows daylight above the surface, while the lower half gradually deepens into blue water. In the far dark blue distance, two warm yellow lights represent a submersible.

There are typically two technical paths for this waterline split-screen effect. One uses two background layers with clipping masks and switches the split ratio when scroll progress reaches a threshold. The other uses video footage with timeline control. The former offers more precise control and adapts better across different screen sizes.

4.2 Parameter Cards and Content Sections

The middle section of the page presents parameter cards for three submersibles, with fields detailing propulsion method, observation window size, and so on. This is followed by six deep-sea creatures, each occupying one full screen. At the end, a “Field Notes” section features three articles credited to a chief scientist, a marine biologist, and a documentary director.

This section demonstrates the principle of layered information density. Parameter cards aim for compactness and comparability, creature introductions aim for immersion, and the notes section aims for credibility, with author attribution serving as endorsement. Three different densities coexist within one site, which requires a unified rule for grid and typography. Without it, the page can easily feel chaotic.

5. Case 3: Luxury Perfume Brand Site—Expressing Extreme Aesthetics Through Technology

5.1 Materials, Lighting, and Typography

The third task was the official website of a luxury perfume brand, which demanded the highest visual precision among the three cases. The main subject is an amber perfume bottle resting on a marble surface. The liquid inside rotates slowly, while light passes through the glass and casts caustic textures on the surface. The brand name is overlaid on the bottle in a serif font.

From a technical standpoint, “rotating liquid plus caustics” is a classic shader effect with a high implementation cost. In an agent delivery scenario, a more practical approach is to approximate the effect using pre-rendered video or high-quality still frames with subtle parallax displacement, reserving computational resources for the initial loading experience.

5.2 Font and Typography Consistency for Brand Identity

Serif fonts carry much of the “premium feel” in this type of brand site. The selection principles are: lighter weights, slightly increased letter spacing, and restrained font sizes. Body text and headings should use different weights from the same font family to avoid loading too many fonts and bloating the page. In addition, font-display: swap should be set to prevent font loading from blocking first render.

6. Key Engineering Practices

Across the three cases, a set of reusable practices emerges:

• Specify prompts in a structured way: separate brand, visual, functional, and constraint information so the model can address each item systematically.
• Deliver frontend and backend from the same source: business rules such as capacity limits must live on the server side. The frontend should only handle display and interaction.
• Prioritize state persistence: booking features must survive a page refresh. This is the dividing line between a demo and something actually usable.
• Apply motion restraint: atmospheric animations should serve the information. Use longer periods, smaller amplitudes, and respect accessibility settings for disabling motion.
• Differentiate error semantics: return distinct error codes for different failure reasons so the frontend can provide meaningful feedback.
• Use progressive enhancement: heavy assets such as video and shader effects should have fallback options to remain usable on weak networks and low-end devices.

7. Conclusion

Benchmark scores answer the question “How capable is the model?” Full-stack delivery capability answers “What can the model actually produce?” As the three cases above show, when an agent can maintain consistency across visual identity, interaction logic, business rules, and data constraints, what it produces is no longer a page that merely “looks like” the real thing. It becomes a product prototype with complete backend logic that can be demonstrated directly or even deployed for trial operation. For developers, this means the center of gravity is shifting from “implementing line by line” to “precisely describing requirements and acceptance criteria.” Write the specification clearly, and let the agent handle the delivery.