This video introduces ECA (Editor Code Assistant), a free, open-source tool designed to provide a unified AI pair-programming experience across different code editors. Inspired by the Language Server Protocol (LSP), ECA uses a central server to handle AI logic, allowing lightweight clients in various editors (like Emacs and VS Code) to offer the same set of features.
The server is written in Clojure and compiled with GraalVM for fast performance. It communicates with Large Language Models (LLMs) and provides them with a suite of tools for tasks like file searching, reading, and editing. The presentation demonstrates ECA's capabilities, including generating unit tests for a Clojure function, and explains its core operational mechanism: the "LLM loop." This loop involves a cycle of the LLM requesting to use a tool, the ECA server executing it, and the result being fed back to the LLM, enabling complex, multi-step problem-solving. Future plans include adding support for more editors like IntelliJ and expanding features to compete with commercial tools.
ECA: A Standardized AI Assistant for Any Code Editor
1:09 Rationale: An "LSP for AI": The project was created to solve the problem of inconsistent AI tool implementations across different code editors. ECA provides a single, standardized server that any editor can connect to, similar to how the Language Server Protocol (LSP) standardized language-specific features.
4:44 Core Architecture: ECA operates on a server-client model. The powerful server, written in Clojure, contains all the logic for communicating with LLMs and executing tools. This allows the editor-side extensions (the clients) to be very simple.
5:57 Why Clojure?: The creator chose Clojure due to his existing experience with clojure-lsp, its strong capabilities for asynchronous operations (essential for handling LLM calls), and the performance benefits of compiling with GraalVM for fast startup and low resource usage.
9:36 Getting Started: Installation involves adding the ECA extension to your editor (e.g., Emacs, VS Code), which then automatically downloads and manages the server. Users then configure their preferred LLM provider (OpenAI, Anthropic, custom models, etc.).
13:17 Context and Tools are Key: The AI's effectiveness relies on providing good context. ECA automatically uses the currently open file and allows users to add more context (files, resources) with an @ symbol. It also provides the LLM with "tools" (called MCPs) to interact with the local environment, such as searching files, reading them, and applying edits.
15:23 Demonstration: Generating Unit Tests: The video shows ECA successfully generating unit tests for a Clojure function. The LLM uses its tools to first find the function's definition, read existing test files to understand the project's style, and then writes and applies the new test code.
23:43 "Plan" vs. "Agent" Modes: ECA offers different operational modes. "Agent" mode allows the AI to apply changes directly (with user approval), while "Plan" mode makes the AI propose a set of changes as a diff for the user to review and apply manually.
25:12 Custom Commands: Users can define their own reusable commands with custom prompts (e.g., /explain_code), streamlining repetitive tasks and tailoring ECA to their workflow.
28:01 The "LLM Loop" Explained: This is the core mechanism behind ECA's agent-like capabilities.
ECA sends the user's query and a list of available tools to the LLM.
The LLM responds not with an answer, but with a request to call a specific tool (e.g., "list files in the /src directory").
The ECA server executes this tool locally and captures the output.
This output is sent back to the LLM as part of the ongoing conversation.
This cycle repeats, allowing the LLM to gather information and act on the environment step-by-step until it can generate a final response.
35:59 Future Development: The project aims to add support for more editors, including IntelliJ, and expand its feature set to be as capable as commercial tools like Cursor and Claude.