How to Vibecode Anything

I’m a marketer. I’ve never written code more complex than hello world.

Yet in the past year I launched my own Swift iOS app and started generating revenue. This website runs on Astro JS and is deployed on Cloudflare Workers. I’m using development standards close to best practices. What used to cost me thousands of dollars in developer fees is now available for subscriptions of tens of dollars a month. Though I’ve since upgraded to Claude Code’s $200/month plan.

I’m not claiming this is a complete guide to vibecoding that will answer every question and solve every problem. I’m simply sharing the principles that work for me. But first, let me repeat the obvious and popular phrase: vibecoding won’t replace developers (yet), but it will make everyone a developer and let anyone build software.

Remember the first thing you asked ChatGPT? In his interview with Lex Fridman, Sam Altman said it looked like one of the very first questions people asked AI was something that genuinely mattered to them. And from that question you could tell who they were and what they needed. For me, one of my first tasks was writing Python code. Back then with ChatGPT 3, I got code that worked after the 10th fix. Still, I was thrilled: I could make code using the English language, not Python.

Use the Cutting-Edge Tools: Claude Code and Codex by OpenAI

There are several reasons.

1. You can be sure you’re getting the most advanced model.
2. The agents themselves — Claude Code and Codex — are powerful and constantly evolving.
3. Anthropic and OpenAI essentially subsidize their agents.

Let me break these down.

First — the model. I’ve had situations where I was using Cursor and debugging an API access service for my app connected to an Anthropic model. At one point, Sonnet 4 decided that Sonnet 4 doesn’t exist and should be replaced with Sonnet 3.5. I asked a follow-up about which model it was, and it answered Sonnet 4. Hard to say if it was a hallucination, a model nerf, or something else. I’m not blaming Cursor here, but the whole situation felt off.

Second — the agents. Another argument for choosing Claude Code and Codex: context window size. Cursor’s context window is roughly 50% of Claude Code’s. In coding agents right now, the context window size and how it’s managed is the biggest bottleneck — not the model itself. Models are universally available via API to any company. But the model stops remembering what was said earlier, and with code that can be critical. It leads to problems: the model doesn’t follow the plan, doesn’t fix bugs, can’t implement a feature. Just recently Claude Code shipped several features that help the model process plans and make fewer mistakes.

Third — cost efficiency. One analysis showed that Claude Code’s Max plan delivers up to 13.5x more value compared to buying the same tokens via API, and up to 36.7x more value in warm cache scenarios. And cache is essentially reading the previous conversation and the agent’s own reasoning. On top of that, vibecoding platforms like Replit and Lovable need to make money, which means they sell you tokens with a markup — and they do. These are decent products for first experiments. But every time I hear that vibecoding doesn’t work for anything more complex than a personal website or a prototype, it turns out the person tried doing it in Lovable or Replit.

How to Work with Claude Code If You’ve Never Done It

Claude Code runs in the terminal by default — the command line interface. If you don’t know, the terminal has existed since the dawn of computing and lets you execute commands. There’s no visual interface like Windows or iOS. And remarkably, this interface from the ’80s is perfectly suited for an AI coding agent in 2026. Here’s why you shouldn’t be afraid of the terminal:

1. The terminal can run commands like installing libraries, accessing GitHub, creating files and folders. But you won’t need to do any of that yourself — you’ll just write in plain language. This is the fundamental difference from copy-pasting out of an AI chatbot window. Files get created, commands get executed, the agent does all the heavy lifting.
2. You probably won’t be reviewing your own code if you don’t really know how. So the main window you need is the chat, not a code editor.

What you need to get started:

• A Claude subscription
• A terminal — it’s already on your computer by default

You chat with the agent just like you would with a model in apps or on a website. Sometimes tasks will come up that require your clicks. Claude won’t pay for your Apple Developer subscription so you can publish apps on the App Store. But it will tell you how to do it. At any point when something is unclear, you can ask any question in your own words and the agent will answer.

How to Write Prompts So Code Actually Gets Built and Works

The general flow for creating code for any task with agents:

1. Describe what you want and chat with the model about how it should work.
2. Ask Claude to write a plan as a markdown file (.md).
3. Read that file at your level of understanding and edit it if your vision of how the feature should work differs from what’s written.
4. Ask Claude to implement the plan.
5. Run it, test it, give feedback.

If the product is complex, just like in real development, start with one core feature, then build another. Each time you repeat the cycle: plan → build → feedback.

Why use markdown files? AI understands them better because it spends fewer tokens reading them. One technique I’ve been using lately for planning: I ask Codex to write the plan, then Claude Code to implement it. Codex shows excellent planning abilities. It persistently and thoroughly walks through the codebase, analyzes it, and produces a better plan. Meanwhile Claude handles the actual development very well. I don’t always plan in Codex. Claude’s built-in planning feature will write a solid plan for something like adding an email signup form to this blog. But when I need to add a new feature to Chiaro or ask to refactor code for performance — I start with Codex.

As for other differences between Claude Code and Codex: Claude is still better at design and UX in terms of actual execution. But that’s my personal assessment based on my specific tasks.

You Don’t Need Figma Either

Vibecoding changes not just coding but the whole workflow around it. I cancelled my Figma subscription and switched to AI for mockups.

I think through how a feature should work, brainstorm with Claude, then ask it to create markdown text mockups for each option I like. Then I take those into Gemini with Nano Banana to generate visual mockups. The result — aligned UX ideas I can bring back to Claude Code and say: build it like this.

Minutes instead of hours. No dragging rectangles in Figma, no design tool subscription to think through a layout.

What to Do When Code Doesn’t Work and Claude Can’t Fix It

Let’s say you’ve hit a wall. The code doesn’t work as expected, you’ve already shared the error and asked to fix it, but there’s no progress. Your gut tells you to push the agent harder. That’s how it works with yourself and with people: not working — try harder. But with an agent you need to start fresh. Here’s why:

1. As the agent works, the context window gradually fills up.
2. All your failed attempts aren’t fully ignored.
3. Hallucinations start appearing at roughly 60% context window fill.
4. Once you’re in the 60-100% zone, you’re at risk. Pushing harder doesn’t help.

What to do about it:

• The /context command shows how much of the window you’ve already used.
• The /compact command summarizes your chat on demand to free up space in the context window.
• The /clear command radically clears the context window. Sometimes when you’re stuck, you need to clear it and ask Claude Code to go through the plan again and analyze the error fresh.

By default Claude Code ships with a clever feature. Despite the limited command line design, Claude displays the percentage of context window remaining. It is a simple but essential indicator.

How to Stop Repeating Yourself

I’ve already touched on markdown, and there are two critical files you should use when working. They need to be in the root folder of the project you’re working on. These are Claude.md (for Claude Code) and agents.md (for Codex). What to put in them:

• What you’re working on
• Recurring rules for how your code should be handled

Here’s an example. When working on my Swift iOS app, I test on a real iPhone, not on the macOS simulator. The simulator is fine, but sometimes it doesn’t match the real device in UX, performance, and errors. Last fall I attended an Apple workshop in Cupertino and Apple recommends testing and performance profiling on real devices, not simulators. Yet agents keep defaulting to launching the simulator. So when developing Chiaro, I added these lines to Claude.md:

## Testing Rules
I prefer testing on the real device to see how the app works.
- **DO NOT** try to run the emulator/simulator
- Instead, say: "It's time to build and test on your iPhone"
- **ALWAYS** provide clear instructions on what to test:
  - List specific features that were changed
  - Describe expected behavior
  - Note any edge cases to check
  - Mention specific UI elements to verify

Every time a feature is done, I get a list of what I need to test to make sure the feature is complete and I haven’t missed anything.

It’s important to remember that Claude Code reads this file every time it performs any operation. Too much text in it means a significantly reduced context window. There’s no point writing instructions telling Claude to act like a top developer — the agent’s developers already did that for us, and it would only clutter the context window.