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.
In this post, I want to show you the demo for the project after making the caching work. Below are two demos of the exact same analysis request. The only difference is that one is a cold start, and the other benefits from the now-functional cache.
When I first started building this application, my focus was on a simple goal: use a Large Language Model (LLM) to read dense SEC filings and extract structured, easy-to-digest insights. The initial prototype was magical. I could feed it the “Business” section of a 10-K filing, and it would return a beautiful JSON object with competitive advantages, key products, and more.
But then, I started to find out each analysis takes time especially when I wanted to analyze multiple sections like Business, Management’s Discussion and Analysis (MD&A), Risk Factors, and Financials. Each of these sections required a separate LLM API call, and I was making those calls one after another in a synchronous loop.
That’s when I hit the wall, together with the previous ‘cache’ implementation that wasn’t caching anything. The user experience was not ideal, and I knew I had to do something about it. So in this post I will show how to transform a sequential script to a multi-layered concurrent application that feels responsive and powerful to reduce the wait time from a couple of min to just seconds.
After running a few analyses, I noticed from the logs that with the existing edgar caching strategy, it still made HTTP requests and my terminal logs showed that the app was re-downloading the same SEC filings over and over.
The caching layer, which was supposed to prevent this, was clearly not working. This post is a chronicle of a classic developer experience: realizing a core feature isn’t working as intended and diving in to fix it.
In this post, we will dive a bit into model evaluation. Building with Large Language Models (LLMs) presents two major challenges:
How do you know if the output is any good?
How do you prevent API costs from spiraling out of control?
Today, I tackled both of these head-on by building a robust evaluation and cost-tracking framework. It’s an (again) interesting learning journey but important step for moving from a fun prototype to a reliable tool.
In the last post, I briefly outlined the project for an AI-powered tool to analyze SEC filings. In this blog, I’m diving deep into the architecture and core components that form the engine of this financial analyst.
We’ll dissect the journey of a single user request, from a ticker symbol entered into a form all the way to a rich, interactive dashboard filled with AI-generated insights.
It’s been a while, but I’m happy to be back to blogging (helped by my AI assistants) with a new project and a new series! This is a dual experiment:
Can we build an AI-powered tool to automate the analysis of complex financial documents for the purpose of learning the latest AI LLM techniques?
How far can a developer push a project by truly partnering with AI coding assistants?
I’ll be sharing the journey right here.
The Problem: Information Overload in Finance
Before the project I had not much experience with financial documents especially company filings, only a basic understanding of their importance and relevance. After spending some time digging into them, I realized the challenge: You’re faced with mountains of dense, jargon-filled documents like 10-Ks and 10-Qs. Buried within these SEC filings is a goldmine of information about a company’s performance, strategy, and risks. But extracting and understanding it is a tedious, manual process and never even mention that not all SEC filings themselves are not standardized.
There are many websites have information about companies like Yahoo Finance, Google Finance, and others. But to build a platform with LLMs that can truly understand and analyze these documents, it’s essential to work directly with the raw data. This is where the SEC’s EDGAR database comes in, providing access to all public filings.
🔎 Intro
In this post, I will start creating resources in Azure using Pulumi. The full process is quite complex, so I will try to break it down into smaller parts and raise the key points here during my implementation.
🔎 Intro
In the last post, I discussed some points of setting up Azure for Inomad’s infrastructure. In this post, I will be creating a Pulumi project and discuss some interesting points about the initial setup and considerations.
🔎 Intro
This post is the beginning of the implementation phase for Inomad’s infrastructure on Azure. As the usual like other posts in Inomad series, I will just highlight the key points I’ve encountered instead of making the series an instruction of ‘How to’. This post will cover the initial steps and considerations for deploying Inomad’s infrastructure on Azure.
🔍 Intro
Auditing, monitoring, and logging are critical components in the realm of cloud computing, ensuring operational integrity, security, and compliance. In this post, I will discuss the importance of auditing, monitoring, and logging in the cloud, and give it a detailed overview and study of these technologies.