Valliance logo in black
Valliance logo in black

Designers and developers have been converging for years. AI just finished the job.

Mar 26, 2026

·

5 Mins

AI Transparency

After every kickoff meeting, the same thing used to happen. Everyone would disappear, retreat to their own tools, and come back a week later with their version of what we'd just discussed. The project manager would return with a PowerPoint deck. The UX designer would have a Miro board full of sticky notes. The UI designer would open Figma. The developer would pull up a system architecture diagram with arrows pointing to databases. Four people, four tools, four interpretations of the same conversation. All of them valid. All of them requiring translation.

We've been doing this for decades. And I think it's finally over.

The tools were always pushing us here

If you've been in this industry long enough, you can trace a line that, in hindsight, looks inevitable. We started by designing websites in Photoshop, a tool built for retouching photographs, not building interfaces. It was what we had, so it's what we used. The thing that got built never quite matched what was in the PSD, but that was just how it worked.

Then UX arrived. Tools like Balsamiq gave us low-fidelity wireframes: scratchy, black-and-white boxes that looked like napkin sketches. They weren't pretty, but that was the point. They forced conversations about structure, flow, and purpose before anyone got distracted by colour palettes and hero images.

Sketch moved us to vector-based design, better suited to the web, outputting SVGs instead of blurry bitmaps. Figma took it further, pulling designers and developers onto the same page at last. Developers could click on a component and get the padding, the font weight, the hex codes. We were finally starting to speak the same language.

But something else was happening inside Figma that we didn't fully clock at the time. Auto layout. Frames. Boxes within boxes within boxes. Figma was quietly teaching designers to think like developers: to stop placing things freely on a canvas and start building in the rigid, nested logic of how code actually works. Each tool in this progression was nudging us away from the creative-branding world and closer to the engineering one.

The convergence is here

Tools like Claude Cowork and Code have collapsed the last remaining gap. Through vibe coding (describing what you want in natural language and watching it materialise as a working interface) anyone on a team can now produce something that looks and functions like the real thing. Not a mockup. Not a prototype. A working front end.

At Valliance, we've seen what happens when an engineer can spin up a full dashboard in a morning: suddenly the whole team is reacting to a real interface, fielding feedback on UI, UX, and data layout all at once. It's exhilarating. It's also chaotic.

We quickly learned that just because you can build fast doesn't mean you should build without thinking. We found ourselves looking at interfaces that ticked every box on the surface: clean layout, sensible navigation, data where you'd expect it. The AI had done a perfectly competent job. But when we applied the kind of thinking that UX designers have been practising for years, abstracting a page down to its core purpose, asking "what is the single job this screen needs to do?", we started finding entire pages that didn't need to exist.

One real example. We had a screen built for users to verify whether data was correct. It looked great. It functioned fine. But when we interrogated the actual job to be done, we realised that incorrect data was an edge case, not the norm. The page in its entirety was unnecessary. That edge case could be handled differently, more simply, without a dedicated screen at all. No AI tool was going to flag that. It took a human asking the right question.

The opportunity is to build that kind of thinking into the workflow itself. What is this page for? Who is it serving? What is the one thing it needs to do well? These aren't new questions. They're the questions UX designers have always asked. The difference is that now they need to be asked earlier, faster, and by everyone on the team, not just the person with "UX" in their title.

What doesn't change

This is the part that should reassure anyone reading this with a knot in their stomach. The skills that make a great UX designer (or a great experience consultant, or whatever we end up calling ourselves) are not the skills that AI replaces. They're the skills AI makes more valuable.

The ability to walk into a room and read the politics. To sense what a stakeholder actually means versus what they're saying. To know that a client who asks for a "big bang transformation" actually needs incremental change they can sell internally. To abstract a complex problem down to post-it notes on a whiteboard and get a fractious team to agree on fundamentals before anyone touches a tool. These are human skills. They're irreplaceable because they involve dealing with humans.

What's changing is not whether these skills matter. It's who gets to build the thing afterwards. And if you're the person who can both steer the conversation and produce the work, if you can facilitate the workshop in the morning and vibe-code a working prototype in the afternoon, you become extraordinarily valuable.

The old handoff model is what's dying. "I've designed it in Figma, now a developer just needs to plug it in." Or worse: "I've built it, now UX just needs to come in and make it work." That wall between design and development has been the source of frustration, misalignment, and wasted effort for as long as I've been in this industry. The wall is coming down. And the people who've been on both sides of it should be celebrating, not mourning.

What to do on Monday morning

If you're a mid-career or senior designer reading this and feeling the ground shift, here's what I'd say.

Start using AI coding tools now. Not next quarter. Not when your company rolls out a policy. Now. Open an AI coding tool, take one of your own designs, and try to build it as a working interface through conversation. You'll be surprised how intuitive it is. It feels like directing a very capable junior designer, not like writing code.

Learn how GitHub branching works. Developers have managed parallel workstreams through branches and merges for years. When the build is the source of truth, not the Figma file that diverges from reality within a week, you need to be able to work in that environment. Take a branch, rework a screen, merge it back. This is the new version control, and "version-two_final-FINAL-v3.fig" isn't going to cut it anymore.

And critically, don't retreat into being "the person who steers the conversation" as a way to avoid the tools. Steering is essential, but if that's all you do, you'll eventually feel like your hands are tied behind your back while someone else makes the decisions you used to make. Stay at the table by being someone who contributes, not just someone who advises.

This is where we were always going

I know this is uncomfortable. It means learning things you might not want to learn. It means letting go of tools and workflows that feel like home. It means the role you trained for and built your career around is evolving into something with blurrier edges and a broader remit.

But look at the trajectory. Photoshop to Balsamiq to Sketch to Figma to Claude Code. Every step brought designers and developers closer together. Every tool taught us to think a little more like each other. This isn't a disruption. It's an arrival. The destination was always convergence, and the tools have finally caught up with where the work was always heading.

And here is the part that should excite you, not just reassure you. These tools do not just ask designers to become more technical. They free designers to be more ambitious. When you can bring an idea to life in an afternoon instead of waiting six weeks for a build cycle, you stop self-editing before you have even started. You stop designing for what is feasible and start designing for what is right. The convergence isn't about everyone becoming a developer. It's about removing the barriers between imagining something and making it real.

The people who pick up these tools now will shape what comes next. And for the first time in twenty years, the thing they imagine and the thing that gets built might actually be the same thing.

Get on board. This is where we were always going.

AI Transparency

After every kickoff meeting, the same thing used to happen. Everyone would disappear, retreat to their own tools, and come back a week later with their version of what we'd just discussed. The project manager would return with a PowerPoint deck. The UX designer would have a Miro board full of sticky notes. The UI designer would open Figma. The developer would pull up a system architecture diagram with arrows pointing to databases. Four people, four tools, four interpretations of the same conversation. All of them valid. All of them requiring translation.

We've been doing this for decades. And I think it's finally over.

The tools were always pushing us here

If you've been in this industry long enough, you can trace a line that, in hindsight, looks inevitable. We started by designing websites in Photoshop, a tool built for retouching photographs, not building interfaces. It was what we had, so it's what we used. The thing that got built never quite matched what was in the PSD, but that was just how it worked.

Then UX arrived. Tools like Balsamiq gave us low-fidelity wireframes: scratchy, black-and-white boxes that looked like napkin sketches. They weren't pretty, but that was the point. They forced conversations about structure, flow, and purpose before anyone got distracted by colour palettes and hero images.

Sketch moved us to vector-based design, better suited to the web, outputting SVGs instead of blurry bitmaps. Figma took it further, pulling designers and developers onto the same page at last. Developers could click on a component and get the padding, the font weight, the hex codes. We were finally starting to speak the same language.

But something else was happening inside Figma that we didn't fully clock at the time. Auto layout. Frames. Boxes within boxes within boxes. Figma was quietly teaching designers to think like developers: to stop placing things freely on a canvas and start building in the rigid, nested logic of how code actually works. Each tool in this progression was nudging us away from the creative-branding world and closer to the engineering one.

The convergence is here

Tools like Claude Cowork and Code have collapsed the last remaining gap. Through vibe coding (describing what you want in natural language and watching it materialise as a working interface) anyone on a team can now produce something that looks and functions like the real thing. Not a mockup. Not a prototype. A working front end.

At Valliance, we've seen what happens when an engineer can spin up a full dashboard in a morning: suddenly the whole team is reacting to a real interface, fielding feedback on UI, UX, and data layout all at once. It's exhilarating. It's also chaotic.

We quickly learned that just because you can build fast doesn't mean you should build without thinking. We found ourselves looking at interfaces that ticked every box on the surface: clean layout, sensible navigation, data where you'd expect it. The AI had done a perfectly competent job. But when we applied the kind of thinking that UX designers have been practising for years, abstracting a page down to its core purpose, asking "what is the single job this screen needs to do?", we started finding entire pages that didn't need to exist.

One real example. We had a screen built for users to verify whether data was correct. It looked great. It functioned fine. But when we interrogated the actual job to be done, we realised that incorrect data was an edge case, not the norm. The page in its entirety was unnecessary. That edge case could be handled differently, more simply, without a dedicated screen at all. No AI tool was going to flag that. It took a human asking the right question.

The opportunity is to build that kind of thinking into the workflow itself. What is this page for? Who is it serving? What is the one thing it needs to do well? These aren't new questions. They're the questions UX designers have always asked. The difference is that now they need to be asked earlier, faster, and by everyone on the team, not just the person with "UX" in their title.

What doesn't change

This is the part that should reassure anyone reading this with a knot in their stomach. The skills that make a great UX designer (or a great experience consultant, or whatever we end up calling ourselves) are not the skills that AI replaces. They're the skills AI makes more valuable.

The ability to walk into a room and read the politics. To sense what a stakeholder actually means versus what they're saying. To know that a client who asks for a "big bang transformation" actually needs incremental change they can sell internally. To abstract a complex problem down to post-it notes on a whiteboard and get a fractious team to agree on fundamentals before anyone touches a tool. These are human skills. They're irreplaceable because they involve dealing with humans.

What's changing is not whether these skills matter. It's who gets to build the thing afterwards. And if you're the person who can both steer the conversation and produce the work, if you can facilitate the workshop in the morning and vibe-code a working prototype in the afternoon, you become extraordinarily valuable.

The old handoff model is what's dying. "I've designed it in Figma, now a developer just needs to plug it in." Or worse: "I've built it, now UX just needs to come in and make it work." That wall between design and development has been the source of frustration, misalignment, and wasted effort for as long as I've been in this industry. The wall is coming down. And the people who've been on both sides of it should be celebrating, not mourning.

What to do on Monday morning

If you're a mid-career or senior designer reading this and feeling the ground shift, here's what I'd say.

Start using AI coding tools now. Not next quarter. Not when your company rolls out a policy. Now. Open an AI coding tool, take one of your own designs, and try to build it as a working interface through conversation. You'll be surprised how intuitive it is. It feels like directing a very capable junior designer, not like writing code.

Learn how GitHub branching works. Developers have managed parallel workstreams through branches and merges for years. When the build is the source of truth, not the Figma file that diverges from reality within a week, you need to be able to work in that environment. Take a branch, rework a screen, merge it back. This is the new version control, and "version-two_final-FINAL-v3.fig" isn't going to cut it anymore.

And critically, don't retreat into being "the person who steers the conversation" as a way to avoid the tools. Steering is essential, but if that's all you do, you'll eventually feel like your hands are tied behind your back while someone else makes the decisions you used to make. Stay at the table by being someone who contributes, not just someone who advises.

This is where we were always going

I know this is uncomfortable. It means learning things you might not want to learn. It means letting go of tools and workflows that feel like home. It means the role you trained for and built your career around is evolving into something with blurrier edges and a broader remit.

But look at the trajectory. Photoshop to Balsamiq to Sketch to Figma to Claude Code. Every step brought designers and developers closer together. Every tool taught us to think a little more like each other. This isn't a disruption. It's an arrival. The destination was always convergence, and the tools have finally caught up with where the work was always heading.

And here is the part that should excite you, not just reassure you. These tools do not just ask designers to become more technical. They free designers to be more ambitious. When you can bring an idea to life in an afternoon instead of waiting six weeks for a build cycle, you stop self-editing before you have even started. You stop designing for what is feasible and start designing for what is right. The convergence isn't about everyone becoming a developer. It's about removing the barriers between imagining something and making it real.

The people who pick up these tools now will shape what comes next. And for the first time in twenty years, the thing they imagine and the thing that gets built might actually be the same thing.

Get on board. This is where we were always going.

_Related thinking
_Related thinking
_Related thinking
_Related thinking
_Explore our themes
_Explore our themes
_Explore our themes
_Explore our themes