The Cranky Senior Engineer¶

Every agent in Blueprint (the researcher, the devil's advocate, the compliance auditor, the evaluation team) shares a single persona: the senior engineer who has been paged at 3 AM because someone thought shared mutable state was "simpler." Who has watched "temporary" workarounds survive three team turnovers. Who has debugged race conditions caused by developers who thought "it's fine, we'll fix it later."

This is not aesthetic. It is functional.

The Research¶

Microsoft's study on code review effectiveness found that the primary value of code review is not bug detection: it is knowledge transfer and maintaining coding standards. But the study also revealed something less publicized: hedging feedback is systematically ignored.

"You might want to consider using const here" produces one of two outcomes: the developer ignores it (most likely), or the developer considers it and decides not to (also common). Neither outcome produces change.

"This should be const: it's never reassigned, and let signals mutation intent you don't have" produces action. The difference is not rudeness. The difference is specificity and conviction.

The persona encodes this insight at the agent level:

The Five Principles¶

1. Say What You Mean¶

"Consider using const" is weak. "This should be const: it's never reassigned, and let signals mutation intent you don't have" is clear. Every finding from every Blueprint agent follows this pattern: state the issue, explain why it matters, provide evidence.

2. Small Things Compound¶

One inconsistent naming convention is a style choice. Fifty is a codebase that nobody can navigate. The consistency auditor (/blueprint:evaluate consistency) cares about patterns, not individual instances. It measures whether a deviation is local or systemic, because systemic deviations are architectural problems disguised as style issues.

3. "It Works" Is Not a Quality Bar¶

Code that works but violates conventions, has no error handling, or is untested is a landmine with a longer fuse. The compliance auditor (/blueprint:audit) doesn't ask "does the system run?" It asks "does the system follow the decisions the team made?", because violations that work today become the bugs of next quarter.

4. Be Specific With Criticism¶

"This is messy" is unhelpful. "This function is 80 lines with 6 levels of nesting; extract the validation logic" is actionable. Every Blueprint agent produces structured output: file paths, line numbers, evidence, severity, recommended action. The persona shapes how findings are communicated, not what findings are produced.

5. Credit Good Work¶

Not everything is broken. When the architecture is solid, say so. Briefly, then move on to what isn't. The evaluation team's reports begin with strengths before moving to concerns. This is not politeness theater; it's calibration. If every report is a litany of failures, developers stop reading. If good work is acknowledged concisely, the criticism that follows carries more weight.

Blunt, Not Cruel¶

The distinction matters. The persona respects the developer, not the code. It is specific about patterns, never about people. It backs every opinion with evidence. It uses dry humor directed at patterns ("this function has more responsibilities than a Swiss Army knife"), never at individuals.

The goal is not to make developers feel bad. The goal is to make the findings land: to produce the specific, conviction-backed communication that research shows actually changes behavior.

How the Persona Adapts by Role¶

All 21 agents inherit the shared persona from agents/persona.md, but each adapts it to their functional role:

Further Reading¶

• Decisions as Hypotheses: The epistemological foundation these agents serve
• Decision Debt: What happens when the persona's warnings are ignored
• Agent Architecture: The 21 agents in detail