The Designer Who Codes: Finding Your Place in a Vibe Coding World

I'd tried to learn to code before. Multiple times, actually. I picked up some front-end basics; HTML, CSS, enough JavaScript to be dangerous. I even dabbled in Python for a while. But it never quite clicked with me. The process felt tedious, disconnected from the creative work I loved, and eventually I'd drift back to Figma, back to design, telling myself that coding just wasn't my thing.

Then August 2024 happened. AI coding tools had been getting better, but something clicked for me that month. I started using them seriously, not just experimenting but actually building. And within months, everything changed. I built six Figma plugins that are now used by over 55,000 designers. I built Twibble, a Tinder-like restaurant matching app for friends and groups. I started building Pewbeam, a church technology product involving real-time Bible verse projection—the kind of technical complexity that would have been completely out of reach for me a year earlier. Today, I position myself as a design engineer, someone who can take a product from concept to code. Not because I finally mastered traditional programming, but because the rules of the game changed entirely.

If you're a designer wondering whether you should learn to code, whether you should chase this "design engineer" title that keeps popping up in job listings and Twitter threads, you're asking the question at the most interesting possible moment.

Finding Your Place in a Vibe Coding World

The Vibes Are Real

Let me tell you about vibe coding, because if you haven't heard the term yet, you will soon. Collins Dictionary named it Word of the Year for 2025. Andrej Karpathy, one of the co-founders of OpenAI, coined it in February, describing it as a way of building software where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists."

What does that actually mean? It means you describe what you want to an AI, in plain English, in your normal words, and the AI writes the code. You don't review every line. You don't necessarily understand every function. You just... tell it what you're trying to build, and it builds it.

This sounds like magic, and in many ways it is. Twenty-five percent of startups in Y Combinator's Winter 2025 batch reported that their codebases were 95% AI-generated. GitHub's 2024 survey found that 60% of developers now use AI for half their code, up from 20% just a year earlier. And here's the number that should make every designer sit up: a 2025 Stack Overflow survey found that 40% of non-engineers (designers, managers, product people) are now coding, thanks to these tools.

Forty percent.

Think about what that means. The barrier between "designer" and "developer" isn't just lowering. It's dissolving. And if you're a designer who's ever felt frustrated by the handoff process, ever watched your carefully crafted designs get "interpreted" into something that made you wince, ever wished you could just build the damn thing yourself... well, now you can. Sort of.

The Design Engineer Is Not a Myth

Before we go further, let me address the elephant in the room: what exactly is a design engineer?

The term gets thrown around a lot, and different companies mean different things by it. But the clearest definition I've found comes from Vercel's design engineering team, which has become something of a reference point for the industry. They describe design engineers as people who "blend aesthetic sensibility with technical skills," allowing them to "deeply understand a problem, then design, build, and ship a solution autonomously."

That last word, autonomously, is key. A design engineer isn't someone who designs and then waits for a developer to implement. They're not a developer who happens to have good taste. They're a hybrid, someone who can move fluidly between Figma and code, between exploring a visual direction and prototyping it in the browser.

The role exists to solve a real problem. When designers hand off to developers, things get lost in translation. Micro-interactions disappear. Spacing gets approximated. That subtle animation you spent hours perfecting becomes a hard cut. The design engineer sits in that gap, ensuring that what ships actually looks and feels like what was designed, so that "as products grow more complex and feature-rich, the user experience does not fall through the cracks."

At Vercel, this means their design engineers care about things like page speed, cross-browser support, accessibility, and inclusive input modes, all the "invisible" work that makes experiences feel polished rather than just look polished. "There is a lot of work behind the pretty pixels," as they put it.

And here's something that surprised me when I dug into this: there's no fixed background for this role. Maggie Appleton, who curates a collection of design engineers and their work, notes that some came from design, some from development, some from completely unrelated fields. What they share is curiosity, an obsession with craft, and the willingness to learn whatever they need to learn to ship something excellent.

How AI Changes Everything (and Nothing)

Now, here's where it gets interesting for designers specifically.

The new Figma MCP (Model Context Protocol) integration with tools like Cursor means you can now send your Figma designs directly into AI-powered development tools and generate working code. Not just HTML and CSS, but full React components with proper state management, responsive layouts, even complex interactions.

One designer described it as "the beginning of a new hybrid workflow where designers step into engineering instead of waiting for it." And the data backs this up: these integrations can cut development time for routine UI tasks by up to 70%.

I've experimented with tools like v0, Lovable, and Bolt. The experience is surreal. You describe a component, and it appears. You say "add a hover state with a subtle scale effect," and it happens. You can go from idea to working prototype in minutes, not hours or days.

But (and this is a crucial but) there's a difference between building a prototype and building production software.

Simon Willison, a programmer whose writing on this topic I deeply respect, draws an important distinction. He says if an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding. That's using an LLM as a typing assistant. Real vibe coding, in his definition, is when you "forget that the code even exists," when you accept AI-generated output without really understanding what it does.

His golden rule for production work: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."

And that approach has consequences.

The Hangover Is Coming

I don't want to be the person who throws cold water on an exciting trend. But I also don't want to be the person who doesn't warn you about the rocks beneath the water.

In September 2025, Fast Company reported that the "vibe coding hangover" is upon us, with senior engineers describing "development hell" when working with AI-generated codebases. In May 2025, a security analysis of Lovable-created applications found that about 10% of them had vulnerabilities that would allow anyone to access personal data. One study found that 45% of AI-generated code contained at least one OWASP Top 10 security vulnerability.

The problem isn't that AI writes bad code. Sometimes it writes excellent code. The problem is that AI-generated code often lacks what experienced developers call "systems thinking," an understanding of how components interact, how data flows, how a change in one place ripples through an entire architecture.

One developer described reviewing a vibe-coded application and being "shocked to see how bad the code was in a lot of places. It looked like it was written by a lot of junior developers, all using different coding practices." Another discovered that over a third of their AI-generated codebase was duplicated. The same text-normalization function appeared in fifteen separate files.

Here's the uncomfortable truth: AI can generate code, but it rarely comprehends the system. And this gap becomes painfully obvious as soon as you need to debug something, or scale something, or hand something off to another person.

Researchers are now talking about a new category of "vulnerable developers," people who can build products but cannot debug them when things go wrong. They're productive in the short term but dependent on AI in ways that become liabilities over time.

So What Should Designers Actually Do?

If you've read this far, you might be feeling a mix of excitement and anxiety. The opportunity is real, but so are the risks. The tools are powerful, but they're not magic wands.

Here's how I think about it.

First, start with prototyping, not production. The best use case for vibe coding as a designer is rapid exploration and validation. Need to test whether an interaction feels right? Build a quick prototype. Want to see if a layout works on mobile? Generate it and test it on your actual phone. This kind of fast iteration is genuinely transformative, and the stakes are low enough that code quality doesn't matter much.

Claude Artifacts, for example, runs in a sandboxed environment where your code can't access external APIs or cause any real harm. That's the perfect playground for learning and experimenting.

Second, learn the fundamentals anyway. HTML, CSS, and JavaScript aren't going away. In fact, understanding them makes you dramatically better at directing AI tools. When you know what's possible and what's hard, you can write better prompts. You can recognize when the AI is taking a suboptimal approach. You can debug issues yourself instead of just pasting error messages back into the chat and hoping for the best.

You don't need to become an expert. But you need enough understanding to review what the AI produces. Simon Willison's rule is a good one: don't commit any code you couldn't explain to someone else.

Third, focus on the gap between design and engineering. This is where design engineers add the most value, and it's the area least likely to be automated away. Accessibility, micro-interactions, performance optimization, design systems: these require judgment, taste, and the ability to hold both design intent and technical constraints in your head simultaneously.

The role of design engineering, as one writer put it, is "purposefully making space and appointing responsibility for this gap between design and engineering, so that as products grow more complex and feature-rich, the user experience does not fall through the cracks."

Fourth, contribute to something real. One of Adobe's recommendations for aspiring design engineers is to find small ways to contribute to your company's design system or your favorite open-source project. File bugs. Write documentation. Learn how design tokens work. Build a simple component and submit it. These small contributions teach you how production code actually works, which is very different from how prototype code works.

The Self-Taught Designer's Advantage

Here's something the credentialed crowd doesn't want to admit: this moment rewards the scrappy.

If you've ever taught yourself design from YouTube tutorials, pieced together knowledge from free resources, or figured things out through sheer determination because you didn't have access to formal training or expensive bootcamps—you already have the core skills this era demands.

The playing field is leveling. An AI doesn't care whether you have a computer science degree from Stanford or whether you taught yourself to code from a bedroom in Lagos, São Paulo, or a small town in the Midwest. It responds to clear thinking, good prompts, and iterative refinement—skills that have nothing to do with credentials.

I think about my own journey, from struggling with Adobe XD exports to building products that thousands of people use. The tools have changed dramatically, but the core skill hasn't: the willingness to sit with confusion, to try things that might not work, to learn in public without worrying about looking foolish.

If you can do that, you can become a design engineer. The path is more accessible now than it's ever been.

The Future Is Collaboration

Here's where I land on all of this.

The future of design isn't AI-driven or human-driven. It's collaborative. It's designers who understand what AI can do, and use it to amplify their creativity and judgment rather than replace it. It's design engineers who can move between Figma and code, using AI as a powerful assistant while maintaining the understanding needed to debug, iterate, and ship with confidence.

The most successful people in this new landscape won't be the ones who generate the most code. They'll be the ones who know what to build, who can architect systems that work, who can tell the difference between code that looks right and code that is right.

In the agentic era, as one observer put it, "success belongs not to those who can prompt code, but those who can engineer systems that last."

So yes, embrace the vibes. Use the tools. Build things faster than you ever thought possible. But stay in control. Understand what you're building. Own your work.

The gap between design and engineering is exactly where the most interesting careers are being built right now. And if you're a designer who's ever felt the pull toward code, who's ever wanted to ship not just designs but products, this is your moment.

The question isn't whether you can make the transition. The question is whether you're willing to.

What's your experience with AI coding tools as a designer? I'd love to hear about it. Find me on Twitter/X.