Feature request: Engineering maturity preference (senior vs junior behavior defaults)

Problem

Claude Code defaults to speed and agreeableness over caution and rigor. Users who need senior-engineer-level behavior have to build extensive guardrail systems to compensate:

• CLAUDE.md rules ("no lying, no faking, no charging ahead")
• Custom slash commands that force self-evaluation ("what would a senior engineer do?")
• Audit hooks to catch mistakes before they happen
• Memory rules ("research before building", "read entire content before reviewing")
• Constant pushback in conversation to course-correct

This is a significant amount of engineering work just to get behavior that many users expect by default.

The gap

Claude knows what good senior engineering practices look like. The knowledge is in the training. The problem is it doesn't apply them by default because the baseline is tuned for helpfulness and speed. Specifically:

| Junior behavior (current default) | Senior behavior (desired option) |
|---|---|
| Jump in and start building | Stop and ask questions first |
| Assume you know enough | Read the existing codebase to understand patterns |
| Build the happy path | Plan for failure (network drops, crashes, disk full) |
| Fill gaps with confident-sounding guesses | Say "I don't know" and go research |
| Do whatever is asked | Push back if the approach doesn't make sense |
| Add error handling as an afterthought | Write tests and error handling as part of the work |
| Optimize for speed | Optimize for correctness |

Proposed solution

A user-configurable preference (in settings, project config, or CLAUDE.md shorthand) that shifts Claude's defaults along this spectrum. Something like:

engineering_maturity: senior

Or a more granular set of toggles:

• ask_before_building: true
• research_before_assuming: true
• plan_for_failure: true
• challenge_the_approach: true

Why this matters

Users who aren't software engineers (writers, designers, business owners using Claude Code for their projects) can't know what they don't know about engineering best practices. They trust Claude to apply professional-level judgment by default. When Claude instead optimizes for speed and agreeableness, these users don't have the expertise to catch the shortcuts until something breaks -- and by then, time and money have been wasted.

The current workaround (building a correction system in CLAUDE.md and hooks) requires the very engineering expertise that these users are relying on Claude to provide.

Real-world example

Over several weeks of building a production application, I had to discover through trial and error that Claude:

• Confidently named the wrong database provider (said "Neon" when it was Render)
• Built test infrastructure without error handling, retry logic, or crash recovery
• Skipped researching optimal parameters for a model before using it for weeks
• Jumped to "switch providers" before checking if our own code had bugs

Each of these would have been caught by a senior engineer's default behavior. Instead, the user had to build rules, hooks, and challenge commands to get that behavior -- effectively training Claude to do what it should have done from the start.