Vibe coding as a non-technical designer

In this journey of learning new AI workflows in Design, 0xDesigner shares his perspective on the MCPs, workflows, and mental models that help him build faster with agents. In this article, we unpack his thinking around setup, PRDs, testing, and how to work with Codex and Claude effectively.

---

Which MCPs are must-haves in your setup and why?

• Figma MCP: I use it to round trip UI. I import a live page into Figma, polish it, then point the agent at a component and it implements the pixel changes. It even ships a fixed prompt that generates design system rules, which makes restyling the whole app trivial.
• Playwright MCP: Gives the agent real browser access for checks and lightweight tests. I use it when I need the web, though it can flood the token window so I keep it targeted.
• Railway MCP: Fast deploys and environment setup through the agent. Keeps me out of manual infra work.
• Supabase MCP: Database scaffolding, auth, policies, and seeding handled by the agent. I do not crack docs, I just ask for the schema and it wires the backend.
• Stripe Checkout MCP: Payments in one shot. If checkout throws errors, I paste the error and let the agent fix the flow.
• Resend MCP: Transactional email for onboarding, receipts, and alerts, wired by the agent without me touching SDK examples.
• Zapier MCP: I pull relevant Discord conversations into context so the agent can use that for planning and strategy prompts.

---

What level of code understanding do you aim for before handing control back to the agent?

I know just enough to unblock. I learnt to read the error, find the right file or component, and name the change precisely. If I can say “move this error message near the button in Checkout.tsx” or “update this CSS class on the glass card,” that is enough. Overall, I got terminal literate, and didn’t become a framework expert. Start, stop, and restart a dev server. Run the agent in the terminal. Paste stack traces. Apply a one line fix if the agent cannot, then hand control back.

I aim for intent clarity over code mastery. I keep a PRD and a style doc so the agent knows goals and rules. I verify by outcome: the error disappears, the UI matches my Figma edit, and the flow runs end to end. My tests are agent driven. I ask the model to set up and run tests, then I read the results. I do not study the testing framework.

When I can localize the problem, describe the desired behavior in plain language, and point to the exact spot in the codebase, I give it back to the agent.

---

What goes into your PRD.md and how do you keep it readable for both you and the agent?

I open PRD.md by writing the product goals in plain English and ask the model to interview me. That back and forth becomes the first section so we’re aligned on intent before any code exists. I let the agent draft a quick persona and pain points, then I edit it. It’s useful for both of us to anchor decisions. Example from the fitness bot: “software engineer wants to build muscle —> time constraints, equipment limits.” Other things in the PRD include:

• Key capabilities at a glance: We build a short list the agent can keep checking against: onboarding, real time coaching, accurate logging, smart progression. If it can do these, we’re on track.
• User stories (the part I actually read): Add a narrative, a step by step: onboarding questions, program generation, weekly plan, guided workout with Telegram inline buttons, logging, progression. I keep this in simple prose so I can verify behavior fast.
• Scenarios / modes: I correct the agent until it covers variants (runner, yoga, strength, combos). This prevents it from overfitting to one use case. Keep the narrative sections short, skimmable, and in plain English. Technical sections can be longer, but they live after the user stories. I treat the stories as the source of truth.
• Backend notes (for the agent, not me): The doc can include DB tables, flows, and architecture sketches. I don’t validate every diagram; I only check that the technical plan supports the user story.
• Platform affordances: I spell out specifics the agent must honor (e.g., “use Telegram inline keyboards for Done/Skip so users don’t type responses”).

I reference PRD.md in my prompts so Codex/Claude always load it. That keeps the “context pool” clean across threads. I rarely reopen the doc unless we change direction. In that case, I edit PRD.md first and tell the agent to re-read it. For styling, I create a separate style markdown after polishing one page in Figma. The PRD stays about product behavior; the style doc carries tokens and component rules the agent can propagate.

---

What questions do you ask the model to ask you before you begin?

I align intent, scope and constraints first. I give details on the goals and the end result we’re aiming for. I ask it to confirm its understanding of those goals, and keep asking clarifying questions while it drafts the plan. Then I ask the agent to give me the user journey in narrative form with user stories and paths including onboarding. For the fitness coach, we discussed experience level, equipment available, time of day, height, weight, gender, and any injuries to tailor the program.

I go over corner cases and details like which modes to support, not just strength training: include runner, yoga, strength, or combinations. I ask it about platform specifics that I expect to be honored, like using Telegram inline keyboards for actions instead of free-text replies. I ask questions about what should be tracked and guided (like a clear weekly plan, guided workouts, and exercise logging with smart progression).

Lastly, I ask it to ask me to validate that any backend notes or database flows the AI proposes actually support the user story, then work backward from there.

---

What signals tell you it is time to step away and reset?

When I’m deep in technical problem solving and my creativity vanishes. I lose sight of product and design sensibility, and that’s my cue to stop. After a timeboxed backend or wiring block is finished. I won’t work in parallel, so I end the block and take a break. Before switching modes. I literally walk away so I can create space between heavy technical work and the 50,000 foot product view, then come back in design mode.

---

What is your process to figure out a release checklist?

I ask the agent to make it. I literally say: you have the PRD, the style doc, and the codebase context, we share the same vision, what do I need to do to confidently release this to about a hundred people. The agent turns that into a checklist. I keep a simple “next steps” markdown in the repo. After I finish an item I ask “what’s next” and let it update the list.

Tests are agent-driven. I ask it to set up and run tests and just tell me the results. I am not managing the framework details. I do a cleanup pass with my “Clean Project” command to remove stray markdown and test files that bloat or confuse the codebase without breaking docs or tests. Typical items that show up for me include wiring subscriptions and payments, email flows, and deploying the domain. I lean on the MCPs for those, rather than doing the infra by hand.

---

You mentioned that recently you favour Codex CLI. What makes it feel more precise in practice?

It understands intent better and makes very precise changes. I do not know what the magic sauce is, but I need fewer custom commands because it just does the thing I ask.

My benchmark is simple: I ask for a change and see how often it lands. With Codex CLI, that frequency feels higher. If I say checkout is broken, paste the error, and the error is gone, that is the signal. I do not review every diff, I check that the problem disappeared.

Because of that precision, I lean on Codex more, and use my Claude Code shortcuts less, even though I still like Claude for MCP setup and terminal flow.

---

Which skills should designers lean into as interfaces get automated?

The same core skills, with a different emphasis.

• Journey mapping: understand end-to-end flows and happy paths.
• Writing user stories: describe what the user can do in narrative form.
• Working with personas: who it’s for, the pains, and why it matters.

Shift from “how it looks” to “how it works”. More product thinking, less pure visual polish.

---

Get to know 0xDesigner’s thoughts behind some of his most famous tweets: