Welcome to my blog!
This blog chronicles my journey of building things (currently interested in LLM-powered features) and figuring out life.
As a born designer who stumbled into data science before learning his first programming language (Python), I believe software is the (current) ultimate vehicle for great thinking and building.
But tools still need analytics to act as proof, and design to make them effortlessly digestible.
I live for these intersections, treat this as my playground for validating life thoughts by building them out, automating the (unfortunately essential) stuff to free up the fun.
Think of it as me trying to debug life while getting better at debugging programs.
Fueled by an insatiable curiosity (and AI's endless patience),
I'm pretty confident this entire script will be error-free by the end of this century.
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.