Design Engineering: The Frontend Job AI Can't Fake (and How to Get In)

Ask an AI model for a dropdown menu and you'll have one in seconds. It opens, it closes, and the code is clean. It also uses transition: all 0.3s ease, slides in from 20 pixels away, and feels slightly off in a way most people can't name but everyone notices.

The gap between "it works" and "it feels right" is turning into a job. Vercel has a whole team for it, and the title on their job posts is design engineer. This post covers what that role is, why motion is the clearest example of the work AI still can't judge, and how to move into it if you already write frontend code.

The squeeze on frontend work is real

Let's start with the uncomfortable part. Stanford's Digital Economy Lab tracked payroll data from millions of US workers and found that employment for software developers aged 22 to 25 fell nearly 20% from its late 2022 peak by September 2025 (Canaries in the Coal Mine, Nov 2025). A February 2026 update put the relative decline for young workers in the most AI-exposed jobs at about 16% (Stanford Digital Economy Lab).

The authors are careful to say AI isn't the only cause. But one finding matters more than the headline number: jobs shrank where AI automates the work, not where it augments it. So the useful question isn't "will AI take frontend jobs?" It's "which parts of frontend work does AI finish on its own, and which parts does it only speed up?"

Where AI stops being useful

AI is very good at the first 80% of UI work. Layouts from a screenshot, forms with validation, a CRUD table, the fortieth variant of a card component. That's exactly the work being automated, and pretending otherwise won't help anyone's career.

The last 20% is different. An AI model can't watch its own output. It doesn't see the menu that lands a frame late, the hover state that flickers, or the button that feels heavy when you press it. It writes the average of everything it has seen, and the average is "fine".

Developers feel this already. In Stack Overflow's 2025 survey, 66% said their biggest frustration was AI answers that are almost right but not quite, and 46% said they don't trust the accuracy of AI output (ShiftMag summary of the survey). In interface work, "almost right" is the whole problem. Users don't read your code. They feel it.

What a design engineer actually does

Vercel's own description is short: "Design Engineers at Vercel blend aesthetic sensibility with technical skills" (Design Engineering at Vercel). In practice, that means one person can take an idea from a rough sketch to shipped code without a handoff in the middle.

Day to day, the work usually looks like this:

• Building and polishing components in a design system, including every state: hover, focus, pressed, loading, empty and error.

• Owning motion: what moves, how far, how fast, and what happens when a user interrupts it.

• Prototyping in code instead of static mockups, so the team can judge how something feels before committing to it.

• Catching the details that never make it into a ticket, like text that wraps badly, focus rings that vanish, or a layout that jumps when fonts load.

The title isn't consistent across companies. You'll see the same work listed as UI engineer, creative developer, design technologist or prototyper. Anna Lefour makes this point well in The Design Engineer symptom: the inconsistency is a sign that teams are still working out what they need as AI blurs the line between designing and building. Read the job description, not the title.

Motion is the clearest test

If you want to see the gap between generated UI and crafted UI, look at animation. Motion happens over time, and time is the one thing a screenshot, a code review or a model reading your diff can't show. You only know if it's right by using it.

Take easing. Every animation has a curve that decides how fast it moves at each moment. Here's the same 300 ms animation with three different curves:

At 100 ms, a linear animation has covered a third of its distance. The CSS default ease has covered about 58%. A strong ease-out like cubic-bezier(0.22, 1, 0.36, 1) is already at 87%. Same duration, but the last one feels much faster, because most of the movement happens while the user is still looking at the thing they clicked.

A dropdown, before and after

This is the kind of CSS you'll get from a quick prompt:

.menu {
  transition: all 0.3s ease;
}

.menu[data-state="closed"] {
  opacity: 0;
  transform: translateY(-20px);
}

Nothing here is wrong. It just isn't decided. Here's the same menu with each choice made on purpose:

.menu {
  transform-origin: top left; /* grow out of the trigger */
  transition:
    opacity 150ms cubic-bezier(0.22, 1, 0.36, 1),
    transform 200ms cubic-bezier(0.22, 1, 0.36, 1);
}

.menu[data-state="closed"] {
  opacity: 0;
  transform: scale(0.96) translateY(-4px);
  transition-duration: 120ms; /* closing is faster than opening */
  pointer-events: none;
}

What changed and why:

• Named properties instead of all. all animates anything that changes, including colours and sizes you never meant to animate. Listing opacity and transform keeps it predictable and cheap for the browser.

• A shorter distance. Moving 4px and scaling from 0.96 makes the menu look like it grows from its button. Moving 20px makes it look like it flew in from somewhere else.

• Ease-out for things that appear. The menu should arrive quickly and settle, not build up speed.

• A faster exit. The user has already decided to close it. Making them watch a slow exit is wasted time. Because transition-duration sits on the closed state, it only applies when the menu is closing.

Use transitions for things people interrupt

If a user opens and closes a menu quickly, a CSS transition reverses from wherever it currently is. A keyframe animation restarts from its first frame, which makes the menu jump. For anything interactive, like menus, toggles and drawers, reach for transitions first and save @keyframes for things that play once, like a loading shimmer.

Respect reduced motion

Some people get dizzy or nauseous from movement on screen, and they can tell the OS to reduce it. Reduced motion doesn't have to mean no feedback. Keep the fade and drop the movement:

@media (prefers-reduced-motion: reduce) {
  .menu,
  .menu[data-state="closed"] {
    transform: none;
    transition-property: opacity;
  }
}

An AI model will add this if you ask. The skill is knowing to ask, and checking that the result still makes sense.

Use new platform features with a fallback

CSS scroll-driven animations let you tie an animation to scroll position with no JavaScript. They work in Chrome and Edge since version 115 and Safari since 26, but Firefox still doesn't support them as of October 2026 (web-features explorer). So wrap them in @supports and make sure the page is fine without them:

.reading-progress {
  transform-origin: 0 50%;
  transform: scaleX(0);
}

@supports (animation-timeline: scroll()) {
  .reading-progress {
    animation: grow-progress linear both;
    animation-timeline: scroll(root);
  }
}

@keyframes grow-progress {
  to { transform: scaleX(1); }
}

In Firefox, the progress bar simply doesn't show. Nothing breaks. Knowing which features are safe today, and what the fallback should be, is part of the job. If you want to go further with page-level motion, my post on React ViewTransition in Next.js covers shared element transitions without a library.

How to move into design engineering

If you already write React or plain HTML and CSS, you're closer than you think. The gap is mostly in how you look at interfaces, not in a new framework.

1. Train your eye before your hands

Pick two or three apps you think feel good and study them on purpose. Screen-record an interaction and step through it frame by frame. On the web, open Chrome DevTools, find the Animations panel, and slow animations down to 10% to see exactly what moves and when. Write down what you notice: which elements move together, which move first, how long things take.

2. Rebuild one small interaction a week

Not a whole app. A toggle, a toast stack, a number that counts up, a bottom sheet you can drag to dismiss. Build each one in a single page and keep short notes on what you changed and why. After a few months, that folder is worth more than another to-do app.

3. Learn the tools in order

• CSS transitions and @keyframes, until you can write a good ease-out curve from memory.

• The Web Animations API, for when you need to control animations from JavaScript.

• A library like Motion (formerly Framer Motion) for springs, gestures and layout animations in React.

• The View Transitions API for moving between pages and states.

4. Learn enough design to argue for your choices

You don't need to become a designer. You need to understand type scales, spacing, colour contrast and visual hierarchy well enough to explain why something looks off. Refactoring UI by Adam Wathan and Steve Schoger is a practical place to start. Learn Figma well enough to inspect a file and build from it without asking for every value.

5. Let AI do the first 80%

This is the part people get backwards. Don't avoid AI tools to prove you're a craftsperson. Use them to scaffold the boring parts quickly, then spend the time you saved on the details they miss. If you work with coding agents, giving them good context helps a lot. I wrote about that in AGENTS.md in Next.js 16.3.

6. Show your work in motion

A static screenshot can't show what you're good at. Put short screen recordings in your portfolio, ideally with a before and after, and a sentence or two on what you changed. A recording of a menu going from "generated" to "considered" says more than a list of skills.

7. Know where to look

Search for the related titles too: design engineer, UI engineer, creative developer and design technologist. These roles tend to show up at product companies that care a lot about craft, on design system teams, and at studios that build marketing sites. Many are remote, so where you live matters less than what you can show.

An honest caveat

AI will get better at defaults. In a year or two, "use ease-out and keep it under 300 ms" may be something tools do on their own. If your value is a list of tricks, that list will shrink.

What lasts is judgment: noticing when something feels wrong, testing it with real people, and caring enough to fix the detail nobody filed a ticket for. The World Economic Forum expects 39% of workers' current skills to be transformed or outdated between 2025 and 2030, and lists creative thinking among the skills expected to keep growing in importance (Future of Jobs Report 2025). The skill isn't a technique. It's the habit of paying attention.

Where to start this week

Open an app you use every day, record one interaction, and slow it down. Then rebuild it from scratch and compare the two side by side. The first time you notice a 50 ms difference you couldn't see before, you've started.