7 Months of Claude Code Lessons in 19 Minutes

Sabrina Ramonov, a UC Berkeley computer science and physics graduate who previously sold an AI company for millions of dollars, presents her refined workflow for using Claude Code in real-world production software engineering — explicitly distinguishing this from 'vibe coding' or MVP building.

The foundation of her workflow is a comprehensive claude.md rules file (equivalent to cursor rules in Cursor AI). This file is organized into sections covering implementation best practices, function writing best practices, test writing best practices, code organization, and git conventions. Key rules include: always ask clarifying questions before coding, draft and confirm an approach, follow test-driven development (TDD), prefer composable testable functions over classes, use branded types in TypeScript, rely on self-explanatory code rather than excessive comments, and critically — avoid extracting new functions unless they will be reused, are the only way to unit test otherwise untestable logic, or dramatically improve readability. Each rule is tagged with codes (C1, C2, T1, T2, BP1, etc.) so Claude can cite specific rule violations in its output.

A major component of her system is a set of named shortcut commands embedded in the claude.md file. 'Q new' clears context and forces Claude to read and internalize the rules file at the start of every session. 'Q plan' instructs Claude to analyze similar parts of the codebase to ensure the proposed plan is consistent with existing patterns and reuses existing code. 'Q code' triggers implementation with TDD enforcement and lint/type checks. 'Q check' runs a quality review against the function and test checklists — she finds it more effective to run 'Q check F' (functions only) and 'Q check T' (tests only) separately. 'Q X' has Claude role-play as a human UX tester and output a prioritized list of test scenarios. 'Q git' stages all changes, creates a conventional commit message, and pushes to the remote branch.

She demonstrates the full workflow by implementing a prompt-selection dropdown feature in her live production app — a content repurposing tool where users convert TikTok videos into LinkedIn or Facebook posts. She shows how she iterates on the plan before ever running Q code, pushes back on unnecessary features like search functionality (arguing users have dozens of prompts, not hundreds), and actively monitors file changes in the source control diff view while Claude is coding. She catches and corrects sloppy code patterns by highlighting specific code blocks and asking Claude to clean them up.

After the first working implementation appears within roughly 10 minutes, she runs the quality check shortcuts and finds issues: no TDD was followed, some code was unnecessarily complex, and there were messy multi-line constructs that could be simplified to one line. She walks through iteratively correcting these. She concludes by running Q X for UX test scenarios, testing the feature manually against the generated list, and finally running Q git to commit and push. Her central thesis is that the first draft from Claude will be functionally working but often of poor code quality, and engineers must stay engaged, actively question the AI's decisions, and use structured checklists to prevent accumulation of spaghetti code in complex production codebases.