The AI-and-design argument, and the structural fight underneath it

There are two main arguments about AI and design. Jakob Nielsen says the old UX skillset is finished and the discipline itself will rise, and he treats that as a natural handover. Gess Puglielli is more direct. If AI can replace your designers, she argues, your organisation never understood design in the first place. She describes a pattern most senior designers will recognise. Product sets the requirements, engineering sets the constraints, leadership sets the strategy, and design arrives at the end to make it look good. In that setup designers are decorators, and AI is an obvious substitute.

Puglielli’s view matches what I’ve seen, and I’d take it further. Many organisations never looked past the surface. Product, engineering and leadership saw design as the final layer that made things look finished, and the judgment behind good decisions stayed out of sight. That suited them. Surface-level design was cheaper, quicker and easier to manage than a designer who pushed back on the brief. The misunderstanding and the preference fed each other for years. Now AI makes skipping judgment almost free. Puglielli’s twelve-second interface needs no conversation with anyone outside the reporting line.

So the idea of a simple pivot doesn’t hold up. Nielsen’s argument works only if organisations are ready to pay for design at a deeper level, and many aren’t. They paid for surface work, and AI now does that for next to nothing. What matters is where design judgment sits in the planning process. Leave it at the end and the role disappears, however experienced the designer.

Both authors end up giving the same advice. Move upstream. Become the judgment. It’s reasonable advice, and most organisations have nowhere upstream to move to. They know how to ship interfaces. They have no way to frame problems, weigh trade-offs or hold design to account for outcomes. Telling a designer to move up when the structure stops short is telling them to leave, and often that’s what it amounts to.

The split underneath the argument

Buzz Usborne describes the mechanism more clearly than either. Software work runs in two modes. Discovery decides what to build; delivery builds it efficiently. Most of the AI conversation is about delivery, because that’s where the gains show up first. Delivery is convergent. It follows known patterns and produces things you can measure, such as throughput, performance, accessibility and consistency. Models built on those patterns now do much of that work in minutes.

Discovery is open-ended and hard to measure. It means finding the problem worth solving, reframing it, making trade-offs, deciding what to leave out and judging what a market will accept. Usborne’s sharpest point is that the roles of person and machine swap between the two modes. In delivery, the person checks and refines what the machine makes. In discovery, the machine becomes one more voice in the room, and a fairly unhelpful one. It goes along with whatever it’s given and generates options without end, yet it rarely says the thing that changes the conversation. Leave discovery to AI alone and you get competent, familiar answers. It drifts towards the middle.

Nielsen and Puglielli are both describing this split without naming it. Read narrowly, Nielsen’s claim holds. Delivery shrinks, and the value moves to discovery. Puglielli’s point lands as a charge against organisations that only ever paid for delivery. Underneath, both are arguing about which half of the work organisations chose to fund.

Usborne also offers a check on all this. Plenty of problems need no discovery at all. Much of software is operational: settings pages, login flows, payment screens, parity features and internal tools. None of it needs a designer challenging the brief, and pretending otherwise is how design got its reputation as a tax on delivery. The skill is knowing where judgment changes the outcome and where it only slows the team down.

What design judgment at the front requires

Three structural changes need to be made for design to work at the level these arguments describe. Each concerns how the organisation sets up its work, and none is based on individual skill.

Problem framing needs to happen in one room. In the operating models I’ve built, that room is the feature kickoff. In the usual production model, product writes the brief, engineering scopes the build, and design comes in afterwards to make it look right. A good kickoff has three people defining the feature together. The product owner brings the why and the priorities. The designer brings the user and the experience. The engineer who owns the code brings the boundaries: what’s easy or hard to change, what an approach costs in server calls and page loads, and where the codebase bends and where it doesn’t.

Having the engineer there makes the design better. A designer working alone designs for what they can imagine. Working with the engineer who owns the code, they find the better interactions the system already supports, the ones that are good for the user and cost almost nothing to build. That’s where the cheap, high-value decisions sit, and only the person who owns the code knows where they are this week. I’ve argued for the better part of twenty years that design and engineering need to sit together. This is why.

This matters more now that designers ship code. Peter Marc, in a recent piece with Tom Scott, argues that a working prototype shows behaviour a design file hides, and he’s right. With an AI agent a designer can build straight into the codebase, and the agent will produce something that works on screen while ignoring the architecture underneath. It reads the code. It has no idea why the code is shaped that way, what’s fragile, or where the system is heading next quarter. The engineer knows all three. A designer working in code needs that map more than one working in a design file, because their mistakes now go straight to production. More people are writing code. Someone still owns the architecture, and that person belongs in the kickoff.

This is also where I part company with the craft-crisis argument Dolphia Arnstein makes in DOC. She says designers lost influence because they can’t speak the language of technical trade-offs, and the answer is for them to learn it. The diagnosis is right. The remedy works at the wrong level. No designer can hold a live model of a codebase in their head. The knowledge that matters is specific to this system, this week and this engineer’s sense of what their code will tolerate, and it lives in the room. Asking designers to become technically fluent asks them to stand in for the engineer. Putting the engineer in the kickoff gets you the engineer.

Seating design and engineering together helps, and it isn’t enough. Plenty of teams sit side by side and still work as a handoff, because design has no say over what gets built. Sitting together gives designers the understanding. Decision rights give them the influence. Most organisations offer neither. That’s becoming urgent, because AI is taking over the production work, and for many designers production is all they were ever given.

Discovery needs to drive decisions. Much of what was called discovery over the last decade was research that produced artefacts. Personas, journey maps and opportunity decks were made, presented and filed away. When execution is cheap, that approach is hard to defend. The question that matters is whether the team can make its next decision with more confidence. Measure discovery by the decisions it supports, and most research functions will have to change how they work.

Design needs to be measured by outcomes. Judge a design team by Figma output and AI probably wins. Judge it by whether the product solved the right problem in the right way, and judgment becomes the most valuable thing it offers. That sounds obvious and rarely happens, because most design leaders still justify their teams in terms a finance director recognises, which usually means deliverables per quarter. Outcome accountability is harder. Design’s value takes longer to show and is easier to question in a bad quarter. When it works, though, nothing replaces it, and the leaders who come through the next five years in better shape will be the ones who accept that trade.

There’s one thing AI can’t do. It can’t refuse. It won’t push back on a brief, delay a launch or insist a feature isn’t ready, and it won’t defend the customer experience when someone wants a cheaper version shipped. AI has nothing at stake. Ask for the cheaper version and it will produce it, then ten more. The judgment that protects brand and trust is the judgment that says no, and saying no needs a designer with enough standing to be heard. Peter Marc describes what many organisations have done to that standing in recent years. Teams shrank, design directors left and reviews stopped, leaving single designers covering whole teams with nobody senior behind them. A lone designer with no director has no mandate to refuse anything. Take that away and the brand gets damaged faster, by people who had no authority to stop it.

What the honest pivot advice sounds like

Nielsen and Puglielli are both right that something is ending. What’s ending is the version of design organisations paid for at scale. It was a delivery function, billed by deliverable and kept away from the decisions that mattered. AI can do that job more cheaply, and the organisations that built it won’t miss it.

Designers shouldn’t read this as vindication. Usborne is right that discovery belongs to the whole product organisation. The best teams let problems get framed by whoever sits closest to them, whether that’s engineering, support, research, leadership or customers themselves. The work is building organisations that do discovery, fund it and act on it before they ship. Design has a strong claim to that work. It doesn’t own it, and acting as though it does is the quickest way to lose the argument.

Peter Marc notes that the gap between those organisations and the rest is widening. Some now expect designers to frame problems, prototype and ship. Others still want screens for a review meeting. So the honest advice is simple. Find an organisation that funds discovery, or build the case for one where you are. Anything else is rebranding the exit interview.

Cover drawing after the discovery and delivery loop by The Fountain Institute.