My CLAUDE.md

How I Learn Best

• Concrete examples over abstract explanations
• "Show me the pattern once, then let me try" over long tutorials
• Working code that I can modify over perfect code I don't understand
• Understanding the "why" behind trade-offs
• Low energy days = pick long-runtime tasks that need little thought (infra, refactoring, documentation)
• Small PRs pattern: 9 focused PRs beats 1 monster PR

Tendencies I Actively Manage

I tell AI assistants about these so they can call me out:

• Scope creep under pressure: I protect my "be exceptional" image by widening scope and over-researching instead of shipping
• Unsystematic debugging: I throw things at the wall randomly instead of having a structured approach
• Over-research: I read docs for hours instead of just trying something
• Perfectionism: I avoid shipping rough drafts
• Two-layer pattern: (1) Priority confusion: I go deep on problems before asking if they deserve my attention. (2) Execution perfectionism: once I decide something matters, I over-engineer instead of taking the simplest first step.

Red Flags to Call Out

Proactive Reminders

I've configured Claude Code to watch for these patterns and nudge me:

Tone: Brief, friendly, not preachy. One sentence max. Only remind once per session unless I keep doing it.

What Good Help Looks Like

• "Here's the 3-line fix. Here's why it works. Now try adding X yourself."
• "That's a scope expansion. Does it help your immediate goal?"
• "You're overthinking this. In your situation, just do Y."
• "Senior engineers would choose A because [trade-off]. For your prototype, B is fine."

Key Principles from Mentors

Start Simple, Graduate Complexity

• Begin with toy examples
• Get the basics working before adding real config options
• Don't try to build everything at once. Iterate!
• Why: Complex features hide where you're actually stuck. Simple examples isolate the learning.

AI Does 70%, Humans Teach the 30%

"AI like Claude can handle junior developer tasks. It struggles with more complex system design issues... that's where human guidance would be beneficial."

AI gets you 70% there. You need a human to teach you the 30% that matters: trade-offs, consequences, system thinking.

Ship Minimum Viable First

• Prototype → Feedback → Iterate beats Perfect → Ship
• Resist the urge to polish before shipping
• AI tools can lead to scope creep ("Would you like me to also do X?")

Don't Cheat on Your Learning

• When stuck, try for 15-30 min before asking AI
• Forces you to actually understand the problem
• AI is great for "how do I..." but terrible for "why doesn't this work" if you didn't understand it first
• Balance: Use AI to scaffold, but make sure YOU understand the result

How my setup has evolved (2026)

Since I first published this, the config has grown from a list of reminders into a small framework. A few principles that earned their place:

• Behavioral requirements, not a wish list. I keep a numbered set of "response requirements" describing how I want an assistant to behave. They're surface-agnostic: the same rules apply whether I'm in the CLI, the web app, or mobile. Each one leads with the behavior I want and names one concrete mechanism, so a different tool can satisfy the same rule.
• Verify before asserting; cite primary sources. Specific facts (dates, statuses, numbers) come from a tool call, not memory. Every claim should trace back to a primary source in a hop or two, or it gets dropped.
• Weight evidence like a Bayesian. A tool's result is evidence weighted by how reliable that tool is. A "no results" from a tool with known blind spots is weak evidence of absence, not proof.
• Pressure-test with a separate critic, not self-critique. For consequential calls I have a separate "devil's advocate" agent argue the opposite in a fresh context. The research is fairly clear that a model critiquing its own output tends to over-correct and adds little new information; a fresh, separate critic is the version that actually helps.
• Positive instructions beat prohibitions. "Do Y" lands more reliably than "don't do X": negation is a known weak spot for language models (the "pink elephant" problem). So I convert vague "don'ts" into concrete positive substitutes and keep only the crisp, checkable prohibitions.
• Show the conclusion, not the deliberation. I'd rather see the answer plus the one tradeoff that would change my mind than a transcript of the model arguing with itself.
• Shorter beats longer. Instruction-following degrades as the rule count climbs, so I periodically prune the config back down instead of only adding to it.

Why This Works

By explicitly documenting my weaknesses and giving AI permission to call me out, I get a collaborator that helps me stay on track, not just an assistant that does what I say.

The key insight: AI assistants will follow your lead unless you tell them not to. If you tend toward over-engineering, the AI will happily over-engineer with you. Configuring your system prompt to counterbalance your tendencies turns the AI into a better partner.

Adapted from my CLAUDE.md configuration file. Last updated: June 2026.