I can ship an entire product experience in an afternoon
Not a concept. Not a rough idea. Flows, wireframes, edge cases, even a first pass at visual design.
What used to take weeks now takes hours.
I built a community platform for an alumni network in Australia, mostly solo. Within two months, we had meaningful engagement across a small, geographically scattered group (the kind where getting anyone to show up is the win). The newsletter stopped being a task I sat down to write; it became a byproduct of the system. Content entered the platform and automatically became the building blocks of each issue. No reinvention, no duplication. Just continuity.
If design were only about producing screens, then most of the job just disappeared.
But it didn't. If anything, the opposite is happening.
Design is becoming more important, not less.
Speed exposed what I couldn't see before
When I first began coding with Claude, I had no idea what the design output would look like. I had rough flows; closer to Balsamiq sketches than design. Enough to explore the idea, not enough to trust.
Then I found Pencil.dev.
That changed the nature of the work. Instead of wondering what rough flows might become, I could translate them into interfaces real enough to challenge. Real enough to break.
And they did break. Edge cases surfaced. States that had been invisible in rough form became obvious. These weren't cosmetic details. They were the kinds of design decisions that usually emerge once development is underway and changes are expensive.
But this time, they showed up early.
Here is what I learned: AI does not just speed up production. It forces decisions forward. Style tiles I would have deliberated over for days were generated, rejected, and blended in hours. Typography, tone, layout cues; those choices were still mine. AI made exploration faster, but it did not remove judgement from the process.
To be fair, Claude is genuinely good at surfacing edge cases and error states. It catches things I might miss on a first pass. The collaboration works. But where it struggles is consistency. Over longer sessions, screens start looking "close enough" but quietly drift from the design language: wrong colour tokens, inconsistent spacing, the right component on one screen replaced by something different two screens later. In systems with lots of interconnected views, this compounds fast. I call them lazy screens. They look plausible. They just don't belong to the same product.
That is where the designer earns their keep. Not by generating more, but by holding the whole system in their head and knowing when the output has drifted. Neither of us does this well alone. Together, we move faster and with more confidence than either could independently.
Once screens, states, and flows can be generated quickly, the value of the designer is no longer in producing the artefact. It is in deciding what should exist, what should not, and how the whole system holds together.
Less screen design. More systems thinking.
Without a process, AI will expose you
There is a reason this worked. It wasn't just the tools.
Before any of this, I had spent years building my own way of working. Grounded in user-centred design, human-computer interaction, journey thinking, and structured decision-making. Something I could rely on when things got messy.
When AI entered the picture, that system became the foundation.
Because once you can generate screens, flows, and interactions on demand, the constraint is no longer output. The constraint is direction.
What should you generate?
In what order?
Based on which assumptions?
Optimising for what outcome?
You can prompt your way into dozens of variations, but you have no way of knowing which one is right, or even what "right" means.
That's the trap. And it's already happening.
What AI really does is remove the friction that used to hide weak thinking.
If your process is unclear, AI will amplify that.
If your process is strong, AI will scale it.
In my case, it meant I wasn't designing screens. I was using AI to execute against a system I already trusted.
And that changes everything. Because the question is no longer "can I design this?" It becomes "should this exist at all?"
When output becomes cheap, outcomes become everything
The real impact showed up not in the screens, but in the system.
With EXATEC Australia, the busy work disappeared and the value-work became visible.
Previously, like in many communities, there was a tendency toward titles. Everyone wanted to lead. Fewer people were anchored in execution. The work was abstract, so it was easy to avoid.
But once the system existed, the work became tangible. The platform needed to be fed. Specific content types needed to be created. Gaps were obvious. Contribution was visible.
And that changed behaviour.
Not because of process enforcement. But because the system made the work real.
It is no longer about designing the thing. It is about designing how the thing works over time.
Operators vs Orchestrators
This is where things start to split.
Not everyone is responding to this shift the same way. And the divide is not about who uses AI more. It is about how they use it.
The Operator | The Orchestrator |
|---|---|
|
|
Operators get faster. Orchestrators get better. Only one compounds.
That distinction matters more than anything else right now.
An orchestrator does not just prompt well. They hold a system loop (user needs to personas to rough screens to journey analysis to heuristic review to domain model to high-fidelity output) and they know when the AI is drifting from it. The "good enough" bar is not just "does it work." It is "does it work and adhere to the loop." That is what separates considered output from plausible output.
I have seen this first-hand. Over time, Claude starts winging it, generating screens that look complete but quietly abandon the project conventions I set up. The happy path renders fine. But the system thinking erodes. Catching that drift is the orchestrator's job. The tool will not flag its own shortcuts.
And you can already see the implications at the organisational level. For years, product teams were built around a familiar triad: design, product, engineering. But these roles were never naturally aligned. Three roles, three perspectives, a healthy tension between them. Design pushed for experience. Product pushed for outcomes. Engineering pushed for feasibility.
I think that model is starting to collapse. Not everywhere, not yet. But the trajectory is clear.
Across several projects in a single month, I found myself doing all three. Designers can now prototype and ship. Engineers can design interfaces. Product managers can generate flows and test ideas directly. The boundaries are dissolving. We are moving toward a new kind of builder; someone who can think, design, and build in a single flow.
But here is the thing people miss: the tension does not disappear. It moves up.
Instead of living between roles, it now lives between people who can build anything and the people responsible for deciding what should be built. Execution becomes fluid. Direction becomes critical.
Which means once AI can generate almost anything, the differentiator is no longer access to tools. It is your personal system; the workflows, standards, and decision frameworks you have built over time. The things that encode how you think. Those compound. They become your leverage. And they will separate the people who scale from the people who just speed up.
Personal systems amplify whatever is already there. If someone operates at a surface level, their system scales that. If someone thinks in systems, their system scales that. The gap does not close. It widens.
Design Got Promoted. Now What?
So what does this actually mean?
It means the job did not disappear. It changed shape.
If you are still measuring your value by how fast you produce screens, then yes, the role is shrinking. AI will always be faster. But if you shift your focus to what those screens are meant to accomplish, the role expands. Because someone still needs to decide what problem is worth solving, define what good looks like, structure the system that produces consistent outcomes, and challenge what gets generated instead of accepting it.
That work is not going away. It is becoming the work.
I manage four designers right now. I have been asked, directly, to figure out what they will do as AI handles the grunt work. That is not a hypothetical for me. It is Tuesday.
And the honest answer is: I am still working it out. But I know the direction. The value is moving from production to orchestration. From "how many screens did you ship" to "how well did you structure the problem before anything got generated."
If you are early in your career: stop optimising for tool speed. Build judgement. Find someone who thinks in systems and study how they make decisions, not what software they use. Start building your own way of working now (even a rough one) because it is easier to refine a system than to invent one under pressure.
If you lead a team: look at what you are actually rewarding. Is it volume of output? Speed to delivery? Or is it the quality of the decisions behind the work? Because...
Design did not get replaced.
It got promoted.
I am not writing this from the other side. I am writing it from the middle. And the middle is where the interesting questions live.
Start Here
|
