How Vibe Coding Became Part of My Design Workflow

At the beginning of 2026, vibe coding was suddenly everywhere.

People were building websites, tools, and small products using AI. As a designer working inside the marketing team at GTM Buddy, I was curious about what this could mean for my own work.

I was not trying to become a developer.

I simply wanted to know if I could take a design further. Could I move from an idea in Figma to something real, working, and live without waiting for a separate development process every time?

For me, vibe coding means using natural language, design context, and AI coding tools to turn an idea into a working digital experience. The AI helps with the code, but the designer still guides the structure, experience, visual quality, and final decisions.

That curiosity slowly became part of my everyday workflow.

It started with Base44

We did not know exactly where to begin.

The first platform we seriously explored was Base44. We started on its entry plan and used it to experiment with campaign websites and internal tools.

Initially, I worked in two ways.

Sometimes I designed the experience in Figma and then tried to recreate it in Base44. Other times, I started directly inside Base44 and shaped the design while building.

It was my first experience of designing and launching something in almost the same space.

During the first three months, we used Base44 so frequently that we moved to the Pro plan. My manager was also exploring the platform, and together we started understanding what it could and could not do.

It was not always perfect. But it showed me that the distance between an idea and a live experience could be much shorter.

Then I started building with Claude

After Base44, I began experimenting with Claude to create HTML websites.

This gave me much more control.

I started learning how to describe layouts, visual hierarchy, responsiveness, components, and interactions through prompts. Slowly, my prompts became clearer. Instead of going through many rounds, I could sometimes reach a strong starting point within two or three prompts.

But prompting alone was not enough.

Every new conversation required me to explain the same brand rules, content style, layout preferences, and web guidelines again. I wanted the AI to understand how we design at GTM Buddy before it started generating anything.

That is when I began building reusable AI skills.

Building a design system for the AI

I created separate skills for different parts of the work.

One skill helped generate content in GTM Buddy’s language. Another explained our visual direction. Others included layout principles, website guidelines, naming rules, and patterns we regularly used.

These skills were more than long prompts. They acted like reusable context that could guide the AI before it started designing or coding.

My manager and I eventually brought those pieces together into a larger skill called Design Engineering for Marketing.

The idea was simple: give the AI enough context to understand both the marketing objective and the design system.

Once we started using it, the outputs became more consistent. I did not need to explain every decision from the beginning. The AI already had a foundation to work from.

This was when vibe coding started feeling less like an experiment and more like a design workflow.

The first moment that felt magical

Before I moved deeply into Cursor and GitHub, I was also experimenting with Figma through the Model Context Protocol, commonly called MCP.

MCP allowed tools like Codex and Claude to work with other applications. I connected them to Figma to see whether AI could help inside my actual design environment.

At the time, I was working on a section for the GTM Buddy website. It contained a complex diagram with multiple rows, steps, and interactions.

The static design was ready, but I needed to demonstrate how the experience should behave. Creating the complete prototype manually would have taken time.

I wrote the interaction instructions in a Markdown file and asked Codex to build the prototype in Figma.

Then I watched it work.

Codex opened the design and started connecting the interactions. It took around 23 or 24 minutes, which felt long compared with the speed of today’s tools. But watching it complete the prototype inside Figma felt magical at that time.

That was one of the first moments when I understood that AI could do more than generate an image or a code block. It could work with my design and help me bring the behaviour to life.

Learning GitHub as a designer

The next step was Cursor.

I was completely new to GitHub and development workflows. Terms like repository, main branch, commit, push, and pull were not part of my regular design work.

I had to learn them one by one.

At first, we used Claude to create Git projects. Later, when we got a Cursor subscription, I connected the projects to GitHub and began working more directly.

I learned how to:

1. Create and organise a repository

2. Run the project locally

3. Review the experience in the browser

4. Commit my changes

5. Push updates to GitHub

6. Connect the repository to a live environment

We also uploaded our AI skills to GitHub. This made it easier to maintain them and share the same working context with internal teams.

GitHub stopped feeling like a developer-only space. It became another part of my design workflow.

Finding a workflow that worked

Eventually, I found a process that connected Cursor, GitHub, and Base44.

I would build the experience in Cursor, run it locally, and review everything in the browser. Once it looked and worked correctly, I would commit the changes and push them to GitHub.

The GitHub repository was connected to Base44, where the project could be synced, connected to a domain, and published.

Base44 became the hosting and publishing layer. Cursor became the space where I did most of the vibe coding.

This workflow gave me more control while still making publishing manageable. I could create the design, build the experience, review it, make changes, and ship it through one connected process.

It gradually became part of my daily work.

From pages to working experiences

Once I became comfortable with the workflow, I started thinking beyond regular campaign pages.

I experimented with calculators, assessments, internal tools, animations, and interactive experiences. I also recreated parts of our product as working demonstrations.

These were not videos or static product screenshots. They behaved like simplified versions of the actual product.

Prospects could click, explore, and understand the flow for themselves. We could include these experiences inside our buyer-facing activation surfaces and campaign journeys.

That changed the way I thought about product storytelling.

Instead of only explaining what the product could do, I could give someone a small experience of it.

You can see some of these experiments in my Microsites and AI Workflows case study.

Taking the workflow into Webflow

My next experiment was connecting the same process to Webflow through MCP.

The first results were not great.

The AI could create elements in Webflow, but it did not fully understand our components, classes, styles, or naming system. The page existed, but it did not feel clean or reusable.

So I went back and improved the context.

I created solid components and documented the component names, class names, styles, and library structure. I turned that information into another reusable skill for the AI.

Then I tried again.

This time, Cursor could understand the system more clearly. I could vibe code the experience, send the structure into Webflow through MCP, and watch the AI build the page using the correct design system.

That was another important lesson for me.

Better results did not come only from changing the model or writing a cleverer prompt. They came from giving the AI a better system.

How my process works now

My current vibe coding process is more structured:

1. I begin with the campaign goal, audience, content, and experience.

2. I use brand, content, design, and web guideline skills to give the AI the right context.

3. I explore the layout in Figma or move directly into code, depending on the project.

4. I use Cursor, Codex, or Claude based on what the task needs.

5. I run the project locally and review it as a designer.

6. I check responsiveness, hierarchy, interactions, content, and visual consistency.

7. I commit and push the work to GitHub.

8. I publish through Base44 or move the experience into Webflow through MCP.

9. I test the live experience before sharing it.

The tools may change, but the thinking stays consistent.

The brief comes first. The user experience comes next. AI helps me build, but I still need to review, question, and refine what it creates.

What vibe coding changed for me

Vibe coding has not changed my role from designer to developer.

It has changed how far I can take an idea.

Earlier, I could design the complete experience and explain how it should work. Now I can also build a functional version, test it with real interactions, connect it to a domain, and ship it.

This is especially useful inside a marketing team. Campaigns move quickly. Ideas often need to be tested while they are still relevant. Small interactive experiences do not always need a full development cycle.

That does not mean developers are no longer important. Larger products, complex integrations, security, scalability, and production systems still need proper engineering.

But designers can now participate much more deeply in the building process.

We can understand what is technically possible, test ideas sooner, and communicate with developers more clearly when their help is needed.

A new kind of designer workflow

When I began, I did not understand repositories, branches, commits, MCPs, or deployment workflows.

I learned them because I had something I wanted to create.

That is probably the biggest change vibe coding brought into my work. It gave me a reason to move beyond the tools I already knew.

I am still learning. The workflow keeps changing, and new tools keep appearing. But I no longer see development as a wall after the design stage.

I see it as another material I can work with.

For me, that is what vibe coding for designers is really about. It is not about replacing design with AI or pretending to be a developer.

It is about helping designers turn more of their thinking into something real, working, and ready to experience.