Posts Tagged ‘KapilReddy’
[reClojure2025] LLMs + Clojure = Who needs frameworks?
Lecturer
Kapil Reddy is a software engineer known for his “business-first” approach to development. He is a prominent figure in the Clojure community, frequently contributing to discussions and ideation at the Scicloj meetups. Kapil has collaborated with other leading engineers in the ecosystem, such as Vedang Manerikar and Daniel Slutzky, to explore the intersection of artificial intelligence and functional programming. He is currently involved in developing the llms.edn project, which aims to bridge the gap between Clojure’s library-centric philosophy and the modern need for rapid project scaffolding using Large Language Models (LLMs).
Abstract
In the modern software development landscape, Large Language Models (LLMs) have significantly altered workflows, particularly in the realm of project scaffolding. However, the Clojure ecosystem, which prioritizes a philosophy of composable libraries over rigid frameworks, often presents a steep learning curve for newcomers who seek the convenience of “Rails-like” frameworks. This article explores a novel methodology introduced by Kapil Reddy that leverages LLMs to automate the composition of Clojure libraries. By utilizing a structured, native format called llms.edn, developers can describe library usage patterns in a way that LLMs can understand and execute. This approach aims to provide the convenience of a framework while maintaining the flexibility and power of Clojure’s traditional library-based architecture.
The Framework Paradox in Clojure
The debate between using frameworks versus a collection of libraries is central to Clojure’s identity. Traditional frameworks like Ruby on Rails provide a “Golden Path,” offering a set of pre-configured tools and conventions that allow for rapid prototyping. For many developers, especially those transitioning from other ecosystems, the absence of such a framework in Clojure is perceived as a significant barrier to entry. Clojure’s core philosophy leans heavily toward composition, where developers select specialized libraries—such as Ring for HTTP, Reitit for routing, and HugSQL for database access—and manually integrate them.
While this library-centric approach prevents the “black box” complexity and “magic” often associated with frameworks, it requires a deep understanding of the ecosystem. Kapil Reddy observes that LLMs are exceptionally proficient at project scaffolding, a task traditionally reserved for frameworks. The challenge, therefore, is to create a system where LLMs can assist in this scaffolding process without forcing the community to adopt a monolithic framework that would sacrifice the language’s fundamental strengths.
llms.edn: Structured Knowledge for AI Agents
To enable LLMs to effectively compose Clojure libraries, Kapil proposes a structured, Clojure-native approach to describing libraries and their common usage patterns: llms.edn. This concept is inspired by the broader llms.txt initiative but is tailored specifically for the unique requirements of the Clojure ecosystem.
The llms.edn file serves as a manifest that provides the LLM with the necessary context to understand how a library should be initialized, configured, and integrated with others. Instead of the LLM relying on potentially outdated or hallucinatory training data, llms.edn provides a source of truth directly from the library authors or the community. This structured data includes:
* Dependency declarations: Specific coordinates for tools like deps.edn or Leiningen.
* Code snippets: Standard boilerplate for starting a server or connecting to a database.
* Interoperability rules: Instructions on how a library (e.g., a router) interacts with another (e.g., a handler).
By providing these instructions in a machine-readable format, the manual task of “wiring” libraries together—often the most frustrating part for beginners—can be offloaded to an AI agent.
LLM-Powered Composition Workflows
The practical application of this methodology is an LLM-powered composition workflow. In this model, the developer describes the desired features of their application in natural language. An AI agent then queries a registry of llms.edn files to identify the best libraries for the task.
Kapil demonstrates that once the “how-to” for each library is codified, the process of generating a cohesive starter project becomes a “looper making a REST call”. This flow engineering treats the LLM as a pipeline that manages state and passes configuration data between different execution steps. This results in a “framework-like” experience where a full project structure is generated instantly, yet the underlying code remains a collection of simple, independent libraries that the developer can easily modify or replace.
The implications of this shift are profound. It suggests that the primary utility of a framework—reducing the cognitive load of setup and configuration—can now be achieved through intelligent automation. As Kapil notes, the LLM world requires more “simple software” because the models themselves introduce enough complexity; Clojure’s inherent simplicity makes it an ideal target for this kind of AI-driven orchestration.