DEV Community: Phillip Lovelace

The AI Productivity Paradox

Phillip Lovelace — Sun, 22 Feb 2026 01:36:26 +0000

Satya Nadella said AI would fuel a "creative revolution." GitHub told us Copilot would let developers "focus on creative and strategic work." Sam Altman measures ChatGPT's success by the percentage of human work it can accomplish. So why am I spending more time reviewing and fixing AI output than I ever imagined?

I'm not here to trash AI. I use it every day. But I need to talk about the gap between what we were promised and what actually showed up, because I don't think I'm the only one feeling it.

The Promises They Made

The pitch was straightforward. AI handles the mundane stuff, the boilerplate, and the grunt work, and you get to spend your time on the interesting problems. GitHub's own research claimed developers using Copilot were 55% faster and that 87% felt it preserved mental effort during repetitive tasks. Nadella called AI "bicycles for the mind" and talked about a future where a billion people could create on Microsoft's platforms.

Who wouldn't want that? Hand off the boring stuff, keep the fun stuff. More time to think and create. More time to actually use the skills you spent years developing.

That's not what happened.

What Actually Happened

AI made producing things fast. Ridiculously fast. Code, documentation, copy, design specs — you can generate a first draft of almost anything in minutes now. The problem is that producing was never the hard part. Thinking was the hard part. Making good decisions was the hard part. AI doesn't do that for you. It just gives you a pile of "done" that isn't.

So now you review. Everything. You review your own AI-generated output because you didn't actually write it. You prompted it, and prompting and writing are not the same cognitive process. You review your teammates' AI-assisted work because they're shipping faster too, and somebody has to make sure it all holds together. The volume of stuff landing on your desk went up. The quality bar didn't move. You became the quality bar.

The research backs this up. A study on arXiv found that AI-assisted programming actually decreases the productivity of experienced developers by increasing technical debt and maintenance burden. Experienced developers reviewed 6.5% more code after Copilot's introduction but saw a 19% drop in their own original output. A randomized controlled trial by METR found something even wilder: experienced open-source developers were 19% slower when using AI tools. And the kicker? They still believed AI had sped them up by 20%. We can't even tell it's not working.

And this isn't just a code problem. Anything AI generates — whether it's a blog post, a design comp, a project plan, or even a Slack message — needs a human to look at it before it ships. We didn't eliminate work. We changed who does what. AI produces. You QA.

Are We Losing the Muscle?

This is the part that worries me. When I used to build something from scratch — write a component, architect a system, draft a document — I was exercising a creative muscle. I was making hundreds of micro-decisions along the way, and each one built intuition. The act of producing wasn't just about the output. It was about what the process did to my brain.

Now I spend a lot of that time reading something else's work and deciding if it's good enough. That's a different cognitive mode entirely. Reviewing is not creating. They're both valuable, but they're not the same skill.

I think about junior developers coming up right now. If they're leaning on AI to produce from day one, when do they develop the instincts that come from struggling through problems yourself? When do they build the taste that comes from making things badly, learning why, and making them better? You can't shortcut that with a prompt. And if we're all just reviewing AI output instead of producing our own work, I'm not sure how we keep that muscle from atrophying.

More Work, Different Shape

I'm not anti-AI. I use Claude, I use Cursor, and I use AI tools constantly. They're useful. But the narrative that AI reduces your workload? That hasn't been my experience. The workload didn't shrink. It shapeshifted.

Producing got faster, but reviewing and fixing filled the gap and then some. And the expectation from the outside didn't adjust. If AI makes you faster, you should be producing more, right? Nobody factors in the review burden. Nobody accounts for the time spent wrestling mediocre AI output into something that meets your standards. The labor moved downstream and became invisible.

I keep coming back to one question: when does the promise actually land? When does AI get good enough that the review burden drops below what the production burden used to be? Maybe that's next year. Maybe it's five years out. Maybe the answer is that creative work was never about efficiency in the first place.

I Want to Know

I don't have a clean answer here because I don't think there is one yet. So instead I'll ask: is this your experience too? Has AI freed up your creative time, or did it hand you a different pile of work? Are you producing more, or just reviewing more? Are you getting better at your craft, or getting better at evaluating someone else's approximation of it?

I'd love to hear from people who feel like AI has given them their time back. Genuinely. Because I'd like to know what I'm doing wrong.

Why AI Needs UX Developers

Phillip Lovelace — Sat, 21 Feb 2026 00:15:46 +0000

The UX developer role has always been hard to explain to everyday folks. “So you design stuff?” Not exactly. “So you code stuff?” Sort of. For years, people who sit between design and engineering have fought for a seat at a table that wasn’t really built for them. Then AI showed up and flipped the whole thing.

Being a UX developer comes with a built-in identity crisis. You’re not designer enough for the design team and not engineer enough for the engineering team. Your title changes every two years depending on which LinkedIn trend is peaking. “UI developer.” “Design technologist.” “Frontend engineer.” The work stays the same. You’re the person translating between two groups that speak different languages, making sure what gets built actually matches what was intended.

For most of my career, that translation work has felt undervalued. Orgs didn’t know where to put us, so they just kept reorganizing until it was someone else’s problem. We’d get shuffled between departments. Left off project kickoffs. Skipped in planning. Then someone would ask us to justify why our role existed at all, because “the designers can just hand off specs and engineers can just build them.” Sure. And you can also throw a football at someone’s face and call it a pass.

What AI actually needs

Here’s what’s changing. AI tools can generate UI code at a speed that would’ve seemed absurd three years ago. You can describe a component in plain English and get something functional back in seconds. That’s impressive, and it’s only getting better.

But generating code isn’t the hard part. It never has been. The hard part is generating the right code, code that respects your design system’s API conventions, uses the correct tokens instead of hardcoded values, follows your accessibility patterns, and fits into the architecture your team has been building for years. AI doesn’t know any of that unless someone teaches it.

That “someone” is the person who already understands both sides. The person who knows why the design team chose a specific spacing scale and how the engineering team implements it. The person who can look at AI-generated output and immediately spot that it’s using the wrong component variant or ignoring a semantic token that exists for exactly this use case.

That’s the UX developer. That’s the bridge role. The one that your org still can’t figure out where to put on the chart.

The new leverage

What’s wild is that the day-to-day work of a UX developer, writing component documentation, defining token taxonomies, and building usage guidelines, is now directly feeding AI systems. The documentation you write becomes the context window. The component API you designed becomes the constraint that keeps generated code on the rails. Those design decisions you encoded into tokens? That’s the vocabulary AI uses to make choices.

This isn’t theoretical. I’ve been building MCP servers and Claude Code skills that let AI tools interact with our design system directly. The whole exercise is bridge work. You need to understand the design intent deeply enough to encode it as rules, and you need to understand the engineering architecture well enough to make those rules actually useful in a development workflow. Strip out either side, and the whole thing falls apart.

The UX developer role went from “nice to have” to a force multiplier. When AI can generate code but can’t generate judgment, the person who provides that judgment is steering the ship. You’re not slowing things down. You’re the reason the output is actually usable.

Stepping into it

I’m not writing this to celebrate a victory; it’s obviously still wild out here. The role still presents the same challenges it has always had: ambiguity, peculiarities in the organizational chart, and ongoing explanations. However, the leverage has changed. If you’ve spent years building the connection between design and engineering, you possess the exact skill set that enables AI to be useful rather than just quick.

Take ownership of it. Define how AI interacts with your systems. Create documentation that serves as the training context. Develop the tools that ensure the generated output aligns with your team’s standards. It turns out we’ve been building this bridge the whole time. The only thing that changed is that everyone, including the robots, now needs to cross it.

Design Systems Are Having Their Moment

Phillip Lovelace — Tue, 17 Feb 2026 00:09:57 +0000

I keep seeing the same conversation play out online. AI is going to replace designers. AI is going to replace developers. AI is going to make everything faster and cheaper, and we should all be terrified or thrilled depending on who you follow on LinkedIn.

But there’s something I think people are sleeping on. AI coding tools are only as good as the constraints you give them. And what’s a design system if not a carefully defined set of constraints? AI doesn’t make design systems obsolete. It makes them necessary.

AI code is only as good as its guardrails

Here’s what I’ve learned from working with AI coding tools daily: they’re fast. Really fast. But speed without direction just means you get to the wrong place quicker.

LLMs generate code based on patterns. When you give them clear boundaries, specific component APIs, defined token values, and documented interfaces, they produce consistent output. When you don’t, they improvise. And LLM improvisation looks like slightly different button styles on every page, spacing that’s close-but-not-quite, and color values that came from who knows where.

A design system is basically a prompt engineering layer for your entire UI. You’ve already done the hard work of defining what “correct” looks like. Now AI can actually use that.

Tokens are the new API

Design tokens have been quietly important for years. In an AI-driven workflow, they become load-bearing.

When an AI agent can read your token taxonomy, your semantic color names, your spacing scale, and your typography ramp, it doesn’t have to guess at your brand. It knows. It’s not picking #3B82F6 because that’s what blue looks like in its training data. It’s picking color.action.primary because that’s what your system defines.

We’re already seeing this with tools like Figma’s MCP server, which feeds real component data, styles, and variables directly to AI agents. When those elements map to actual code through something like Code Connect, the agent isn’t hallucinating your UI. It’s being built with your real parts.

Tokens aren’t just a way to sync Figma and code anymore. They’re the shared language between humans, tools, and AI. The API your AI agent consumes to build things that actually look like they belong in your product.

Smaller teams, bigger systems

AI coding changes the economics of design systems in ways I don’t think enough people have caught on to yet.

Building and maintaining a component library used to require serious headcount. Dedicated engineers, designers, and documentation writers. A lot of orgs looked at that investment and said, “not right now.” So they shipped without a system and accumulated UI debt instead.

AI changes that equation. The bottleneck isn’t building components anymore. An AI agent can scaffold a component in minutes. The bottleneck is defining the rules. Token naming conventions. Component API patterns. Governance decisions about what goes in the system and what doesn’t. The thinking work.

That’s good news. A two-person team with clear opinions and good token architecture can maintain a system that used to require a squad. Orgs that couldn’t justify a design system team before, suddenly can.

The drift problem gets worse without a system

Here’s what should worry you if your org doesn’t have a design system: more people are about to ship more UI code, faster than ever.

Vibe coding is real. Product managers, designers, junior devs, and people who weren’t writing frontend code six months ago are now generating it with AI tools. That’s exciting. But every person generating UI code without shared constraints is another source of inconsistency.

Without a design system, you get ten different interpretations of what a simple component should look like. Ten slightly different button sizes. Ten versions of your brand color that are all close, but none of them match. AI doesn’t fix this. AI accelerates it.

A design system is the immune system. Not blocking people from shipping, but keeping what they ship coherent. The AI generates the code, and the system provides the grammar.

The strongest argument you’ve ever had

I’ve spent years in the design systems space, and I know how hard it can be to justify the investment to leadership. The ROI conversation never gets easier. “Consistency” and “reusability” are real, but they don’t always move the needle in a budget meeting.

AI coding just changed that conversation. Without a design system, your AI tools produce inconsistent output. With one, they produce on-brand, accessible, production-ready UI. That’s a direct line from design system investment to AI tool effectiveness. It’s the clearest ROI story design systems have ever had.

Design systems aren’t competing with AI. They’re the infrastructure AI needs to do its job well. The orgs that figure this out early will ship faster and stay more consistent.

If you’ve been building and maintaining a design system, your work should be becoming more valuable. If you haven’t started one yet, AI coding just handed you the best reason to.

More from Pixelflips

This post was originally published on *Pixelflips*. If you enjoyed this, I dive deeper into design systems and the intersection of UX and engineering over on my personal blog. I'd love to hear your thoughts in the comments!