How I'm Vibe Coding in 2026

Even two years ago — maybe even one — if you wanted to build a startup, you needed a team. You needed developers. Getting to an MVP was going to cost real money.

That's basically gone now.

Since Opus 4.5 came out, it's crazy what you can build and how quickly. One person can do in a day what used to take weeks. For someone like me — who wouldn't say I "know how to code" but understands how apps are built and has worked in tech my whole career — it opened up everything.

That was part of why I left my PM job. I've gone back and forth between jobs and doing my own thing throughout my career, but I felt like this was a shift I couldn't sit out.

I recently read Peter Steinberger's post on shipping at inference speed and wanted to share my own take — what's working for me, where I agree, and where my workflow differs.

My Stack

Claude Code is my primary tool. I use it through the Cursor extension, running Opus 4.5.

Six months ago, debugging was a huge pain. That's pretty much gone. Errors are rare. When they happen, the fix is quick. I now use "Dangerously Skip Permissions" mode, which means I can start Claude on something and let it run while I do something else.

Claude Skills I've used a bit, though a lot of it is noise. The one that's actually useful is the front-end design skill — it gives you a product that looks less generic, less "AI-y." That's worth something when you want to ship something that doesn't scream "built by a robot."

Language & Ecosystem Decisions

Peter mentions that "the important decisions these days are language/ecosystem and dependencies." I'd agree, but in my experience, the models will choose correctly as long as you describe accurately what you're building.

I've had some pains — like when it optimizes for a single-page app when I actually wanted a multi-page blog setup — but honestly, it's not that big a deal. Refactoring is easy now. If something's wrong, you just tell it to fix it.

Using Multiple Models

I primarily use Opus for building, but I've started using multiple models strategically:

• Opus to build the thing
• Codex (or another model) to review it — "Does any of this not make sense?"
• Multiple models during planning to critique each other

I did this recently when trip planning. I had Grok, Claude, and ChatGPT all critique the same plan. It's like getting different opinions from different advisors. They catch different things.

I've also seen people use different personas and prompts with the same model — "you're a security expert, review this" or "you're a UX designer, what feels off?" It's basically running separate agents without needing separate tools. Cheap way to stress-test your work from multiple angles.

No Plan Mode

Peter talks about skipping "plan mode" — I do the same. I don't use formal planning modes. I just go straight in and say "don't implement anything yet" if I want to think through something first. Then when I'm ready, I say "build it."

My Workflow

Like Peter, I work on multiple projects at the same time — usually one or two active ones. The context switching is tough, but the trick is using multiple conversation threads within the same project:

• One thread for troubleshooting an error
• One for building a new feature
• One for planning

I let them work in the background while I go back and forth answering things. The analogy that comes to mind: it's like when I was a PM, responding to Slack while doing deep work. You're staying on top of stuff, but you're also getting your own work done.

Lately I've been using OpenClaw (an AI assistant I set up) to orchestrate task updates. It always updates the task lists in the projects themselves, so I never miss context — whether I'm working through OpenClaw or directly in the codebase.

Commits & Checkpoints

I basically never revert or use checkpointing. If something breaks, I'll ask the model: "What changed between the last commit and now?" and it can check those changes.

I commit to main. No PRs, no branches for most things. I'll probably start using PRs for big features on production apps like SEOTakeoff, or if I'm working with others, but for solo work? Straight to main.

Documentation as Context

I always have the model update a to-do list or development plan as we go. This serves two purposes:

1. If I need to onboard a new model (or a new conversation), the context is already there in the project folder
2. It helps me stay on top of what the plans actually are

This paid off when I set up OpenClaw — all the project context was already documented, so onboarding it was seamless.

Context & Prompts

I don't really think about context management anymore. I'll start a new thread for a specific issue, but that's mostly to keep me organized, not for the model. They handle large context much better now.

Prompts have gotten much shorter. Sometimes I'll add a line like "test this thoroughly" or "pretend you're a senior engineer reviewing this." But other times? I just paste an error and hit enter. That's it.

What This Actually Looks Like

Example 1: A newsletter in 90 minutes

A friend wanted to launch a newsletter. We sat down and in 90 minutes we had:

• A full year of content, automated
• A website
• A formatted newsletter template
• Everything connected and ready to go

90 minutes. That's not an exaggeration.

Example 2: Multi-language support in 2 hours

For SEOTakeoff, I wanted to add multi-language support. It took one hour to build and another hour to test. Done.

A year ago, that feature would've taken my entire dev team weeks to scope, build, and merge. Now it's an afternoon.

The Mental Shift

You're not a coder anymore. You're an architect. A question-asker. An orchestrator.

The skill now is knowing what to ask, when to ask it, how to prompt, and when to push back. A lot of that comes from intuition — for me, from years as a product manager. You still have to think clearly about what you actually want the app to do.

But the friction has shifted.

Building the thing? Not the hard part anymore.

Where the friction lives now:

• Integrating with third-party services — easy if the API is clean, annoying if it needs manual setup
• Marketing — this is the real bottleneck now. You can build fast, but getting customers still takes time.

Where Vibe Coding Doesn't Work

Honestly? I don't know. It seems like everyone is building all kinds of stuff. I haven't found the ceiling yet.

What This Means

If you've been sitting on an idea because you "can't code" or "don't have a technical co-founder" — that excuse is dead.

You can build it. Today. By yourself.

The question isn't can you build it anymore. It's should you build it and can you sell it.