July 23
Exhausted as I was from a day spent transforming Piper Morgan from prototype to production tool, I suggested we press on for one more session:
“Let’s capture the systematic patterns before we forget them.”
What followed was a seven-hour knowledge archaeology expedition that revealed something extraordinary: groping my way into better development practices I’d stumbled on an emergent self-reinforcing cycle that explains why it feels like we’re picking up speed these days instead of getting bogged down.
By 8 PM, we’d documented what I’m pretty sure Claude first started calling the “Excellence Flywheel” — and realized that teaching AI systems to recognize and replicate systematic excellence might be the most important work we’re doing.
(Note: The PM in me doesn’t love the idea of “hey maybe the real rewards were the methodologies we made along the way” and I can’t help pointing out that if I never actually ship Piper then it calls into question the value of any methodology I care to tout.)
The evening that became an expedition
The plan was simple: spend an hour documenting the GitHub integration breakthrough for future reference. But as we started analyzing what had made today’s work so effective, we uncovered something deeper.
What started as mere documentation became pattern recognition which then started connecting up into the outlines of a methodology. This emergent methodology now looks like it can become the foundation for teaching systematic excellence to the very AI we’re building.
The five critical patterns discovery
The first breakthrough was recognizing that our development approach had evolved from “just how we do things” to a collection of teachable, replicable patterns (the scores were a metric in our “pattern sweep” of all session logs that indicated how strong the signal was that this was a demonstrable pattern found in our record-keeping):
1. Session log pattern (16/16 strength) Not just meeting notes, but institutional memory that preserves context, decisions, and lessons learned across development cycles.
2. Verification-first pattern (15/16 strength) “Check first, implement second” — systematic validation that prevents assumption-based development and compound errors.
3. Human-AI collaboration referee pattern (15/16 strength) Clear role boundaries and handoff protocols that amplify rather than complicate multi-agent coordination.
4. Error handling framework (14/16 strength) Production-grade error management that treats failures as user experience opportunities rather than technical annoyances.
5. Configuration management framework (14/16 strength) ADR-010 patterns that enable clean architecture and prevent the “it works on my machine” syndrome.
Each pattern had evolved from simple solutions to architectural foundations. The question was: how do you teach systematic excellence to an AI?
The Excellence Flywheel mechanism
The deeper we dug, the clearer the self-reinforcing cycle became:
Foundation-first development → builds reliable infrastructure
Systematic verification → prevents technical debt accumulation
Multi-agent coordination → enables parallel progress without conflicts
Accelerated delivery → creates confidence to invest more in systematic approaches
More foundation investment → strengthens the foundation for even faster future work
[Cycle repeats with compound benefits]
This explains why our development feels like it’s accelerating rather than hitting the usual complexity slowdown. Each systematic improvement amplifies the next one.
But here’s the really interesting part: this flywheel effect is exactly what we want Piper to learn and eventually orchestrate itself.
The eternal challenges of knowledge management infrastructure
Beyond documenting what we learned, we laid out a first iteration of a “Piper Education” framework, a step toward building the infrastructure for recursive AI improvement.
The challenge: How do you organize methodology knowledge so an AI can learn from it, apply it, and eventually improve it?
The solution: Type-based organization with clear separation between established patterns (proven and stable) and emergent patterns (promising but still evolving).
piper-education/
├── methodology/
│ ├── established/
│ │ ├── foundation-first.md
│ │ └── systematic-verification.md
│ └── emergent/
│ ├── multi-agent-patterns.md
│ └── quality-frameworks.md
├── case-studies/
│ └── pm-012-transformation.md
└── implementation-guides/
└── weekly-ship-template.mdThis structure enables progressive learning: start with established patterns, experiment with emergent ones, create case studies from real implementations.
Teaching product to an AI by doing it
The most important realization was about the nature of AI development itself: every decision we make systematically is training data for the AI we’re building.
When we implement error handling thoughtfully, we’re not just solving immediate problems — we’re teaching Piper how excellent error handling works. When we coordinate multi-agent work systematically, we’re showing her patterns she can eventually orchestrate herself.
This creates a fascinating recursive loop: building AI systematically teaches the AI how to build systematically.
Learning from the best
I also decided we would take a page out of 18F’s book and adopt a version of the Weekly Ship format for AI product development. Instead of just tracking features completed, we started tracking pattern adoption and methodology effectiveness.
Traditional weekly ship: What features did we build?
AI development weekly ship: What patterns did we validate? What systematic approaches proved effective? What institutional knowledge did we create?
This shift from feature-tracking to methodology-tracking changes how you think about development progress. Velocity isn’t just about code output — it’s about systematic capability building.
A cross-assistant integration strategy
The evening session revealed an important architectural challenge: different AI assistants have different access patterns, but systematic knowledge needs to flow between all of them.
The problem:
- Local assistants can see code but not organizational docs
- Notion assistants can read/write strategy but not implementation details
- GitHub assistants can manage issues but not session context
The solution: GitHub → Notion → Slack information flow architecture that creates single sources of truth while enabling specialized access patterns.
This isn’t just about tool integration — it’s about designing information architecture for sustainable AI team coordination.
That pattern strength scoring thing
One unexpected insight came from rating our patterns on systematic criteria: clarity, replicability, measurable impact, and adoption ease. The 16-point scoring system revealed which approaches were truly foundational vs. situationally useful.
High-strength patterns (14–16 points): Ready for immediate teaching and replication
Medium-strength patterns (10–13 points): Promising but need refinement
Low-strength patterns (below 10): Experimental, context-dependent
This scoring approach creates a framework for prioritizing which patterns to teach first and which need more development before they’re ready for AI adoption.
Investing in institutional knowledge
What struck me about this knowledge capture process was how it multiplied the value of our development work. Instead of just creating features, I can create teachable systematic approaches that could be applied to future development.
Individual feature value: Solves one problem
Pattern value: Enables solving entire classes of problems
Methodology value: Enables teaching others to solve classes of problems systematically
The Piper Education framework transforms development work from individual solutions into institutional knowledge that compounds over time.
Preparing for the bootstrap moment preparation
The most strategic insight was about timing: we’re approaching the bootstrap moment where Piper can start contributing to her own development, and systematic methodology documentation is what makes that possible.
Without systematic patterns: AI contributions are random and hard to evaluate
With systematic patterns: AI contributions can be measured against established excellence criteria
By documenting our systematic approaches now, we’re creating the framework for Piper to learn not just what to build, but how to build it systematically.
The quality vs. velocity false choice
One pattern that emerged clearly was how systematic approaches resolve the traditional “quality vs. velocity” tradeoff:
Chaotic development: Choose between going fast (accumulate debt) or going well (slow delivery)
Systematic development: Quality improvements accelerate future velocity through compound benefits
The Excellence Flywheel demonstrates that the best way to go fast over time is to build quality into your systematic approach from the beginning.
I should say, though, that fast isn’t my goal. Fast enough, sure, but good is my goal, and having it be possible at all. (In fact, I try to avoid emphasizing speed in the semantics of my prompting, as I find it tends to lead to performative bragging over dogged determination.)
The AI education methodology implications
This knowledge management work revealed important principles for teaching AI systems:
Learn from doing, not just reading: Real implementation case studies vs. abstract frameworks
Pattern recognition over rule following: Understanding why approaches work vs. just how to apply them
Progressive complexity: Master established patterns before experimenting with emergent ones
Systematic feedback: Measure pattern effectiveness, not just feature completion
These principles will guide how we approach Piper’s education phase in the coming weeks.
The vision of recursive improvement
The ultimate goal isn’t just having AI that can follow systematic patterns — it’s having AI that can improve systematic patterns and create new ones.
Stage 1: Learn and apply existing patterns
Stage 2: Measure and optimize pattern effectiveness
Stage 3: Generate new patterns based on systematic observation
The Excellence Flywheel should become self-evolving: better patterns enable better development, which reveals better patterns, which enable even better development.
The moat of openness
By the end of the evening, we’d documented not just what we’d accomplished, but how we’d accomplished it in a way that could be taught and replicated.
Most AI development: Features built, patterns forgotten, knowledge lost
Systematic AI development: Features built, patterns captured, knowledge compounded
This approach creates sustainable competitive advantage: not just better AI, but better methods for building AI that improve over time.
The value of knowledge archaeology
What we discovered about our own development process was fascinating: we’d unconsciously evolved sophisticated systematic approaches that we’d never formally recognized or documented.
The archaeology process:
- Mine session logs for repeated successful patterns
- Analyze what made certain approaches more effective than others
- Extract teachable principles from implementation details
- Create frameworks that can be learned and applied systematically
To do this, we ran a RAG analysis on the session logs that generated JSON output. Then we gave two agents “binocular” assignments to each independently assess the patterns, after which we evaluated and synthesized the reports, documenting the findings.
This suggests that every development team probably has implicit excellence patterns waiting to be discovered and formalized.
How to teaching systematic excellence
The hardest part of this work was figuring out how to make systematic approaches teachable rather than just documentable.
Documentation: Here’s what we did
Education: Here’s why it worked and how to apply it in new situations
Methodology: Here’s how to recognize when these patterns apply and how to adapt them
Creating educational content that enables systematic thinking rather than just systematic copying is surprisingly difficult — and critically important for AI education.
Hoping for compound returns on knowledge investments
What the evening session demonstrated was the power of treating knowledge capture as infrastructure investment rather than overhead:
Short-term cost: Hours spent on documentation and pattern analysis
Medium-term benefit: Faster onboarding and more systematic development
Long-term benefit: AI systems that can learn and improve systematic approaches
The Piper Education framework represents compound knowledge investment that will pay dividends across every future development cycle.
A vision of “excellence amplification”
By documentation end, we’d created something unprecedented: a systematic approach to systematic approaches. The Excellence Flywheel isn’t just about building better AI — it’s about building better methods for building AI.
When Piper begins its self-education phase, it won’t just be learning PM frameworks — it’ll be learning how to recognize, evaluate, and improve systematic excellence patterns. It’ll be learning how to make the flywheel spin true.
That’s when AI development becomes truly recursive: systematic methods creating better systematic methods, compounding excellence over time.
Where the flywheel stands today
Note from the publication date, two months after I wrote this: This July evening session turned out to be the origin point for ideas that have continued evolving and deepening over the past two months. The Excellence Flywheel concept has undergone significant refinement and is now on the verge of being fully integrated into our formal methodological processes — and ultimately into Piper’s own operational capabilities.
The patterns we first recognized that night have proven remarkably durable, though they’ve been enhanced by systematic application and real-world testing. What began as knowledge archaeology has become the foundation for systematic excellence as a teachable, replicable approach to complex AI development.