What is a product designer for, when anyone can build?

Key idea 1 of 6

The handoff is disappearing, and the walls between roles with it

Picture a designer on a Tuesday morning with an idea for a feature. A few years ago the next steps were a sketch, a wireframe, a clickable prototype, a review with the product manager and, eventually, a handoff to an engineer. Weeks, if it went well.

Today they open a coding agent and describe the feature, with some context about the product. Twenty minutes later it’s running in a browser. They click through it, find a problem, change the instructions and watch it rebuild. By lunch they’ve done what used to take days of coordination.

So what are they now: a designer, an engineer, a product manager? Companies are asking the same question at scale. Atlassian’s AI Product Builders Week (opens in a new tab) put more than a thousand of its people to work building with AI for a week. A later round (opens in a new tab) invited 1,400 and produced more than 240 builds.

The work has started to look different too. Luke Green’s case study of Data Lens (opens in a new tab), visual data profiling for Data Cloud, describes leading the design of a reusable profiling module end to end. It’s built to be composed into other parts of the product, designed toward WCAG 2.1 AA, and carries natural-language guidance from Data Cloud’s agents. The deliverable isn’t a screen. It’s a part.

Cheap now

• A working screen
• Ten variations of it
• Code that compiles and passes its tests

Still scarce

• Knowing which problem matters
• Knowing whether people want it
• Knowing when it isn’t good enough

My own career runs the same arc. From 2005 I was a hybrid designer and developer, in studios too small to keep the two apart. When the roles split, I went with design. Now they’re meeting again, and I build what I design, with coding agents.

The wall between roles was never where a designer’s value came from. It came from understanding a situation well enough to make better decisions, and that part didn’t get cheap.

Key idea 2 of 6

A working prototype is a question, not an answer

When a working version costs an afternoon, it’s tempting to treat it as the answer. It isn’t. A prototype is a question, and the fastest way to ask it is to let people answer by using the thing.

Ryan Brownlow’s case study of Korl (opens in a new tab) is the clearest public example I know. Korl generates branded, personalized presentations for customer-facing teams from each customer’s data. Its first iteration went like this:

1. 01Research40+ go-to-market professionals, and the people they sell to
2. 02A working versionFigma’s MCP server and Claude Code, tested with users
3. 03What brokepeople’s hand edits broke the sync with the data
4. 04The fixa variable for every tracked figure, one source of truth

The fast prototype wasn’t the valuable part. The valuable part was what testing found: people’s hand edits broke the presentation’s sync with its data source. Better generation wouldn’t have fixed that. A different system did.

That suggests a different shape for the work. Instead of weeks spent preparing one carefully defended solution, a designer can build a few working hypotheses, put them in front of real use and throw out the weak ones. It only works if you’re willing to be wrong, and if each one ends in a decision. I wrote about the three honest calls, build, kill or park, in What should a working prototype actually prove?

A fast prototype is worth the assumption it breaks, not the time it saved.

Key idea 3 of 6

Building fast doesn’t make understanding fast

The speed is real, and it cuts both ways. A misunderstood requirement can now become a working feature before anyone notices it was misunderstood.

Julia D’Amico, Justworks’ VP of Product (opens in a new tab), wrote about both edges. An associate product manager built about 70% of an applicant tracking system with agents. A hackathon produced a working version in under three days, and that led to the applicant tracking system Justworks launched. But the agents’ first drafts were generic. It took conversations with real customers to find what they’d left out.

Some knowledge can’t be generated at all. Door County Found is a guide to a Wisconsin peninsula that I built and my sister keeps current. Each of its places opens on a line about why we love it: best perch you will ever have, real goats on the roof. Those lines come from decades of visits in every season. AI wrote the code. It couldn’t have written the guide, because the knowledge is the product.

You can make building much faster without making understanding any faster.

Key idea 4 of 6

Sometimes the right move is to stop generating and go get evidence

When making something is nearly free, making another one feels like progress. Often it’s a way to put off a question only people can answer.

Stephanie Jensen, a staff product designer at Adobe, gave a talk in September whose title says it: “One Small Question, System-Wide Impact: How user research helped us rethink one deceptively simple icon” (opens in a new tab). An icon is exactly the kind of thing a generator can produce fifty of in a minute. Fifty icons don’t tell you which one people understand, and they can make the choice harder.

I learned the same lesson on Lucy Learns, the dog-training app I built for our household. Once its illustration pipeline existed, a picture cost almost nothing, so making one stopped being the accomplishment. The decisions moved up a level:

• What has to stay the same from one picture to the next
• What is allowed to vary
• Whether the picture shows the behavior it claims to
• When to stop

The third one couldn’t be settled by drawing more. It took a blind pilot. Four language models with no knowledge of the project saw the same eight pictures in shuffled order, filenames hidden, and said what the person and the dog were doing. Two pictures failed, all four viewers misreading them the same way, and both were redrawn until fresh viewers read them right. That isn’t a substitute for testing with people. It’s a cheap way to catch the obvious failures first.

Generate when

• You need options to react to
• The work is repetitive and the rules are clear
• You already know what good looks like

Go find out when

• Every option looks plausible
• The question is what people understand or want
• Nobody has used it yet

Fifty versions of an icon don’t tell you which one people understand.

Key idea 5 of 6

A prototype should leave something the team can build from

A throwaway prototype answers its question and disappears. Its evidence ends up in a slide, and the next team starts from nothing. When building is this fast, that’s a waste, because the prototype could leave the next builder, person or agent, somewhere to start.

Atlassian’s design team built a tool around that idea. Protobox (opens in a new tab), described by Guy Jenkins in September, is a shared workspace for coded prototypes. A prototype becomes a spec with tasks for humans and agents, and a pre-flight skill checks the code’s quality.

1. 01The callbuild, kill or park, and why
2. 02The evidencewhat people did, and what broke
3. 03The partsbuilt from the system, not around it
4. 04The next taskswritten for the next builder, person or agent

Door County Found is my small version. Every place in it is structured data rather than a page of text: town, category, dog policy, vegetarian flags, notes. So the filters are real, and my sister, who isn’t a developer, keeps the guide current through a web form. A change she saves is live about two minutes later. It also has an honest exit. Everything is structured markdown, so moving it somewhere else is mechanical, not a rewrite.

A prototype that only answered its question has done half its job.

Key idea 6 of 6

Knowing enough engineering isn’t owning all of it

There’s a bad reading of all this, and some organizations will reach for it: if a designer can build, one person can do the work of a team. That isn’t a sustainable picture of anyone’s job.

Knowing enough engineering to test an idea is different from owning production. Security, infrastructure, scale, on-call and years of maintenance are disciplines of their own, and a working prototype touches none of them.

Enough to test an idea

• A working version on real inputs
• Parts from the system, not new ones
• Something easy to roll back or throw away

What stays the team’s

• Security and access
• Infrastructure, scale and cost
• On-call and years of maintenance

Part of the skill is knowing where your end is. On Door County Found I chose boring technology on purpose, so there would be nothing to maintain: a statically built site that costs about $12 a year to run. The first editing tool I tried turned out to need a server runtime and a GitHub App, exactly the moving parts I couldn’t promise to keep running, so it went.

What I’d want from a designer who builds isn’t a full stack. It’s the whole loop of the design: understanding why something matters, making it real fast enough to find out, and recognizing when it isn’t good enough. Knowing enough engineering to test an idea is different from owning the system it runs in.