RipeSeed Logo

AI Is Creating a New Role: “The Design Engineer”

July 6, 2026
There's a quiet shift in every product team as AI blurs the line between design and engineering. In a real Garden AI feature, defining hierarchy and behavior before visual design turned a week-long process into a day.
AI Is Creating a New Role: “The Design Engineer”
Fatima Farooq
UI/UX Designer
6 min read

There's a conversation happening inside every product team right now, whether people are saying it out loud or not. The line between designer and developer is getting blurry, and AI didn't just nudge it. It's erasing it.

I felt this firsthand. Not from a trend report, but from inside a real feature build.

The old process

A new requirement lands. First instinct: open a new Figma file, start pulling references. But you can't really design something you don't fully understand yet. You need to understand what's technically feasible before you design anything.

  • What would this break? 

  • What constraints exist?

  • What does the data model look like? 

That meeting takes a few days to schedule. Then you research, iterate, present multiple directions, the client picks one, you revise. By the time a design is finalized - a week is gone. Sometimes two.

Nobody's doing anything wrong. That's just how it worked. Design and engineering lived in separate rooms, passing notes under the door.

What changed

I was working on a feature for Garden AI, a Dutch garden management platform. 

The ask: commercial users - think building managers and landscape contractors overseeing multiple properties - needed a way to organise a large garden into borders, break each border into sub-borders, get plant suggestions per section, and swap plants in and out as their plan evolved. 

Not a tracking tool. A planning tool. The hierarchy existed so a user could carve up a complex garden into manageable sections, let the platform suggest plants for each one, and iterate on the plant selection until the design felt right. 

Old me would have scheduled that developer meeting immediately.

Instead, I opened Claude and described the requirement. And something different happened - rather than getting answers, I got questions back. 

What's the primary job at the sub-border level - is the user curating a plant palette, or comparing suggestions side by side? If a user swaps a plant, does that affect suggestions for other sub-borders in the same border, or are they independent?

These were the exact questions I would have been asking a developer three days later. But I was answering them now, before touching Figma, before committing to any visual direction. Working through them forced me to define what the hierarchy was actually for, how plant suggestions should behave, and what interaction model made sense for someone planning at scale - all in a two-hour conversation.

When I finally opened Figma, I wasn't guessing anymore.

The feature that would have taken a week was designed, iterated, and finalized in a day.

What the iterations actually looked like

Once the structure was clear, I used Claude to explore layout directions before opening Figma. The prompts weren't "design me a screen" - they were functional: 

Given a user managing 3 gardens, 7 sub-borders, and 42 plants , what should be visible at a glance on the overview screen versus one click deeper?

That kind of question produces architectural decisions, not just aesthetic ones.

The first iteration focused on the garden-level overview’ a card layout showing each border with its sub-border count, plant count, and dimensions at a glance. Fast read for a commercial user who needs to see how a full property is shaping up before drilling into any individual section.

The second went a level deeper: the border detail view, where the real planning happens. Plant suggestions in a browsable grid with species info and pricing, the ability to swap any plant out, and sub-borders listed below so the user can plan section by section. Soil type, light conditions, and dimensions surfaced as context so suggestions actually match the environment.

And then the final Figma design - the full project view where a commercial user sees all their borders at once, drills into any section, browses plant suggestions, and swaps them out until the plan is right.

These weren't throwaway wireframes. They became the structural foundation for the final Figma design. The difference: I wasn't iterating to find the right structure. I already knew it. I was iterating to validate the execution.

The shift nobody's talking about

Here's the thing: AI didn't make me a better visual designer. What it did was make me think like an engineer before I started designing.

That's the actual gap that's closing.

Traditionally, design and engineering were sequential. The designer hands over screens, the developer builds them, and somewhere in that handoff, things get lost - constraints that weren't communicated, edge cases that weren't considered, interactions that cost three times more to build than the designer realized. The feedback loop is slow and expensive.

What AI does is collapse that gap at the start of the process. When you're forced to articulate a feature in enough detail for Claude to ask you the right counter-questions, you've already done the engineering thinking before you've drawn a single frame. You arrive at Figma with a design that's not just visually considered - it's functionally coherent.

That's a fundamentally different way of working. And it's creating a new kind of designer.

The design engineer

Some companies are already giving this role a name. Vercel has an entire Design Engineering team. Linear, Stripe, Airbnb have been quietly hiring for it. The job isn't "designer who can code" - it's a designer who thinks across the full product system. Someone who, when a feature requirement lands, is already thinking about data flow, edge cases, error states, and implementation cost, not just layout and color.

The designers who are thriving right now aren't the ones who learned to code. They're the ones who learned to think like engineers and AI is making that skill dramatically more accessible.

What this means for you

If you're a designer: the bar isn't to become a developer. It's to understand enough about how things are built that your designs survive contact with engineering. Use AI not to skip thinking, but to think more - ask it to poke holes in your approach before your developer does.

If you're a developer: the designers coming into your team are going to arrive with more technical context than before. That's a good thing. The handoff conversation changes when the designer has already stress-tested the logic.

The line between these two roles isn't disappearing - but it is shifting. The best product work has always happened in the overlap. AI is just making that overlap bigger, and easier to stand in.

RipeSeed - All Rights Reserved ©2026