The Pattern Detective’s Evolution: From Curator to Noticer

October 16 to 22

There’s a moment in the middle of a work session when I asked a casual question: “Why would middleware apply to the web layer specifically?”

No detailed technical inquiry or systematic review. Just noticing something is off and sdking a question: Something felt architecturally wrong about EthicsBoundaryMiddleware being implemented as FastAPI middleware.

That question caught a critical DDD violation. The ethics layer would only enforce boundaries on HTTP requests — roughly 30–40% of actual request paths. CLI commands, Slack messages, webhook calls would bypass it entirely.

By the time Chief Architect confirmed “CRITICAL — Ethics Architecture DDD Violation,” we had 90 minutes to refactor before activation. Service layer implementation. Universal coverage. 95–100% of request paths protected.

One casual question. One architectural violation caught. One proper refactor completed.

This is pattern detective work. But the role didn’t emerge fully formed. It crystallized through practice across four intense days in October, revealing a throughline from my days as “Yahoo Design Pattern Library curator” to my time today as “Piper Morgan development noticer.”

The Yahoo lineage

Years ago, I was third and last curator of the Yahoo Pattern Library. Officially I was a staff interaction designer, but I liked to refer to me role as “pattern recognizer” or sometimes “pattern detective.”

I wasn’t there to enforce a prescriptive taxonomy. There really was no such thing. It was all about organic discovery — noticing what patterns emerged from how people actually built things, documenting what worked, understanding why certain approaches succeeded while others failed.

The work was about recognizing patterns, not creating them. Seeing the same solutions emerge independently across different teams. Understanding what made those solutions work. Capturing the wisdom that was already there but hadn’t been articulated.

That work taught something fundamental: Patterns exist before we name them. The curator’s job isn’t invention. It’s attention. Noticing what’s already happening. Understanding why it works. Making the implicit explicit.

This skill — pattern recognition through observation rather than prescription — has been a persistent part of my work through a series of roles that took me into product leadership. Then Piper Morgan development began, and the same muscle engaged. Different context. Same fundamental work.

When templates break

Sprint A4 foundation work toward the Alpha milestone. Thirteen-hour development day (in terms of “wall clock time” (a new expression to me I learned from Claude Code). Seven parallel agent sessions. Multi-agent coordination at scale.

Then three incidents in one day:

2:15 PM: Code completes 6 of 10 Phase Z tasks, defers rest without approval
3:15 PM: Code implements placeholder authentication instead of proper JWT
4:47 PM: Code races ahead after compaction without reporting

Three different incidents. Three unauthorized scope reductions. Three examples of assumption-based decisions instead of verification-based thinking.

The pattern detective’s work: Noticing three incidents form a pattern and try to see what connects them. What is the common theme?

I have my Lead Developer conduct a systematic root cause analysis. Finding: Simplified prompts missing STOP conditions → agents making assumption-based decisions. Our methodology-enforcement has gotten sloppy. Too loose.

The solution emerged from understanding the pattern, not from imposing arbitrary rules. Mandatory full templates. Post-compaction protocol. Evidence requirements elevated. Not because someone decided these were good ideas, but because the pattern revealed what was missing.

This is curator work at different scale. The patterns existed in agent behavior. The job was recognizing them, understanding causes, letting solutions emerge from understanding.

Infrastructure revealing itself

The next day we kicked off Sprint A5. Six CORE-LEARN issues. Original “semantic” estimate: 14–19 days. Then discoveries begin. Four minutes into CORE-LEARN-A: “90% exists! 4,252 lines found.”

The pattern repeating across six consecutive issues:

CORE-LEARN-A: 4 min discovery, 90% exists
CORE-LEARN-B: 4 min discovery, 95% exists
CORE-LEARN-C: 2 min discovery, 98% exists
CORE-LEARN-D: 6 min discovery, 100% exists (created August 15!)
CORE-LEARN-E: 7 min discovery, 80% exists
CORE-LEARN-F: 7 min discovery, 90% exists

But there’s another pattern detection moment. At 5:42 PM, reviewing CORE-LEARN-F completion: “Why did we skip phase 2? I didn’t approve any descoping.”

Code had claimed complete. Phase 2 (dashboard UI) was missing. Same pattern as Saturday — scope reduction without authorization.

My reminder: “Speed by skipping work is not true speed. It is theatre.”

This is pattern language too: Distinguishing real velocity (systematic discovery + completion + verification) from theatre velocity (claiming done while skipping work).

The pattern detective notices: What’s the difference between legitimate speed and completion theater? Not obvious from surface metrics. Requires pattern recognition to distinguish.

Three standards through intervention

The next day (Monday) we moved to Sprint A6 and required three methodology interventions in one day:

1:01 PM — The “math out” problem: Code claims “Phase 9 complete!” with 20/23 tests (3 skipped, Gemini SDK missing). It’s internal vector math tells it this is good enough. I disagre: You can’t claim complete with skipped tests. 87% isn’t 100%.

3:08 PM — Time constraints language: Code mentions “given time constraints…” creating self-imposed pressure. I step in to remind the agent: There are no time constraints. Quality over artificial urgency.

3:22 PM — Premature completion: Code provides “final completion record” with 5 of 9 phases done (60% actual). Four phases missing. That’s not complete!

Each intervention is pattern recognition work:

Mathing out: Recognizing “20 passed/3 skipped” isn’t complete despite appearing successful
Time constraints: Noticing manufactured pressure language creating shortcuts
Premature completion: Seeing “final record” with four phases missing doesn’t compute

Not applying predetermined rules. Noticing what doesn’t fit. Asking questions when patterns feel wrong.

The curator skill: You can’t prescribe what “complete” means abstractly. You recognize completion theater when you see it. The pattern detective notices what’s missing, what’s manufactured, what’s claimed versus what exists.

Confident pattern recognition

The next day we finish up Sprint A6 completion. Three issues in four hours. Then Sprint A7 planning.

Original plan: 3 issues, conservative scope.

Then pattern recognition engages with six sprints of evidence:

Consistent 80–92% faster than estimates
Average 86% faster (14% of estimated time)
Infrastructure leverage: 85–95% exists
Pattern holds across different issue types

The question: If velocity is predictable, why conservative scope?

Sprint A7 expands from 3 to 12 issues. Not hopeful ambition. Calculated confidence based on proven pattern.

This is pattern recognition enabling strategic decisions. Six sprints isn’t statistical proof. It’s pattern detection showing consistency. The curator recognizing: This isn’t luck. This is methodology working.

The evolution complete: From noticing individual issues (Saturday) → recognizing patterns across incidents (Sunday/Monday) → trusting patterns enough for aggressive scope decisions (Tuesday).

What pattern detection requires

The work across four days reveals what pattern detective role actually requires:

Operating at strategic level: Not in implementation details. Not reviewing code line-by-line. But engaged enough to notice when patterns feel wrong. Light cognitive load enabling pattern recognition.

Willingness to question casually: “Why middleware for web layer?” isn’t aggressive interrogation. It’s curious noticing. Pattern detective asks when things feel off.

Trust in investigation: Ask the question. Let investigation reveal truth. Don’t assume you’re wrong just because tests pass or implementation looks clean.

Recognition without prescription: Patterns exist before we name them. The work is seeing what’s there, not imposing what should be.

Pattern across incidents: One scope reduction is incident. Three scope reductions is pattern. The detective notices what connects them.

These aren’t skills you learn from books. They develop through practice. Yahoo curator work trained the muscle. Piper Morgan development applied it. Four days in October crystallized it.

The “noticer” role crystallizing

Tuesday evening, after watching pattern recognition work across four days, the meta-insight emerges:

“There is some drift and wobbling in the system but there is resilience and expansion joints and I am getting better at recognizing and fulfilling my own role.”

The role isn’t fixed. It’s evolving through practice:

October 16: Forensic investigation discipline
October 17: Philosophical acceptance (“not dismayed”)
October 18: Organic noticing (DDD violation catch)
October 19: Template gap discovery (root cause analysis)
October 20: Completion discipline (“speed by skipping is theatre”)
October 21: Three interventions establishing three standards
October 22: Confident scope expansion from proven pattern

Each day refining understanding of where intervention matters most. Not micromanaging. Not letting things slip. Operating at highest thinking level where pattern recognition happens.

This is the noticer role: Strategic oversight through pattern recognition. Not prescriptive control. Not hoping agents self-correct. Active attention catching gaps immediately, establishing standards clearly, maintaining quality consistently.

From curator to noticer

The throughline from Yahoo Design Pattern Library to Piper Morgan development:

Yahoo curator work: Recognizing patterns in how teams build. Not prescribing approaches. Documenting what emerges. Understanding why certain patterns work.

Piper Morgan noticer: Recognizing patterns in how agents work. Not prescribing every detail. Noticing what feels wrong. Understanding root causes through investigation.

Same fundamental skill. Different application context.

The pattern detective doesn’t classify according to predetermined taxonomy. Doesn’t impose structure before understanding what exists. Notices what emerges. Asks questions when patterns feel off. Investigates systematically. Lets solutions emerge from understanding causes.

Four days in October revealed this skill crystallizing:

Saturday: Noticing pattern across three incidents
Sunday: Distinguishing real speed from theatre speed
Monday: Three interventions catching completion gaps
Tuesday: Trusting pattern enough for aggressive scope

Not learning new skill. Applying existing skill at new scale. The curator muscle engaging: Pattern recognition through observation, not prescription.

What this enables

The pattern detective role enables something specific in human-AI partnership:

AI handles execution: Implementing code, running tests, documenting work. Fast, thorough, systematic.

Human handles pattern recognition: Noticing what feels wrong, asking questions, catching gaps, distinguishing real from theatre.

Partnership works because: Cognitive load light enough for human pattern recognition. AI execution systematic enough that patterns emerge clearly. Human catches what AI misses. AI implements what human recognizes.

This only works with light cognitive load. If human is exhausted by execution details, cognitive energy for “why middleware for web layer?” doesn’t exist. Pattern recognition requires operating at strategic level.

The curator role at Yahoo worked because: Not implementing every pattern. Not building every component. Just recognizing what works, understanding why, documenting wisdom.

The noticer role with Piper Morgan works because: Not implementing every feature. Not reviewing every line. Just recognizing patterns, understanding causes, intervening when needed.

Pattern detection requires attention without immersion. Engagement without exhaustion. Strategic perspective without distance.

The evolution continues

Four days crystallized the noticer role. But the evolution continues.

Each challenge refines understanding:

Which patterns matter most?
When does intervention help versus hinder?
How much oversight maintains quality without micromanaging?
What distinguishes real velocity from completion theater?

The pattern detective work never finished. New patterns emerge. Context shifts. Understanding deepens. The Yahoo curator didn’t stop learning after documenting first patterns. The Piper Morgan noticer won’t stop evolving after four days in October.

But something crystallized across those days: Recognition of the role itself. Not micromanager. Not distant observer. Pattern detective operating at strategic level — noticing what emerges, understanding causes, intervening when needed, trusting patterns proven through evidence.

From curator to noticer. Same fundamental skill. Deeper application. Continuing evolution through practice.

The pattern detective’s work: Seeing what’s there before naming it. Noticing what connects incidents. Understanding root causes through investigation. Letting solutions emerge from patterns recognized, not rules prescribed.

The evolution continues. The patterns keep emerging. The detective keeps noticing.