Source of truth
Exact frontend, backend, schema, and deployment paths.
Library / Working with AI
Reviewed Oct 2026Building Software with AI
Prototype to learn, then freeze boundaries and build reliably.
01 / table
Different phases, different AI jobs
| Phase | Goal | AI role |
|---|---|---|
| Prototype | Discover interaction and behavior | Explore and challenge disposable ideas |
| Transition | Document golden behaviors and ownership | Audit source-of-truth paths and invariants |
| Real build | Make implementation maintainable | Small bounded changes, tests and QA |
Make the prototype answer a question: Name the uncertainty the prototype should resolve. Use representative data (synthetic, sanitized, or explicitly authorized) and familiar components where they affect that question, and include realistic exceptions. Record what it demonstrated and what remains untested. A search prototype should show whether people find useful results across representative queries, including weak or empty ones; a polished screen with hand-picked results cannot. A realistic prototype can support a product decision without proving production readiness. Further reading: Inside Reddit Proto: Real Data, Constrained Prototypes, and a Better Handoff (Claire Vo, How I AI, Oct 2026).
02 / cards
Before production code
Behavior contract
What must always remain true independent of model output.
Golden behaviors
Written expected user outcomes before implementing.
Ownership map
Which layer owns routing, validation, persistence, and authority.
Provider spike
Real schema, cost, latency, failures.
Smoke gate
Deployed journeys proving baseline usability.
03 / flow
Repair loop
ReproduceFailing testFind owning layerRemove conflictFixFull suite + deployed check
04 / table
AI as separate jobs
| Role | Use |
|---|---|
| Architect | Find simplest owning design and invariants |
| Builder | Implement one bounded slice |
| QA | Attack assumptions and capture regressions |
| Product | Test actual user confusion and value |
05 / list
Working rules
- Keep one source of truth for each behavior
- Use deterministic rules for mechanical facts
- Do not confuse valid schema with correct meaning
- Do not equate capability with authority
- Instrument latency before optimizing
- Every important bug earns permanent coverage
GOING DEEPER
Three debugging lessons from real builds
Symptom → actual cause → reusable lesson
| Symptom | What went wrong | Product/engineering lesson |
|---|---|---|
| Wrong factual answer | Frontend used the wrong execution path; the model was not the owning layer | Check routing, retrieval, context and authoritative state before prompt changes |
| Broken deployed modal | Conflicting CSS/JS visibility mechanisms and accumulated overrides | Remove the conflict; give the behavior one owner instead of patching again |
| AI calls felt slow | Model inference dominated latency, not SQL | Measure provider timing and optimize the real bottleneck; use interaction design or genuine streaming where useful |
Complexity worth keeping vs removing
| Useful complexity | Avoidable complexity |
|---|---|
| Explicit authority and product invariants | Duplicate runtime paths and ambiguous routing |
| Meaningful state transitions and review history | Patch-on-patch CSS or hidden fallback behavior |
| User journeys learned through testing | Multiple files claiming to own the same behavior |
Deployed smoke gate: The repair loop is reproduce → failing test → identify owner → remove conflicts → fix → full tests → deployed-browser check. Convert important bugs into regression coverage, and preserve the prototype → transition → maintainable build phase boundary.