Dako's AI Builder Notes
⌘K
中EN
System
Color theme
Changsha HubOffline
大可 Dako
大可 Dako大可 DakoAI Builder · Agent PractitionerTurning AI into working software. Practical notes on agent engineering, vibe coding, and commercial delivery.
Platform links coming soon
Don't chase perfection on the first try01Rough versionget it running first02Polish each roundchange a little, verify a little03Stable versionhold one down, then go forward✓ Iteration is fast because every step is easy to roll back and redo
Fast because you can redo, not because it's right the first time.

Iterate Fast, Don't Wait for Perfect

Ship a rough, runnable version first, then polish round by round. Commit each round to keep it fast and safe.

A common beginner mistake in vibe coding: wanting AI to write a perfect, ship-ready version on the first try—then you go back and forth for N rounds, each a teardown and redo. The smooth way works the opposite: ship a rough, runnable version first, then iterate and polish fast.

After reading, you should be able to answer:

  • Why does "make it work, then make it good" fit vibe coding?
  • How do you iterate fast without crashing?
  • When do you stop—stop polishing?

Rough first, then polish

  • Rough version first: any feature, have AI push out a runnable rough version first. If it works, can be seen, and can be verified, anchor it
  • Don't sweat details up front: styling, boundaries, perfect logic—fill those in after it runs
  • A rough version is a "seen version": make what you want visible first, then the remaining adjustments have a reference

Get it implemented first and perfect second—it's the shortest path to validating whether an idea can even work.

Keep each iteration small

  • One round, one change: each round picks a single "what does this round change," don't pile on
  • Verify after changing: after the round, is it right? run it, look at it copilot-cost
  • Commit when right: make it a new safe point

Small iterative steps plus a commit each means you always have a "last working version" to fall back to; a problem never sends you all the way back to scratch.

When to stop

Polishing never ends; give it a stopping standard:

  • Does the feature meet the acceptance criteria? → if yes, stop
  • Am I doing "polish" or "fixing a bug"? → if it's polish, stop first; safety and experience get their own priority
  • Will users really touch this? → only polish the corners users hit

Remember "ugly but running" beats "beautiful but never shipped." Lock a usable version down before chasing perfection.

With iteration material banked, the next step is the acceptance stage: Review the AI's Output, and learn to decide whether to take this result.

References

  1. How we make AI coding more cost-efficient (GitHub Copilot)