Planning Is the New Coding

I built the same app twice.

The first time it was one day of coding and several days of debugging. In the end, I deleted the code.

The second time I spent several days on planning and research. One day of coding and I had a finished app, exactly how I wanted it.

The difference wasn’t the code itself, but the plan I started with.

The First Attempt

Late last year, during the holiday season, I wanted to build a local meeting transcription app for Mac. With speaker recognition and the ability to create documents from the transcript and chat with it. All local.

I already knew Whisper. I had used it several times in Python apps and scripts. That’s why Whisper was my first choice.

I started with a simple prompt like “I want to build a local meeting transcription app with Whisper.”

Within a day I had a working app. Or so I thought. But after some testing I noticed that the speaker recognition wasn’t optimal. It was really bad.

That surprised me. I had tested other apps with the same functionality. They could do it. What were they doing differently than me?

I spent hours optimizing the parameters. Nothing helped. Then, during some research, I found out that most apps use a paid version of it, which is why it works so well.

That threw my project off track. I had to find a different solution.

First of all, I deleted the project. I knew I had to start from a blank page.

The Second Attempt

The second time I did things fundamentally different. Even though I already knew that planning in development with language models (LLMs) is extremely important, I had ignored it in the first attempt and sacrificed hours of my time.

First, I started with intensive research to find out what other options exist. That’s when I came across FluidAudio, which is optimized for Apple Silicon. That was the key to building the app the way I envisioned it.

Then I went into a deep planning phase with Claude Code. I used the DeepWiki MCP to give Claude Code access to FluidAudio’s documentation.

Then I wrote a detailed plan together with Claude. What should the app do? Recording capability, upload of existing meeting audio or video files, then transcription including speaker recognition. That was the MVP version.

During the planning phase I decided that I need the ability to create a document directly from the transcript and chat with the transcript.

I decided to keep it simple. There’s Ollama. The user can install models that interest them. In my case I chose Qwen3, but gpt-oss works wonderfully too.

I wrote everything I wanted into the plan. Then I split the whole thing into phases to see after the first phase whether the result is usable or not.

After I implemented the first phase, it was immediately clear that investing the time in planning had paid off.

The app looked exactly how I wanted it. It had exactly the features I needed. That saved me an enormous amount of time.

I invested one or two days in planning. It wasn’t one-shot. You always need some back and forth to get it right. But I got the app to match my vision very quickly.

Vibe Coding

The insight from this leads to the term coined by Andrej Karpathy. Vibe Coding. You surrender to the vibe and accept whatever the AI outputs.

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — Andrej Karpathy, February 2025

It works. But it works even better when you write a concrete plan.

In the first attempt I only did vibe coding, with little information, because I thought: “I’ve used Whisper before, I know how this works.” That didn’t work.

With a concrete plan, vibe coding works much better. That’s how you get the results you actually want.

The Numbers

The Engprax/J.L. Partners study (May 2024) with 600 software engineers showed exactly this:

• 97% higher success rate for projects with clear requirements before development
• 50% more success through specification before coding
• 57% more success through accurate requirements
• 39% of all failures are due to poor requirements

This was true before AI. With AI it becomes a multiplier.

The Job Has Changed

People used to have to invest many years to become good developers. To know how things work.

Now, with the rise of language models and agentic coding, this is changing. Developers are becoming product managers, requirements engineers and business analysts. But not just developers. Anyone who knows what they want to build can now build products with AI.

You describe what you want, and the AI builds it.

The more precise your description, the better the result.

Planning is the new coding.