AI moved craft from production to judgment; the same tools can help you protect it, if you describe your standards and keep humans reviewing.

For a decade, design proved itself in the artifact: A pixel-perfect Figma file, a prototype that clicked exactly right, a design system with everything perfectly documented.

That proved you were good.

A Figma frame has never shipped revenue — It promises a product but it is not one, and we spent years mistaking the two.

Design was never supposed to be about production, it was about products people use — products where engagement, retention, and revenue are the outcomes that prove the work mattered.

The craft narrowed to the file, and our impact narrowed with it.

The shift isn’t new. When desktop publishing arrived in the 1980s, typesetters who guarded the metal lost; those who followed craft to judgment thrived. Artificial intelligence (AI) is running the same play on design, only faster.

The production layer — the wireframe, the boilerplate, the competent first draft of a screen — is collapsing toward free, which changes our own perceived value proposition.

When making gets cheap, much of what you called craft turns out to be production wearing craft’s clothes. What survives is the part that was never about the file: choosing the right problem and owning the outcome it moves. Not a loss but a relocation you can get ahead of. Here is where craft goes.

Craft is not decoration on the product. It is part of what makes the product worth trusting.

Craft Now Means Choosing The Right Problem, Not Producing The Artifact

For most of your career, craft was legible in the output. A tight layout, a clean component, a flow with no dead ends: these were how you proved you were good, and they were mostly production.

AI is good at production.

Point a competent model at a clear prompt and it returns a plausible screen, a serviceable component, a first draft that would have cost you an afternoon.

The polish that used to signal skill is now a commodity.

So the signal moves upstream. John Maeda has been making this argument for a while; in Practicing CRAFT: Keeping Ahead of the Machine, he reframes craft as the human discernment a machine optimizing for the shortest path will skip. The efficient answer and the right answer are not the same answer, and knowing the difference is the work.

When a tool can generate a thousand plausible screens before lunch, the scarce skill is no longer making one; it is knowing which one deserves to exist.

I have argued the same from the production side: when execution gets cheap, the work that survives is deciding what to build, understanding who it is for, and owning the call when the evidence is mixed. That is craft now. It is less visible than a beautiful artifact and far harder to fake.

The practical shift is from making to curation.

When a tool can generate a thousand plausible screens before lunch, the scarce skill is no longer making one; it is knowing which one deserves to exist. That skill has a name, taste, and most people have been outsourcing it to whoever runs the critique.

None of this means polish stops mattering. It means polish is table stakes, not the differentiator. The differentiator is the judgment that points all that cheap production at a problem worth solving in the first place.

That judgment is also what earns trust. Users never see your process, but they feel its absence. A product built on the right calls feels coherent and reliable, and reliability is what brings people back; one built on plausible guesses feels off in ways people cannot name and do not forgive.

Action items

• Defend one direction in writing. The next time AI hands you three or four plausible directions, pick one and write two sentences on why it wins for this user, this moment, and this constraint. Do it even when no one asks.
• Separate production from judgment. Audit one recent deliverable and split the parts a machine could regenerate from the parts where you owned the decision. Defend your calendar for the second kind.
• State the problem before you open the tool. Write it down in one sentence first. If you cannot state the problem cleanly, you are not ready to evaluate any solution the machine hands you.

Resources

• John Maeda, “Practicing CRAFT: Keeping Ahead of the Machine”
• Patrick Neeman, “When Execution Gets Cheap in an AI World, Most UX Ceremony Loses Its Point”
• Patrick Neeman, “AI Wants Builders. Here’s How to Become One.”

Make Research And Iteration A Habit, Not A Phase

The focus is now people and not the machines, by design.

The tools are so fluent that they will happily produce the thing research was supposed to earn.

• Ask a model for a user persona and it writes one.
• Ask for a research readout and it returns ten pages, every paragraph plausible, every quote invented. The document is finished before any research has happened, and it looks exactly like the real thing.
• Ask it to test it with a synthetic usability test, and it will do it in sections.

That is why the answer is not more research documents, it is a research habit that feeds the machine. Teresa Torres calls this continuous discovery: at a minimum, weekly touchpoints with customers by the team building the product, doing small research activities in pursuit of an outcome.

The point is contact with reality on a cadence, not a phase you complete and file away.

Research is no longer the slow part you skip under deadline; it is the cheap insurance against a machine that is wrong in fluent, well-formatted prose.

AI raises the value of that habit rather than replacing it. When the machine can fabricate a confident answer to any question, the habit of checking that answer against a real person becomes the thing standing between you and shipping fiction.

Iteration changes shape too. Breadth used to be expensive, so you explored two directions and committed early, often to the wrong one. Now breadth is close to free: you can put ten directions on the table in the time it took to mock up one. The skill is no longer generating options. It is killing the weak ones fast, before anyone grows attached, and the only reliable way to kill them is evidence from someone who is not on the team.

Action items

• Book a weekly customer touchpoint. Put one recurring slot on the calendar this week and defend it like a production deadline. Small and weekly beats large and quarterly.
• Label AI findings unverified by default. Before you accept any AI-generated persona, quote, or finding, mark it unverified until a real person confirms it. Ship the label, not the assumption.
• Kill weak options with evidence, fast. When AI gives you ten directions, run a five-minute test with one user to cut the bottom half before your team debates the top half.

Resources

• Teresa Torres, “Everyone Can Do Continuous Discovery — Even You! Here’s How”
• Teresa Torres, “Continuous Discovery: Definition and Overview”
• Patrick Neeman, “Tool-Shaped Objects in UX, Part 1”

The Machine Can Only Apply The Craft You Can Put Into Words

Here is the good news the panic skips over. AI can carry real craft, not just production. It can hold your standards, catch your anti-patterns, and apply your definition of good across a thousand screens without tiring.

It can do this only for the part of your craft you can put into words. Everything you cannot say, it cannot use.

Most craft is tacit. You know a layout is wrong before you can explain why. You feel that a flow has one screen too many. Michael Polanyi named this decades ago: we know more than we can tell.

Your taste lives mostly below the waterline of language, in pattern recognition you built over years and never had to state, because your own hands did the work. That gap is harmless when you do the work yourself. It becomes the whole problem the moment you hand the work to a machine.

Point a model at a vague brief and it fills the silence with its own defaults, which is the average of everything it has seen. Average is exactly what craft is supposed to beat.

The machine cannot read your hands; it can only read your words.

So the new literacy is description. The work is turning “I will know it when I see it” into stated constraints, named anti-patterns, and an explicit account of what good means for this product and no other. Geoffrey Litt frames the shift in Malleable Software in the Age of LLMs: the old bottleneck was turning fuzzy, informal intent into something formal, and the machine is opening that bottleneck fast. It opens from your side.

The intent still comes from you, and the sharper you make it, the better the machine bridges the gap.

This is uncomfortable, because taste resists being written down. Say the standard out loud and it sounds either obvious or arbitrary, and you lose the cover of the knowing nod in critique.

Maggie Appleton’s Language Model Sketchbook points the same way from the interface side: the tools that work are scoped, structured, and specific, not open-ended chat that hopes you will supply the constraints. They are well defined controlled vocabularies that define exactly what you mean with nothing left to chance.

Specific beats open-ended, for the same reason a good brief beats a vague one.

Writing your craft down is itself craft. It forces you to find the rule under the reflex, and finding it sharpens the reflex. Do it well and you get a second thing for free: a standard the machine can hold, so its help finally looks like your work instead of the internet’s.

Action items

• Write your definition of good. For one current project, state it in plain sentences: three things it must do, three it must never do. Hand that to the model before anything else, and watch the output move toward your standard instead of the average.
• Turn every rejection into a rule. The next time you reject an AI draft, do not just regenerate. Write the one sentence that says why it failed, add it to your standing instructions, and make the correction permanent instead of repeating it.
• Make one tacit standard explicit. Take a piece of your taste you have never stated, such as spacing, tone, or when to break a pattern, and force it into a rule you could hand to a stranger. If you cannot write it, you cannot delegate it.

Resources

• Geoffrey Litt, “Malleable Software in the Age of LLMs”
• Maggie Appleton, “Language Model Sketchbook, or Why I Hate Chatbots”
• “Tacit Knowledge in Large Language Models,” The Review of Austrian Economics (2025)

Build The Scaffolding First Starting With A Design.md File

Give an AI agent no context and it will guess. It will invent a hex code, reach for default framework blue, and hand you a settings page that looks like a cousin of your dashboard rather than a sibling. The fix is not a better prompt every time. It is scaffolding: standing context the agent reads before it does anything, so it starts inside your constraints instead of wandering toward them.

This practice now has a name and a shape. In April 2026, Google Labs open-sourced DESIGN.md, a portable format that describes a design system to any coding agent in a single file.

It pairs machine-readable tokens, meaning colors, typography, and spacing, with human-readable rationale explaining why those values exist, and it ships with a validator that checks choices against accessibility contrast rules. The format specification reads like a README written for the machine instead of the new hire.

Scaffolding is how you stop re-explaining your world in every prompt.

The deeper idea travels beyond design.

Coding agents already read standing instruction files, and the teams getting reliable output are the ones treating those files as a source of truth: conventions, boundaries, the vocabulary your product uses, the things an agent could never infer from the code alone.

One caution worth stating plainly. Scaffolding only helps when a human writes it. A context file auto-generated from your codebase and left unattended tends to bloat, drift, and mislead, because it encodes what the machine already guessed rather than what you decided. The value is in the curation, which means the design file is a living document you own, not a one-time export you forget.

Write the scaffolding before you write the feature. It is the highest-leverage hour you will spend all week.

Action items

• Create the design file this week. Put tokens for color, type, and spacing on top, with a short paragraph under each explaining the intent an agent cannot infer.
• Set explicit boundaries. Add a section that names what the agent must never touch and the vocabulary your product uses, then version it alongside your code.
• Keep the file living. When you correct the same mistake twice, that correction belongs in the scaffolding, not in your next prompt. It should be self learning, if possible.

Resources

• Google Labs, “Stitch’s DESIGN.md format is now open-source”
• DESIGN.md format specification (GitHub)
• DESIGN.md specification document

Keep A Human In The Loop And Put The Work In Front Of Users

The most important number in AI right now is a gap between what people believe and what is true. In a 2025 randomized controlled trial, METR had 16 experienced developers complete 246 real tasks, randomly allowing or forbidding AI tools.

The developers predicted AI would make them 24% faster. Afterward, they estimated it had made them 20% faster. Measured against the clock, AI had made them 19% slower. They were confidently wrong about their own experience, in real time.

That is the case for keeping a human in the loop, and then keeping a user in the loop after the human. Your own read on whether the AI got it right is not trustworthy, because the output is fluent enough to feel correct.

Developers are the first to sense this now and we should adopt this stance: in Stack Overflow’s 2025 survey, 84% of developers use or plan to use AI tools, yet only 29% trust the accuracy of the output and 46% actively distrust it. High use, low trust.

The verification of craft did not go away; it moved to you as the owner.

The failure mode is specific and worth naming. I once watched an AI draft a research readout before the research existed: ten pages in twenty seconds, every quote invented, the document finished before a single interview. Nothing in the artifact told you it was fiction.

Only a human who knew the research had not happened could catch it, and only a real user could tell you whether the concept underneath was any good.

So build the loop in on purpose. Put a person between the model and the decision, and put the concept in front of the people it is meant to serve before it hardens into a shipped feature. The machine is a fast, confident first draft. It is not a witness, and it is not your user.

Action items

• Name a human owner. Assign one for every AI-assisted deliverable before it moves forward. The rule is simple: a person signs, not the model.
• Require a real user before deciding. For any AI-generated finding, insight, or quote, demand one real user contact before it informs a decision. Treat unverified output as a hypothesis, not a result.
• Test the concept before the build. Schedule it first. Put the idea in front of five users while it is still cheap to change.

Resources

• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”
• Stack Overflow, “2025 Developer Survey: AI”
• Patrick Neeman, “Tool-Shaped Objects, Part 2: A UX Designer’s Field Guide to What Survives”

Evaluating The Machine’s Answers Is Now Craft And Now Part Of The System

For your whole career, craft was something you applied to your own work. You made a thing, then you judged it. That order is inverting. More of the work now arrives already made, generated in seconds, and your first real job is to decide whether it is any good.

Evaluation used to be an afterthought at the end of a process; it is becoming the center of the process, and a designed part of the product itself.

This is the taste from earlier turned outward. Choosing the right problem asks for judgment about what to build; evaluating a model’s output asks for the same judgment about what it just built, at volume, all day. It is the skill AI raises the value of most, because the machine will hand you a hundred confident answers and only some of them deserve to survive.

The industry has already turned evaluation into infrastructure. In a 2023 study, Zheng and colleagues showed that a strong model acting as a judge agreed with human preferences more than 80% of the time, the same rate at which humans agree with each other.

Live systems now run this continuously: Chatbot Arena has collected more than 240,000 human preference votes to rank models in the open.

Judging outputs is no longer a side task. It is a system you can build.

A judge is only as good as the standard you hand it, and the standard is still yours to set.

But look closely at that 80%. It is also the ceiling on how often two people agree about what good means, which tells you the hard part was never the mechanics of judging. It was defining the thing being judged.

A model judge inherits whatever rubric you give it, along with its own leanings toward longer answers and toward its own kind of writing.

This is why evaluation stays craft even when it runs on autopilot. @Aman Khan puts it plainly in his guide to building evals: the difference between AI products that work and ones that fail is not the model or the prompt, it is the willingness to argue about what good means, and to keep arguing as new failure modes surface. An eval is a living definition of done. Skip it and the product drifts toward plausible and away from correct, and users feel the difference before your metrics do.

So build the judgment in. Write the rubric, keep a small set of examples you have labeled by hand, and treat evaluation as a first-class part of the system, not a gate you bolt on later. The machine can apply your standard a thousand times an hour. It still cannot decide what the standard is.

Action items

• Build one rubric this week. Take a task you already delegate to AI and write the three to five criteria that separate a good answer from a merely plausible one. Hand it to the model as a judge and to yourself as a reviewer.
• Keep a hand-labeled golden set. Collect a small set of real inputs and label the outputs good, average, or bad yourself. Do not outsource the labeling; the judgment is the point, and it is yours to own.
• Make evaluation the definition of done. Before a feature ships, require it to pass the rubric, not just the tests. When a new failure mode appears in production, fold it into the eval instead of fixing it once and forgetting.

Resources

• Lianmin Zheng et al., “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”
• Aman Khan, “Beginner’s Guide to AI Evals (Walkthrough)”
• Wei-Lin Chiang et al., “Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference”

Review At The End Because AI Erodes Quality Quietly

AI does not fail loudly. It fails by accretion, one plausible shortcut at a time, and the damage shows up in the codebase months later. GitClear analyzed 211 million changed lines from 2020 to 2024 and found the signature of that erosion.

Refactored code, the lines that get moved and consolidated when someone reshapes a system, fell from 25% of changes in 2021 to under 10% in 2024. Copy-pasted lines rose from 8.3% to 12.3%, and 2024 was the first year on record that copy-pasted code outnumbered moved code. Duplicated blocks rose roughly eightfold.

Read that as a pattern, not a verdict. The study is correlational, and other things changed over those years. But the mechanism is familiar to anyone who has watched a fast tool meet a tired team: the machine makes adding easy and reusing hard, so people add. The result passes every test and still weakens the foundation, because duplication and drift do not announce themselves in a green build.

A test suite tells you the code runs. A review tells you the code belongs.

This is why the review at the end is not optional ceremony. It is the one checkpoint positioned to catch what the machine hides: the third copy of a function that should have been shared, the pattern that broke from your system, the shortcut that works today and costs you four times over by year two. A test suite tells you the code runs. A review tells you the code belongs.

The review also has to change to match the tool.

Reviewers should know which parts were AI-assisted and read those parts harder, not softer. The instinct to trust fluent output is exactly the instinct a good review exists to correct. You are not reviewing only for whether it works. You are reviewing for whether it should stay.

Action items

• Add an end-of-work review gate. Check for duplication and drift, not just passing tests. A green build is necessary, not sufficient.
• Flag the AI-assisted sections. Label them so reviewers apply extra scrutiny where fluent output is most likely to hide a shortcut.
• Hunt the third copy quarterly. Once a quarter, look for anything duplicated. If a function or pattern exists in three places, consolidate it before it becomes five.

Resources

• GitClear, “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones”
• GitClear, “Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality”
• Stack Overflow, “Mind the Gap: Closing the AI Trust Gap for Developers”

Conclusion

Return once more to the typesetters. The ones who struggled were not the least talented; they defined themselves by the part of the job the machine took.

The ones who thrived had decided, before the beige computer arrived, that their craft was never the metal. It was the judgment the metal carried.

AI is handing you the same decision on a shorter clock. The production layer is leaving and not coming back. You can defend the artifacts, the polished screens, hand-built components, or follow craft to its new address.

That address has seven rooms. Choose the right problem first. Keep research a weekly habit, not a phase. Describe your craft, so the machine applies your standards, not its defaults. Build the scaffolding to hold that description. Keep a human in the loop, and a user after them. Evaluate what the machine hands you, and build that judgment into the system. Put a real review at the end, where erosion hides.

None of this is nostalgia. It is where the leverage moved. The tools got faster, judgment got scarcer, and scarce is where craft has always lived. Name it clearly and the machine carries it, amplifying your judgment, not replacing it.

---

Craft still matters, but it’s about outcomes was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.