AI is useful to me when it shortens the distance between a question and something concrete enough to evaluate. It can help explore structures, compare alternatives, pressure-test copy and remove repetitive production work.
That speed does not replace product judgment. Someone still has to decide which question matters, which context is missing and whether the result deserves to become part of the product.
The uncomfortable part is that the two are easy to confuse. Output arrives looking like progress. A team that measures progress by output will not notice the difference until much later - by then the product has plenty of material and no argument.
Use AI to widen and compress exploration
Early product work benefits from range. I can ask for alternative structures, edge cases or ways to explain the same idea, then compare those outputs against the actual product context.
Later, AI can compress repetitive work such as reorganizing notes, drafting state matrices or turning an established pattern into a first implementation pass. The value comes from reducing mechanical effort around a decision, not delegating the decision itself.
The best moment for it is when a rule already exists. Once the product has decided how something behaves, producing the twelfth instance of that decision is mechanical, and mechanical work is exactly what should be handed off.
- Generate several structures before choosing a direction
- Surface missing states and assumptions for review
- Translate established rules into faster production drafts
Recognize where speed creates noise
AI tends to produce plausible completeness. A response can look considered while quietly assuming a user, a business model or a technical constraint that does not exist.
Visual output can have the same problem. It can arrive polished before hierarchy, product language and edge cases have been tested. That polish makes weak decisions harder to notice because the work already feels finished.
Volume compounds it. Reviewing one weak proposal is easy, because the weakness stands alone. Reviewing thirty is not, because the shared assumption underneath them starts to read as consensus.
Faster output is useful only when the direction remains easy to question.
Keep a human-controlled loop
My preferred loop is brief, generate, inspect, correct and integrate. The brief states the product constraint. Generation creates range. Inspection looks for assumptions and weak reasoning. Correction adds the missing context, and integration brings only the useful part into the system.
This loop keeps authorship visible. AI contributes material, but the designer remains responsible for what the product says, how it behaves and which tradeoffs it makes.
Inspection is the step that gets skipped, and it is the only one that cannot be automated by the same tool that produced the work. A model asked to check its own reasoning will usually confirm it.
There is also a category I do not hand over at all: anything the product asserts as true. Numbers, claims about how a system behaves, the wording of a promise to a customer. Those have a source, and the source has to be checked by someone who can be held to it.
The last step of the loop is the one that compounds. A correction that stays in a chat window has to be made again next week; the same correction written into the product's shared rules does not. That is the argument in a design system is a decision system, and it is what stops speed from turning into drift.
- State the constraint before requesting output
- Compare alternatives against the same product goal
- Verify facts, states and content before integration
- Record the final rule in the product system
The same problem, one level up
Everything above applies again when AI is not the tool but the product, and there the stakes are external rather than internal.
MontNoir sells a security audit run end to end by an agent. Security buyers are trained to distrust automated findings, and they are right to be. A false critical costs more than it saves. Someone senior has to spend a day disproving it.
The design answer was not to make the automation look more impressive. It was to make it auditable by a person who did not run it. Every finding ships with its evidence and the steps to reproduce it by hand, and the run narrates itself while it works. The agent stops being an oracle to be believed and becomes a colleague who shows their working.
That is the same discipline as the internal loop, made visible to a customer. Speed is only worth buying when the direction stays easy to question.
Let judgment shape the final product
Taste is not only preference. In product work it is the ability to notice three things. When hierarchy is weak. When an interaction asks too much. And when a technically valid answer does not fit the character of the product.
AI can offer more material to judge and less friction in producing it. The final coherence still comes from a person holding the product context across strategy, interface, content and implementation.
It also changes where the scarce hour goes. When production stops being the constraint, the constraint becomes knowing what is worth producing - and that is the part of the job that gets more valuable, not less.
The way I read a portfolio has changed for the same reason. Execution is no longer strong evidence on its own, because execution is now cheap. What a case has to show is the reasoning. Which behavior was being changed. What was ruled out. Why the result looks the way it does, rather than some other way that would have rendered just as nicely. That is how my own cases are written. Axis is the clearest of them: the team using the tool built it, so a weak assumption has nowhere to hide.
I use AI to move faster through exploration and production, then spend the saved attention on the parts that require judgment. The goal is not more output. It is a clearer path to work that is useful, coherent and accountable.