AI-Assisted Development Process
This site was built with Claude Code and a structured GSD workflow — human-directed, AI-authored, and cross-model-reviewed, from initial planning through final polish. Here is how that process actually works.
Development Velocity
Claude Code + GSD Workflow
The GSD framework turns AI-assisted development from exploratory chat into repeatable engineering. Every piece of work follows a defined lifecycle, and nothing is shipped without a verification step and a commit.
Each phase starts with a RESEARCH.md document: existing patterns, known risks, design constraints.
PLAN.md files define explicit tasks with files, actions, verification steps, and done criteria.
An executor agent implements each task atomically, commits on completion, and tracks deviations.
TypeScript checks, test runs, and visual inspection confirm each task meets its criteria.
SUMMARY.md captures what was built, decisions made, deviations from plan, and metrics.
Two-Model Loop & Parallel Execution
The development model is deliberately adversarial. Claude Code authors the code; OpenAI Codex and an independent reviewer roster review every plan and every diff, and their findings drive fix cycles before anything merges. Plans are written test-first (red → green), and independent plan tasks run in isolated git worktrees scheduled by a dependency DAG, each committing back to the phase branch — so non-conflicting work proceeds in parallel without stepping on itself.
None of this is asserted on faith — it is recorded. The planning history spans 41 phase directories and 268 execution plans under .planning/, and every file change is logged across 77 devlog days. The raw, unedited record is browsable on the Dev Log.
Phase by Phase
Representative milestones from the early roadmap — the full planning history spans 41 phase directories.
Infrastructure, authentication, rate limiting, semantic cache, devlog system.
Key decision: Server Components by default; client only when hooks are required.
RAG pipeline, pgvector setup, streaming chat with email gate.
Key decision: RAG over fine-tuning — knowledge base stays up-to-date without retraining.
Job description parsing, match scoring, gap analysis, notification system.
Key decision: HMAC-SHA256 for PII hashing — stronger than plain SHA-256.
End-to-end test suite covering chat, JD analysis, auth, and rate limiting.
Key decision: FakeRedis (sync-safe FakeServer) for pytest — avoids event loop binding issues.
Real-time voice via the OpenAI Realtime API over WebRTC; transcripts stream over a separate WebSocket.
Key decision: WebRTC + a short-lived ephemeral token — the OpenAI key never reaches the client; only transcripts use a WebSocket.
Email integration, admin dashboard, analytics, this case study section.
Key decision: Case study as proof of competency, not just documentation.
What Worked / What Didn't
What Worked Well
- +Boilerplate and scaffolding — AI excels at generating correct, idiomatic code for well-defined patterns.
- +Test writing — AI-generated tests are comprehensive and catch edge cases quickly.
- +Refactoring — given a clear goal, AI can restructure code without introducing regressions.
- +Documentation — SUMMARY.md files, inline docs, and README updates happened automatically.
- +Debugging — AI found root causes faster than manual inspection in most cases.
Where Guidance Was Needed
- !Design decisions — AI can implement any design but needs explicit direction on which one.
- !Security nuance — AI knows security patterns but needs human review on threat models.
- !Business logic — what the system should do requires human input; AI handles how.
- !Tradeoff resolution — when multiple valid approaches exist, AI presents options but humans decide.
- !Scope creep — AI tends to add features; PLAN.md tasks kept scope controlled.
Development Log
Every file modified during development is logged with a timestamp, action type, and summary. This is the raw record of how AI-assisted development looks in practice — not curated, not edited. View the full development log on the Devlog page.