|
Hi HN! I'm Inacio, the author of REASON. I've been tinkering with LLMs since the GPT-3 API's release May 2020. Seeing the emergence of many frameworks in the last 15 months has been exciting. While many understandably focused on launching quick, I found myself intrigued by a different question: what would a thoughtful, first-principles approach look like? This curiosity led to a personal project, RΞASON, a minimalistic open-source TypeScript framework. It's been a couple of months of digging deep and learning a ton, and I'm eager to share it and grow it with insights from all of you. In the early days of LLMs, I didn't feel the need for external libraries/frameworks — it seemed straightforward with mostly HTTP calls and simple prompting. But as the field evolved, new techniques were introduced — such as agents with tools, advanced RAG pipelines and function calling to name a few — and I found myself increasingly doing undifferentiated heavy lifting. A significant chunk of my time was consumed by tasks like parsing strings to determine which tool the LLM selected and with what parameters, handling potential cases where the LLM passed the wrong parameters, parsing text-based HTTP streams to extract structured output, handling with back-pressure and cancellation in streams, creating robust observability and measures for troubleshooting agent runs. It was a ton of work that didn't increase my app's competitive advantage. Around March I realized that using a framework would help. Yet, and to my surprise, existing LLM frameworks seemed to focus elsewhere — offering pre-made prompts, adaptors to vector databases, ready-to-use tools, and data ingestion solutions. While these features are good for beginners, they weren't addressing my needs. This is when I started to think about RΞASON. RΞASON's number one goal was to be a framework that does the undifferentiated heavy lifting for you. No pre-made prompts or agents, no vector DBs integrations. That's all up to the developer. As RΞASON evolved, another thing became clear: LLMs are a new programming primitive, akin to databases in the 70s and the explosion of web technologies in the 2000s. But they are not a completely new way to program — LLMs should be adapted into our current programming paradigms, not the other way around. For instance, we should strive to leverage familiar programming concepts interact with LLMs. One of the many places we see this in RΞASON, is when you want to get structured output from a LLM: you create a normal TS `interface` describing what you want and just pass that as a generic to the `reason()` function. RΞASON transpile the interface into a JSON Schema object that is used during runtime. I think this creates a really good experience for devs. RΞASON is still in its early stages, with just me and a few friends testing it out — so expect bugs, but you can start playing with now (npx use-reason@latest). Our docs (https://docs.tryreason.dev) offers a good learning experience also. As mentioned, this is a passion project, and I'm really eager to hear what you think and all your feedback! Any insights about this problem space are also super welcomed. |