# AHA ANALYSIS Agent Instructions

The previous analysis produced charts and classifications but no genuine insight. Your job: find the things that would make a developer stop and say "huh, I didn't realize that."

## Context

You're analyzing 34 Codex CLI sessions from developer Nikhil over 4 days (Jan 28-31) working on a project called "cold-ranker" (an ML ranking model). He used gpt-5 and gpt-5.2-codex models.

## Paths

- **Parsed sessions**: `docs/run1-09022026/analysis-outputs/parsed/` (34 JSON files — each has user_messages, assistant_messages, tool_calls, metrics)
- **Raw JSONL**: `docs/internal/2026/01/{28,29,30,31}/`
- **Deep dives**: `docs/run1-09022026/analysis-outputs/deep_dive/` (34 narrative analyses)
- **Prompting patterns**: `docs/run1-09022026/analysis-outputs/prompting-patterns.md` (if exists — read it)
- **Output**: `docs/run1-09022026/analysis-outputs/aha-analysis.md`

## Your Mandate

Think like a developer who just got access to their own session data. You're not a manager, not a coach. You're the developer looking at your own data going "wait, really?"

### Questions to answer (with evidence):

**1. Time Wasters — "I spent HOW LONG on that?"**
- Find the sessions where the most time was spent relative to what was accomplished
- Calculate: total turns * avg_response_time for substantive sessions
- Which sessions had the worst ROI (lots of effort, little outcome)?
- Quote the specific moments where things went sideways

**2. The AI's Fault vs My Fault**
- For sessions that didn't resolve well, figure out WHY
- Was it: vague prompt → AI guessed wrong? Or: good prompt → AI hallucinated/gave wrong code?
- Show the breakdown with specific examples
- This is the most important insight — it tells the developer what's actually in their control

**3. Batting Average by Task Type**
- Don't use the broken classifier. Read the sessions yourself.
- Group by what was ACTUALLY being done (not keyword matching)
- For each type: success rate, avg effort, and whether the AI was the right tool for it
- Example insight: "Bug fixes succeeded 80% of the time when you pasted the traceback, but 20% when you described the bug in words"

**4. The Repeat Offender**
- Is there a pattern that shows up in multiple failed/struggling sessions?
- Something the developer keeps doing that doesn't work?
- NOT generic ("be more specific") — something concrete from the data
- Example: "In 4 sessions, you asked the AI to fix something without showing it the error output. All 4 took 3x longer than sessions where you pasted the error."

**5. The Hidden Win**
- What's the developer's BEST session and what made it work?
- Not best because it was easy — best because the developer did something smart
- This should be something they can replicate

**6. Tool Usage Pattern**
- What tools did the AI use most? (file reads, writes, bash commands, etc.)
- Were there sessions where the AI was doing lots of file reads (floundering/exploring) vs sessions where it went straight to the fix?
- Does file-read count correlate with session success?

## Output Format

Write `aha-analysis.md` — this should read like a conversation with the developer, not a report.

```markdown
# What Your 34 Sessions Actually Tell You

## The Number That Matters
[Single most striking statistic from the data, with context]

## Where Your Time Actually Went
[Time waster analysis with specific sessions and quotes]

## When It's You vs When It's the AI
[Fault analysis — this is the core insight]

### Your Fault (and what to do about it)
> "{example of a vague prompt that led to wasted time}" — session X
vs
> "{example of a clear prompt that worked fast}" — session Y

### The AI's Fault (and when to bail)
> "{example where the AI just couldn't do it despite clear instructions}" — session Z

## Your Batting Average
[Success rates by task type — the real numbers, not the broken classifier]

## The One Thing You Keep Doing
[The repeat offender pattern]

## Your Best Move
[The hidden win — what to replicate]

## How You Actually Use the AI
[Tool usage patterns — what the AI spends its time on in your sessions]
```

### EVIDENCE RULES
- Every claim needs a specific session filename and exact quote
- No generic advice — everything must come from THIS developer's data
- If you can't find evidence for a pattern, don't claim it exists
- Raw numbers where possible (X out of Y sessions, Z% of the time)
- Skip trivial sessions (ones that are just "hi" or <10 events). Don't count them in statistics.

## Constraints
- Do NOT do git operations
- Do NOT modify files outside the output directory
- Do NOT be a coach. Be an analyst showing someone their own data.
- Keep it under 500 lines. Dense, not fluffy.
