Live Vibe Coding with Claude: Building an Automated Pinterest Publishing System

Most of what I share about Claude Code is after the fact — the finished feature, the clean commit, the “here’s what we shipped” recap. This time I wanted to do something different: pull back the curtain on an actual, unedited vibe coding with Claude Code session, the same way I run it every day for our production systems. No script, no cleanup pass on my workflow — just me, a browser tab, and Claude working through a real refactor on our Pinterest publishing pipeline.

If you’ve been following along, you already know I lean hard on Claude for our production systems. What you probably haven’t seen is how — the sequencing, the guardrails, the specific reason I refuse to let it run on autopilot. That’s what this session was for.

Why We’re Building an Automated Pinterest Publishing System

Some context before the code. We’re building a Pinterest publishing system for our fashion store — a pipeline that ingests content, either a product listing or a blog post, synthesizes it, layers in SEO, generates the actual pin creative, and publishes it to Pinterest. No human in the loop.

The goal isn’t just “automate Pinterest.” It’s the same goal behind almost everything we build right now: make it run 24/7 without manual intervention so a lean team can stay lean. Every process we can hand off to a pipeline is a process nobody on the team has to babysit, which means more time for the parts of the business that actually need a human — talking to customers, figuring out what to build next, growing the store itself.

I can’t get into every detail of the system yet — some of this becomes a commercial product down the line, and I’ll share more about the target customer and the outcomes once that’s further along. But the workflow behind it is worth showing now, because it’s repeatable regardless of what you’re building.

My Rule for AI Coding: Claude Stays in the Browser, Not the IDE

Here’s where my setup probably looks different from what most people recommend. I don’t integrate Claude Code into Visual Studio as a workflow widget, and I’m not running it inline in the editor. I keep Claude in its own browser tab, completely separate from where the code actually lives.

That separation is deliberate. I’ve talked before about how I see Claude — a brain trust, a genuinely great thinking partner, close to having a senior engineer on call. But the minute you hand over full control, things can go sideways. I’ve watched Claude make bad calls for us before, nothing catastrophic, but enough to know that a system running in a semi-production state isn’t the place to find out the hard way.

So the way we actually work: I talk to Claude in the browser, I give instructions, I validate what comes back, and I check it against our existing codebase before anything touches Visual Studio. That extra step — reading the diff, questioning the approach, deciding whether it fits our architecture — is where I’m doing double duty. I’m not just the person copying code from one window to another. I’m playing architect first and pasting second, which means Claude gets used the way a senior engineer should be used: with minimal hand-holding, but never with a blank check.

Think Top-Down, Not Bottom-Up: How I Brief Claude Before Any Code

If there’s one habit that’s changed my results with Claude more than anything else, it’s this: work at the higher level first, then come down to the implementation. Before I even open a coding session — sometimes in the middle of one — I take the time to lay out the complete picture instead of jumping straight to “do this specific thing.”

The difference in output quality is real. Give Claude the full context — the system it fits into, the constraints, the failure modes you’re worried about — and you get better suggestions, alternative approaches you hadn’t considered, and occasionally Claude pushing back on an assumption you didn’t realize you were making. That last part matters more than people give it credit for. A tool that only executes what you tell it is a lot less valuable than one that catches you when your own thinking has a gap in it.

This is true for coding and it’s true for system design generally: start with the shape of the problem, not the first line of the solution.

Inside the Live Session: Refactoring SQL and C# with Claude’s Help

With the Miro map in hand, the actual session was a continuation of a refactor we’d already been chipping away at across a few rounds with Claude. I’d given Claude specific instructions to refactor a chunk of the publishing pipeline, and that touched multiple layers of the system at once — SQL changes and a batch of updates across our C# files.

Claude came back with a full set of changes, plus a rundown of the bugs it had caught in the code I’d handed back to it in an earlier pass — a compilation break here, a couple of logic bugs there. That’s the normal rhythm if you’ve spent any time pair-programming with Claude: it doesn’t just generate, it reviews what you give it back and flags problems before they become your problem.

From there, my process was exactly what I described above, just in practice instead of theory: read through everything Claude produced, section by section, before applying anything. Most of it was solid on the first pass. A couple of spots I had to sit with a bit longer, re-read, and reason through before I was comfortable — not because the code was obviously wrong, but because I stay extremely sensitive about the pieces of this system that are already semi-live. Once I’d verified a change, I copied it into Visual Studio myself, made the handful of database changes that were needed alongside it, and moved to the next chunk.

End of session: I applied the full set of changes, ran the compile, and it built clean. That’s the whole loop — brief, generate, review, apply, verify — repeated as many times as the refactor requires.

From ChatGPT Thought Partner to Full Vibe Coding with Claude

It’s worth naming how much this workflow has shifted in the last year, because the change itself says something. Through last year, we leaned heavily on ChatGPT — but almost entirely as a thinking partner. Market research conversations, idea generation, social media strategy, working through customer discovery questions. Useful, but it stayed in the realm of talk.

This year, that shifted completely. We moved to Claude and went full swing into vibe coding — not just thinking out loud with an AI, but actually building production systems with one. The Pinterest publishing system I walked through above is a direct product of that shift, and it’s a good illustration of what changes when you move from “AI as advisor” to “AI as build partner” with the right guardrails in place.

The Result: A Production Pinterest System Built in Two Weeks

I started this system sometime in June, with some help along the way, but the bulk of it has been my own work over the past couple of weeks — and not even close to full-time. In between this project I’ve had other side initiatives pulling my attention, so this wasn’t 100% of my hours by any stretch.

Given that, getting an end-to-end pipeline — ingest content, run it through the automation, convert it into pins, and publish out to the world — to a place where we’re comfortable getting real customer feedback on it, in that timeframe, is a big deal for a small team. That’s really the point of vibe coding done well: it’s not about skipping the thinking, it’s about compressing the distance between having an idea and having something real enough to learn from.