1. Build Rough
Don’t aim for perfection from the start. Get something working first.
In TokiQR’s development, within 75 minutes of the first commit on day one, all CDN dependencies were eliminated and the system was migrated to system fonts. By the next day, the audio encoding had been switched from Opus to Codec2, i18n support was added, a service worker was in place, and the rebrand to TokiQR was complete. None of these were finished products. A rough working version was shipped, then refined from there.
When collaborating with AI, what matters is not front-loading every detail into the first prompt. Convey the outline of what you want, and when something working appears, interact with it. What you learn by touching a working prototype vastly exceeds what any specification document could tell you.
In the time it takes to write a perfect design document, you could rebuild three times.
2. Trace the Data Flow
When code gets complex, what you should read is not the logic. It’s the data flow.
Where does the user’s input go, how is it transformed, where is it stored, and how is it displayed? Trace this flow, and both the source of bugs and opportunities for architectural improvement become visible. In TokiQR, audio data flows through a single pipeline: recording → Codec2 encode → Base64URL → QR code → URL → decode → playback. Because this data flow is clear, knowing where to intervene is instantaneous.
When asking AI for fixes, don’t say “fix this function.” Say “this data flows from here to here, and something goes wrong at this point.” When you speak in terms of data flow, AI writes precise code.
3. Check Against Design Philosophy
Once working code exists, the next question is: “Does this align with the design philosophy?”
TokiStorage’s design philosophy is clear. Don’t add external dependencies. Don’t run servers. Work local-first. Build as if it must last 1000 years. Because these criteria exist, the switch from Opus to Codec2 was made without hesitation when Opus proved unusable. The decision to go “Chrome only” came after investing enormous effort into Safari print support. An FFmpeg-based video feature was built in two hours and entirely deleted the moment WASM memory issues appeared.
Without design philosophy, every judgment reduces to “does it work?” Code that works but contradicts the philosophy will inevitably become debt.
“It works” is the minimum bar. “It aligns with the philosophy” is the passing grade.
4. Ruthlessly Align to Philosophy
Deepen the alignment with design philosophy further, and you reach philosophy itself.
Why eliminate external dependencies? For permanence. Why not run servers? To sustain at burn rate zero. Why open source? Because there’s no reason to hide. Push the “why” behind every technical choice far enough, and you always arrive at philosophy.
Ruthlessly aligning to philosophy does not mean using philosophy to justify technical compromises. It means the opposite. When you notice a technical choice that contradicts your philosophy, you ruthlessly change the technology. The decision to decline a patent application—even with an attorney’s endorsement—was made because the contradiction with the philosophy of openness became clear.
AI has no philosophy. That is precisely why the human must. When you tell AI “implement this without external dependencies,” the depth of philosophy behind that instruction determines the quality of output.
5. Don’t Hesitate to Discard
Among the 765 commits, there are features where dozens of commits’ worth of effort was invested and then entirely deleted.
Safari print support. The video feature (FFmpeg + TokiVideo binary format). The patent application. Each of these consumed significant time and effort, but the moment they were found misaligned with the design philosophy, they were cut. The feeling of “what a waste” clouds judgment. It is the sunk cost trap.
In vibe coding, because AI generates code at high speed, the cost of discarding drops dramatically. Throwing away 100 lines you wrote by hand hurts. Throwing away 1000 lines AI generated does not. This asymmetry should be consciously leveraged. The speed of the build-destroy-rebuild cycle is the true strength of vibe coding.
The volume of what you discard determines the purity of the product.
6. Preserve the Thinking
Code changes. Frameworks go obsolete. APIs disappear. But the thinking behind why something was built that way endures.
At TokiStorage, over 130 essays were written. The reasoning behind technology choices, the record of discarded features, the intent behind design decisions, the articulation of philosophy. These are not “documentation.” They are archives of thinking.
When collaborating with AI through vibe coding, the intent embedded in a prompt vanishes when the session ends. But once articulated as an essay, that same thinking can be reproduced in the next session, the next project, or by the next generation.
In an era where writing code is increasingly delegated to AI, the uniquely human work that remains is defining the “why,” articulating it, and preserving it. The final deliverable of vibe coding is not code. It is philosophy.
Build rough, trace data flow, check against design philosophy,
ruthlessly align to philosophy, don’t hesitate to discard, preserve the thinking.
The precision of vibe coding is determined by the resolution of your philosophy.
For the concept of vibe coding, see “Vibe Coding.” For rapid development methodology, see “Rapid Prototyping.” For the full development record, see “Thirteen Days of Building.”