The Designer Who Codes

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 different product including an AI powered sport parser bot that runs in telegram and a web app. 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.

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.

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.

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 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 question isn't whether you can make the transition. The question is whether you're willing to.