AI-Driven Software Engineering [Part 3]: Ready to Use Tomorrow — Implementing CLAUDE.md and AI Analysis Prompts

3-part series | Estimated reading time: 12 minutes

Part 1 laid out the skeleton of the framework; Part 2 covered Working Backwards and the margin for exploration. In Part 3, we translate this framework into actual files and prompts that work. And at the very end, we look back at what this article series itself actually was.

Implementing with CLAUDE.md in Claude Code

Claude Code has a file called CLAUDE.md. It's automatically loaded at the start of each session, conveying the project's rules, conventions, and architecture to the AI.

This framework is implemented as CLAUDE.md with the following structure.

/
├── CLAUDE.md                        # Shared foundation (common to all profiles)
├── .claude/profiles/
│   ├── PROFILE_A.md                 # Small-scale, high-speed type
│   ├── PROFILE_B.md                 # Large-scale system type
│   ├── PROFILE_C.md                 # Security-strict type
│   └── PROFILE_D.md                 # Mission-critical type
└── apps/<app-name>/CLAUDE.md        # Each app specifies its profile

Root CLAUDE.md: Shared Foundation

The root CLAUDE.md holds only the rules that apply universally, regardless of profile. The key is to keep it short. Claude Code's context window is finite.

What to include: project structure description, command list, commit message conventions, non-negotiable rules (the Beyoncé rule, test pyramid, "shift left"), design decision workflow, Working Backwards principles, and exploration margin recommendations.

What to leave out: linter/formatter rules (enforced on the CI side), profile-specific rules (delegated to each profile file), and lengthy explanations.

Profile A: Speed Is Everything

The core of Profile A is "speed > perfection."

# Profile A: Small-Scale, High-Speed Type

## Top Priority: Speed
- Code review: AI-first only. Humans involved only for architecture changes
- Test coverage: 60% (lower threshold accepted)
- Strictly follow YAGNI. Don't build what you don't need right now

Especially important is spelling out the promotion criteria upfront. If a system that started on Profile A grows and you can't decide "when to move up to Profile B," you'll end up running a large system indefinitely with low test coverage.

Profile C: Security Takes Precedence Over Everything

Profile C's design philosophy is defense in depth. AI is one layer of defense — not the final one.

# Profile C: Security-Strict Type

## AI's Role (Intentionally Limited)

### What to delegate to AI
- Automated detection of known vulnerability patterns (OWASP Top 10, etc.)
- CVE monitoring for dependency libraries

### What NOT to delegate to AI
- Discovering novel attack vectors → humans expand through sparring sessions
- Design decisions around authentication and encryption → humans design, AI assists with review only

What stands out most in Profile C is the threat modeling workflow. After enumerating threats with STRIDE analysis, you expand by sparring with AI: "List five attack paths in this design that we might be overlooking." A prime example of combining human analytical depth with AI's breadth of coverage.

Profile D: Not Changing Can Be the Right Call

Profile D is the most conservative — and the most distinctive.

# Profile D: Mission-Critical Type

## What Makes This Profile Special
- The burden of proof for any change lies with the person making it
- "Don't touch what's working" is a legitimate decision
- PRs strongly recommended to stay under 200 lines
- No deployments Friday afternoon through Monday morning

While other profiles support "writing good code quickly," Profile D institutionalizes the courage not to change things. For systems like infrastructure or databases — where a failure stops everything — "doing nothing" is genuinely the best call in some situations.

Canary releases start at 1% increments, with at least one hour of monitoring between each stage. Stable operation in staging for 24 hours is confirmed before moving to production. This is a world where caution beats speed.

Designing the AI Analysis Report Generation Prompts

To run the third layer of the framework (the talent development environment), you need prompts that analyze sparring session logs. I designed these in four stages.

Prompt 1: Single-Session Analysis (Immediate Feedback)

Feed in the log from one sparring session, and it returns a five-dimensional score (1–5), improvement suggestions (up to three), and strengths (up to two) in JSON format.

The most critical part here is the privacy instructions.

[ABSOLUTE RULE]
The output must NOT contain:
- Specific questions used in the sparring session
- Project names, technology names, team names, or individual names
- Specific code snippets or error messages

All findings must be written in abstracted form.
  ✗ "Asked a structurally layered question about React state management"
  ✓ "Asked a layered, decomposed question about state management in a framework"

These instructions make it impossible to reconstruct the specific content of the raw log from the AI analysis report.

Prompt 2: Quarterly Analysis (Pattern Recognition)

Feed in a time series of scores from multiple sessions to visualize growth trajectories and patterns. In v2, a goal alignment check was added here.

When generating "recommended actions," rather than simply patching weak spots in the scores, the system cross-references the individual's self-reported career goals and prioritizes strengthening the dimensions that contribute most to achieving them.

Prompt 3: Team Aggregation (For Managers)

Aggregates anonymized quarterly reports to analyze the team's overall five-dimensional profile, diversity of thinking styles, and profile gaps. Output is generated in a form that makes identifying individuals impossible.

Prompt 4: Bias Audit (Conducted Quarterly)

Verifies the fairness of the AI analysis model itself. All members' scores are segmented by gender, nationality, age, and years of tenure to check for statistically significant differences.

The key point: "a difference exists" ≠ "a problem exists." Correlation between tenure and scores is reasonable. But if a correlation exists between gender and scores, that's a warning sign to suspect model bias.

Overall Data Flow

Raw sparring log (individual + AI only)
  ↓ Prompt 1
Single-session analysis score (individual only)
  ↓ Accumulated quarterly
  ↓ Prompt 2
Quarterly report (individual → mentor → manager)
  ↓ Anonymized
  ↓ Prompt 3
Team trends (manager)
  ↓ Attribute tagging
  ↓ Prompt 4
Bias audit (auditor)

At each stage, the level of abstraction increases, and the specific content of the raw log never leaks upward. This is the technical implementation of the privacy architecture.

Rollout Roadmap: Not Overdoing It Is the Top Priority

If you've read this far and thought "there's no way to do all of this at once" — that's the right reaction. The framework itself cautions against excessive upfront investment.

Phase	Duration	Do This	Don't Do This
Phase 1	1–2 weeks	Monorepo + trunk-based + AI-first review. Start operating on Profile A	Introducing Profiles B/C/D, changing evaluation systems
Phase 2	2–4 weeks	Test automation, phased introduction of Profiles B/C/D	Building the sparring log analysis infrastructure
Phase 3	Ongoing	Sparring log infrastructure + 6-dimension evaluation + privacy architecture	Trying to complete everything at once
Phase 4	Ongoing	Hackathon sparring days, cross-profile pair sparring	"Mandating" exploration

If you're pre-PMF, Phase 1 alone is enough. Set up a monorepo and trunk-based development, run AI-first review. That alone will dramatically improve your development foundation.

Phase 4's "cultivating an exploration culture" comes last — but from Phase 1 onward, start sending the message that exploration is welcome. The formal structures can come later. The atmosphere starts from day one.

This Article Series Is Itself a Live Example of Sparring

Over these three parts, we've traced how a framework was born from sparring sessions with AI. To close, I want to reflect on that process itself.

What the Chain of Questions Produced

The first question was a simple one: "Would AI-driven development change Parts 3 and 4 of this book?" From there, through a chain of seven questions, a comprehensive three-layer, two-axis framework took shape.

What matters is that AI didn't design all of it.

AI returned logically consistent answers every time. But it was the human on the questioning side who discovered the implicit assumptions embedded in those answers and steered things toward better structures.

When AI said "humans handle this independently," I corrected it to "this can be expanded through sparring"
When AI played it safe with "don't use this for evaluation," I overturned it with "this should be the most important evaluation criterion"
When AI said "uphold ethics through willpower," I had it redesign the approach to "make it structurally impossible to break"

The quality of the question determines the quality of the answer. That's precisely the principle this framework itself preaches.

Three Sparring Patterns

The sparring patterns extracted from this session were codified into guidelines as the framework's "sparring pattern library."

The logical staircase pattern. After receiving AI's conclusion, ask yourself: "Taking this conclusion as a premise, what's the next deeper question?" The previous endpoint becomes the next starting point, and the questions form a single staircase.

The assumption surfacing pattern. Ask: "What is this answer implicitly assuming?" and "What happens if we remove that assumption?" AI tends not to be aware of the assumptions underlying its own answers. Surfacing them is the questioner's job.

The devil's advocate pattern. Ask AI to "construct the three strongest arguments against choosing this option." Use AI as the best possible critic of your own choices.

What Sparring Doesn't Produce

At the same time, there are things that sparring didn't produce.

The Working Backwards perspective didn't emerge from within the sparring sessions — it came from self-criticism directed at the framework's design output. The idea of exploration margin came from stepping back to survey the entire rational framework and asking "what's missing?"

Sparring expands thinking, but the power to question the frame of thinking itself lies outside the sparring session. The reason the framework itself concludes with "this framework should itself be subject to sparring" is precisely this recognition.

Closing: Keep Asking

"Software engineering is programming integrated over time."
  — Titus Winters, Google

Software engineering in the age of AI is
"the ongoing practice of humans and AI collaborating to sharpen the quality of questions,"
and simultaneously "the practice of nurturing, outside the realm of questions,
what questions alone cannot measure."

A 685-page classic was transformed, through sparring with AI, into an actionable framework. And that framework itself says: "Every quarter, spar with AI about the framework itself."

In other words, this framework has no "finished" state. As long as the questions keep coming, it keeps evolving.

That, I think, is the essence of software engineering in the AI-driven era.

The content of this series is itself "a live example of building a framework through sparring with AI." In your own project, try throwing out just one question. "What is the biggest weakness in this design?" — everything starts from there.