Testing General-Purpose LLMs: Frontend Generation and Agent Capabilities in Practice

1. It Starts with a Somewhat Abstract Question

For a while, I kept coming back to one question: can a large language model act like a kind of “philosopher’s stone,” turning rough inputs into usable engineering artifacts?

The metaphor is obviously imprecise. In legend, the philosopher’s stone turns base metals into gold, but an LLM does not create value out of nothing. It behaves more like a high-density knowledge compressor and generator: given enough context, clear constraints, and verifiable goals, it can produce nearly usable code, pages, documentation, and even task plans within minutes. Without constraints, however, it can just as easily generate output that looks plausible but is actually wrong or unmaintainable.

So rather than debating whether it is a philosopher’s stone, it makes more sense to treat it as a complex tool that needs to be used with engineering discipline. With that in mind, I ran a practice-oriented test on the latest generation of general-purpose LLMs. The goal was not benchmark chasing, but two areas developers care about deeply:

1. Frontend generation quality, especially page aesthetics, spatial understanding, 3D modeling, and lighting effects;
2. Agent capabilities—whether the model understands what task it is executing, what comes next, and how to verify results.

The rest of this article strips away product marketing and focuses on capabilities and engineering judgment.

2. Why Frontend Generation Is an Ideal Window into Model Capability

Frontend development is an excellent observation window because the feedback is immediate and visual.

Whether a piece of backend logic is well written usually requires interfaces, data, concurrency, and edge cases to evaluate. But whether a generated page is good can be judged almost at a glance:

• Is the layout stable?
• Are the colors harmonious?
• Is component spacing reasonable?
• Do interactions and animations feel natural?
• Are dark mode and light mode consistent?
• Does the layout collapse on narrow mobile screens?
• Are the perspective, lighting, and materials in 3D scenes convincing?

These traits can be assessed by a human in minutes. So instead of relying on abstract capability scores, I asked the model to build a relatively complex frontend page and then broke the result down from an engineering perspective.

2.1 Does Page Aesthetics Still Depend on Templates?

Frontend pages generated by many earlier models had an obvious “template feel”: centered hero headings, three cards in a row, uniform rounded buttons, blue-purple gradient backgrounds. Such pages are not ugly, but they lack real design judgment.

In this test, the generated pages showed clear aesthetic progress. Instead of defaulting to a fixed style, the model adapted the layout to the input description. For example, when asked to build a dark, tech-styled data monitoring dashboard, it used a low-saturation background, thin line borders, and localized highlight colors to build visual hierarchy, rather than slapping glow effects on every component.

This suggests the model’s understanding of “visual weight” is improving. It has begun to grasp that:

• Not everything needs emphasis;
• Low-contrast areas can carry secondary information;
• Highlight colors should be reserved for key metrics or abnormal states;
• Animations should serve the information hierarchy, not pile up as decoration.

This level of aesthetic judgment still cannot fully replace a designer, but it is already good enough to serve as a high-fidelity prototyping tool.

2.2 Spatial Understanding and 3D Layout

More critical is spatial understanding.

In traditional frontend work, CSS layout is fundamentally two-dimensional. Even with transform, perspective, and 3D transforms, most developers still reason about pages in 2D terms. But when you ask a model to generate an interactive page with 3D elements directly, it has to understand depth relationships between objects, rotation angles, viewer position, and light direction.

In the test, the model produced a showcase page featuring 3D card flips, multi-layer parallax scrolling, and subtle depth-of-field effects. During card flips, the front and back faces occluded each other correctly; parallax layers moved at speeds consistent with their logical depth; and the background lighting effects showed no obvious clipping.

This indicates that the model’s abstract representation of 3D space is fairly mature. It probably does not literally “see” the rendered visuals; rather, it has learned extensive mappings between 3D scenes and corresponding code during training.

2.3 Plausibility of Lighting and Shadow Effects

Lighting has always been one of the hardest parts of frontend visual work.

Shadows, reflections, refraction, and ambient occlusion are common in 3D rendering, but on the web, developers often have to combine CSS, Canvas, and WebGL to approximate them. If a model simply stacks filters and shadow parameters, the result tends to look messy.

In this test, the generated lighting effects were restrained. For example, in a product showcase card:

• The main light source had a clear direction;
• Shadow offset and blur radius matched;
• Highlights appeared only in plausible positions;
• In the glassmorphism effect, background blur and edge highlights were not overused.

This shows the model does not just know “how to make a shadow”—it is starting to understand “why a shadow should be built this way.” For developers, results like these can go straight into refinement instead of requiring hours of visual bug fixing first.

3. Beyond Frontend: Agent Capabilities

If frontend generation represents a model’s ability to “build things,” agent capabilities represent its ability to “get things done.”

In this test, I paid special attention to how the model behaved on complex tasks rather than single-turn Q&A. One clear impression: the model increasingly understands what task it is executing.

3.1 Clearly Describing Its Execution Stages

In traditional conversations, many models rush straight to the answer. On complex tasks, the answers often contain omissions, scrambled order, or scope drift.

In this test, when given a multi-step task, the model first clarified:

• What the current goal is;
• Which subtasks it should be broken into;
• What the acceptance criteria for each subtask are;
• Which steps are already complete;
• What it plans to do next.

This sense of staging matters a lot. It means the model is no longer just a passive answer generator but something closer to a continuously working executor.

For example, when asked to build a complete product landing page from a short description, it did not dump all the code at once. Instead, it planned first:

1. Define the page goal and information architecture;
2. Design the visual style;
3. Generate the HTML structure;
4. Write styles and responsive rules;
5. Add basic interactions;
6. Self-review and fix issues.

This is only an output format, but it significantly reduces the chance of users getting lost in complex tasks.

3.2 Proactively Recognizing Resource Contention

One interesting behavior surfaced during testing. In one simulated task, I asked the model to manage multiple resources while executing a task. At a certain step, it proactively pointed out that a resource in the current environment was occupied by another step, and suggested either waiting or reallocating.

Behavior like this shows the model is developing some awareness of conflicts during task execution. It no longer mechanically follows a fixed sequence; it adjusts when the environment state changes.

That said, this capability is still not reliable. For subtler resource dependencies and more complex execution conflicts, the model can still miss things. When deploying it in real production environments, you still need external process control and state verification.

3.3 A Stronger Tendency to Maintain Goals

Earlier models tended to drift off-goal during long tasks. Asked to generate an admin dashboard, they would produce a few sections and then wander into documentation, or repeatedly explain unrelated concepts.

In this test, goal maintenance was noticeably stronger. Even when intermediate output ran long, the model kept pushing toward the original goal instead of drifting into irrelevant territory.

This matters to developers because it means the model can handle longer engineering tasks, not just quick, short code snippets.

4. Boundaries and Recommendations for Engineering Use

Although the overall test results were satisfying, one point must be emphasized: LLMs are still not a silver bullet, let alone a real philosopher’s stone.

4.1 Generated Output Still Requires Human Review

Model-generated frontend code may look right visually but still fall short in maintainability, accessibility, and performance details. For example:

• Redundant styles may exist;
• Responsive breakpoints may be too coarse;
• Keyboard navigation support may be incomplete;
• Animation frame rates may be unstable on low-end devices.

So before using generated output in a production project, human review and optimization are still necessary.

4.2 Complex Agent Tasks Need External Constraints

For agent capabilities, the model shows good planning awareness, but for real deployment it is best combined with rule engines, state storage, and human approval checkpoints. Models are well suited to tasks like information organization, first-draft generation, plan decomposition, and code scaffolding—they should not be given direct authority over critical operations.

4.3 Capability Depends Heavily on How You Use the Model

The same model can perform very differently depending on prompt quality, context organization, and acceptance criteria. Developers should gradually build up their own prompt templates and workflows, for example:

• Specify the output format;
• Provide positive and negative examples;
• Limit the technology stack;
• Require staged output;
• Attach a self-check list to every step.

Only then can general capabilities be converted into reusable engineering productivity.

5. Conclusion

Based on this hands-on test, the latest generation of general-purpose LLMs is already highly usable for frontend generation. Page aesthetics, 3D spatial understanding, layout control, and lighting details are all more mature than before. For developers who need to quickly produce visually impressive pages, 3D demos, or interactive prototypes, these models can significantly shorten the distance from idea to interactive interface.

Agent performance is improving as well. The models now show clearer goal awareness, stage planning, and conflict recognition. They are still far from fully autonomous execution, but as an assistive executor they already deliver real value.

Back to the original question: is an LLM a philosopher’s stone?

I would put it differently: it is not a legendary material that turns stone into gold, but a very powerful machine that must be operated correctly. Give it enough context, clear goals, and reasonable constraints, and it will produce results close to engineering-grade quality. Treat it as magic that can do everything automatically, and you will get a pile of polished but not necessarily reliable output.

For developers, the most important thing is not chasing every new release, but building a working method that continuously evaluates, constrains, and integrates LLM capabilities. Tools will keep changing, but engineering judgment is the asset that lasts.