You Should Be Vibe Coding - ProductFTW #64

Everybody wants to talk about AI right now. “AI is going to replace jobs, automate your workflows, run your company for you…” blah blah blah. I disagree, but that’s another article.

This one’s about vibe coding. And why you, as a product manager, should be doing it.

What I Mean by Vibe Coding

Let’s set the record straight before we go any further: As a product manager, you are not an engineer. You are (likely) not a trained developer. You should not be shipping production code. And for the love of all that is secure, do not open up vulnerabilities in your stack because you wanted to vibe.

Okay, with that out of the way: vibe coding is about using lightweight scripts, AI tools, or quick and dirty automations to poke at your product directly. It is about testing things, validating requirements, and unblocking yourself faster than waiting for engineering or QA to hand you results.

Think of it this way: vibe coding is not about building production features. It is about making yourself dangerous enough to run experiments, validate assumptions, and make sure your product actually works the way you think it should.

Why Vibe Coding Matters for PMs

Product managers are natural bottlenecks. Not because we want to be, but because so much flows through us. We are writing requirements, answering questions, reviewing designs, prioritizing tickets, and signing off on releases. Often, we cannot move forward until someone else has run a test, filed a bug, or handed us a result.

Vibe coding flips that. Instead of waiting, you just do it. You grab a script, spin up a test, or hack together a quick automation. Suddenly, you are not waiting around. You are validating requirements in real-time, and you walk into meetings with data instead of guesses.

And let’s be real: as a PM, your job is not just to write a ticket and sit back. Your job is to make sure the thing that ships actually works the way it is supposed to. Vibe coding makes that sign off faster, sharper, and more confident.

Example 1: Testing Rewards Logic

I spend a lot of time building consumer credit products. One of the most brutal parts of that job is making sure the rewards logic works correctly. On paper, it is simple: spend in X category, earn Y multiplier. In practice? It is a nightmare.

We are talking about +200 different rules. And if you are testing it the “normal” way, you would have to either make transactions in person or go into some half-baked test environment and trigger them one by one. Depending on your processor, that could mean manual API calls or endless UI clicks. It is the definition of painful.

Vibe coding turns that all-day slog into a quick run. I can spin-up a script that runs through every single rule, validate that the points are posting correctly, and feel confident in minutes instead of hours. Sometimes I even catch things QA would not, like a rounding rule that did not match our requirements.

The result: faster UAT, less pain, and way more confidence when we push to production.

Example 2: Onboarding Flow Testing

Rewards are not the only place vibe coding saves me. Onboarding is just as bad, maybe worse.

In consumer credit, you do not just onboard one “happy path” user. You need to test dozens of different scenarios. KYC policies. Underwriting decisions. Edge cases. Every variation has to be accounted for.

Doing that manually means creating tens of different fake users, each with the right data to trigger the scenario. Over and over and over again. It is exhausting.

So instead, I use vibe coding. Pairing ChatGPT with Cypress, I can automate the entire onboarding flow. I generate users with the right data, run them through the UI as if I were a real applicant, and check granular requirements along the way. Did the address error fire correctly for this scenario? Did the right underwriting decision get triggered? Did the KYC check pass or fail the way we expected?

Suddenly, instead of clicking through every single edge case, I have automated tests aligned to my requirements. It is fast, thorough, and gives me confidence that the product is actually working the way we promised.

Example 3: Scrappy Automations

And then there are the scrappy hacks.

At a startup, engineering’s time is gold. They need to stay focused on core product work. Which means if I need to do something like trigger user communications, I cannot just throw it on their backlog and expect it to get done tomorrow.

But I also cannot just not do it. So I vibe code.

One of the scrappiest automations I have thrown together was connecting our API to Zapier to Campaign Manager. I needed to send automated emails to users based on certain triggers. Instead of begging engineering for a sprint slot, I wired it up myself. API to Zapier to Campaign Manager. Done.

Was it elegant? Not really. Was it production ready for the long haul? No. But did it unblock me and keep the product moving? Absolutely. That is the whole point of vibe coding.

And it is not just about emails. You can use this approach to automate reporting, test integrations, or even prototype quick flows before design and engineering touch them. It is about being resourceful and keeping momentum instead of waiting around.

“That’s Not a PM’s Job”

I can already hear the pushback: “But Ellen, that is not a PM’s job. Testing is for QA. Scripting is for engineers. Automations are for ops.”

Sure. But vibe coding is not about taking someone else’s job. It is about moving faster, gathering real feedback sooner (yes, data), and reacting.

When you vibe code, you are not stepping on toes, you are catching gaps earlier, answering questions faster, and unblocking your team. You are a better partner to QA because you have validated your own requirements before they even start testing. You are a better partner to engineering because you are not wasting their time with “what if” questions they could have told you in five minutes if you had just hit the API yourself.

If anything, vibe coding makes the whole team more efficient.

Why This Is Especially Important in Startups

Big companies can get away with the old school model (maybe–I am still skeptical). Engineers engineer. QA tests. PMs write tickets and sit in meetings. But in a startup? That is a death sentence.

When you are moving fast, you cannot afford to wait around. Engineering’s focus has to be on core features. QA might not even exist yet. Ops is usually just whoever drew the short straw.

That is where vibe coding becomes a startup superpower. It is how PMs keep things moving without blocking the team. It is how you test quickly, automate boring stuff, and build just enough glue to hold things together until the real solution is built.

It is not about being perfect. It is about being dangerous enough to get things done.

The Bottom Line

Look, AI is cool. It is fun to watch the hype cycle play out. But while everyone else is busy predicting how many jobs AI will eliminate, there is a much more practical skill product managers should be learning right now: vibe coding.

It is about making yourself faster, sharper, and more credible with your team. It is about validating requirements, catching issues earlier, and keeping momentum in environments where every week counts.

And once you start vibe coding, you will not want to go back. Because suddenly you are not just the PM who writes tickets. You are the PM who knows how the product really works. And that is the kind of PM every team wants.

So, yes. Product managers should be vibe coding. Period.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.