The old “measure twice, cut once” advice assumed execution was expensive. For exploratory work, it’s not anymore. AI made building cheap, so the bottleneck moved upstream to clarity. We don’t need to measure… we need to clarify. And clarification doesn’t come from more planning. It comes from 2.6.5.5.2 touching the real thing.

So the workflow inverts. Instead of planning rigorously, 2.6.5.5 clarify through dialogue while building the first prototype. Grab an idea, 2025-02-09_00-36_leveraging-llms-for-efficient-code-prototyping-and-automation start prototyping, share the rough version, gather early feedback. An ugly prototype beats no prototype because it reveals what I don’t know. Even an ugly implementation beats no implementation. 2024-12-19_21-31_cult-of-done Cult of Done logic: prototype → POC → polish (if there’s time).

This compounds in exploratory work. Time spent building, testing, and learning gives us hands-on experience with the problem. When we try something, we get grounded in reality instead of assumptions. To get clarity, dig into a prototype early. The experience itself generates the understanding that planning was supposed to provide. 2.6.5.4 Ideas emerge bottom-up (I discover what I actually need by building, not by speculating about requirements).

I also realized that to communicate ideas, I have to visually present them. Demos beat decks. Working software melts away abstract objections.

The catch: skipping written planning means I replace it with real-time dialogue-based thinking. Direct AI collaboration helps here. My tmux collab workflow lets me dig into issues with Claude to get clarity before (or while) building. The thinking still happens… it just happens through prototyping instead of speculation.