I'll be honest: I hate the term "vibecoding." But the alternative is "AI-assisted development," and I can't argue with anything being worse than that. So vibecoding it is.
Here's how I actually define it: using AI to bridge the technical knowledge gap so you, the practitioner with deep subject matter expertise, can act as both the developer and the product manager for anything you want to create. You know the problem better than any engineer ever will because you have years of context… and perhaps light trauma. But the AI knows the syntax, and together, you ship.
I was an early adopter of using AI to build things, but I really started building this way in earnest about a year ago when I installed Claude Code. I've learned enough (mostly by stepping on rakes) that it felt worth writing down. If you're in marketing ops, or really any non-technical role, and you've been wondering whether this stuff is for you: it is. Here's the tour.
How it started
I lead the marketing ops team at Vercel, and like every MOPs team ever, our resourcing did not (and does not) scale with the marketing org. Last year our entire marketing leadership team moved on to their next chapters, and in about six months we went from a small org of ~10 core stakeholders to over 50. We're still hiring, but we needed a way to deflect work ASAFP so we could preserve bandwidth for strategic projects.
Think about all the stuff that eats a MOPs team alive: list imports, SFDC campaign management, reports, building emails and workflows... All of it should be self-serveable. But there are knowledge gaps on any marketing team, and that’s not intended to be incendiary, just a fact. Marketers usuallly lack the context and/or exposure to understand the nuance between this field and that one. Example: we have four different segment fields, how could a new hire know which one to use? So "self-serve" without guardrails is really just "future cleanup project for ops."
That's when it clicked for us: apps and agents could and should be the guardrail.
My first big swing was building an entire marketing automation platform (we were having some growing pains with our vendor at the time, including no API access). I got it pretty far along and presented it at Vercel's weekly demo day, even being so bold as to send an email live to the entire company. The feedback from our c-suite, was that it was cool and very fast... but a little old school to have a UI-based workflow tool without a more agentic surface. So I pivoted to a Slack-first approach.
Nearly 9 months on, I think the best answer is do both. But this idea changed how my team operated in a monumental way this year.
That pivot became mOperator and a couple other apps, namely an Email QA tool and a list import app that each ran both deterministic and AI-driven quality checks.
The first version of mOperator had just two tools: list imports and SFDC campaign creation. Marketers loved it. Asking an agent in plain language, and still having all the QA checks and balances enforced by rules we configured? So much simpler than a form or a ticket. From there it snowballed avalanched: landing pages on our site and Luma, ticket queue management, auto-answering questions, even building emails and workflows.
At this point it's our strongly held belief that agents like this are going to change how marketing operations work gets done, and largely eliminate campaign ops as a standalone function at agencies and large companies. That headcount doesn't disappear, it just gets redeployed toward strategic work. That's exactly what's happening on our team today, and it’s glorious.
What surprised me
The biggest surprise wasn't that any of this was possible. It was how easy it is to ship a functional agent, and how fast you can iterate once it exists.
There's an old documentary about Halo: Combat Evolved (humor me, I’m a gamer nerd) where the developers describe designing "7 seconds of fun" that just runs in a continuous loop. That's what building with these tools feels like. Idea, prompt, working thing, dopamine. Repeat. I cannot overstate how addictive that loop is, especially if you've ever had to beg/barter for engineering resources at an enterprise company.
The lessons
My dad, for my entire life, has been trying to impress upon me that experience is the best teacher, but they don’t all have to be your experiences. But when I was 5 or 6, I high-fived a habachi grill because he told me not to touch it… So… walking past that smoking hole in my credibility as a reasonably intelligent person, what I’m saying is I hope my experiences with vibecoding will be helpful for you.
- More Learning is More Good. Very few people have unlimited token budgets. The more you understand the basics of the CI/CD pipeline and know basic terms like environment variables and pull requests, the faster you'll become code literate by exposure… That is IF you’re exposing yourself to the code. I like shipping from a terminal with multiple tabs going; it’s efficient and you cover a lot of ground quickly, potentially on completely different projects. But it’s really important that as much as you can you should review the code as it’s written. Asking claude to explain it to me like a 5-year-old has worked particularly well for learning how things work and how my codebases are set up. It also means the next time I build something, I’m just a little bit smarter WRT how to do it.
- Security has to be your default operating model, not an afterthought. Even I, a former crayon eater, knew from day one not to paste environment variables into chats. But you see all sorts of things out there, and learning about things like running CRM integrations through Vercel's Secure Compute for dedicated egress IPs and making env vars sensitive by default really took all the fear (okay, most of the fear) out of threat actors threatening. And… maybe like a Skynet, end of days situation. Before you set out to build anything for your organization, align on security guardrails and clarify how you’ll protect the business and your customer’s data from exposure.
- Life, uh… Finds a way (to build the same thing 4 times). Tools like Claude Code, Codex, and Cursor make
you can just ship thingsgenuinely true. Which means your org needs to align early on two things: requirements (what needs to be built) and R&Rs (who's building it). If you don’t have some sort of codified roadmap in place, it’s very easy to find different teams building similar versions of the same things. I think it happens a lot like Dr. Malcolm in Jurassic Park: "your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." Everyone that wants to ship a PR can… just add some structure around a “GTM Monorepo” from the start and save yourself some pain later. - Clear your context often. Those token costs add up fast. Treat long chat sessions like browser tabs: at some point, close them and start fresh. Docs can help your preferred coding agent preserve context over multiple sessions.
- Replatforming hurts, then it's worth it. Mid-year we rebuilt mOperator on a new framework (eve), which changed core architecture and broke some tools. That meant a stretch of ongoing ITG ("iterate to great," as we say). The agent is now faster (rough guess, maybe 30-40%?) and more performant than ever, so… ultimately it was worth it. I always tell myself I should give things time to mature before being an early adopter, but honestly I think the pain is worth it more times than it isn’t.
The tools journey
Around two years ago, I started with ChatGPT, copy/pasting code from the chat into my local repos. Great for learning the basics. Dog slow for actually building.
Then I leaned hard into v0, especially my first year at Vercel. It's fantastic for prototyping because you see everything render as you go.
When Claude Code came around, everything changed again. Working from a terminal app (I use Ghostty) made it so much easier to work across several projects at once. v0 and Claude Code aren't really competitors in my workflow. Prototyping vs. building each have their place.
One pattern I’ve noticed, though, is the tools keep getting better, and the barrier keeps getting lower. I have no idea what the ideal tech stack will look like in a year or what AI Model will be the best for a given use case, but I’m confident building on Vercel AI Gateway will make any updates across my projects relatively light work.
Go build something
If you're an operator (or any non-technical person) who's been curious about where to start, I want to help. You're already more qualified than you think by the sheer virtue of deep subject matter expertise in your discipline. The code is increasingly the easy part. Even trained developers are using agents to generate most of their code (they probably just do a much better job of reviewing it than I do).
Start small. Automate one annoying thing. Chase your own 7 seconds of fun.
And if you want a head start, fork mOperator and make it yours. It's open source, it's built for marketing teams; all you need to do is deploy to your own Vercel project and add the environment variables to connect your systems – Salesforce, Marketo, Customer.io, Asana and many more. Instructions available here.