My Personal Vibe Coding Workflow

Hello, I'm Yoshiko.
Recently, I've been increasingly creating tools I personally want using "Vibe Coding," so I thought I'd summarize the workflow that has become standard for me.

By the way, "Vibe Coding" refers to a coding style where humans give instructions via voice or text, and the AI takes the lead in writing the code. I hardly write any code myself when I work this way.

Requirements Definition

Tool: ChatGPT 4o
Deliverable: requirements.md

First, I decide things like "what to make," "who the target is," "what functions are needed," and "how the screen layout should be." I summarize these while chatting with my favorite AI.
Even if I haven't fully thought things through, if I start the conversation with "I want to make an app that does XX, help me with the requirements definition," the AI will interview me for the necessary information.

I often use ChatGPT 4o for this. I personally like its tone and vibe, and reasoning models tend to have a slower tempo.
Brainstorming and summarizing specifications is a level of difficulty that can be done perfectly well without reasoning.
But I think anything works here. The important thing is that the conversation flows well, so use your favorite model or chat app.

As a key point, let's also decide on the product name at this stage. Since the name appears in various places in the source code, changing it later increases the effort. AI is extremely good at coming up with name ideas, so it's a fun process.

Even if the conversation is rambling, it's so easy because if I just say "summarize everything we've talked about so far into requirements.md" at the end, it will do it. Even though I've already forgotten what we talked about in the first half.

Tech Stack Selection

Tool: ChatGPT 4o
Deliverables: tech_stack.md, directory_structure.md, db_schema.md, api_spec.md, etc.

Next, I decide on the technologies to be used, directory structure, DB design, API specifications, etc.
The reason for doing this much during the preliminary brainstorming is that if you start coding after only letting the AI read the requirements definition, it often runs off with technologies different from what you intended. For example, "I wanted to use Deno, but it wrote it in Node," or "I intended it to be a mobile app, but it came out as a web app."
To avoid wasting tokens, I decide on the technologies and directory structure in advance.
Conversely, as long as these documents exist, the AI will run with them on its own.

In this article, I've separated the sections for Requirements Definition and Tech Stack Selection, but in reality, I often don't clearly separate the steps and talk about them all mixed together in the same chat.
It's convenient because if I say "output requirements.md and tech_stack.md" at the end, it separates them properly.
If I feel like it, I might casually ask about DB or API design like, "Given the specifications we've discussed, what kind of API and data structure do you think it would have?" and it will churn out a draft, which I then give small pieces of feedback on and convert to Markdown. So easy...

For reference, my typical stack is:

• monorepo
• API (Hono or Mastra)
• iOS app (Flutter)
• DB/Auth (Supabase)

At the very end of this, it might be a good idea to have ChatGPT o3 review all the Markdowns at once.
When I tried it briefly, it organized and pointed out things that are easy to overlook, such as non-functional requirements and cost aspects.

Creating the Codebase

Tool: Claude Code
Deliverables: Environment setup, working code for each application

Now, it's finally time to start coding.
When initially setting up the entire monorepo, I use the CLI-based Claude Code.
In this step, since I'm generating a large number of boilerplate files and installing dependencies, editor-based agents tend to get heavy because index generation and type resolution run every time.
Also, environment setup involves frequent use of commands, so a CLI-based tool feels more natural.
(A similar tool, Codex, was also recently released by OpenAI.)

As for the work procedure, I first create a directory myself, run git init, place the Markdown documents created in the previous step into docs/, and commit them.
From there, I launch claude and have it read the entire contents of docs/.

The only thing I don't leave up to the "vibes" when doing Vibe Coding is Git management.
Since it often happens that "it was looking good a moment ago, but this instruction messed everything up!", I commit as soon as things look good.

Even just glancing at the file list in the diff helps you notice things that are clearly unnecessary. Reducing the number of files is important because it costs the AI more effort to keep track of everything.

When you have it read docs, it usually starts building based on that content automatically, so it's a good idea to say "Ask if you have any questions" along with the instruction to read. It usually asks about something I missed.

Claude Code moves the work along so quickly that the human essentially becomes a machine that looks at the execution commands and answers "Yes".
Personally, seeing the output stream out in the CLI feels very futuristic, and this is the stage where I get the most excited using Claude Code.

In terms of order:

• Creating and launching the API (DB mocked)
• Creating and launching the client (API mocked)
• Establishing communication between both
• Creating the DB and establishing communication
• Deployment

It's easier to proceed step-by-step like this.
If there's an API specification in advance, both the API and the client will be built based on it, making communication setup easy.

I run them locally and check the operation for each unit. Usually, some errors pop up, so I copy-paste them into Claude Code and have it fix them. After about two rounds of this, they usually both start up properly.
(If you run the local startup command through Claude Code, it will keep running and Claude won't be able to return, so you should type it yourself in a separate process.)
Even with just text, it does a pretty good job with the look of the views, but if there's anything I want to change, I have it fix those bit by bit with words.

Fine-tuning

Tool: Cursor
Deliverable: Final application

The final fine-tuning is done with familiar editor-type agents like Cursor.
I often use models like Gemini 2.5 Pro or Claude 3.7 Sonnet.

For things like splitting files into modules when they've grown too long, or small wording changes, it's easier to proceed while looking at the files yourself, so an editor-type agent is a better fit.

By the way, if you manually modify the AI's output, it often isn't recognized in the context and gets reverted in the next generation. So, when I make changes, I tell it, "I've made some adjustments, so please take note," to prevent it from being reverted. It sometimes feels like manual intervention is more work than it's worth...

---

So, that's a summary of how I've been doing things lately.

As an example of something I've made, here's a language learning app where you can talk to an AI via voice, and it gives you feedback if you sound unnatural.

Claude did a pretty good job with the design too.

Right now, I'm making a LINE-like chat-based playground app where I can have natural conversations with various AIs while also calling MCP Tools.

I've mostly done web development and had almost no experience with mobile app development, but now I can create mobile apps on a daily basis, which has expanded what I can achieve. (Actually, I chose it partly to catch up on Flutter, but with Vibe Coding, you really don't write code, so it didn't help with catching up... I did learn the startup commands, though.)

If you're deploying something, even if it's for personal use, you need to be careful with authentication and API key management, so an engineer's eye and intuition are helpful for giving those kinds of instructions. Even so, the experience of seeing an app come together before your eyes without writing code yourself is truly amazing.

Everyone probably has their own favorite procedure, but I hope this example helps you get a sense of what it's like!