I set out to build a technical blog. Three weeks in, I had 37 workflow documents and zero published posts.
The bottleneck wasn’t the writing, and it wasn’t Claude Code’s capability. It was process structure. Every time the pipeline hit a problem I fixed the problem instead of publishing, and each fix became another document. The research-to-blog pipeline had quietly turned into a self-improving system, and it got there by solving immediate problems rather than by design. Here is what that actually looked like.
The pattern: problem, research, solution, documentation
Across 15 improvement cycles the same loop kept repeating: a failure triggered a solution, and writing the solution down kept the failure from coming back.
Note: the code examples below are simplified to illustrate the approach, not the exact implementation.
The duplicate PDF problem
Research PDFs were getting processed twice, scattered across directories under variant filenames. Checking filenames didn’t scale: “AI-research-2024.pdf” and “ai_research_final_v2.pdf” held identical content. So I switched to SHA-256 content hashing for deduplication, which then grew into a full intake pipeline with metadata extraction, automatic routing, and standardized naming.
The citation verification bottleneck
Verifying a research claim by hand took 3 to 5 minutes. At 50+ claims per document, that was over 4 hours per paper. The fix evolved through three stages: manual markdown checklists, then batch processing with structured templates, then a tiered system that classifies claims by priority. Blog-bound claims get verified immediately, academic sources verify in the background, and tutorials and opinions are optional.
The insight synthesis failure
Research kept piling up in topic folders with nothing pulling the patterns together. The fix was dynamic insight tracking: each new document updates the existing pattern files, with explicit evidence for and against each insight. One insight matured from “feedback loops seem important” at 2 documents to “the system that documents itself, improves itself” at 12.
The architecture nobody designed
Every component exists because something broke first. None of it was planned up front:
- Research intake pipeline: deduplication, extraction, classification, routing.
- Dynamic insight system: pattern matching, evidence accumulation, maturity tracking.
- Verification pipeline: four tiers, from immediate to optional.
- Blog seed generation: promotes an insight automatically once it reaches maturity.
- Feedback integration: SESSION_LOG.md captures friction and drives the next improvement.
Why it improves itself
The self-improvement comes from three habits, not from any architectural cleverness:
- Document the problem when it happens.
- Research the solution from verified sources.
- Automate the solution once it’s validated.
Run that loop consistently and the system compounds. Skip the documentation step and it doesn’t. That’s the whole mechanism.
What I set out to build versus what I got
I wanted a technical blog. What I have is a self-improving research system: content-hash deduplication, automated citation extraction, insight evolution across documents, systematic claim verification, and 37 workflows that captured every iteration along the way. The blog is still downstream of all of it.
If you want to try this, start with one file. Call it SESSION_LOG.md. Record one problem, build one solution, and let it iterate from there. The architecture shows up on its own once the loop is running.