Alchemy Lab

AI Development Iteration Insights

Personal reflections on collaborating with AI in development

Author: Blue
Updated: 2024-12-24
Based on: feat-unified-sitemap-preview iteration retrospective

This is not a process specification, but personal insights I've accumulated from AI-assisted development. Recording them here, hoping they'll inspire future iterations.

Background

After completing feat-crawl-sitemap-export, I discovered several experience gaps:

  1. Single page scrape had no ZIP download option
  2. sitemap.md couldn't be previewed directly in frontend
  3. Should we add bilingual sitemap?

These problems seemed simple, but how you handle them determines iteration quality.

Insight 1: Proactively Identify Gaps, Don't Wait for Feedback

Experience

Instead of waiting for user feedback, I used the feature myself first and proactively discovered where the experience felt disconnected.

Reflection

AI can help write code, but won't proactively find experience issues. As a developer, I need to:

  • Walk through the complete flow myself after feature completion
  • Ask from user's perspective: "If I'm using this for the first time, where would I get stuck?"
  • Document the gaps, don't say "next time"

Conclusion

The best feedback comes from yourself. Don't leave QA work to users.

Insight 2: Borrow External Perspectives for Decisions

Experience

Facing three requirements, I asked a question: "How would a Google PM evaluate this?"

The result was clear:

  • P0: Single page ZIP download — High value + low cost, must do
  • P1: Frontend sitemap preview — Clear value, should do
  • P2: Bilingual sitemap — YAGNI, cut it

Reflection

Introducing external perspectives (Google, Apple, any team you respect) isn't about imitation, but to:

  • Break out of your own mental patterns
  • Evaluate requirements with higher standards
  • Gain courage to cut features

Conclusion

When you're uncertain whether to build a feature, ask yourself: Would this pass Google's bar?

Insight 3: Question Your First Reaction

Experience

My initial thought was: "Since we want unification, let's just use the multi-page list UI for single page too."

But I paused and asked: "How would Google approach this?"

After analysis:

  • Single page shows content directly (1 step)
  • Multi page requires selection first, then display (2 steps)
  • Forcing unification would degrade single page experience

So I kept two UI modes, sharing only the underlying logic.

Reflection

"Unification" sounds beautiful, but sometimes it's a lazy excuse. True good design means:

  • Different scenarios get different solutions
  • Share logic, separate presentation
  • User experience over code tidiness

Conclusion

Beware of "unification for unification's sake". Ask yourself: Does unification actually make users happier?

Insight 4: One Sentence Saves One Component

Experience

When discussing sitemap preview, I said:

"sitemap.md is just like other converted markdown, we can preview and render it with existing components."

This sentence let us skip the "create new SitemapPreview component" discussion and directly reuse the existing markdown renderer.

Reflection

The best code is no code. Before coding, ask:

  • Can existing components be reused?
  • Can existing functions be ported?
  • Do we really need a new file?

Conclusion

Before writing code, first see what you can avoid writing.

Insight 5: YAGNI Requires Courage

Experience

Bilingual sitemap sounds very "internationalized", but I cut it.

Reasons:

  • Current user base doesn't need it
  • Adds 50% workload
  • Can add later when actually needed

Reflection

Cutting features is harder than adding them. Someone will always say "what if we need it later?" But:

  • "What if" mostly doesn't happen
  • Premature code becomes maintenance burden
  • YAGNI's essence is delaying decisions until you have more information

Conclusion

Not sure if you should build it? Then don't. Wait until you're sure.

Insight 6: Process is a Tool, Not the Goal

Experience

After the iteration, I thought: Should I add "Google PM Evaluation" and "Alternative Analysis" to the OpenSpec process?

But then I reconsidered:

  • This success came from my proactive questioning, not from a checklist
  • Turning judgment into process would become formalism
  • CODEBUDDY.md already has YAGNI principles, no need to add more

Reflection

Good practices should become tacit knowledge, not mandatory process. The difference:

  • Tacit knowledge: Called upon when needed, doesn't get in the way when not
  • Mandatory process: Must follow every time, even when context doesn't fit

Conclusion

Experience should inspire judgment, not replace it.

This Iteration's Numbers

Metric Value
Phases 6
Commits 5
Average diff < 100 lines
Tests 284 (all green)
Cut features 1 (bilingual sitemap)
New components 0 (all reused)

Summary

This iteration confirmed several things for me:

  1. Proactively finding problems is more effective than waiting for feedback
  2. External perspectives help make better decisions
  3. Questioning first reactions often avoids over-engineering
  4. Reuse first is the most underrated principle
  5. YAGNI requires courage, but is worth maintaining
  6. Process isn't everything, judgment is

These aren't rules, they're pits I've fallen into, things I've done right. I hope next iteration, this document will remind me:

Slow down, think clearly, then act.