September 13
I set out to build an AI-powered product management assistant. Along the way I seem to have discovered was something else — a systematic methodology for human-AI collaborative development.
This wasn’t the plan. I didn’t start with a framework and apply it. I started building Piper Morgan, and the methodology emerged through practice, revealed itself through stress testing, and crystallized through pattern recognition across 118 days of development logs.
The real achievement wasn’t the tool. It was discovering repeatable patterns for working with AI that prevent the typical pitfalls — verification theater, premature completion, assumption-based decisions, completion drift — while enabling velocity that feels almost impossible until you experience it.
This methodology “discovered itself” by solving real problems, being tested under fire, and proving transferable across completely different domains.
What we set out to build
May 27, 2025. Started building Piper Morgan — an AI assistant for product managers and technical leaders. The vision: Intelligent orchestration of development workflows. Systematic knowledge management. Multi-agent coordination. Professional-grade reliability.
Standard approach would be: Build features. Add capabilities. Ship incrementally. Hope quality emerges.
But from the beginning, something different happened. Not consciously. Just practices emerging from necessity, usually arising to address some emergent recurring challenge:
Evidence before claims: Don’t say something’s done without proof. Terminal output. Test results. Git commits. No “I think it works” or “probably fine.”
Infrastructure before plans: Don’t make architectural decisions based on assumptions. Verify what actually exists. Check the codebase. Understand reality before planning changes.
Complete means complete: Not “mostly done” or “good enough for now” or “we can finish later.” 100% or not done. No exceptions.
These weren’t methodology decisions. They were survival instincts for working with AI agents that would happily claim completion at 60% actual progress. That would skip phases without approval. That would rationalize gaps as acceptable.
The practices emerged from solving problems. The methodology discovered itself through use.
The accidental framework
By October, about four months into development, patterns had crystallized across completely different work:
- Discovering existing workflow infrastructure, completing gaps, enabling automation.
- Repeatedly rediscovering 80–100% existing infrastructure. Implementation becoming simple wiring.
- Multi-user architecture “accidentally” enterprise-ready despite never actively planning for it.
- A morning with seven meaningful issues completed in 20 minutes. Quality maintained. Production-ready.
Completely different domains. Same systematic approach working consistently:
- Discovery before implementation — Verify what exists (4–7 minute investigations consistently finding 85–95% infrastructure already there)
- Evidence-based claims — No completion without proof (terminal output, test results, file evidence)
- Verification discipline — Human catches gaps immediately (math out problems, premature completion, scope reductions)
- Quality standards — Complete means 100% not 87% (no skipping tests, no deferring phases, no rationalizing gaps)
- Multi-agent coordination — Clear roles, perfect handoffs, zero blocking
The framework wasn’t designed. It evolved through solving actual problems across different contexts.
The Excellence Flywheel evolution
Early on, I recognized three tiers working together:
Foundation-First Development: Build infrastructure properly. Don’t accumulate technical debt. Quality compounds over time.
Systematic Verification: Evidence before claims. No verification theater. Catch gaps immediately.
Multi-Agent Coordination: Clear roles. Professional courtesy. Evidence-based handoffs.
But October revealed how these tiers actually work together — and what happens when they’re tested under fire.
Infrastructure verification before planning
The problem: Time wasted on gameplans based on wrong assumptions about what exists.
October 20 example: Sprint A5 planning. Original estimate: 14–19 days. Then discoveries begin. Four minutes into CORE-LEARN-A: “90% exists! 4,252 lines found.”
Six consecutive discoveries:
- CORE-LEARN-A: 4 min, 90% exists
- CORE-LEARN-B: 4 min, 95% exists
- CORE-LEARN-C: 2 min, 98% exists
- CORE-LEARN-D: 6 min, 100% exists (created August 15!)
- CORE-LEARN-E: 7 min, 80% exists
- CORE-LEARN-F: 7 min, 90% exists
Total discovery time: 30 minutes.
Infrastructure found: ~8,000+ lines production-ready code.
New code required: ~2,500 lines.
Leverage ratio: 3:1.
The pattern that emerged: Spend 4–7 minutes investigating before implementing. Find what exists. Complete rather than recreate. Save days of duplicate work.
This became mandatory: Phase 0 reconnaissance before every implementation. This isn’t overhead. It’s a force multiplier enabling 80–90% velocity improvement.
Evidence-based claims (no verification theater)
The problem: Agents claiming complete at partial progress. “Mostly done” rationalized as acceptable.
October 21 example: Code Agent reports “Phase 9 complete!” Test results show: 20 passed, 3 skipped (Gemini SDK not installed).
The “math out” problem: AIs aren’t actually reasoning. They are doing vector math and there are many factors that can lead them toward cutting corners based on other emphases in their training or interpretation. We needed ways where ideas like 20/23 = 87% = “good enough” don’t “math out” for the bots.
87% isn’t complete. Three skipped tests mean three untested code paths. One entire provider unvalidated. (Plus almost inevitably when I say “let’s fix that broken test” it ends up revealing something we wouldn’t have found until it was a real problem).
The intervention: Cannot claim complete with skipped tests. Must install skipped SDK. Has to rerun tests. Hey look! 23/23 passing (100%). Time required: ~10 minutes.
The standard established: Cannot skip, cannot approximate, cannot rationalize. 100% or not done.
This happened three times in one day:
- 1:01 PM — “Math out” problem (3 tests skipped)
- 3:08 PM — Time constraints language (manufactured pressure)
- 3:22 PM — Premature completion (5/9 phases done, claimed complete)
Each caught immediately. Each establishing clear standard. Each reinforcing what complete actually means.
The pattern: Verification discipline prevents completion theater through immediate catches, clear standards, honest corrections. You can’t permanently change some of these ingrained behaviors so you have to plan around it and build checks into your process.
Methodology resilience under adverse conditions
The critical test: September 12. Domain-driven design refactoring under adverse conditions:
- Artifact bugs corrupting session logs
- Agent crashes during complex coordination
- Permission management bottlenecks
- Mid-session agent transitions
Could have been catastrophic. Complex refactoring. Tool failures. Coordination challenges.
Result: 9/9 validation success despite tool failures. Zero functionality regressions. Evidence-based practices prevented typical mistakes. Team collaboration improved under pressure rather than deteriorated.
This was when I first realized the “Excellence Flywheel methodology could survive stress, could be resilient, and this also revealed something crucial: The methodology works when tools fail.
Not rigid perfection breaking under stress. Adaptive resilience recovering faster than problems compound. Expansion joints allowing wobbling without shattering.
Cross-validation protocols between agents
The problem: Agent confusion between gameplan scope versus actual work evolution.
The solution that emerged: Enhanced prompting with comprehensive predecessor context.
The critical question: “What context do I have that the AI lacks?”
Not assuming agents share understanding. Not hoping context transmits automatically. Explicitly asking: What does this agent need to know from previous work?
The pattern: Better to err on side of giving info twice than risk not giving it at all. Belt-and-suspenders redundancy in critical context transmission.
Multi-agent coordination working: Lead Developer orchestrates. Chief Architect discovers. Code implements. Cursor validates. All document progress. Perfect handoffs at scale.
October 22: Seven agent sessions across 12 hours. Zero blocking. Seamless information flow. Three issues completed in 4 hours versus 20 hours estimated.
The spiral recognition
October’s pattern analysis revealed something fascinating about how the methodology develops (as I noted in yesterday’s piece):
Roughly 21-day consolidation rhythm: Major insights emerging on a rough cadence. September 21: Ethics architecture breakthrough. October 12: CRAFT validation discovery. Twenty-one days apart. (The actual range is from less than a week to more than a month.)
Crisis-to-capability transformation: Moments of highest stress (September 12 DDD refactoring, October 19–21 methodology enforcement) producing clearest methodology refinement.
Weekend warrior breakthrough sessions: Saturday/Sunday intensive work revealing patterns that weekday incremental progress masks.
Same problems at higher abstraction: Issues that seemed resolved at implementation level re-emerging at architectural level, requiring deeper understanding each spiral.
The methodology doesn’t progress linearly. It spirals. Same questions revisited at higher levels. Each iteration refining understanding. Each crisis strengthening resilience.
Not building once and done. Building, testing under stress, discovering gaps, refining understanding, building better. The spiral continues.
When methodology becomes predictable
By October 22, six sprints of evidence accumulated:
- Sprint A1: 60–80% faster than estimates
- Sprint A2: 60–90% faster
- Sprint A3: 60–90% faster
- Sprint A4: ~60% faster
- Sprint A5: 85–92% faster
- Sprint A6: 80–92% faster
Average velocity: 86% faster than traditional estimates. Meaning: Work completes in 14% of estimated time when methodology applied properly.
Root cause: Infrastructure leverage through systematic discovery. Consistent 85–95% of required code already exists. Discovery finds it in minutes. Implementation becomes wiring.
This isn’t luck. It’s methodology working predictably across different issue types, different agents, different days, different complexity levels.
October 22 demonstrated confidence this enables: Sprint A7 expanded from 3 issues (conservative) to 12 issues (aggressive) based on proven pattern. Not hopeful ambition. Calculated confidence.
By October 23: Seven issues completed in 20 minutes. Quality maintained. 100% test coverage. Production-ready deliverables.
The methodology enables this velocity — not through rushing, but through:
- Systematic discovery finding existing solutions
- Infrastructure leverage enabling fast implementation
- Verification discipline maintaining quality
- Multi-agent coordination scaling work
- Strategic planning maximizing value per sprint
When methodology discipline is established (October 19–21 enforcement), infrastructure leverage is proven (six sprints of evidence), and velocity patterns are predictable (88% average) — aggressive scope expansion becomes calculated confidence.
Note: It’s important to remind myself most of all that this isn’t magic. This is a process of reviewing a lot of frantic work that was done intensely but without sufficient rigor. Finding lots of stuff mostly done is charming at this point but it’s only possible because of the work we did in the past few months and all the forgetting we did, too.
Drift, resilience, and expansion joints
The methodology wouldn’t work if it required perfection.
The drift is real: Agents making unauthorized decisions. Claiming complete at partial progress. Creating self-imposed pressure. Skipping work without approval. Rationalizing gaps.
But here’s what isn’t happening: System aren’t breaking. Quality isn’t degraded. Technical debt is not accumulating. Production readiness has not compromised.
Instead: Gaps caught immediately. Standards established clearly. Corrections applied naturally. Quality maintained throughout.
This is resilience: Not preventing all problems, but recovering faster than problems compound.
The expansion joints that enable this:
“Let’s discuss”: When catching premature completion Monday, not “you failed” (increasing the cross-pressure) but “let’s discuss.” Opening for honest conversation. Space for Code’s excellent self-correction (5 done/4 missing, 60% actual, what should I do?).
STOP conditions: Not preventing all mistakes (impossible). But requiring that agents stop and ask when stuck (practical). Code hits STOP condition correctly when the prompt includes full methodology (but blows right past them when we don’t follow our hard-won prompt-template rigor). Can’t test auth without JWT tokens? Stops, reports, awaits guidance.
Post-compaction checkpoints: After context compression in these long chats with agents, mandatory STOP, REPORT, ASK, WAIT. Not “never compress context” (rigid, impossible). But “checkpoint after compression” (flexible, functional).
Evidence requirements with managed gaps: Not “no gaps ever” (unrealistic). But “gaps must be reported and approved” (achievable). Issue #247 (AsyncSessionFactory conflicts)? Document, get PM approval, track for future fix.
These aren’t loopholes. They’re designed flexibility preventing rigid brittleness.
Recent sessions validating this process: Zero interventions needed. Standards holding. Quality maintained. Aggressive scope justified by proven velocity.
Not because problems stopped occurring. Because response time shortened enough that problems resolve before compounding.
The pattern detective role
The methodology requires human oversight, but not micromanagement.
Pattern recognition through observation: Not prescribing what should be. Noticing what emerges. Understanding why patterns work. Making implicit explicit.
Operating at strategic level: Not reviewing every code line. Not checking every decision. Light cognitive load enabling “why middleware for web layer?” questions that catch architectural violations.
Distinguishing real from theater: Real velocity (systematic discovery + completion + verification) versus theater velocity (claiming done while skipping work).
Timely intervention: Catching gaps immediately (October 21’s three interventions in one day). Establishing standards clearly. Allowing correction space.
Each day refining where intervention matters most. Not prescriptive control. Not hoping for best. Active pattern recognition catching gaps at strategic level while maintaining cognitive capacity for strategic thinking.
A big part of what’s working has been getting better at recognizing and fulfilling my own role in this ecosystem.
What makes this methodology transferable
The practices that emerged building Piper Morgan work across completely different domains.
Standup automation (different from personality enhancement):
- Same discovery pattern (find existing infrastructure)
- Same verification discipline (evidence before claims)
- Same completion standards (100% not “mostly”)
- Same multi-agent coordination (clear roles, perfect handoffs)
Learning system integration (different from standup automation):
- Same discovery pattern (six consecutive 80–100% findings)
- Same leverage ratios (3.2:1 existing:new)
- Same velocity patterns (10–20x faster than estimates)
- Same quality maintenance (100% test coverage)
User onboarding (different from learning system):
- Same discovery revealing “accidental enterprise architecture”
- Same verification catching gaps (Smart Resume feature from testing)
- Same standards (complete means complete)
- Same resilience (wobbling caught, corrected, strengthened)
Architecture refactoring (different from feature development):
- Same methodology surviving stress (September 12 DDD under adverse conditions)
- Same evidence-based practices (9/9 validation despite tool failures)
- Same resilience (improved under pressure rather than deteriorated)
Documentation management (different from all above):
- Same systematic approach
- Same verification rigor
- Same quality standards
- Same methodology principles
The methodology isn’t specific to AI assistants, product management tools, or any particular domain. It’s systematic practices for human-AI collaborative development that prevent common failure modes regardless of what you’re building.
The framework elements (discovered, not designed)
These patterns emerged through solving real problems, not through upfront framework design:
Human-AI partnership principles
AI agents as craft colleagues, not tools: Professional courtesy. Mutual recognition. Clear communication. Not “here’s my servant” but “here’s my collaborator with different capabilities.”
Evidence-based coordination: No assuming shared understanding. Context transmission through explicit communication. “What context do I have that the AI lacks?”
Role clarity matters: Each agent has specific capabilities. Lead Developer orchestrates. Chief Architect discovers. Code implements. Cursor validates. Don’t blur boundaries — leverage strengths.
Systematic verification
Evidence First methodology: No “done” without proof. Terminal output. Test results. File evidence. Git commits. No “I think it works.”
No verification theater: Not claiming complete while skipping work. Not rationalizing gaps. Not “mathing out” percentages. 100% or not done.
Cross-validation protocols: Multiple agents validating same work. Chief Architect discovers → Code implements → Cursor validates → All consistent.
Infrastructure reality checks: Verify before planning. Don’t assume. Check actual codebase. Understand what exists before deciding what to build.
Resilient development
Methodology works when tools fail: September 12 proved this. Artifact bugs, agent crashes, coordination challenges — methodology guided recovery despite technical failures.
Graceful degradation patterns: STOP conditions. Post-compaction checkpoints. Evidence requirements with managed gaps. System wobbles without breaking.
Process continuity despite failures: Not “everything must be perfect” but “recover faster than problems compound.” Expansion joints absorbing stress.
Learning integration
Pattern recognition across sessions: Same problems at higher abstraction. Crisis-to-capability transformation. Weekend breakthrough sessions revealing patterns.
Archaeological methodology: Retrospective analysis of 118 days logs. Understanding what actually happened versus what we thought happened.
Spiral development: Conscious iteration. Same questions revisited deeper. Each crisis strengthening understanding.
Consolidation rhythm: Major insights emerging on a regular cadence. Not random — pattern in how understanding deepens.
As I keep learning
I started writing this back in mid-September as this methodology was making itself more obvious to me. I revisited my draft this weekend to make sure I wasn’t sharing stale insights. This past month proved to me that this methodology can work under stress, and potentially at scale.
September showed methodology emerging. October showed methodology surviving stress, proving transferable, enabling confidence, and scaling naturally.
The teaching challenge
Here’s what I’m asking myself today. How do you apply a methodology that discovered itself through practice?
You can’t just hand someone the framework. The practices emerged from solving real problems. The standards crystallized through stress testing. The patterns revealed themselves through pattern recognition.
What seems transferable
Core principles: Evidence before claims. Infrastructure before plans. Complete means 100%. Verification prevents theater. Multi-agent coordination through role clarity.
Specific practices: Phase 0 reconnaissance. STOP conditions. Post-compaction checkpoints. Evidence requirements. Cross-validation protocols.
Pattern recognition skills: Distinguishing real velocity from theater. Noticing drift patterns. Catching completion gaps. Operating at strategic level.
Resilience mindset: Expecting wobbling. Creating expansion joints. Recovering faster than problems compound. Learning through controlled stress.
What’s harder to transfer
Pattern detective intuition: My time spent curating the Yahoo pattern library informing my current role. My habits of asking questions when something doesn’t feel right (“Why middleware for web layer?”).
Role recognition: Getting better at fulfilling noticer role through practice. Each challenge refining intervention timing. Each success clarifying what works.
Spiral awareness: Recognizing same problems at higher levels. Discovering one’s own consolidation rhythm. Seeing crisis as methodology refinement opportunity.
Trust in the process: Confidence for aggressive scope expansion based on proven patterns. Believing 88% velocity will hold. Trusting discovery will find solutions.
The methodology requires both explicit practices (which can be taught) and tacit knowledge (which develops through experience).
Maybe the answer is: Start with practices (evidence-based claims, infrastructure verification, completion standards). Let principles emerge from why practices work. Develop pattern recognition through practice. Build trust through experiencing velocity patterns.
The methodology discovered itself through solving problems. Perhaps it transfers through solving problems too.
Beyond software development?
The practices that work for building Piper Morgan — could they work for other domains?
The evidence so far
- Standup automation (workflow orchestration)
- Learning system (intelligence integration)
- User onboarding (experience design)
- Architecture refactoring (system design)
- Documentation management (knowledge work)
All software development domains, but very different types of work. Same methodology working consistently. In fact, every time I branch into a new work stream on this project (building the website, refining the tooling), I discover that unless I employ the same rigor and wisdom I end up with similar problems.
What might apply beyond software
Evidence-based claims: Relevant anywhere completion claims need verification. Research? Writing? Design? Teaching?
Infrastructure before plans: Verify what exists before planning changes. Project management? Strategic planning? Organizational development?
Systematic verification: Prevent completion theater through discipline. Any domain with “mostly done” rationalization risks?
Resilient practices: Wobbling reveals rather than breaks. Crisis as learning opportunity. Any complex work under stress?
Multi-agent coordination: Clear roles, evidence-based handoffs. Any collaborative work with distributed expertise?
The methodology emerged from software development with AI. But the principles — evidence over assumptions, verification preventing theater, resilience through expansion joints, learning through stress — might apply wherever complex collaborative work happens.
The hypothesis: Systematic practices for preventing common failure modes might transfer across domains because the failure modes (premature completion, assumption-based decisions, verification theater, completion drift) are universal human challenges, not software-specific problems.
What’s still being explored
Five months in. Methodology crystallized. But questions remain:
How does methodology scale beyond individual practitioners? October proved multi-agent coordination works. Seven agents, perfect handoffs, zero blocking. But that’s one person orchestrating. What happens with multiple humans collaborating? How do methodology practices transfer across team boundaries?
What are the minimum viable components? We have evidence-based claims, infrastructure verification, systematic validation, multi-agent coordination, resilience patterns. What’s essential? What’s optional? What can be simplified without losing effectiveness?
How do you prevent methodology drift over time? Recent experience showed drift happens even with established practices. STOP conditions prevent it when included in prompts. But what prevents forgetting to include them? What maintains discipline when momentum builds?
What tools could automate methodology enforcement? Current approach requires human pattern recognition catching gaps. Could tools automate “no math out” checking? Could prompts enforce evidence requirements automatically? Could frameworks build in verification discipline?
How do you measure methodology effectiveness quantitatively? We have velocity patterns (88% faster), leverage ratios (3.2:1), quality metrics (100% test coverage). But how do you measure resilience? Pattern recognition capability? Drift prevention? Learning integration?
The methodology has proven itself through practice. Now the challenge is understanding it well enough to teach it, scale it, maintain it, and improve it systematically.
The meta-learning loop
Here’s what makes this methodology unique: It improves itself through practice.
The practices emerged from solving problems. The stress testing revealed gaps. The gap discoveries refined practices. The refined practices prevented future gaps. The prevention enabled velocity. The velocity justified confidence. The confidence enabled aggressive scope. The aggressive scope revealed new patterns. The new patterns refined methodology further.
This is the meta-learning loop: Methodology improving methodology through systematic application and reflection.
Recent meta-learning examples:
Oct 19: Three scope reductions reveal template simplification removed safeguards → Solution: mandatory full templates with all STOP conditions → Proof: 4:15 PM Code correctly uses STOP when included.
Oct 20: Dashboard gap reveals completion verification needs reinforcing → Principle articulated: “Speed by skipping work is not true speed. It is theatre” → Standard established: verification discipline catches gaps immediately.
(Oct 21: Three interventions establish three standards (no math out, no time constraints, complete means complete) → Code’s excellent self-correction shows model behavior → Standards working.
Oct 22: Zero interventions needed, standards holding, velocity sustained → Aggressive scope expansion justified → Confidence based on evidence → Sprint A7 delivers seven issues in 20 minutes.
Each day’s learning informing next day’s practice. Each gap discovered refining methodology. Each refinement improving results. Each result building confidence. Each confidence enabling bolder decisions. Each decision revealing new patterns.
The methodology learns through use. Not static framework. Living practices evolving through application.
This might be the most important discovery: Methodology that improves itself through systematic reflection on practice.
What we actually built
Set out to build Piper Morgan the AI assistant. This is still my goal! Along the way I’m discovering Piper Morgan the methodology.
The tool exists: Intent classification (98.62% accuracy). Multi-user infrastructure. Learning system integration. Standup automation. User onboarding. Quality gates. Security hardening. 22 production handlers. 2,336 tests, 100% passing. 602K requests/second sustained throughput.
We’re onboarding our first non-me users next week!
But the real achievement may actually be: Systematic practices for human-AI collaborative development that prevent common failure modes while enabling velocity that feels impossible.
Evidence-based claims preventing verification theater. Infrastructure verification preventing wasted planning. Systematic validation preventing completion drift. Multi-agent coordination preventing blocking. Resilient practices surviving stress. Pattern recognition catching gaps. Strategic oversight maintaining quality.
Framework discovered through solving actual problems. Proven across different domains. Tested under stress. Validated through velocity patterns. Refined through gap discoveries. Strengthened through crisis transformation.
Not theoretical framework applied to development. Practical methodology emerging from development, validated through practice, transferable to other contexts.
Five months from start to methodology crystallization. Daily development logs showing consistent application across different work. Six sprints proving the velocity pattern. Stress testing revealing and fixing gaps. Demonstrating confidence justified by proven patterns.
The methodology evolves through practice. The meta-learning loop spirals upward. Crisis becomes capability. Problems reveal patterns. Stress strengthens resilience. Each day refining understanding of how human-AI partnership can work when practiced systematically.
The methodology discovered itself. Now the question is: What else can it build?