As Ted Lasso explains it, “yes” opens the door and “and” lets people walk right on through it. Or, as Coach Beard puts it: “Yes and, baby.”

I keep having the same conversation. With my team, with friends, with family who still think I “do computers.” Most people use AI like a really good Google. Ask it something, get an answer, maybe have it clean up an email. Which is great! But it’s kind of like buying a car and only using the cup holders.

And it’s not just my friends. Microsoft’s 2026 Work Trend Index surveyed 20,000 AI users and found only about 16% regularly hand it real, multi-step work. Stack Overflow’s 2025 survey tells a similar story for developers: 84% use or plan to use AI, but only 31% regularly use agents.

Meanwhile, I’ve been pushing AI on side projects to see how far it goes, and it keeps surprising me. Stuff that used to take weeks takes a day or two. And a lot of the steps I’ve followed my entire career as a front-end engineer are changing shape.

What finally got me writing this was a conversation with a designer I work with. I’d thrown together three quick, super interactive mockups for a client build, partly because I was getting a little stir crazy building the same kinds of designs over and over. He wanted to talk through how we could change our workflows and handoffs to do that kind of creative work more often, the stuff that’s hard to pull off in Figma today. Somewhere in that conversation it clicked. If we can throw something like that together that fast, what would it look like to rethink how design and development work together? Not just the handoff. How we plan, what we deliver and how we show up for the people we build for.

Quick disclaimer: I don’t have all the answers. And if parts of this make you a little nervous, same. It’s exciting and kind of scary at the same time, and I think both feelings are fair. This isn’t about needing fewer designers or developers. It’s about changing how we work.

The quick answer

How is AI changing the design-to-development workflow? AI can now produce hi-fi mockups, working prototypes, 3D scenes and animation code in hours instead of weeks. That shrinks the slow, handoff-heavy steps (wireframes, static comps, specs) that most design and dev processes were built around. The time that frees up can go into more ambitious work, like motion, interactivity and automation, and into being a real partner to clients instead of a vendor who only builds what’s asked.

Key takeaways:

• Most design and dev processes were built for a time when making things was slow and expensive. That’s no longer true.
• Designers and developers aren’t going away. Taste, research and judgment matter more when making things is cheap.
• The biggest opportunity is the “and”: delivering the ambitious version, and automating the manual work clients never have time for.

Why were design and development workflows built for slow?

For the last decade or so, designers and developers have built a whole system for working together. Wireframes, then mockups, then prototypes. Figma files with an “explorations” page, a “final” page and a “final FINAL (use this one)” page. Component libraries, design tokens, design systems with governance, handoff specs, Dev Mode, ticket templates. You know the drill.

Most agencies and product teams have a formal version of this too: a playbook with phases, who’s in each one and what gets handed to who. And to be clear, it’s good! It exists because it solved real problems. Clients needed to see something before anyone spent months building it. Design and dev needed a shared language. Big teams needed consistency.

But all of it was built for a world where making stuff was slow and expensive. A hi-fi mockup took days. A working prototype took a sprint. So we built a lot of process to make sure we only built things once.

The kicker is that these systems take forever to set up, and even longer to get everyone actually using them. The bigger the company, the harder it is to change course. By the time something’s documented, trained and followed, the ground has already moved.

What does an AI-first design workflow look like in practice?

I’ve been testing this on a couple of side projects. The interesting part isn’t what I built. It’s how the familiar steps of the process changed shape along the way.

Wireframes became one evening of live exploration

Orbit is an interactive family tree I’ve been building on the side. Instead of the usual boxes-and-lines chart, it shows each branch as a little solar system, with a 3D globe of where everyone lived and a timeline set against world history. Normally I’d pick a direction, wireframe it, then mock it up. This time I had AI build four totally different directions (a galaxy, an atlas, a canvas and a storybook), all working, and I picked one by clicking around in them. On a typical client project, that’s a few rounds of comps and a couple of weeks.

The mockup became the sign-off

If Orbit was about exploring directions, my other side project, Solstice, was about skipping steps entirely. It’s a dashboard for my home’s solar panels and Tesla Powerwalls, and there was never a Figma file. Every screen started as a clickable HTML mockup that I looked at on my phone and said yes or no to, and then it got built for real. Idea to working app: about a day and a half.

The “phase two” feature took one conversation

I wanted to show Solstice to people, but it’s full of personal stuff. On a normal project, a sharing system with a guest view and rules about what’s hidden would be its own ticket. Estimate it, scope it, push it to phase two. Here it was literally one more conversation.

The stuff design tools never handled well came along for the ride

Live 3D with three.js, real data and fancy animation all came out of the same conversation as layout and color. And it doesn’t stop at visuals. Orbit has guided tours now, narrated by an AI version of my own voice (via ElevenLabs) with custom music made in Suno. Try handing that off in a Figma file. A teammate of mine saw the same thing: a three.js scene that took him more than four months a few years ago took about six hours this time.

It wasn’t magic

I had to add a rule telling the AI to only change what I asked for, because it kept “improving” parts of the screen I never mentioned. I also had to spell out that me asking a question is not me saying yes. I tossed a bunch of mockups. The judgment calls were still mine. What changed was how fast I could see an idea, react to it and move on.

And I want to be really clear about this part: none of it made design or engineering skills matter less. If anything, they mattered more. The AI didn’t know which Orbit direction was right, or which Solstice screen actually made sense to a real person. Taste, research and judgment did the real work. The tools just made it faster to get to the part where those skills count.

Do you still need detailed AI rules, prompts and skills?

Less than you used to, and this one surprised me more than the speed.

A year ago I’d have spent the first chunk of any project writing rules files, style guides and skills just to get the AI to behave. Solstice’s whole instruction file is about 70 lines, and most of it isn’t “here’s how to code.” It’s guardrails. Don’t touch the pool controller unless I ask. Keep personal info out of the repo. Show me a mockup before you build anything. It already knew how to write decent TypeScript. It just needed to know what I cared about.

The funny part is I can see the shift in my own writing. In March I wrote about my AI workflow for a 200K-line app, and the whole point was the system around it: 8 instruction files, 11 rule files, hooks and 9 skills. That was the right call then. Six months later I’m using a fraction of that and getting about the same results.

Anthropic is seeing it too. In July 2026 they said they removed over 80% of Claude Code’s system prompt with no measurable loss on their coding evals, because newer models have better judgment and need fewer explicit rules.

There’s still a good case for skills. They’re great for capturing the things that make your team’s work feel like yours: tone, quality bar, the non-negotiables. Where I get less sure is the big, heavy, built-to-last stuff. If AI keeps roughly doubling the length of tasks it can handle on its own every several months (that’s more or less what METR has been tracking), a system you spend six months defining could be half out of date by the time it rolls out. Sometimes the best thing to build is less.

Is Figma dead?

No, but the “design file, then handoff” model might be. I’m treading carefully here, because I love Figma. It changed how designers, devs and clients work together, and a lot of us built careers on it. But when AI can spit out a hi-fi mockup, a working prototype, a color system, a three.js scene and the animation code in one go, it’s fair to ask what the design file is actually for.

Fun fact: this post is kind of proof. It started as a messy brain dump of stuff I’d been chewing on for months. I tossed it at AI, and instead of just fixing my typos, it went and found research I’d never seen. The weird part was seeing how many people are landing in the same spot:

• The design process is changing at the top. Jenny Wen, head of design for Claude at Anthropic, said on Lenny’s Newsletter that the process designers were taught is “basically dead.” She spends far less time mocking and far more time pairing with engineers.
• Designers are shipping code. Figma’s 2026 AI report found the share of designers doing development work rose from 21% to 41%. A Designer Fund survey of 900+ designers found half have shipped AI-generated code to production.
• Figma is evolving, not dying. Figma Make, its MCP server and Code Layers all pull code into the canvas, and Q2 2026 revenue grew 48% year over year. So maybe it’s less “Figma dies” and more “Figma turns into something we barely recognize.”

The stat that stuck with me most came from McKinsey’s 2026 State of AI report. The companies actually getting value out of AI were far more likely to have redesigned their workflows, instead of bolting AI onto the old way. Making the old process faster is the easy part. Asking whether you need it at all is the hard part.

One thing isn’t changing: when everyone can build, judgment becomes the scarce skill. Making stuff is getting cheap. Knowing what’s worth making isn’t.

What should designers and developers do with the time AI saves?

This is the part I’m actually excited about. For years, a huge chunk of every project went to the slow stuff: wireframes, rounds of comps, specs, handoff, then rebuilding what the file said in the browser. That’s where the time and budget went.

If that part gets way faster, we get time back. And every designer and front-end developer I know already knows what they’d do with it, because we say it in every retro: “we’d love to, but there’s no time or budget.”

• Real animation and motion, not just another fade-in on scroll (the View Transitions API alone opens up a lot)
• Interactive stuff people actually want to play with, like tools, configurators and data they can poke at
• 3D and data visualization
• Turning a brochure site into something people actually remember

Be a partner, not a mechanic

That also changes the relationship with clients. I think of it as mechanic vs. partner. With a mechanic, you drive in, say “fix this” or “add that,” they do exactly that, hand back the keys and send the bill. Totally fine work. But it’s transactional, and it’s easy to shop around. And when budgets get tight, the vendor that’s just keeping the lights on is the first thing that gets cut.

A partner does the “yes, and.” (Coach Beard would add “baby.”) “Yes, we can fix that. And while we’re in there, we can also do this, for the same budget.” Maybe that’s an interactive that turns a flat page into something people play with. Maybe it’s a data viz that makes their story click. Maybe it’s the big version of the idea they figured wasn’t possible on their timeline.

We didn’t skip that stuff because we were short on ideas. We skipped it because the slow parts ate the time and budget. If AI gives some of that back, the “and” stops being a phase-two pitch and turns into something you can deliver in the same project. A lot of the industry still seems slow to jump on this, which feels like an opening to me.

Can AI automation be part of the “and”?

Yes, and it might not even be a website. Cooler front ends are one kind of “and.” My side projects pointed me at another one: the stuff nobody has time for.

• The forgotten backlog. I’ve maintained a WordPress plugin, Zero Spam for WordPress, for over 12 years. There were stretches where years went by without an update because, well, life. Sound familiar? That’s every client’s backlog. Now updates, new features and even the marketing around it mostly get done with AI.
• The manual grind. My wife and I sell comics and collectibles on the side, and inventory, price research, shipping labels and customer messages used to eat our evenings. Most of that runs on its own now, and I’m tinkering with automating our live Whatnot auctions too.
• The stuff that was never worth doing by hand. With ForexFlow, my trading side project, I can run strategies that only make small wins. Never worth hours of staring at charts, but worth it when a system does the staring. (Not financial advice!)

None of that would show up on a typical web project scope. But pretty much every client has their own version of these problems: the product nobody’s had time to touch, the manual inventory process, the marketing that never happens, the customer emails piling up.

That’s where “yes, and” gets really interesting. “Yes, we’ll build the site. And we noticed your team spends hours a week doing this by hand. Want us to automate it?” If you’re the people clients call to help automate their own work, not just build their front end, you’re not the mechanic anymore.

Is personalized software replacing one-size-fits-all apps?

Maybe, and it might be the biggest shift of all.

I’ve always had a running list of app ideas I’d “get to someday.” Now I actually get to them, and I’ve started canceling subscriptions and building my own. Solstice replaced a $20-a-month solar monitoring service that gave me four static screens and some graphs. Mine does what my house actually needs, because it was built for my house and nobody else’s.

Naturally, the next thought is “package it up and sell it!” But then the old math kicks in. Open sourcing or selling something means support, docs, feature requests and edge cases. And my setup probably doesn’t match yours. Different battery, different utility, no pool.

Software has been built one-size-fits-all for decades because building was expensive and the cost had to be spread across a lot of people. Products get built for everybody, which usually means they fit nobody perfectly. Every new user wants one more feature, the thing bloats, and most people end up paying for (and scrolling past) stuff they’ll never use.

If a friend wanted their own Solstice, I probably wouldn’t hand them mine. I’d just build them one. It’d be faster than turning mine into a product, it’d do exactly what their house needs, and with AI in the mix, keeping it running is easier and cheaper than maintaining one big shared app.

Now think about that for agencies. The classic pitch is “we built this great platform and other clients love it.” What if it turns into “we’ll build something just for you, around how your business actually works, in less time than it used to take to customize someone else’s thing”? Even in-house starter kits and frameworks get this question. They’re great for getting any developer up to speed fast, but a lot of project time goes into turning off and ripping out features a client doesn’t need. If AI can build exactly what’s needed in about the time it takes to strip a starter kit back, does the shared framework still earn its keep?

Questions I can’t answer (yet)

No neat conclusions here. Just the questions I keep chewing on, and I’d love for more than designers and developers to chew on them with me.

• What if the prototype is the spec? What if design and dev start in the same working prototype on day one, and the “handoff” disappears because nobody’s handing anything off?
• Where does the design system live? A Figma library? Code? A short list of principles AI can apply anywhere?
• What do clients actually need to sign off on? A static comp, or something they can click around, break and react to?
• Which processes still earn their keep? And which ones only exist because building used to be expensive?
• What does planning look like if building takes a day instead of a sprint?
• What does “yes, and” look like in a contract? If you can deliver more for the same budget, how do you scope it, price it and talk about it?
• How do we bring everyone along? How do we make it safe to learn, experiment and say “I’m not sure about this” out loud?
• How do we keep the good stuff? Research, taste, systems thinking, actually talking to each other. The same Designer Fund survey found designers reporting less collaboration since AI showed up jumped from 5% to 20%. Faster on its own isn’t the goal.

I don’t think anyone figures this out by writing a new process doc (yes, I see the irony). We figure it out by trying stuff, sharing what works and being upfront about what doesn’t.

So tell me: what’s one thing in your workflow you’d delete tomorrow if you could? Or one thing about all this that worries you? Concerns are just as useful as ideas. Reach out, I’d love to hear it.

Frequently asked questions

Sources

• Microsoft 2026 Work Trend Index via GeekWire (May 2026)
• Stack Overflow 2025 Developer Survey: AI (July 2025)
• Anthropic: The new rules of context engineering (July 24, 2026)
• METR: Time Horizon 1.1 (January 29, 2026)
• Lenny’s Newsletter: The design process is dead, with Jenny Wen (March 2026)
• Figma 2026 AI Report
• Designer Fund: AI in Design 2026 (May 20, 2026)
• Figma Q2 2026 financial results (August 5, 2026)
• McKinsey: The State of AI (August 2026)