Craft still matters, but it’s about outcomes

Craft still matters, but it’s about outcomes

The craft never lived in the metal. When the medium changed, judgment moved to a new address. 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. When a thousand plausible options are free, the work is knowing which one deserves to exist.

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

Discovery is not a phase you finish. It is a loop you keep, at least weekly. 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

Your standards are useless to the machine until you pull them out of the tangle and set them down in 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

Standing context, written by a human, is the highest-leverage hour in the week. 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 output feels correct before it is. Put a person, then a user, in the path. 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.