title: What actually changed when I started designing with AI summary: >- Not the speed. The strange part is working with a tool you cannot fully specify, cannot file a bug against, and cannot ask for support on, while still shipping work with your name on it. pubDate: 2026-08-05T16:00:00+03:00 tags: - design - ai

I have been designing mobile interfaces for eighteen years. Almost all of it for other people's products. Last month I put my own app in the App Store for the first time, and I got it there by working with AI for most of the parts I cannot do myself.

The thing everyone talks about is speed. That is real, and it is also the least interesting change.

Here is the interesting one. For eighteen years, every tool I used did exactly what I told it, and when it did not, that was a bug, and I could report it. Figma has a support address. Xcode has a radar. Now the most important tool in my process is one whose output I cannot fully specify, whose failures I cannot file, and whose behaviour I cannot escalate. If it consistently misunderstands something I need, there is no version of that conversation where I win. I can only rephrase and try again.

That should be intolerable and somehow it is not, because of a reframe I keep coming back to. A lot of people dismiss these tools for being unreliable. I understand why, but I think it misses the point. The tools are unreliable. What they are extremely good at is helping you build something else that is reliable. The output is not the product. The output is the scaffolding you use to get to a product that behaves the same way every time.

The other thing nobody warned me about is that there is a vibe to it. There is a way of talking to these things. Sometimes you have to feel for the phrase that hooks. And they latch onto small fragments of what you said and start orbiting them, treating some throwaway clause as a north star for the next twenty minutes. Learning to notice that early, and to start over rather than argue, has saved me more time than any prompt technique I have read.

What has not changed is the part I am actually responsible for. I still decide what the thing is, who it is for, what it refuses to do, and what it looks like when it fails. Nobody has automated the taste, and I am not sure the question is even well formed.

Eighteen years of designing other people's apps taught me how software should feel. This year taught me I no longer need to convince someone else to build it. That is a bigger shift than any of the rest of it, and I am still working out what to do with it.