Zerox.LSAI

Language Server for AI — Project Overview

What It Is

LSAI is an MCP server that provides token-efficient semantic code analysis to AI assistants. It wraps Roslyn (C#) and LSP servers (Python, TypeScript, JavaScript, Java) behind a unified plugin architecture, delivering rich code intelligence (search, usages, hierarchy, callers, outline, etc.) in compressed formats that save 82–86% tokens compared to raw LSP JSON.

It includes a web management console (Angular + PrimeNG) for managing repositories, monitoring usage, and configuring workspaces. Everything is packaged in a single Docker image.

Architecture

graph LR
    AI["🤖 AI Assistant\nAI Assistants"] -->|"MCP Protocol\nHTTP"| Server
    User["🌐 Browser"] --> SPA

    subgraph LSAI["Zerox.LSAI Server — ASP.NET"]
        Server["MCP Host\n18 Tools + Formatters"]
        WS["Workspace\nSession Manager"]
        DB[("SQLite")]
        SPA["Angular Console\nPrimeNG"]
        Server --> WS
        Server --> DB
    end

    subgraph Plugins["Plugins — runtime loaded"]
        Roslyn["Plugin.Roslyn\nC# via Roslyn APIs"]
        LSP["Plugin.Lsp\nStreamJsonRpc Client"]
    end

    WS --> Roslyn
    WS --> LSP

    subgraph LSPServers["External LSP Servers — managed processes"]
        Pyright["Pyright\nPython"]
        TSLS["typescript-language-server\nTS + JS"]
        JDTLS["Eclipse JDTLS\nJava"]
    end

    LSP -->|"stdin/stdout"| Pyright
    LSP -->|"stdin/stdout"| TSLS
    LSP -->|"stdin/stdout"| JDTLS
  

Development Time Estimate

How long would a super senior .NET/Angular developer take to build this from scratch, writing all code by hand?

Breakdown

Scenario Comparison

Where The Time Really Goes

The LSP Bridge Plugin (Phase 7) dominates because:

• Each LSP server speaks the same protocol differently
• JDTLS needs 5 specific initialization steps or it deadlocks
• Pyright silently returns empty results without correct capabilities
• Process lifecycle (spawn, init, warmup, crash recovery) is non-trivial
• You only discover these issues after hours of debugging

The Roslyn Plugin (Phase 6) is the second time sink:

• MSBuildLocator picks wrong SDK versions silently
• Workspace loading fails in creative ways on different platforms
• Symbol resolution across projects requires understanding Roslyn internals

Actual Development Timeline (with AI Coding Assistant)

The project was built with an AI coding assistant writing ~95% of the code, directed by a senior developer who designed architecture and made all decisions. Human role: architecture, decisions, prompting, review, manual testing.

Day-by-Day Breakdown

Estimate vs Reality

Using the realistic estimate (1.8x) as baseline, since the optimistic 51-day figure assumes zero surprises — which never happens with undocumented LSP server quirks.

Key Observations

1. Boilerplate-heavy phases (contracts, DI, server scaffold) = 10–15x speedup. AI excels at generating repetitive, pattern-based code. Core contracts + plugin loader + server host were done in a single evening + morning.
2. LSP debugging = only 2.2x speedup. This was the one area where AI couldn't shortcut the pain. Each LSP server has undocumented quirks. OmniSharp had an architectural deadlock that required reading library source code, forming hypotheses, and testing them. This phase alone consumed ~45% of total development time.
3. The OmniSharp → StreamJsonRpc rewrite (27 files) happened in a single day. This is where AI coding shines: large-scale mechanical refactoring with clear patterns. A human would need 3–5 days for the same rewrite.
4. Day 2 was superhuman. 26 commits covering 6+ estimated phases in one day. This kind of output is physically impossible without AI assistance — not because of typing speed, but because of the sheer volume of correct, tested code produced.
5. Total human effort was ~73–80 hours over 9 days. The “human” work was primarily: architecture decisions, prompting, reviewing AI output, manual MCP testing, debugging LSP server behavior, and directing the AI to fix issues. Actual keystrokes-to-write-code was minimal.