This is article 3 in a four-part series on vibe coding for designers. Article 1 covers the mindset difference between solo and org building. Article 2 covers the solo builder playbook in detail. This article is for designers and design leaders working inside product teams.
Something quietly significant happened
Something quietly significant happened in the organisations paying attention.
Engineering teams started writing documentation, not for other engineers, but for designers, product managers, and other non-technical colleagues. Guides explaining how to use Claude Code to implement changes, raise pull requests, run QA, and get features into production.
Not because standards had dropped. Because the standards had changed.
The question in a modern product team is no longer “can you write code?” It’s “can you direct AI to produce code that meets our standards, works within our architecture, and doesn’t break what everyone else has built?”
That’s a design skill as much as an engineering skill. And the designers who understand this early are going to have an outsized advantage in the years ahead.
Why this matters for designers specifically
Designers have always sat at the intersection of user needs and technical constraints. We’ve always had to understand enough about engineering to have meaningful conversations with the people building what we design.
Vibe coding inside an organisation extends that role. Instead of handing over a spec and waiting, you can now take a feature further yourself. You can prototype in code, not just in Figma. You can test your assumptions in a real environment, not just a simulated one. You can contribute directly to the product, on your terms, within the team’s process.
This doesn’t make engineering teams redundant. It makes the handover between design and engineering smoother, faster, and less prone to the gaps that appear when one person designs something and a different person builds it.
The learning: Vibe coding inside an org isn’t about replacing engineers. It’s about closing the gap between what you design and what gets built.
The baseline, what you need before you start
Before you write a single prompt inside an organisation, you need to understand four things.
Your tech stack and code structure
You don’t need to understand the code in detail. But you do need to know what you’re working with. What framework does the frontend use? What’s the component library? Are there naming conventions or file structures you need to follow?
Ask an engineer for a 30-minute onboarding on the codebase. Ask Claude to explain anything you don’t understand. The more context you have, the better Claude’s output will be, and the less likely you are to produce something that creates work for someone else to fix.
Your organisation’s PRD and ticket process
In most organisations, work starts with a ticket. A Product Requirements Document or a Jira or Notion ticket that defines what needs to be built, why, and what done looks like.
This is where AI can help you before you’ve written a line of code. Use Notion AI or Claude to help you write better tickets. A well-written ticket with clear acceptance criteria, relevant context, and links to design specs is the single best input you can give Claude when you start building. The better the ticket, the better the output.
Your code review and sign-off process
Every organisation has a process for reviewing and approving code before it goes into production. Understand yours before you start.
Who reviews pull requests? What do CI checks look for? What are the common reasons things get rejected? Knowing this upfront means you can build with these constraints in mind, rather than discovering them after Claude has already done the work.
Visual regression and QA
When you make a change to the UI, how does your team check that it hasn’t broken something else? Some teams use automated visual regression tools that take screenshots before and after a change and flag differences. Others rely on manual QA.
Know what your team uses. And use Claude to help you QA your own work before it gets to review. It will catch things you miss.
The learning: The better you understand your team’s process, the more effectively you can direct Claude within it.
The org builder workflow
What follows is the workflow we use at Equals, a fintech company based in London. Every organisation will implement this differently, with different tools, different commands, and different sign-off processes. But the foundations are the same everywhere: get context before you start, implement from a well-written ticket, review your own work before others do, QA against a real environment, and get approval before you release.
The specifics will vary. The principles won’t.
Step 1, get guidance before you start
Before you begin any task in an unfamiliar area of the codebase, run a guidance command:
/guidance [ticket-url]
This tells Claude to read your ticket, analyse the relevant parts of the codebase, and give you a brief before you start. It will tell you who to talk to if the task is more complex than it appears, what risks and dependencies exist, and what patterns already exist in the codebase that you should follow rather than reinvent.
Think of it as the conversation you’d have with a senior engineer before starting a new piece of work. The difference is you can have it at any time, without interrupting anyone.
Step 2, implement from the ticket
Once you’re ready to build, give Claude your ticket URL:
/implement [ticket-url]
Claude will fetch the ticket details, understand the requirements, create a branch, and start implementing. It will ask you questions if something is unclear. It will follow the patterns it found during the guidance step. And it will report back on what it’s done when it’s finished.
You don’t need to understand every decision it makes. You do need to review the output and check that it matches what the ticket asked for.
Step 3, create a draft pull request and review it
When the implementation looks right, create a draft pull request:
/pr draft
Then wait a few minutes for your CI checks to run. Once they’ve finished:
/review-pr
Claude will review its own work. It will check for code quality issues, look for test coverage gaps, diagnose any failing CI checks, and fix what it finds. This self-review step catches the majority of issues before a human engineer ever sees your code.
When the review looks clean and you have a preview deployment URL, move to QA.
Step 4, exploratory QA against the preview
With your preview URL and your ticket URL, run:
/qa-explore [preview-url] [ticket-url]
Claude will open a browser, navigate to your preview, and test your changes against the ticket requirements. It will create a test report documenting what it tested, what passed, and what failed.
Read the report. Verify it matches what you expected. If something failed, fix it and run QA again.
Step 5, handle review comments
Once your PR is up, engineers and automated tools will review it. When you get feedback:
/review-pr-comments
Claude will fetch all unresolved review comments, analyse the feedback, and suggest or apply fixes. Review what it does. Push the updates. Then go back to the PR and resolve the comments that have been addressed.
If comments were made by a human engineer, request a re-review once you’ve fixed them. Don’t just resolve them yourself.
Step 6, release approval
When the PR is approved and you’re ready to release:
/rar
Claude will automatically detect whether this is a frontend or backend release and create a Release Approval Request in Notion. Share it with the relevant approvers and wait for sign-off before merging.
The mindset shift this requires
The org builder workflow asks something different of you than the solo builder workflow does.
When you’re building alone, you set the rules. When you’re building inside an organisation, you work within them. That’s not a constraint to work around. It’s the point.
The process exists because other people depend on what you build. The code review exists because your changes affect a codebase that engineers maintain. The release approval exists because your changes reach real users.
Understanding and respecting this process is what makes you a trusted contributor rather than a liability. And Claude, used well, makes it possible to follow the process properly without needing years of engineering experience to do so.
The learning: Inside an org, Claude doesn’t help you skip the process. It helps you follow it better than you could on your own.
What solo and org building have in common
Across all three articles in this series, one thing has stayed constant.
The quality of what Claude produces is a direct reflection of the quality of what you bring to it. Your context, your judgment, your taste, your understanding of the problem you’re solving.
Whether you’re building alone at night with a problem you want to solve, or working inside a team trying to ship a feature, you are still the designer. Claude is a powerful tool. But it is your vision, your decision making, and your standards that determine whether what gets built is actually good.
That has not changed. And it will not change.
The designers who thrive in the next few years will not be the ones who learned to code. They will be the ones who learned to direct, to give context, to review output critically, and to bring their design skills into a new kind of collaboration.
That is what this series has been about.