Player Three Has Entered the Game: How AI Is Finally Bridging the Divide Between Design and Engineering

As AI begins to become more prominent in our day-to-day lives, I find myself in a unique position. As a practicing software engineer and UI/UX designer, I am genuinely happy to see the introduction of AI tools begin to take shape in our industry. But more importantly, I am happy to start seeing the effects it is having on what has historically been a pretty challenging relationship: the one between design and engineering. 

There has always been a great divide between designers and developers. Different tools, different priorities, different definitions of “done.” But here we are — with the introduction of AI, we are finally starting to break down those barriers. Cats and dogs are comfortably living together. Designers and engineers are starting to come together as one cohesive team. 

AI is Player Three entering our game. And it is not here to pick a side. It is here to be the moderator between design and development. The more tools that come out for the most popular AI platforms — whether it is OpenAI, Claude, or Gemini — the smaller the gap between these two teams will become. 

The Tug-of-War Over Control

Historically, at least in my own experience, the main point of contention between design and development has been control. Who truly controls a product? 

TL; DR? Everyone. Product managers, product owners, designers, developers — everyone has a stake. But there is a real point of friction when it comes to execution. Who controls what a product truly is? What can it do? How does it make a user feel? What kind of productivity can a user get from it? It depends entirely on who you ask. 

From a designer’s perspective, it is their responsibility to do the user research, to discover business processes alongside business analysts and product managers, and to really discern where value can be delivered — what jobs or roles can be improved or even eliminated by a better product experience. Developers, on the other hand, are typically thinking about the business side of taking a product to market. Their criteria for success are often weighed on how efficient the program is, how cost-effective it can be, how quickly it can adapt and change, and how low they can keep latency, data consumption, and cost. 

Each party carries real leverage when it comes to delivering a product. The design team’s leverage comes from the position of the customer: if a product is not intuitive or easy to understand, your customer base will not use it. On the other side, the developer is the last person to touch a product before it goes to market. So, while a designer might have the best of intentions about what a product should do and what experience should be delivered, it is the developer’s job to figure out how to deliver that experience. And unfortunately, there has historically been a difference of opinion on both of those goals. 

The friction does not stop at the strategic level, either. It shows up at the time of implementation — when a design gets handed from the design team to an engineer for development. Because engineers are people too, and as such, they have opinions on design. 

Tell me if you have heard this one before, designers: you hand a design to your engineering team, and off they run for several agile sprints. Only to have a new, unexpected feature appear in final deliverable that was not part of the original design. This is not malicious. The engineering team does not do it to be a fly in the design ointment. It is meant to fix an issue or address an opportunity found during development. But what was implemented does not match the design narrative, and as such, it can feel out of place — or even contradict what a designer knows to be the natural flow of the user experience. 

I have lived this. A few years back, I was serving as the principal designer on a large product meant to modernize a legacy system. Because we were making the leap to a contemporary code stack from an existing platform, there were behavioral carry-overs from the old system that a junior engineer on the team expected. To their credit, they were right — a certain third-party API response could fail, and there was no handling for it. So, they stayed late, implemented an error banner, pushed it to the repo, and out it went. The problem? It was a stark red banner — a color nowhere in the design system, not complementary to the rest of the UI, and completely disconnected from the visual language we had carefully established. To them, the work was good and complete. I disagreed and tried to educate on why it needed to change. I even wrote the replacement code myself to make the swap as painless as possible. They dug their heels in.  

That is the kind of control tug-of-war I am talking about. A developer is proud of what they delivered. They are hoping you, the designer, are appreciative of the extra effort. And then you ask them to change it. From the engineering perspective, it is more money and more time to change what was already shipped — even if it is something as seemingly simple as a color treatment or a prompt in a multi-step process. Even though you, the designer, are the one responsible for the resulting success of the product from the customer’s standpoint — not from the technology solution’s standpoint. 

Sound familiar? 

From Ping-Pong to a Wheel

Here is what excites me most about what is happening right now: AI tools are helping teams move faster, yes. But more importantly, they are evolving the design-to-engineering handoff and reducing friction in a way that goes beyond speed. They are beginning to bridge the divide. 

These AI tools are shifting the mindset and the way of thinking when it comes to design and engineering teams working together. AI is enabling both teams — design and engineering — to learn from one another at a remarkably fast pace. It’s allowing each side to learn from the other’s area of expertise. And more importantly, it’s helping build a common vernacular that is directly meant to increase speed and success. 

What used to be a ping-pong match — design throws it over the wall to engineering; engineering throws it back with questions (or unsanctioned additions) — is becoming a wheel. A continuous loop of shared stakes, shared responsibility, and shared end goals. 

The Tooling That is Making This Real

Today’s AI tools are growing at an accelerating rate. Even just in the past 30 days, we have had several major features launch that are worth paying attention to. The partnership between Anthropic’s Claude and Figma stands out in particular — because these two platforms have historically lived on opposite sides of the divide. Claude has been primarily an engineering tool. Figma has been primarily a design tool. But what is exciting is seeing both companies build integrations that are not just meant to send work from one platform to the other. They are meant to enable the other platform to send back. 

This is what makes the wheel real. 

Claude Code to Figma: Code Meets Canvas

In February, Figma launched a capability that lets developers working in Claude Code capture live UI — whether from production, staging, or localhost — and convert it directly into editable Figma frames. As Figma’s team put it, the idea is that code is powerful for converging on a single state, while the canvas is powerful for diverging and seeing the full picture. The integration allows teams to move fluidly between the two, so work can narrow when it needs to and open when it is time to collaborate. 

This is significant because it addresses one of the oldest pain points in our industry: the engineer who builds something real and functional but has no painless way to get it back into the design environment for review and iteration. With Claude Code to Figma, that friction point is disappearing. An engineer who has a bright idea about a way to handle an opportunity within the software can now implement a code-based design and share it directly back to Figma for the design team to iterate upon. 

Agents on the Figma Canvas

Recently, Figma took things even further. They opened the Figma canvas directly to AI agents. Using Figma’s MCP server alongside the use_figma tool found in Claude Code, Codex, and other MCP clients, AI agents can now generate and modify design assets that are linked to your design system, directly on the Figma canvas. 

And it doesn’t stop there. Figma introduced something called Skills — sets of instructions written as markdown files that guide how agents build on the canvas. Skills ensure that AI agents have the specialized knowledge and context they need to produce durable, brand-aligned designs. As Cat Wu, Head of Product for Claude Code at Anthropic, described it: skills teach Claude Code how to work directly in the design canvas, so teams can build in a way that stays true to their intent and judgment. There are already nine community-built example skills available, ranging from generating component libraries from codebases to syncing design tokens between code and Figma variables. 

This is incredible. This is allowing the bridge between design and engineering to become, in many ways, nonexistent. It is introducing the future of what a design-and-engineering process can look like. It is no longer a ping-pong match, but an ever-evolving, constantly spinning wheel. As teams begin to adopt this methodology, your team should no longer be able to tell who is driving what part of the process. It becomes one cohesive team with design intent and quality code being the shared end goal — allowing for faster delivery with higher-quality products reaching market sooner. 

A Dose of Honest Realism

Now, I’d be doing you a disservice if I painted this as a frictionless utopia. Because it isn’t — not yet. 

All of these tools being built by Anthropic and Figma are brand new, and they are not without their quirks. If you’re starting from a greenfield project and following the exact process laid out in the online tutorials — using the tools and skills exactly as described — the results can be pretty fantastic. I have seen it work, and when it clicks, it feels like the future. 

But if you are trying to introduce these tools into an already existing ecosystem? That is a different story. Maybe your design team isn’t as fluent in Figma as the industry experts writing the tutorials. Maybe your development team is new to utilizing AI tools, or “vibe coding,” or trusting themselves to lead multi-agentic coding sessions. In those cases, adjusting to this new flow of going from Figma to Claude Code to your codebase, then back to Claude Code, and back to Figma — it is going to feel alien. And it will be full of early-days growing pains. 

I have experienced this firsthand. When I tested the Figma-to-Claude Code workflow, design system components did not always translate cleanly. Results were inconsistent at times and required manual cleanup that chipped away at the time savings the tools are supposed to provide. It is not a knock on the technology — it is the reality of any tool in its early days. The integrations are improving rapidly, but teams adopting them today should set expectations accordingly. 

The key, as it always has been when design teams and development teams work together, is patience. It is about trusting the process of learning, and understanding that you will have to start slow in order to eventually go fast. These tools will mature. Your team’s comfort with them will grow. The workflow will tighten. But you have to give it the room to get there. 

The Unicorn’s Perspective

For the past decade-plus, it has been my responsibility to bridge the gap between design and development. Earlier in my career, people like me were referred to as “unicorns” — someone who could operate on both sides of the divide. I started my collegiate career in computer engineering before realizing I’d rather use the newest computers and technologies to make cool things than to build the computers themselves. The idea of designing a product that people actually enjoyed using, or making a business’s website feel modern and alive — that resonated with me in a way that circuit design never did. So I shifted toward design, carried the engineering mindset with me, and spent my career living in the space between the two. 

That perspective has let me see, for years, that there is a better way to make products look, feel, and act — and also have the understanding of how to make that a reality from the engineering side. 

Today, there are still entire teams, companies, and industries that are not ready to make the shift that these AI tools are enabling. But I believe that very quickly, all of us will be operating from the same sheet of music. Design and development will function as one cohesive unit, and we will not just see incremental improvements across industries — we will see a dramatic shift in the quality of products going to market. 

From where I sit as I type this today, the divide that defined my career is starting to close. And honestly? It is about time.