Why AI Lags at Design

Sources#

Summary#

Andrew Ambrosino (OpenAI Codex) answers a question the wiki keeps circling — why is "this looks like AI design" still a putdown while AI writes production code? — with four reasons frontier models trail at visual/product design, two practical (and fading) and two harder. It's a sharp, first-hand articulation of where the verifiable-reward frontier stops: code has a clean grader ("does it compile, does it do what it's supposed to"); design's grader is human taste, which is expensive to put in a training loop.

Evidence note. practitioner-opinion — an OpenAI product leader's read, explicitly hedged ("I'm not in our research… I'll get yelled at for saying this"), not a research claim.

The four reasons#

1. Design is hard to grade (the load-bearing one). "Creating a loop where you can train the model on what's good design and what's bad design is more tedious and onerous than 'does the code compile.'" Code carries its own verifier; design's verifier is the human aspect of taste, "part of the feedback mechanism you need." This is the verifiability thesis stated from the design side: capability advances fastest where reward is cheap and objective, and design's reward is neither.

2. It sat outside the AI-research flywheel. "Labs historically invest in making their models good at things that accelerate AI research." In the early coding-model era it was obvious that a model writing correct code would accelerate research; "you can't really make the same case for design." So design got less deliberate investment — not because it doesn't matter, but because it isn't in the self-improvement loop. (Practical; Ambrosino expects it to fade — "these models will get pretty good at design.")

3. Design rewards novelty; code rewards known patterns. "In software engineering you almost want it to over-index on known patterns." In design you don't: "there's an element of randomness and novelty." His example: for a year every new website was a copy of Linear's — "if a model outputs Linear's website every time, that's not the challenge here." Regression-to-the-mean is a feature for code and a failure for design. (Cf. Transformative Creativity / the abstraction-barrier critique: novel-concept generation may be a real ceiling, not just the next capability to fall.)

4. The design↔code abstraction layer (the deep one). Being a better visual designer isn't sufficient; there's "an interplay between the software design and the code being written" that is "visual design but significantly deeper — it's about the abstractions." His rebrand thought-experiment makes it concrete:

Shallow version: "we have to update 263 components one by one."
Deep version: understanding that "these two things look different but they're both in lists that have this style that conveys this interaction pattern to the user" — the semantic relationships between elements, not their pixels.

"That is still feeling a little bit out of reach with the current technology." This is the design-system-as-semantic-layer problem: real design competence lives in the maintainable abstraction between look and code, exactly the layer models are weakest on.

A 2026 hands-on test relocates part of reason 4 from the model to the system: driving Meta's Astryx against a real brand, the agent read the brand correctly everywhere and still emitted off-brand components — because the design system exposed customization slots for only four of them (I tested Meta's "agent-ready" design system Astryx. Here's the results., case-study, n=1; full account in Living Design System). The rebrand thought-experiment's deep version fails there not because the model can't hold the semantic relationships but because the abstraction layer offers nowhere to express them — "layered tokens get flattened." That is a weaker claim than Ambrosino's and worth keeping distinct: some of what reads as model incompetence at the design↔code layer is missing surface area in the tooling, which is fixable without any capability gain.

Why it matters#

If reasons 1–2 are practical and fading but 3–4 are structural, then design is a durable pocket of human taste longer than code was — the human "feedback mechanism" is not just labeling data, it's the reward function itself. It's also a caution against reading model-produced polish as competence: a model can emit a prod-looking surface (reason-3 mean-reversion to "good-looking") while missing the semantic abstraction (reason 4) that makes the design actually maintainable.

Connections#

Andrew Ambrosino — articulates the four reasons
Design by Selection — first-party confirmation of reason 3 from inside the tool built to close the gap: "left undirected, Claude picks one of its favorite aesthetics — you'd probably recognize them." Mean-reversion observed as a daily nuisance with working countermeasures (explicit fonts/colors, moodboards, using the model to brainstorm its way out of its own default)
The Verifiability Thesis — reason 1 is this thesis from the design side: design has no cheap objective grader
Verification as the New Bottleneck — the general shape: capability races ahead where verification is cheap, stalls where it isn't
Research Taste as the Human Bottleneck — design taste as a durable human residue; the human is the reward function, not just the labeler
Jagged Intelligence (Ghosts, Not Animals) — design as a current valley of the jagged frontier (a thing AI fails at, per the optimistic read, until it doesn't)
The Bitter Lesson / Build for the Next Model — "these models will get good at design" is the bitter-lesson bet; reasons 1–2 are the wait-for-the-model gaps, 3–4 the maybe-durable ones
Living Design System — reason 4's abstraction layer is the design-system problem: semantics between components, not the components themselves. Its Astryx test supplies the counter-case: an agent that reads the brand perfectly and still ships the wrong color, because the system had no slot — tooling coverage, not model taste
Transformative Creativity — reason 3 (novelty premium) borders the harder claim that new-concept generation is a real ceiling
Claude Design — the counter-effort: tooling aimed squarely at closing the model's design gap
Context Advantage, Not Taste — the test case for Andrew Ng's reframe: if design taste is a closable context gap it goes the way of every other lag; if it is discrimination without a statable criterion, it doesn't
Prototype Fidelity After Cheap Polish — the capability counterweight to the economics story: cheap high-fidelity output is not cheap design, so a flattened cost curve across fidelity does not flatten the quality curve

Open Questions#

Are reasons 3–4 (novelty, the abstraction layer) genuine ceilings, or — like reasons 1–2 — just under-invested capabilities that fall once a lab builds the grader?
Can design be made gradable without a human in the loop (learned taste models, preference data at scale), or does the "human aspect of taste" resist automation the way research taste might?
Does the design↔code abstraction layer improve with better code-understanding models even if pure visual design stalls — i.e. is reason 4 a coding-capability problem in disguise?

Sources#

OpenAI Codex lead on the new shape of product work — Ambrosino's four-part answer on why frontier models lag at design
I tested Meta's "agent-ready" design system Astryx. Here's the results. — Evangeline, Substack, July 2026 (case-study, n=1): partial relocation of reason 4 from model capability to design-system coverage