My Journey into AI-Assisted Development

You can do so much more in code

I've been a product designer for four years. I've shipped experiences reaching 50 million users. I've won a Red Dot Award. And for most of that time, I couldn't build anything I designed. That's the thing nobody talks about. You can design the most elegant interaction in Figma, prototype it with smart animate, present it to stakeholders - and then watch it get simplified, compromised, or killed during implementation because the handoff broke somewhere between your intent and the engineer's interpretation.

The moment it changed was when I realised you can do so much more in code that you simply cannot do in any design tool. Not "more" as in more features - more as in closer to truth. A Figma prototype is an opinion about how something should feel. Code is the thing itself. I didn't set out to become a developer. I set out to stop being blocked by the gap between what I could imagine and what I could ship. AI made that possible.

Designing a brief for an AI engineering partner

My first real project was ambitious - maybe too ambitious. I wanted to build the CMS I wished I could have shipped during my time at Glance. At Glance, I'd redesigned their editorial CMS - the tool 250M+ daily active users' content flowed through. Editors were spending 7 minutes per card, averaging 40 cards a day. I redesigned it as a three-column workbench that doubled throughput to 88 cards a day. But there were features I couldn't ship due to organisational constraints - ideas that got stuck in the backlog. So I built them myself.

It took a solid month of daily iteration. I designed the full information architecture in a visual format optimised for LLM consumption - not a Figma file, but a structured document describing what each panel does, how they relate, and what the content types are. I was essentially writing a brief for an AI engineering partner. The specific tools didn't matter - VS Code, GitHub Copilot, Figma Make, Cursor, Amazon Kira - whatever worked that day. What mattered was being clear about what I wanted and what I was trying to achieve.

Four features the AI built without a Figma file

Here's what surprised me. The features the AI produced weren't just functional - some of them were more thoughtful than what I'd originally designed.

Context-Aware Search

I described how editors work: they're in different modes depending on whether they're reviewing pending articles, checking published content, or moderating flagged pieces. The AI built a search system that generates different suggestions based on which tab the editor is on - without me designing a single screen for it.

It even extracts popular tags from live article data and surfaces them as suggestions - something I hadn't asked for but immediately recognised as the right call. The same input field becomes three different tools depending on the editor's current context.

Multi-Dimensional Filtering

The content panel needed to filter articles across six dimensions simultaneously: status, date, search term, source, category quick-filters, and sort order. As a designer, I think of filtering as "layers of refinement" - you start broad and narrow down. Turns out that's exactly how code composes it.

Each filter layer narrows the set. The pipeline is additive - status first, then search, then category. Watch the count change as you stack filters. This is how 20 articles become 5, and why progressive refinement feels intuitive both as a design pattern and as code.

Safety Scoring

Content moderation was critical. Every article gets a safety tier from 1 (Not Suitable) to 5 (Publish Ready), with colour coding that maps directly to editorial confidence. This is design system thinking - except implemented in TypeScript. One number determines everything: the color, the label, the border, the description.

What struck me was how naturally interaction design translates to code when you think in terms of data flow rather than pixel coordinates. Designers already think this way - we just call it "design tokens" instead of "type-safe configuration."

No Figma file exists for this site

After the CMS, I wanted to push further. This portfolio - the site you're reading this on - was the result. No Figma file exists for it. The entire thing was built with AI coding agents. I wanted to test the limits: could I build something genuinely ambitious without ever opening a design tool? The answer was yes, but it wasn't clean. The ambition list was aggressive: WebGL shaders for the hero section, a streaming AI chat that answers questions as me, spring physics animations, iOS-style corner smoothing, scroll-triggered carousels, and a real-time timeline clock that converts the visitor's local time into a visual position on a 24-hour axis.

The Timeline Clock

One of the features I'm most proud of is the horizontal timeline in the sidebar. The idea: show time not as numbers updating, but as a physical position moving across a 24-hour axis. The core concept is deceptively simple - convert the current time into a percentage of the day.

JavaScript's Date object automatically uses the visitor's system timezone, so the clock shows the right time anywhere in the world without any extra work. One division operation, one percentage, one moving dot - and time becomes spatial.

Figma, Figma Make, then Claude Code

This isn't a product review. It's a timeline of how my relationship with tools changed as I started building.

I started where every designer starts -in Figma. It's where I think, explore, and make decisions visually. For four years, that's where my work lived and died. The designs were polished, the prototypes were convincing, but they were still simulations. The gap between what I presented and what got built was always someone else's problem.

Then Figma released Figma Make -their AI-powered design-to-code tool. It was the first time I could take a design and get working code without handing it off. I used it to generate initial components, quickly scaffold layouts, and bridge that gap between visual intent and real markup. It wasn't perfect, but it changed my mental model. For the first time, code felt like something I could touch directly from inside my design tool.

But Make had limits. It could translate static designs, but it couldn't reason about architecture, state management, or how components should compose across an entire application. That's when I moved to Claude Code -a terminal-based AI agent that reads and modifies your entire codebase. The difference is fundamental: Figma Make translates designs into code. Claude Code is an engineering partner that builds systems while you direct the architecture.

The biggest lesson was that context management matters more than model quality. A mediocre model with the right context will outperform a powerful model that's seeing the wrong files. I now maintain a CLAUDE.md file in every project -a structured document that tells the AI what the project is, what patterns to follow, and what to avoid. It's like onboarding a new team member. The prompt itself is the design -when I prompt an AI to build a feature, I'm essentially writing a design spec. The clearer my intent, the better the output. This is where designers have an underrated advantage: we're trained to articulate intent clearly. My current split is roughly 30% Figma and 70% code. For fast-moving teams, the code is the source of truth -not Figma.

I fought the AI instead of guiding it

I got a lot wrong -the mistakes are where the learning lives. I didn't learn Git early enough. Version control felt like a developer concern until I lost a day of work because I overwrote a file without a commit to revert to. When the AI's output wasn't right, my instinct was to re-explain the same thing louder. That doesn't work. What works is giving the AI the right context: show it the existing code, point it to the right files, describe the constraints. Think of it as creative direction, not dictation.

I also didn't understand context windows early on -I'd dump an entire project into a conversation and wonder why the AI lost track of earlier decisions. Context is finite, and you have to be deliberate about what the AI sees, just like you'd be deliberate about what you put on a design brief. Debugging was the hardest part. AI is excellent at writing new code but mediocre at debugging its own. When something broke, I learned to cross-reference multiple models -one to explain the problem, another to suggest fixes -because different LLMs have different strengths. "Thinking in structure" turned out to be real, but not the way I originally understood it. It doesn't mean understanding HTML divs and CSS boxes. It means understanding component hierarchies, state flow, and data dependencies. Designers already think this way -information architecture is component architecture. We just hadn't made the connection explicit.

The question isn't whether designers should code

Within 10-20 years of the printing press, the world had published as many books as in all of prior human history. AI is the same inflection point for software. The baseline of design-to-code has been solved. There are only so many interaction patterns you can make, and most are already adopted. What we need to solve next is intent - capturing the intent of the user and designing the product for them.

The scale of content production will increase exponentially, but the premium on taste, relevance, and craft will rise with it. AI can generate a thousand components - it takes a designer to know which ones matter. The question isn't whether designers should code. Code is now a tool to build a product. If you're a product builder, you have to learn the tool. The real question is: do you want to build? Because if you do, the gap between what you can imagine and what you can ship has never been smaller.