Zhicheng's Blog
A Chronicles of a 👨💻 Programmer (with 📊 📈 Analytical Mindset Who was Once a 🎨 🖌️ Designer): Learn to Debug Life
Welcome to my blog!
This blog chronicles my personal exploration into the worlds of building (with LLMs ofc, what were you expecting?) and life itself.
Here, I share the things I encounter while building.
Think of it as me trying to debug life while getting better at debugging programs.
Fueled by my own insatiable curiosity (and AI's endless patience), bolstered by my humble attitude of learning (with millions of searches on Google),
I'm pretty confident this debugging process will be wrapped up by the end of this century.
I'm passionate about building LLM powered features, with a particular interest in the intersection of geography, corporate intelligence, and (maybe) financial analysis.
👨💻 Building:
Geo Intelligence
• 🌍 Dossigraphica — macro scale: corporate analysis & company intelligence
• 📍 NearPulse — micro scale: neighborhood insights for finding your next place to live
Random Side Hobby
• 📸 Shotwise
• 📈 AperilexLabs
✉️: zcmmwang@gmail.com
🐦: X
🌟: GitHub
Technical debt often manifests as rigidity. Our application’s journal feature was a prime example, built on a hardcoded assumption that all activities were either “Work” or “Life”. This was simple to implement initially but impossible to scale. Every user’s life is more nuanced than that binary choice.
This post outlines a foundational refactor to move from this static system to a dynamic, user-driven one.
Raw data is valuable, but insights are transformative. Synapse has been good enough at capturing daily activities, but the next logical step has always been to synthesize that data into high-level understanding. Today’s task is to implement the new feature on the roadmap: AI-Powered Weekly Reports.
This feature moves beyond simple data retrieval and uses LLM to analyze a week’s worth of activities, generating a concise, structured summary of your time allocation, key accomplishments, and emerging trends.
Previously in Synapse, we have a core feature: an agentic semantic search system (Still confused what actually makes RAG, a RAG and what’s the difference between it and semantic search? They both seem to intersect. But like Andrew Ng mentioned in one of the interviews, how to define if an agent is truly autonomous? How? maybe the definition does not matter, as long as the agent works itself.) that allows users to ask natural language questions about their activities. The initial version was a standard, three-step pipeline: a Planner agent to generate keywords, a Retrieval step using those keywords against the database, and a Synthesizer agent to generate a summary.
This worked, but it suffered from the classic limitation of keyword search—it lacked true semantic understanding. A query for “time spent on backend improvements” might miss an entry described as “refactored the authentication service.”
Today, I implemented one of the new features proposed on roadmap in my personal journal analysis app: a semantic search and synthesis engine. Instead of a traditional keyword search, I opted for an “Agentic RAG” (Retrieval-Augmented Generation) pipeline. This approach leverages a local LLM (gemma3n:latest) not just for generating text, but for orchestrating the entire search process. This post outlines the design thinking behind this implementation and its future potential.
For a while now, I’ve maintained a daily journal in a simple text file. It’s a straightforward system: I write the date, then list my activities under WORK: and LIFE: headers. This approach is simple and low-friction, but as the file grew, its limitations became obvious. Searching for specific activities was a grep-and-pray operation, and any form of analysis was purely manual. The data had no structure.
Today’s objective was to containerize the SEC filing analysis application to ensure a consistent and reproducible runtime environment. This process involved not only creating the necessary Docker artifacts but also refactoring the application’s configuration to adhere to best practices for handling secrets and environment-specific variables.
When building financial analysis tools, one of the most common and dangerous assumptions is that the financial data you receive—whether from an API or directly from SEC filings—represents discrete, isolated time periods. A “Q2” report, for instance, should contain data only for the second quarter. Right?
Unfortunately, this is often not the case. Raw SEC filings, specifically the quarterly 10-Q and annual 10-K reports, follow reporting rules that can be misleading if taken at face value. In this post, I’ll walk through the challenges of parsing these documents and present a robust Python solution to derive true, discrete quarterly financial figures.
In the world of financial data extraction, the challenge of parsing and interpreting complex documents is ever-present. As I continue to refine my financial analysis tool, I’ve encountered a new set of challenges that highlight the messy nature of financial filings. This post delves into these issues and how they impact the accuracy and reliability of data extraction.
This week I’ve started reading the second book in 2025 after finishing “The Psychology of Money” by Morgan Housel. The book is “Thinking, Fast and Slow” by Daniel Kahneman. This book delves into the dual systems of thought that govern our decision-making processes.
For our financial analysis tool, the latest series of updates focuses on an architectural enhancement: the integration of a persistent database layer for caching, performance tracking, and data retention. This post details the changes, the rationale behind them, and how they set the stage for future development.