CODE IN TOKYO

Design-First Is Right. But in the AI Era, "Think While You Build" Is Powerful Too

In a previous blog post, I wrote:

“AI development is more efficient when you nail down the spec first.”

I still believe that.

Especially for production builds, there are tons of things that are painful to fix later:

AI writes code fast, but if you push forward with a vague spec, you end up rewriting massive chunks later. The more production-grade the system, the more value there is in locking down the design.

That said, lately I’ve felt another style is also very strong.

”Actually, scrap that” is now viable

With AI, you can rapidly cycle through:

“How about a screen like this?” “Nope, that’s off.” “This one feels better.”

What used to take days of prototyping is now working software in hours.

That’s literally what I’ve been doing the past few days — rebuilding the same thing over and over until the spec finally clicks.

In other words, the style of:

Designing while implementing

has become realistic.

Especially powerful in POCs

This style shines in POCs (proof-of-concept).

In a POC, the spec isn’t fixed to begin with.

So rather than building a perfect design upfront, it’s faster to show something working — “kind of like this” — and check:

AI dramatically multiplies the number of iterations you can run.

But showing it to the client is dangerous

There’s a catch, though.

The moment you show a working demo, the client almost always thinks:

“It’s already done.”

Which tends to lead to conversations about:

But in reality, “the screen moves” and “it runs in production” are entirely different things. Honestly, every time someone says “it’s basically done, right?” I want to cry a little.

In the AI era, building something that looks like it works has become absurdly fast. The flip side: if you stop at “looks like it works,” you’ll see hell.

For POCs and production builds, use AI differently.

…that’s what I keep reminding myself, again today.