The Missing Layer: Design Taste in AI Agents

How do you make an AI app look good when you are not a designer? For Hassan El Mghari, who introduces himself as Together AI’s developer experience lead, this is a recurring app-building problem. He reports building about ten apps a year for five years, with some reaching millions of users. He credits design and UX as the biggest reason people tried them.

The infrastructure behind that work is Together AI: an inference API spanning chat, images, audio, and vision; fine-tuning on customers’ data; and reservable H100 and B200 GPU clusters for training or inference. His model examples include GLM 5.2 and Nano Banana. The platform’s model catalog includes open-source models, but API availability does not make every offering open source: Nano Banana is Google’s Gemini image model.

The apps themselves are usually small: one page, a clear task, and deliberate attention to design and animation. His LogoCreator demonstration shows a settings sidebar beside six generated logo tiles. Hassan reports that about 85,000 people used the logo creator. A focused interface gives the generated work room to be the product.

The next examples extend that approach beyond a gallery of generated images:

• Make Comics: Turn the user into a comic-book superhero. At the conference booth, the flow starts with a photo on an iPad and ends with a printed comic to take home.
• Subtitle generation: Generate subtitles with open-source models for videos destined for YouTube and Twitter. Hassan reports that about 8,000 people checked out the subtitle app.
• Chat: Provide a straightforward interface to open-source models.
• Landing-page variations: Generate five or six alternatives, then let the user choose a direction.
• Cloud coding agent: Accept a GitHub repository, start a sandbox, and create a pull request.

These examples range from a single creative task to an agent that changes code, but the interface still needs to make the task and its result clear.

A working app can still look interchangeable with every other generated app. Hassan’s practical recommendation is to reserve roughly another 10–20% of effort for the UI; he sees that polish as a competitive advantage. The first step is to identify what makes the output feel generic.

His examples begin with purple gradient backgrounds, italic headings, a habitual “scroll to explore” instruction, and all-caps pill labels with widely spaced letters. These are concrete choices an agent can change, unlike a request to simply make a page look better.

Gradient logos, excessive emojis, inconsistent spacing and padding, and random decorative graphics round out the inventory. None requires a mysterious faculty of taste to describe. Hassan suggests that close inspection could produce a list of twenty or thirty recurring patterns. Naming the pattern turns an impression into an actionable instruction.

Hallmark, Hassan’s design skill, packages those observations into reusable context. Its first component is a set of AI slop gates: explicit instructions against recurring patterns, such as purple gradients and italic titles. Its second component is a collection of themes that gives the agent positive design directions to work from.

The two inputs solve different problems. Exclusions narrow the space of acceptable output; themes supply inspiration within that space. When Hallmark creates a website, those themes become part of the model’s context. Hassan’s recurring observation is that good visual inspiration improves the result.

Hassan reports that more than 10,000 people tried Hallmark within roughly a month and a half of its launch. Its initial emphasis was landing pages: he shows an indie-podcast page, then discusses feedback from the announcement and continued iteration before showing an invoicing-app page. The point of those examples is that the output does not need to repeat the same familiar design tells.

He describes the displayed sites as single-prompt generations, then compares a children’s learning page without Hallmark on the left against one with Hallmark on the right. He judges the latter cleaner and nicer, and says it also has more animation, although the static comparison does not demonstrate that motion. A second comparison puts a gradient-heavy baseline beside Hallmark’s output. The improved page is still not perfect; the skill produces a better starting point for iteration, rather than removing the need for it.

Once the base exists, the useful unit of work becomes a refinement cycle. Hassan often starts in Codex or Claude Code, then switches to a cheaper open-source model such as GLM 5.2 for iteration. He describes it as newly released two weeks before the talk and, in his assessment, the first open-source model he found very good at design. The relevant requirement is not merely low cost: the model must remain capable enough to make the requested changes well.

To make the comparison tangible, he asks the audience to identify which of two landing pages came from GLM 5.2 and which came from Opus 4.8. Four hands go up for A, which is the GLM result on the left. Hassan describes the pages as nearly indistinguishable in some respects and says GLM generated its page faster.

For this landing-page pair, Hassan reports that the Opus generation cost about five times as much and was slower. The revealed slide labels GLM 5.2 at $0.07 and Opus 4.8 at $0.39, with a heading describing GLM as 5.6× cheaper. Those are costs for the displayed generations; the talk does not supply prompts, token usage, serving conditions, or measured durations.

The next comparison reverses the visual association: Hassan judges the left-hand page more obviously AI-generated, and that one came from Opus. His selection rule is therefore task-specific. A cheaper model that produces sufficiently good design can make repeated refinement more practical than using the expensive model for every change.

The image-playground demonstration shows what a refinement cycle actually changes. A single prompt to GLM 5.2 produces a working website: enter a prompt and receive an image. That is a meaningful functional base, but Hassan can still see familiar AI design tells in its presentation.

Hassan reports that one or two follow-up prompts improved the image playground’s logo, loading states, animations, and spacing. The overall layout stays roughly similar. This is a useful distinction: the next prompt does not have to ask for another app or an entirely new design. It can improve the identity, feedback, and visual rhythm of the app that already works. Loading states are especially consequential because the user experiences the waiting period as part of image generation, not as something outside the product.

The target is an app that looks and feels good, not necessarily the best-designed app in the world. That makes the process accessible to a builder who does not identify as a designer. Start by moving beyond instant recognition—“that looks AI-generated”—to the specific causes: the purple gradient, the logo, or another repeated choice. Once you can name the cause, you can ask the agent to avoid it.

Then preserve the preference in a skill, a Markdown file, or AGENTS.md. Repeated logo regeneration is a good signal: if you reject the same kind of logo every time, write down both what to avoid and what to do instead. The correction should become an input to the next generation.

For the image playground, a small AGENTS.md entry could turn those recurring corrections into explicit instructions:

# Interface preferences

- Avoid purple gradient backgrounds and italic page titles.
- Use a simple text wordmark instead of a gradient logo.
- Keep spacing consistent between the prompt field, action, and result.
- Show a clear loading state while an image is being generated.
- Preserve the working prompt-to-image flow when refining the design.

The file is useful because it records decisions the builder would otherwise have to repeat. Hassan describes accumulating a substantial AGENTS.md this way; Hallmark offers a starting collection for someone who has not yet built their own.

Give agents references and screenshots is Hassan’s highest-priority recommendation. He maintains an inspiration vault: whenever an app or website looks particularly good, he saves it. When starting a project, he can choose a combination of references—Duolingo mixed with other apps, for example—and supply multiple screenshots. That gives the model a concrete visual direction instead of requiring it to infer one from a vague adjective.

He also uses voice notes to make his prompts more specific. Speaking for one to three minutes lets him describe the intended user, how the app should work, where a text box or image upload belongs, what the interface should look like, and which references matter. His resulting prompts are typically two or three paragraphs long. The useful detail is the product description: who is using the interface, what they are trying to accomplish, and what they should encounter along the way.

The displayed example puts a long prompt with highlighted instructions beside two outfit-app screenshots. Hassan points to the lower interface as an output produced from that prompt. The example connects the detailed request to a visible result, rather than leaving “be more specific” as abstract advice.

Detailed prompting does not mean putting every feature into a single request. For an app with seven features, Hassan recommends describing one or two features extensively at a time. His sequence is:

1. Start with a substantial foundational prompt and screenshots that establish the app’s direction.
2. Queue follow-up messages for individual feature additions.
3. Keep each request focused enough to explain its behavior in detail.

The distinction is between depth within a request and the number of features bundled into it. You can increase the former while limiting the latter.

Fast models make that sequence easier to sustain. Hassan returns to cheaper open-source models for iteration and cites Composer 2.5 as an example of how effective a fast editing loop can feel. More precisely, Cursor trained Composer 2.5 from the open-source Kimi K2.5 checkpoint; that provenance does not establish that Composer’s resulting weights are public. His practical point is about the experience of refinement: a sufficiently capable model that responds quickly can be more useful for these tasks than routing every change through a closed-source model.

The remaining responsibility belongs to the builder. Publishing the first generation unchanged leaves the agent’s defaults in charge of the product. Treat that generation as the base, supply more context and inspiration, and work back and forth until the app looks and feels good. Keep the app simple as you do so: the objective is to improve the experience of the working product, not to bury it under more features.