The AI aesthetic

Jim Nielsen’s The AI Aesthetic (July 2026) starts from an observation about zeitgeists: each one brings design idioms unique to its challenges, and while many disappear as fads change, others bake themselves into software for good. The hamburger menu proliferated under mobile screen constraints and spread everywhere. The sparkle emoji, whose connotations before AI he cannot name, now simply means AI. Some patterns are specific to the technology, like streaming text, made for and refined by chat. Others are spreading: the shimmering text that in AI land implies thinking is being repurposed for any asynchronous task. He also notices the tiny, thin icons in desktop Electron AI apps clashing with the system grain of native macOS apps beside them, and asks whether tiny icons are our collective future (he hopes not). Then the list that gives the post its title: the aesthetics his brain now associates with AI are beige and cream colours, orange accents, serif typefaces, and “whack-a-mole UI controls,” where clicking a toggle repaints the entire interface so you have to chase it. The non-determinism of the technology, he suggests, has seeped into its UI.

Sameness at scale has a second cause, and Jim wrote about it a year earlier in Some Miscellaneous Thoughts on Visual Design Prodded By The Sameness of AI Company Logos, prompted by Radek Sienkiewicz’s observation that AI company logos converge on the same circular shapes dressed in flowery justification. Code, Jim says, has an allure here: to most people it either works or it does not, and however bad it is you can say “Yeah, but it’s working.” Visual design is subjective forever, so you must forever justify your choices, and in that environment decisions go to whoever has the best language or the most senior title. The homogenisation reveals that the industry, despite its claims of disruption, is afraid to stand out. Against it he sets the work of individuals and small teams, who “have a sense of taste that doesn’t dilute through the structure and processes of a larger organization.” Radek’s point, which Jim endorses, is that nobody suggests the bad logo; it emerges when everyone’s feedback is incorporated, so no individual would ever recommend what a corporate hierarchy produces. The websites of individuals still have soul; you can sense the people behind them. In The Tumultuous Evolution of the Design Profession he adds the economic reason: bad design does not visibly hurt profit margins, so most decision makers do not care, and designers rise into doing less design and more “performing taste.” Less craft, more optics.

Maggie Appleton describes the production side of the same worry. In Vibe Code is Legacy Code she agrees with Steve Krouse that vibe code and legacy code are roughly the same thing, code that nobody understands, and is honest about the pull: it is always easier and faster to let the agent go, an impulse she has to actively keep in check. Her note on Gas Town (January 2026), Steve Yegge’s entirely vibecoded agent orchestration system, reads it as speculative design fiction rather than a tool, and draws a conclusion that matters for this chapter: once a stack of agents is churning through code, development time stops being the bottleneck and design becomes the limiting factor, imagining what you want and working out the gnarly details that make it real. Her own blockers are never build time; they are “Is that transition subtle enough? How composable should this be? Is this the right metaphor?” These are decisions agents cannot make for you because they need your context, taste, and vision. The biggest flaw in Gas Town, she says, is that it was poorly designed; she quotes a commenter calling it vibe designed as well as vibe coded. And she names the footgun: you can move so fast you never stop to think. On the front end in particular, language is a poor medium for easing curves and aesthetic feelings; she always needs to touch the CSS.

The response, in the same set of authors, is that taste can be articulated and therefore transferred, and that the loop has to include review. Emil Kowalski’s Agents with Taste starts where Train Your Judgement ended: agents do not know what great feels like, so “if you know what great feels like, describe the rules, then give them to your agents.” His unit is a skill file per aspect of the interface. The argument is the balloon again: once you can say why scale(0) feels wrong and a higher initial scale feels right, you have a reason, and “almost every taste decision has a logical reason if you look close enough,” so the reason can be written down for an agent the way you would guide a less experienced designer. The post shows the tables: a Practical Tips table mapping scenarios to solutions (scale(0.97) on active, start from scale(0.95) not scale(0), set transform-origin to the trigger, a 44px minimum hit area, subtle blur under 20px), an Easing Decision Flowchart that is deliberately strict so the agent does not invent its own rules, Duration Guidelines (under 300ms, larger elements slower, exits around 20 percent faster, match duration to distance), and typography rules such as capping body text at about 65ch and tabular numerals on price columns. Any taste decision can be packaged this way, layout, icons, colour; he uses Anthropic’s skill-creator to make the writing easier. The demo is a dialog animation: asked to improve it with his skill, Claude Code returns a list of issues against his rules and a before and after table of what changed. The whole blog became one design engineering skill at emilkowal.ski/skill, and the repository README states the limit plainly: the skills are a side effect of domain expertise, AI does not replace that expertise but amplifies it, “a shortcut to stand out in a sea of slop.”

Kathryn Gonzalez said something compatible earlier, at Config 2023, in Design Systems in Transition: AI can help bridge the gap between our taste, intentions, and our ability to execute on them, and a design system becomes the language by which AI tools understand and consume your design, which makes systems more important, not less. She defines taste as critical judgement paired with deep domain expertise, used to set the standards an organisation should strive for, and predicts that more people will design, code, and build because the skills will be more accessible than ever. Jim and Kathryn describe the same profession under pressure from opposite ends: she expects the systems and standards work to grow, he watches craft lose to optics. Neither thinks the judgement itself becomes optional. Maggie’s bet is the most specific: she is in the code-must-be-close camp for serious work today, expects to drift toward code at a distance as harnesses mature, and says the infrastructure that will make that safe is validation loops, tests, and specialised reviewing agents, because “the more agents can validate their own work, the better the results.” Emil’s review skill, which audits animations strictly against his rules, is one such loop, built from articulated taste.

Jim has a two-frame test for whether any of this has taken. His Job Screening Blog Post is two animated GIFs of a button being clicked; in one the heading shifts up by a pixel, in the other it does not move. “Can you tell the difference between them? Do you care? If not, we might not be a good fit.” That is the whole chapter in three sentences. Taste is noticing the pixel, caring, and being able to say why it matters, and nothing about generated interfaces changes the first two; it only raises the price of the third.

So, what to practise. Do Emil’s exercises and write the reason before reading his. Keep a list of the rules you find yourself repeating in review, and when one is stable, write it down as a rule an agent could follow, with its why, the way his tables do; you will find out quickly which of your preferences have reasons and which are habits. Run a Rauno-style novelty budget over every screen you touch and spend the accent on one thing. Look at what the agent made at slow speed and frame by frame, the way you would your own work, and review it again the next day. Keep the code close on anything whose feel matters, as Maggie does with CSS. And when the screen in front of you is beige, orange, serif, shimmering, and shifting by a pixel, notice it, care, and be able to say what you would change.