Luke Wroblewski published the number this week that every design systems team should pin up, and then proposed the next step I would not take. This is a rewrite of that step.
The short version
Wroblewski's November 3 post says his coding agents, steered by the design system and the agent instructions, get a screen about 90% right on the first pass, up from 50 to 60% with earlier models, and that the last 10% is closed by pointing at the screen, which is why Intent now turns the macOS notch into a whole-screen annotation surface. His proposed next step is to feed that feedback back into the design system so it improves over time, held back only because models over-document instead of simplifying. The over-documenting is not a model limitation that a later model fixes. It is what any system does when every fix is an entry, and the same post says his team spent years deliberately shrinking its systems for that reason. The rewrite: log every last-mile fix against the surface and the component it touched, promote a fix into a constraint only when it recurs on a third surface, and measure the systems team on the time from a quality complaint to a rule change rather than the size of the system. A designer signs the weekly diff, and with a threshold of three the diff fits on a screen.
What Wroblewski shipped, and what he proposed
The post is short and concrete, which is why it is worth arguing with. His earlier piece described steering coding agents with design specs and components so every change stays cohesive with the product and the brand. This one reports what that gets you: about 90% of a screen on the first pass. Earlier models managed 50 to 60%. The remaining 10% is the variants and composite layouts that no design system anticipates, and his line for it is that no design system survives contact with the product.
The 10% is closed by feedback. His team tried comments in Figma, annotated screenshots, and typing each change into a chat box, and the experiments turned into a feature: in Intent's latest release the macOS notch turns the whole screen into a feedback surface. Type or speak the instruction, annotate anything on screen, take a screenshot, record a video, or combine them, for what he calls last-mile UI fixes.
Then the proposal. The logical next step, he writes, would be feeding this feedback back into the design system so it improves over time. He holds back for one reason: today's models lack the judgment to decide what to integrate and how, and left alone they over-document instead of simplifying patterns, so a designer's judgment still matters a lot.
I agree with the caution and not with the step.
Over-documenting is not a model gap
Read the same post again for the sentence that undercuts the proposal. Over the years, his team deliberately reduced the content in their systems, because otherwise systems grow in team size, components, states, and documentation.
That growth was never caused by a lack of judgment. It was caused by the fact that adding an entry is visible and pruning one is not. Every design systems team I have worked next to, at Salesforce, at Adobe, and at Smartcat, had the same gravity: a component added is a contribution someone can point to, and a component removed is an argument someone has to win. A model that over-documents is doing exactly what the incentive does to a person in the seat, faster.
The Design Operating Model's Design's Kill List retires that object by name. The component library as monument: a design system maintained as a comprehensive catalogue, curated as an end in itself, surviving because it is visible, countable, and there is a team whose identity is attached to it. The replacement is a constraint layer and a much smaller set of primitives, because when surfaces get assembled at runtime, the value is in the rules that govern assembly.
An agent asked to learn from every annotation is the monument rebuilt with a faster mason. Wroblewski's own team shrank its systems on purpose. The next step after a tool that captures every fix cannot be a system that keeps every fix.
Tanner Kohler at Nielsen Norman Group has the other half of the reason in his October 30 article on agentic software factories. The AI-native playbooks from the labs, he argues, treat UX as context that guides generation, which is one of UX's three roles and not the other two, and his line is that context can encode only what we already know. His sixth recommendation is to make the design system machine-readable so generated mockups stay aligned. Machine-readable, yes. The question is what earns a place in the file, and a single annotation on a single screen has not earned it yet.
The rewrite: log, promote on the third surface, time the rule change
Three moves, in place of "feed it back."
Log every fix against the surface and the component. The notch's real output is not a prompt to the agent. It is a row: which surface, which component or primitive, what was wrong, what the fix was, who annotated. The agent still applies the fix to the screen in front of it, as it does today. The row is what the system learns from later, if it learns at all.
Promote on the third surface. A fix on one screen is the agent getting that screen right. The same fix on a second screen might be one designer's taste. The third surface, usually annotated by someone else, is where a rule becomes cheaper than the next three fixes, and that is the moment it enters the constraint layer. Everything below three stays a fix, because two is a coincidence and three is a pattern.
Measure the time from complaint to rule change. Team Shape(coming Jan 20) gives a design org three health numbers in place of headcount ratios: the percentage of live surfaces with a current constraint set, the percentage with a calibrated rubric, and the time from a quality complaint to a rubric change. The third one is the number for this loop. A growing catalogue makes it worse, because every rule change has to be reconciled with more entries. A threshold of three keeps the file short enough that the clock stays fast.
Someone on design signs the weekly diff, the rule from LangChain's Design Agent Updates Its Own Design System Weekly. Someone on Design Should Sign the Diff. The difference the threshold makes is that the diff is a handful of promotions with their three surfaces attached, not a week of annotations. A reviewer can read that in ten minutes and refuse half of it, which is what reviewing means.
What this changes for the team
The systems team, which Team Shape already renames the design rules team, gets a new input and a smaller output. The input is the fix ledger, which the annotation tool should write for free. The output is the constraint layer, which gets shorter as the agent's first pass improves, because every rule it absorbs is one the agent no longer needs a fix for.
Under Product Leadership the claim is that leadership work now is deciding which coordination roles stop being necessary. The design systems team does not stop being necessary. The catalogue does. Wroblewski's 90% is the agent taking over the part of the job that was assembling screens from a catalogue, and the 10% is the part that was always judgment. Feeding the 10% back in hands the judgment to the catalogue. Logging it, and promoting on the third surface, keeps the judgment with the person who signs.
This week, if your agents build from a design system: count the last-mile fixes from the past month by surface and component. If any fix appears on three surfaces, that is your first promotion, and it has been waiting. If none do, the system is the right size, and the notch is doing its job.
Related answer: Should last-mile design feedback be fed back into the design system?
Sources: Luke Wroblewski, "Design Feedback for AI Agents," LukeW, November 3, 2026, read in full; the 90%, the 50 to 60%, the Intent notch feature, and the over-documentation observation are his. Tanner Kohler, "The Role of UX in Agentic Software Factories," Nielsen Norman Group, October 30, 2026, read in full. Falk Gottlob, "Design's Kill List" and "Team Shape(coming Jan 20)" in the Design Operating Model, and "LangChain's Design Agent Updates Its Own Design System Weekly. Someone on Design Should Sign the Diff." (October 29, 2026).
Frequently asked
What did Luke Wroblewski report about agents and design systems?+
In his November 3, 2026 post, Wroblewski says the agent's first pass, guided by the design system and the agent instructions, now gets about 90% of the way, where earlier models reached 50 to 60%. The rest is closed by showing the agent where layouts misalign or fail and having it fix each case until the variants and composite layouts work. His team tried Figma comments, annotated screenshots, and typing each change into a chat, and shipped a visual feedback feature in Intent where the macOS notch lets you use the whole screen as feedback, by typing, speaking, annotating, screenshotting, or recording.
What is the claim this post disagrees with?+
Wroblewski writes that the logical next step would be feeding the last-mile feedback back into the design system so it improves over time, and that he holds back only because today's models lack the judgment to decide what to integrate, over-documenting instead of simplifying patterns. My disagreement is with the next step, not the caution. The feedback is a repair, and a repair is a fact about one surface until it recurs. A system that absorbs every fix is the component library as monument, built by an agent instead of a team.
What is the three-move rewrite?+
Log every last-mile fix against the surface and the component it touched, so the annotation tool's output is a ledger rather than a prompt. Promote a fix into a constraint only when it recurs on a third surface, and leave the one-offs as one-offs. Measure the systems team on the time from a quality complaint to a rule change, the third of the three health numbers in the Design Operating Model's Team Shape chapter, rather than on how many entries the system holds. Someone on design signs the weekly diff, and with a threshold of three the diff is short.
Where does Tanner Kohler come in?+
His October 30, 2026 Nielsen Norman Group article on agentic software factories says the AI-native playbooks from the labs cover only one of UX's three roles, adding context to generation, and that context can encode only what we already know. His sixth recommendation is to make research insights and the design system machine-readable so agents surface evidence early and keep generated mockups aligned. Machine-readable is right. The question this post answers is what earns a place in the file.
Why a threshold of three surfaces and not two?+
Two is a coincidence and three is a pattern. A fix on one screen is the agent getting that screen right. A fix on a second screen could be the same designer's taste. The third surface, usually with a different designer annotating, is the point where the rule is cheaper than the next three fixes. The threshold is the part to tune per team; what should not be tuned is that there is one.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn