llm / effective-llm-coding
Project Kickoff: Plan together with LLM
- Solicit questions to turn inacurate requirements to accurate spec
Accumulate knowledge artifacts
- Accumulate and update PRD-doc
- Maintain DESIGN doc
- Maintain plan-tree and progress-tree
- Explicitly require planning before big changes like refactor
- > Read PRD to understand requirements, read DESIGN for current codebase, check out plan and progress and pick up where you left
- Balance man-hours and tokens:
- As more tokens get burn, user get familiar with codebase and should proactively understand it
MVP / First-demo
- Logging: "Add debug/trace logs at each point where it might go wrong. Log with context"
- Have an idea on data flow / event sequence to facilitate debugging
- refactor:
- Make existing codes more concise before moving on
- Compare with original project plan and add missing parts
Re-think at middle of task
- Go through PRD/DESIGN again and ask more clarification questions
- Go through core data structure/types to see if they support functionalities well
Per-task Tips
- Self-verify
- "After each step use
xxx buildand fix compiler errors
- Limited scope
- Don't touch xxx module yet / don't worry about missing xxx field yet
- Mimic
- Refer to practice in XXX module, re-write YYY module
- Be specific
- instead of "rewrite/improve/refine", use "make it shorter" or "use xx but don't change APIs"
- "Ask clarification questions after reading XXX but before implementing"
LLM (Claude 5.5 Sonnet) Common Pitfalls
- Due to limited eye-sight:
- Multi definition of the same types
- Hard-code literals as it codes forgetting they are already defined in global consts/configs
- Focus on wrong level of abstraction
- add a "missing" method where it should call another existing one
- try modify method when the class design has flaw