How to compete with AI as a designer (you don't)

The question arrives phrased the same way every time. How do I compete with AI as a designer. It is an honest question and it has no good answer, because the verb is wrong. You cannot win that race, and the part that nobody says out loud is that you would not want the prize if you did.

Competing means offering the same output to the same buyer on better terms. Look at what that commits you to. It commits you to selling the artefact — the screen, the flow, the twenty states of an empty table — against something that produces artefacts at zero marginal cost and improves on a release schedule. You are not underpriced in that market. You are in the wrong market — which is a different diagnosis from the one most of this conversation reaches, and a considerably better one than deciding the career is over.

The race you can win and still lose

Say you win it. Say you get quick enough to hold your own on turnaround against a model, which some people genuinely can for another year or two. What you have won is the right to keep charging for the input whose price is falling fastest, and to defend that position again next quarter against a version of the tool that did not exist when you started reading this.

Speed was worth money because it was scarce. It bought you the second direction, the third, the one you would not have had time to try.

That was never the value — the value was having options to choose between, and speed was just the toll you paid to get them. The toll is gone. Paying it faster than everyone else is not an achievement, it is a habit you have not dropped yet.

What the framing hides

The reason "compete" feels natural is that for twenty years the job's scarce input and its visible output were the same object. You were paid for screens, you produced screens, and getting better meant producing better screens more quickly. One word covered the whole thing, so nobody had to separate the craft from the decision it encoded.

They have come apart now, and they came apart quickly. A model will give you five directions before lunch, each one competent, each one defensible on its own terms, and not one of them knowing which problem you are actually solving. The inventory of what has already been automated is a list of production tasks. Nothing on it is a judgement.

The position that is open

Somebody has to say which of the five ships, and then answer for it in six weeks when the number moves or does not. That person is not doing a smaller version of your job. They are doing the part that was always underneath it, the part that got squeezed into whatever time was left after the screens were finished.

It looks unglamorous from outside because the output is a sentence, not a file.

We are shipping the third one, because people abandon at step three when we ask them to commit before we have given them a reason to, and this is the version that gives the reason first. If second-week returns have not moved in a month, I was wrong and we take it out. That is the whole deliverable, and it is worth more than the four alternatives it rejected.

Notice what makes it work. It names a mechanism rather than a preference, which means it can be argued with. It carries a number that would prove it wrong, which means it can be checked. A model can produce the screens and cannot produce either of those, because it never met your user and it will not be in the room in six weeks. The vocabulary for the first half is a body of knowledge you can learn on purpose — the behavioural principles behind interface decisions is where it is written down, and it is the same lever you already pull on your users, pointed at your own work.

Train the evaluation, not the execution

Here is the version of this you can do on a Tuesday. Take a real brief, generate four or five directions, and then throw four of them away out loud — one sentence each on the behaviour it produces, the mechanism behind it, and the thing that would tell you it failed. The generating part is not the exercise. The rejecting part is.

Do it on something with a shape, not on a made-up product where any answer is fine, because the whole skill is discrimination and you cannot discriminate between options that carry no consequences. A realistic brief works. So does any of the practice projects that have a real constraint in them.

Once a week is enough to change how you sound in a review inside a couple of months. And it is the only version of this that compounds, because you are not training a skill the tools are eating — you are training the one they made scarce. It helps to have the honest inventory of what is left in front of you while you do it, and a workflow that says which half is yours to put it into practice on Monday. The question was never how to be faster than the machine. It is how to be the person who knows which of the five it should be, and can say why.