The Discovery Pattern: Why Verification Before Implementation Saves Time
October 12–15
Between Sunday and Wednesday of mid-October, I discovered four separate times that work I expected to build from scratch was already 75% complete.
CI/CD infrastructure that had existed — sophisticated and operational — for two months, invisible because we never triggered it. Classification accuracy that had improved from 89.3% to 96.55% without direct targeting. An MVP with 22 production-ready handlers when I expected skeleton placeholders. Three issues scheduled for implementation that were already done.
Each discovery saved between hours and days of unnecessary work.
The pattern isn’t luck. It’s what becomes possible when you build comprehensive infrastructure first, then verify systematically before implementing.
When reality hides behind assumptions
Sunday morning, October 12. GAP-2 interface validation beginning. I expected routine work — verify enforcement patterns, check handler compliance, maybe find a few minor issues.
By noon, we’d uncovered three layers of hidden problems. But the surprising thing: each layer existed alongside something already working.
Layer 1: Three bypass routes allowing direct IntentService access. The router enforcement worked — it just wasn’t required everywhere. Fixed in 30 minutes.
Layer 2: Libraries two years out of date (litellm from September 2022, langchain from November 2023). Everything ran fine — 49 tests just couldn’t execute because they depended on modern features.
Layer 3: Production bug in the LEARNING handler, invisible until we pushed from 94.6% to 100% test pass rate. The handler returned success=True with an invalid field that looked valid at first glance.
None of these were obvious. All revealed themselves through systematic validation, not casual inspection.
But here’s what struck me: The most sophisticated infrastructure was the most invisible.
Six CI/CD workflows — quality checks, testing, architecture validation, configuration verification — had existed for two months. Comprehensive coverage. Working perfectly. Completely unseen because our workflow didn’t create pull requests to trigger them.
The gap wasn’t technical. It was all a matter of visibility.
When the Lead Developer investigated, I pointed out: “The infrastructure is sophisticated — it’s just unwatched.”
The compound effect you don’t track
Monday morning, October 13. GAP-3 accuracy polish beginning.
The goal: Improve classification accuracy from 89.3% (documented October 7) to at least 92%.
Phase 1: Measure current accuracy.
Result: 96.55% already achieved.
The “accuracy problem” didn’t exist. We’d exceeded the target by 4.55 percentage points before we even started.
Where did the improvement come from?
Not from accuracy-focused work. From:
- Interface validation fixing bypass routes (Sunday)
- Library modernization unblocking tests (Sunday)
- Production bug fixes in handlers (Sunday)
- Architecture enforcement through proper patterns (previous weeks)
None of these were targeting accuracy. They were infrastructure improvements, architectural fixes, quality validation. But they improved accuracy as a byproduct.
This is the discovery pattern at work: Systematic infrastructure work compounds in ways documentation doesn’t always capture.
The decision: Polish to perfectio, because we could achieve something exceptional.
Three precise GUIDANCE patterns added. Result: 98.62% accuracy.
GUIDANCE category: 90% → 100% perfect.
Total time: Less than two hours versus 6–8 hour estimate.
But here’s what matters: We weren’t fixing a problem. We were refining excellence that already existed, invisible in outdated documentation.
When “months away” means “mostly done”
Tuesday afternoon, October 14. VALID-2: MVP workflow assessment.
Expected finding: Skeleton handlers needing months of ground-up implementation. Architecture complete, but actual business logic? Placeholder city.
I’ve seen this pattern in countless projects. The framework exists. The structure is sound. The actual functionality? return {“status”: “not_implemented”} everywhere.
Actual finding: 22 production-ready handlers with 70–145 lines each.
Not placeholders. Production code:
- _handle_create_issue: 70 lines, full GitHub integration
- _handle_summarize: 145 lines, LLM integration with compression ratios
- Strategic planning: 125 lines, comprehensive
- Prioritization: 88 lines with RICE scoring
Real error handling. Actual service integrations. Complete implementations.
46 occurrences of “FULLY IMPLEMENTED” markers in the code.
MVP Readiness: 70–75% complete when I expected 10–20%.
Timeline transformation: 2–3 weeks to MVP, not months.
The remaining work: Not ground-up development. API credentials and E2E testing. Infrastructure exists. Handlers work. Integration completion only.
The Chief Architect’s assessment: “MVP isn’t months away, it’s 2–3 weeks of configuration work.”
This discovery rewrote roadmap understanding. Not because the plan changed, but because reality was ahead of documentation.
The three “already complete” moments
Wednesday, October 15. Sprint A2 planning with five issues scheduled.
7:42 AM: Chief Architect reviewing scope. CORE-TEST-CACHE #216 listed as first item.
Quick investigation: Already complete. Removed from sprint.
Time saved: 30 minutes.
8:25 AM: Issue #142, add get_current_user() method to NotionMCPAdapter.
Code Agent investigation: Functionality already exists in two places (test_connection() line 110, get_workspace_info() line 135).
The “problem”: Not that functionality was missing. That it wasn’t exposed as public method.
Phase 1 implementation: 3 minutes to extract existing pattern.
10:51 AM: Issue #136, remove hardcoding from Notion integration.
15-minute verification instead of reimplementation: Completed already through child issues #139, #143, #141. Tests passing. Documentation excellent. Architecture improved.
My reflection: “If I had properly read these parents and children before I might have saved us all some time!”
Time saved by verification: An entire day of reimplementation.
Three discoveries in one morning. Pattern: Work is 75% complete more often than assumed.
What makes discovery possible
The four-day pattern — invisible CI, exceeded accuracy, MVP readiness, completed issues — doesn’t happen by accident.
It requires specific foundations:
Comprehensive test coverage (2,336 tests in our case). For behavior verification. When tests validate behavior comprehensively, you can verify completion by running tests rather than reading code.
Systematic documentation (99%+ accurate in our case). For truth-checking. When documentation captures current state accurately, you can spot gaps between documented and actual state.
Quality gates that run automatically (pre-commit hooks, CI/CD workflows). For continuous validation. When quality gates run on every change, work stays validated without manual checking.
These aren’t Day 1 capabilities. They’re Day N results from systematic preparation.
Early weeks on Piper Morgan: Slow. Building test infrastructure. Establishing patterns. Creating documentation standards. Setting up quality gates.
Recent weeks: Fast. Test suite validates completeness. Documentation reveals gaps. Quality gates catch issues. Verification happens systematically.
The efficiency isn’t from working faster. It’s from having infrastructure that makes verification reliable.
How to verify before implementing
The pattern that worked across these four days:
Start with investigation, not implementation. When assigned Issue #142 (add get_current_user method), Code Agent spent 25 minutes investigating before writing any code. Found functionality existed. Implementation took 3 minutes.
Alternative approach: Jump straight to implementation. Build from scratch. Discover later that it duplicated existing code. Delete and refactor. Hours wasted.
Investigation time is never wasted when it prevents unnecessary implementation.
Question authoritative-sounding requirements. (This is one specifically for working with AIs.) Issue #165: “Upgrade to notion-client>=5.0.0 for API 2025–09–03 support.”
Sounds definitive. Upgrade to 5.0.0. Simple.
Except: Version 5.0.0 doesn’t exist for Python SDK.
TypeScript SDK: 5.0.0 versioning. Python SDK: 2.5.0 latest. Issue description conflated API version (2025–09–03, correct) with SDK version (5.0.0, wrong for Python).
Discovery saved hours searching for non-existent packages. Resolution: Upgrade to 2.5.0, add API version parameter. 15 minutes versus original 2–3 hour estimate.
When instructions contradict reality, verify reality is wrong before assuming your understanding is broken.
Check child issues and related work. Issue #136 appeared incomplete on first reading. 15-minute verification: Complete through child issues #139 (config loader), #143 (refactoring), #141 (testing/docs).
The work was done. Just never formally verified and closed.
How many projects have completed work sitting in “Done but not reviewed” limbo? How many hours spent reimplementing what already exists in a different branch or under a different issue?
Reduce scope to actual gaps. Original estimate for SDK upgrade: 12–17 hours assuming breaking changes.
Investigation: NO breaking changes in 2.2.1 → 2.5.0. All changes additive (Python 3.13 support, file uploads).
Revised scope: 30–45 minutes for SDK + API version.
Actual delivery: 15 minutes including full implementation.
Efficiency: 12x faster by verifying assumptions and reducing scope to essentials.
What this isn’t
This pattern isn’t about being suspicious of your team or assuming work is incomplete.
It’s about recognizing that software development produces invisible completeness:
- Features implemented but not exposed
- Infrastructure built but not documented
- Tests passing but metrics not captured
- Work done but issues not closed
The gap between actual state and visible state grows naturally. Not through negligence, but through the pace of development.
When you’re building fast, documentation lags. When you’re fixing issues, GitHub issues don’t always get updated. When you’re improving accuracy, metrics don’t auto-refresh.
Discovery over assumptions means: Trust your infrastructure exists. Verify its current state. Then complete rather than recreate.
When you can apply this
The discovery pattern requires preparation. You can’t verify completion without:
- Tests that validate behavior comprehensively
- Documentation that captures current state accurately
- Quality gates that run automatically
- Tools that enable quick verification (like Serena MCP in our case)
It was only about or two month into this project when verifying first became consistently faster than YOLO-type implementation. But once those foundations exist, the pattern compounds:
Early investigation finds work 75% complete → Quick completion → More confidence in verification → More investigation before implementation → Find more completed work → Compound time savings
The four days in mid-October weren’t special. They were typical of what becomes possible when infrastructure enables discovery.
If you’re early in a project: Build the foundation. Invest in tests. Establish documentation standards. Create quality gates. It feels slow. It compounds.
If you’re mid-project: Start verifying before implementing. Question requirements. Check related work. Reduce scope to actual gaps. You’ll discover completion hiding in plain sight.
If you’re late in a project: You probably have more completed work than you think. Systematic verification might reveal you’re closer to done than documentation suggests.
What I learned about assumptions
The pattern crystallized on Wednesday when three issues in one morning turned out complete through investigation.
My honest reflection: “If I had properly read these parents and children before I might have saved us all some time!”
Not frustration. Recognition. The tools for discovery existed — parent/child issue relationships in GitHub, test suites that validated completeness, documentation that explained current state.
I just needed to use them systematically.
The cost of investigation: 15–25 minutes per issue.
The cost of reimplementation: Hours to days per issue.
The efficiency: 12x faster by verifying before implementing.
It’s about recognizing a pattern, not perfectionism: My work is consistently further along than assumptions suggest.
The methodology that works: Question everything. Verify before implementing. Accept minutes of investigation over days of unnecessary work.
When you build comprehensive infrastructure, systematic verification finds completion hiding behind assumptions. Not sometimes. Consistently.
That’s the discovery pattern. And once you see it, you can’t unsee it.