Practical AI Agent Coding: From a Single Prompt to Full-Stack Delivery

Over the past two years, the capabilities of open-source large language models (LLMs) have advanced rapidly. In public benchmarks covering complex knowledge, software engineering, and terminal-based coding, the gap between top open-source models and closed-source commercial flagoffs has narrowed significantly, with some open-source models even ranking among the global leaders on third-party aggregate leaderboards. For the open-source community, the question of “usability” is largely resolved. However, for frontline developers and enterprise engineering teams, the marginal value of leaderboard numbers is rapidly diminishing.

The reason is straightforward: benchmarks exist in a “sterile environment.” The repository is prepared, the test assertions are written, and the task boundaries are clearly defined—the model simply needs to run faster on a given track. In real-world work, requirements are often vague, incomplete, or even contradictory. A stakeholder might drop a one-liner like, “Build us a website with booking capabilities,” without specifying the information architecture, data model design, or how to handle sold-out scenarios.

Therefore, when evaluating a coding agent, benchmark scores are merely an entry ticket. The real question to ask is: given a natural language requirement, can it deliver a complete system in a single pass—one with a cohesive frontend, a runnable backend, and persistent data? In engineering terms, benchmarks measure the ceiling of problem-solving ability, while delivery measures the floor of engineering capability. The floor determines whether the agent can truly integrate into your workflow.

1. Why “Generating a Complete Website from a Single Prompt” is a Good Litmus Test

This task may seem like simply “building a webpage,” but it actually applies composite stress testing to six core agent capabilities:

1. Requirement Understanding and Completion: Expanding a single sentence like “near-Earth orbit travel company website with seat selection and flight booking” into a complete information architecture encompassing brand narrative, product showcase, and booking flow. This tests the model’s prior knowledge of “what a complete product should have.”
2. Visual Design Capability: Color palettes, font hierarchies, whitespace ratios, and animation rhythms. This tests aesthetic vocabulary and design system awareness.
3. Frontend Engineering Capability: Responsive layouts, component decomposition, and interactive cabin maps. This tests engineering organization.
4. Backend Engineering Capability: API design, data modeling, and parameter validation. This tests server-side competence.
5. Data Consistency: Whether booking data is persisted and whether state machines (available/locked/sold out) form a closed loop.
6. Narrative and Content Generation: Copywriting quality and the professionalism of mock data determine whether the final product feels like a “template” or a “masterpiece.”

Individual capabilities can be assembled via toolchains, but these six capabilities must interlock within a single generation. This is precisely the dividing line between an “agent” and a “code completion tool.”

2. Frontend Delivery: Domain Language Defines “Sophistication”

Using a commercial spaceflight theme as an example, a qualified frontend delivery should exhibit the following level of completeness: The hero section features a full-screen video background simulating a space capsule porthole view, with the Earth’s curvature slowly rotating and the edge of the atmosphere glowing blue. In the bottom right corner, a flight data panel is rendered in a monospace font, while in the top left, a fluorescent cyan dot pulses slowly at a breathing rhythm, indicating “system online.” Scrolling down reveals a vertical timeline-driven flight narrative—from donning custom pressurized suits at the spaceport 60 hours before launch, through the high-G phase of orbit insertion and zero-gravity moments, to splashing down in the ocean about 92 hours later and recovery divers converging. Each stage is accompanied by a key orange data point and scene imagery.

These details are worth examining individually: monospace fonts naturally imply “instrumentation and telemetry” in visual vocabulary; breathing animations are an industry convention for “heartbeat/survival signals”; and launch countdown formatting is the standard time expression in the aerospace domain. In other words, the model is not simply “generating a page.” After understanding the domain language of the theme, it systematically translates it into color schemes, fonts, animations, and information organization.

A deep-sea research theme presents an entirely different language system: The opening shot sinks vertically from the sea surface, splitting the screen the moment it crosses the waterline. The blue gradient transitions from shallow to deep, with two warm yellow submarine lights shining in the distant ink-blue—this is cinematic camera language. Submarine parameter cards are precise down to propulsion methods and observation window dimensions, demonstrating the ability to populate “structured data + domain parameters.” The field notes section features three articles authored by a chief scientist, a marine biologist, and a documentary director, reflecting multi-role content generation. A luxury brand theme tests the convergence ability of “extreme aesthetics”: amber liquid slowly rotates in a glass bottle, light penetrates the glass to cast caustic patterns, and the brand wordmark overlays it in an elegant serif typeface. Three themes, three language systems. This yields a universal formula for frontend delivery: Domain Language × Visual System × Animation Narrative. All three are indispensable.

3. Backend Delivery: The Critical Leap from “Looks Good” to “Actually Runs”

The frontend determines the first impression; the backend determines whether the system is an empty shell. Returning to the flight booking example, a qualified backend delivery must include at least five elements:

1. Data Modeling: Clear relationships for four core entities—flights, seats, passengers, and orders—rather than cramming everything into in-memory arrays.
2. Booking Flow: Select date → choose seat → fill in passenger info → submit. The entire chain must be traversable and reversible.
3. Persistence: Booking data is saved to a database, and state is not lost upon page refresh.
4. Capacity Constraints: A limit of 6 seats per flight, with available status automatically locking once sold out.
5. Concurrency Protection: Race condition handling when two people simultaneously attempt to grab the last seat.

Points 4 and 5 best distinguish a “toy” from a “production prototype.” This can be illustrated with language-agnostic pseudocode:

function bookSeat(flightId, seatId, passengerInfo):
    start database transaction
    apply row-level lock to the flight seat record
    if seat status == LOCKED:
        rollback transaction; return "Seat unavailable"
    if soldSeats for flight >= 6:
        set all seats for flight to LOCKED   // Auto-lock when full
        rollback transaction; return "Flight full"
    createOrder(flightId, seatId, passengerInfo)
    commit transaction; return orderReference

To evaluate an agent’s backend capabilities, focus on three signals: First, modeling awareness—whether state enters the database rather than memory. Second, boundary condition awareness—whether there are handling paths for sold-out scenarios, duplicate submissions, and invalid inputs. Third, concurrency awareness—whether it proactively introduces transactions, locks, or atomic operations. These three points are precisely the dividing line between junior and senior engineers. The agent’s performance here essentially equates to “how far it can write for you.”

4. A Reusable Evaluation Checklist and Prompt Engineering

If you need to systematically evaluate candidate agents within your team, it is recommended to score them based on the following checklist (1–5 points per item). Run tests across multiple domains (e.g., tech, scientific research, consumer goods, education) to mitigate single-point luck:

• Requirement Fidelity: Is the information architecture inferred from vague requirements reasonable and complete?
• Visual Completeness: Are the site’s color palettes, font sizes, spacing, and animations systematic, rather than just a single impressive page?
• Engineering Rigor: Is data persisted? Are there capacity and concurrency constraints? Are error paths recoverable?
• Code Maintainability: Are components reasonably decomposed and clearly named, or is all logic dumped into a single file?
• Iterative Consistency: After changing requirements, does it incrementally modify the existing structure or start from scratch?
• Domain Language Understanding: Can industry conventions (aerospace countdowns, ocean layered data, luxury serif typography) be correctly invoked?

For prompts, a “five-section structure” is recommended, with acceptance criteria placed up front:

1. Background—business setting and brand tone.
2. Role—full-stack engineer and designer.
3. Feature List—core functions listed item by item.
4. Constraints—technical preferences and data rules (e.g., 6 seats per flight, auto-lock when full).
5. Acceptance Criteria—what defines completion (can submit an order, data survives refresh, full flights show locked state).
   Empirically, the more specific the constraints and acceptance criteria, the higher the success rate of one-shot delivery.

5. From Demo to Production: Steps the Agent Won’t Handle, But You Must

The agent delivers a “production prototype.” There is still a clear engineering gap before going live:

1. Security Layer: Authentication and session management, input validation, injection protection, and API rate limiting.
2. Data Layer: Formal relational databases and caching strategies, object storage for media assets, and message queues to decouple asynchronous tasks (like booking confirmation notifications).
3. Operations Layer: Containerized deployment, logging services, monitoring and alerting, and canary releases with rollback plans.
4. Testing Layer: Writing unit tests for business rules (e.g., full-capacity locking, concurrent seat grabbing) and supplementing with end-to-end test cases.

Not all of these components need to be built in-house. Taking deployment as an example, integrating the agent-generated project into general-purpose cloud infrastructure is a pragmatic choice to shorten the path from demo to launch. For instance, on Baidu AI Cloud, you can use a container platform to host application services, object storage to manage media resources, and logging and monitoring services to complete the observability loop. This allows the team to focus on business logic and user experience refinement.

Conclusion

The shifting dynamics between open-source models and closed-source flagships on leaderboards are merely the prologue of this competition. For developers, the judgment framework truly worth establishing is this: benchmarks measure the problem-solving ceiling, while delivery measures the engineering floor. Rather than agonizing over fractional score differences, it is better to stress-test using the most real requirement from your own business—seeing if it can start from a single sentence and deliver a complete work with a cohesive frontend, a runnable backend, and persistent data. Ultimately, how many points a model can score on a test is unimportant; how much actual work it can deliver for you defines its real headcount in the team.