DEV Community: Ladislav Sopko

I've been coding for 30+ years. All I ever wanted was to stop typing.

Ladislav Sopko — Fri, 15 May 2026 10:15:15 +0000

I started coding in the early 90s. Assembly first, then C, then the C++ years where you'd fight the compiler more than you'd write features.

By 2007 I was deep into enterprise systems — building a document engine with a colleague. My part was the fun stuff: a plugin system, a parallel B+Tree block file system, Lua scripting integration. I even wrote a custom virtual memory manager to fix LuaJIT's 1GB RAM limit on 64-bit — patching memory pages at the OS level, Windows and Linux, portable. The kind of thing where you're staring at hex dumps at 2am wondering if you've gone too far.

My colleague handled the C core. We shipped it. Enterprise clients used it for years.

But here's the thing nobody tells you about decades of systems programming: your hands pay the price. Thousands of hours of typing. Millions of keystrokes. I started dreaming about a world where I could just say what I wanted and watch the code appear.

The voice coding rabbit hole (spoiler: it sucked for 20 years)

I tried everything. Dragon NaturallySpeaking with custom macros. Voice Attack. Talon. Various VSCode extensions that promised voice-to-code and delivered voice-to-frustration.

The problem was always the same: programming isn't dictation. You can't just say "open curly brace semicolon" and expect to be productive. The overhead of translating your intent into dictation commands was worse than just typing. Every time I tried, I'd give up within a week and go back to the keyboard.

But the dream never died. I kept trying, year after year. My colleagues thought I was obsessed. They were right.

Then the wave hit

When Cline came out, something clicked. Not because it was voice — it wasn't. But because for the first time, the AI wasn't just autocompleting tokens. It was understanding intent. You could describe what you wanted at a high level and watch it navigate files, read code, make changes.

I jumped from Cline to Cursor to Claude Code in maybe 6 months. Each one better than the last. Claude Code was the inflection point — a real terminal-based agent that understood my codebase, my project structure, my intent.

But I still had to type everything. The irony.

Voice ...

I think human progress actually happens because we're naturally lazy. We need to simplify our lives — and I'm no different. I'm an eternal optimiser. So I built VoiceCC.

VoiceCC is what happens when a guy who's been dreaming about voice coding for 20 years finally has the right foundation to build on.

I have a small USB keypad on my desk. Each button is mapped to a different terminal session. I press a button, speak naturally — Italian, English, Slovak, doesn't matter — and Whisper transcribes it locally. No cloud, all offline, about 600ms. The hub figures out which terminal to target and injects the right keystrokes into that specific session.

What this means in practice: I run 3-4 Claude Code instances in parallel, each working on a different task. Press button 1: "yes approve that". Press button 3: "try the alternative approach with dependency injection". Press button 2: "show me the test results". Each going to a different Claude Code working on a different part of the project.

I built it in about 40 days. Co-authored most commits with Claude Code itself. Which felt... appropriate.

For the first time in 30 years, I could sit at my desk with a little keypad and direct multiple AI agents with my voice. Not "open curly brace" — actual intent.

The dream, somehow, actually worked.

The plot twist

Here's where it gets funny.

I spent 30 years wanting to stop typing. I built the tools to make it happen. And now I sit here, talking to my terminal, watching AI write code that sometimes scares me with how good it is.

I went from "I wish I could dictate code" to "I wish the AI would slow down and let me think."

Once you have an AI that writes code, you realize the bottleneck shifts. The AI is fast, but it's also blind — it doesn't know your libraries, it hallucinates APIs, it greps through thousands of files burning tokens. So I kept building. A server to give it access to Visual Studio's compiler intelligence. A language server for AI agents, covering 9 languages. A service that indexes 890+ open-source libraries so it stops making things up. Each one solving a problem the previous tool exposed.

But those are details for another article. What I want to say here is something else.

What I actually learned

I wanted voice coding in 2005. I got it in 2026. The version I got is wildly better than what I imagined — and also stranger.

Building B+Trees, memory managers, and plugin systems by hand for a decade is exactly why I could build the rest. I knew what "real code intelligence" meant because I'd lived without it. Systems programming didn't become obsolete when the AI showed up. It became the thing that let me know what to ask for.

The keyboard isn't dead, but it's optional now. I still type when I'm in deep flow. But for the 80% of coding that's orchestration, navigation, and review. Voice plus AI is just... better.

At 20 I imagined dictating code like a typist imagines dictating a novel. At 50 I find myself orchestrating agents that are sometimes better than me. It's not what I wanted. It's better, and it makes me a little uncomfortable. Twenty years of waiting to discover that the dream was wrong — and the right dream was something I couldn't even have formulated back then.

I'm starting to think I might end up leading the resistance against Skynet. Only half joking.

Stuff I built along the way

If you want to try any of the tools:

VoiceCC — github.com/LadislavSopko/VoiceCC — the multi-channel voice command center described above. Currently a proof of concept. If you'd like to build a community around it, reach out — I'd be happy to open the sources fully, I just don't have the bandwidth to maintain it alone.
vs-mcp — VS Marketplace — Visual Studio's Roslyn intelligence exposed via MCP. The first piece of software I ever built without writing a single line of code by hand.
LSAI — github.com/0ics-srls/lsai-xmp4.public — LSP-style intelligence for AI agents, 9 languages, 14 tools.
xmp4 — add https://mcp.example4.ai/mcp to your MCP config — 890+ pre-indexed libraries, 17 tools, free.

30 years of typing. Now I just talk. What a time.

Disclosure: I built all of these. The code is real, the benchmarks are published. AMA in the comments.

I gave my AI agent the compiler's eyes — here's what changed

Ladislav Sopko — Wed, 13 May 2026 14:42:23 +0000

— grepping across my monorepo, reading 50 files, half of them irrelevant, then guessing.

So I built two MCP servers. They changed everything.

The problem every AI coding agent has

Whether you use Claude Code, Cursor, Copilot, or anything else — when your AI needs to understand code, it defaults to text search. Grep, ripgrep, file reads, regex.

On a real codebase (mine is 1,500+ C#/.NET projects), that means:

"Who calls PublishAsync?" → grep → 200 string matches → read 50 files → half are tests/docs/comments → guess which are real callers
"What breaks if I change this?" → no idea, read everything that mentions it
"How does GetRequiredService work in the DI container?" → clone dotnet/runtime, search, give up

Cost: 40,000-60,000 tokens per question. Often wrong.

The fix: give the AI the compiler's eyes

I built two MCP servers that solve opposite sides of the same problem:

LSAI — your code, live

LSAI runs on your machine and wraps real LSP servers — the same language servers your IDE uses:

Language	LSP Server
C#	Roslyn (in-process)
Python	ty
Java	jdtls
TypeScript/JS	typescript-language-server
Rust	rust-analyzer
Go	gopls
PHP	intelephense
C/C++	clangd

14 MCP tools. The highlights:

lsai_callers("PublishAsync")
→ 15 callers, exact file:line, compiler-resolved

lsai_impact("PublishAsync")  
→ MEDIUM risk, 15 references, 27 tests affected
  Tests: PublishServiceTests, V32SpecComplianceTests...

lsai_hierarchy("BaseService")
→ full inheritance chain, interfaces, implementations

Install once, add one line to .mcp.json:

{
  "mcpServers": {
    "lsai": {
      "command": "~/.lsai/run",
      "args": ["--stdio"]
    }
  }
}

Your code never leaves your machine. LSAI is 100% local.

xmp4 — every library, pre-indexed

xmp4 is the other lens. It has 900+ OSS libraries already indexed across 12 languages — 15,000+ navigable projects. When your AI needs to understand how a third-party API actually works, it reads the real source, not docs:

xmp4_source("GetRequiredService", project="dotnet/runtime")
→ public interface ISupportRequiredService {
    object GetRequiredService(Type serviceType);
  }

xmp4_callers("MongoClient.connect")
→ 26 real call sites across 4 repos, typed

One line in your MCP config, no install, no API key:

{
  "mcpServers": {
    "xmp4": {
      "type": "http",
      "url": "https://mcp.example4.ai/mcp"
    }
  }
}

17 MCP tools. Covers C#, Java, TypeScript, Python, Rust, PHP, Go, JavaScript, Dart, Ruby, C++, Scala.

The tandem — where it gets powerful

Here's what happened yesterday in a real session. I needed to understand a dependency chain:

Step 1 — LSAI on my code:

lsai_callees("PublishAsync")
→ CreateScope()             — PublishService.cs:22
→ GetRequiredService<Ctx>   — PublishService.cs:23
→ Where<PublishedProject>   — PublishService.cs:74

My AI now knows my code calls GetRequiredService. But how does that work?

Step 2 — xmp4 on the library:

xmp4_source("GetRequiredService", project="dotnet/runtime")
→ ISupportRequiredService interface
→ Throws InvalidOperationException if not registered

Now it knows the contract AND the failure mode.

Step 3 — LSAI for risk assessment:

lsai_impact("PublishAsync")
→ MEDIUM risk — 15 refs, 27 tests
→ All test names listed, all lines numbered

Three calls. The AI traced from my code → into a library's internals → back to risk assessment. ~1,500 tokens total. No grep. No guessing. No cloning.

The numbers

I measured this on real tasks across 4 tier-1 libraries (spring-boot, tokio, django, efcore):

Approach	Tokens	Accuracy
xmp4	1,558	Exact (compiler-resolved)
grep + clone	47,200	Approximate (string match)
GitMCP	65,629	Approximate (text search)
Context7	n/a	Can't answer (docs only)

42x fewer tokens than GitMCP. 30x fewer than grep. Full benchmark whitepaper.

Get started

LSAI (your code):

curl -fsSL https://github.com/0ics-srls/Zerox.Lsai.Public/releases/latest/download/install.sh | bash

xmp4 (libraries): add the JSON config above. That's it.

Visual Studio users: there's also vs-mcp — same concept but as a VS extension with 41 Roslyn-powered tools.

Landing page: example4.ai

Both free. Both actively developed — I ship improvements every week. Both speak standard MCP, so they work with Claude Code, Cursor, VS Code, Claude Desktop, and any other MCP client.

I'm building this because I needed it myself. If you're spending tokens on code exploration instead of code generation, these two might help. Happy to answer questions.

I plugged my Claude Code into 881 indexed libraries. Here's what changed.

Ladislav Sopko — Wed, 29 Apr 2026 20:47:45 +0000

There's a class of bug that the current generation of AI coding assistants reliably produces, and it's worth naming because the fix is real and available now.

The bug: your assistant calls a library method that doesn't exist.

Not a typo. Not a logic error. A confident, well-formatted, syntactically perfect call to a method that has been deprecated, renamed, or never existed in the version you're using. The compiler tells you. You go back, ask the assistant to fix it, and 40% of the time it suggests a different method that also doesn't exist. By the time you've corrected it manually, you've burned 15 minutes and 30,000 tokens.

This isn't because the model is bad. It's because the model's training data is a snapshot, and library code is a stream. The data set knew StackExchange.Redis 2.5; you're on 2.8. The data set knew Tokio when its runtime API had a different shape. The model is doing exactly what it was trained to do — reproduce patterns it saw — and the patterns have moved.

The grep workaround makes it worse. When the assistant fetches your repo and runs textual searches over node_modules or vendor directories, it's still pattern-matching on substrings. It finds "Connect" in 200 places and has no way to tell which is the actual method definition vs. a comment vs. a similarly-named function in an unrelated package.

What's missing is the same thing your IDE has: a semantic index. A structured map that knows ConnectionMultiplexer.Connect is one specific method, returns these types, is called from these 47 places, was added in version X. SCIP — the format Sourcegraph open-sourced — is exactly that. It's how your "Find references" key works.

What I did

I connected my Claude Code (and a parallel Cursor session for cross-checking) to a public MCP server that hosts SCIP indexes for 881 popular open-source libraries: mcp.example4.ai. Free, zero install, one URL in the MCP config.

Then I re-ran the kinds of questions that usually go sideways:

"Use StackExchange.Redis to connect to a sentinel cluster."
"Show me how tokio::select! actually expands at runtime."
"Find every place in Spring Boot where WebSecurityConfigurerAdapter is used so I know what to migrate to."
"What does useFormStatus actually do under the hood in React 19?"

In every case, the assistant didn't hit the model first. It made tool calls — xmp4_search, xmp4_source, xmp4_usages, xmp4_callers, xmp4_hierarchy — and pulled back real, current, indexed source. Then it answered.

The token economics

The team behind it published a reproducible benchmark on their protocol repo. Same questions answered with grep-based retrieval vs. SCIP-based retrieval — between 70 and 93 percent fewer tokens for equivalent answers, depending on the kind of query (outline lookups land near the top, deep impact-analysis queries near the floor). I rerun a slimmed version on my side: same direction, same magnitude. The savings come from the index returning just the relevant symbols instead of the assistant having to triangulate through dumps of file content.

The downstream effect is the part nobody talks about: when you save tokens on retrieval, the conversation stays coherent for longer. Long sessions on hard refactors stop drifting because the context window isn't half-full of grep results.

Where it works and where it doesn't

It works on the libraries that are indexed. 881 today, including most of the ones I touch in real work — React, Vue, Svelte, Django, FastAPI, Flask, Spring Boot, Tokio, Axum, StackExchange.Redis, gRPC, Tailwind, Vercel AI SDK. 11 languages.

It does not work on:

Your private repo (you'd need to run a private indexer).
Libraries not yet in the index (request publicly, they triage weekly).
Niche language ecosystems they don't yet cover.

How to try it

In your MCP client config (Claude Code, Cursor, Claude Desktop, Continue, Cline — all support MCP), add:

{
  "mcpServers": {
    "example4": {
      "url": "https://mcp.example4.ai/mcp",
      "transport": "http"
    }
  }
}

Restart your client. Ask it a library question. Watch the tool calls.

My take

This is not a "10x your productivity" claim. It is a "stop your AI from making this specific class of mistake" claim. That alone is worth the two-minute config change for me. The token savings is a bonus.

Spec + numbers (open source): github.com/LadislavSopko/lsai-protocol
Public endpoint: mcp.example4.ai

How to give Your AI Coder Visual Studio's IntelliSense?

Ladislav Sopko — Thu, 05 Feb 2026 19:28:17 +0000

The Problem Nobody Talks About

Every AI coding tool operates at the filesystem level. They read files. They run grep. They parse text.

When you ask "find all usages of ProcessDocument", they run something like:

grep -rn "ProcessDocument" . --include="*.cs"

And you get back:

The actual method definition
ProcessDocumentAsync (different method!)
String literals in log messages
Comments mentioning the method
Variable names like processDocumentResult
XML documentation references

Now imagine doing a rename based on that. 💀

Meanwhile, Visual Studio knows — through Roslyn, the C# compiler — exactly:

Where ProcessDocument is defined
Every place it's called (and nothing else)
What interface declares it
What classes override it
What it's not (ProcessDocumentAsync is a different symbol)

The Solution: Expose Roslyn via MCP

VS-MCP is a Visual Studio extension that exposes Roslyn's semantic analysis as MCP (Model Context Protocol) tools.

Any MCP-compatible client — Claude Code, Claude Desktop, Codex CLI, Gemini CLI, OpenCode, Aider, Cline, Windsurf — can now use 20 tools powered by the actual C# compiler.

The Tools

🔍 Navigation (find things semantically)

FindSymbols — Search symbols by name. Not text. Symbols.

You: "Find WhisperFactory in my solution"

AI: Found WhisperFactory
    → Class | Whisper.net | WhisperFactory.cs | Line 16

One result. Exact. Knows it's a class, knows the namespace.

FindSymbolDefinition — The semantic equivalent of F12.

You: "Go to the definition of IDocumentService"

AI: → Interface | DocFlow.Core | IDocumentService.cs | Line 8

FindSymbolUsages — Every reference, compiler-verified.

You: "Find all usages of ProcessDocument"

AI: Found 4 usages:
    → IDocumentService.cs:12 (declaration)
    → DocumentService.cs:45 (implementation)
    → DocumentController.cs:23 (call)
    → BackgroundWorker.cs:67 (call)

    Note: ProcessDocumentAsync NOT included — different symbol

GetSymbolAtLocation — What's at line X, column Y?

You: "What's the symbol at line 15 in Program.cs?"

AI: → Method: ConfigureServices | Class: Program | Returns: void

🌳 Understanding (comprehend architecture)

GetInheritance — Full type hierarchy.

You: "What inherits from BaseDocument?"

AI: BaseDocument hierarchy:
    → Base: EntityBase
    → Interfaces: IDocument, ITrackable, IAuditable
    → Derived: Invoice, PurchaseOrder, CreditNote, DeliveryNote

Try getting this from grep. I'll wait.

GetMethodCallers — Who calls this method?

You: "What calls ValidateToken?"

AI: ValidateToken is called by:
    → ApiKeyMiddleware.Invoke()
    → LoginController.Authenticate()
    → RefreshTokenHandler.Handle()

GetMethodCalls — What does this method call?

You: "What does ValidateToken call internally?"

AI: ValidateToken calls:
    → TokenRepository.FindByHash()
    → ClaimsParser.Extract()
    → AuditLogger.LogAccess()

Combine callers + callees and you have a call graph. From the compiler. Not from guessing.

GetDocumentOutline — Semantic structure of any file.

You: "Show me the structure of DocumentService.cs"

AI: DocumentService.cs outline:
    → Namespace: DocFlow.Services
      → Class: DocumentService : IDocumentService
        → Method: ProcessDocument(Document doc) → Result
        → Method: ValidateDocument(Document doc) → bool
        → Property: Logger (ILogger)
        → Field: _repository (IDocumentRepository)

✏️ Refactoring (change things safely)

RenameSymbol — The killer tool. Roslyn-powered rename across the entire solution.

You: "Rename ProcessDocument to HandleDocument"

AI: ✓ Renamed in 8 files, 23 locations
    → Interface updated
    → Implementations updated
    → Call sites updated
    → ProcessDocumentAsync: untouched (different symbol)
    → String literals: untouched
    → Build verification: 0 errors

FormatDocument — Visual Studio's own formatter, not dotnet format.

🏗️ Infrastructure

ExecuteCommand — Build/clean with structured diagnostics.

You: "Build MyProject"

AI: Build succeeded | 0 errors | 2 warnings
    → Warning CS0168: Variable 'ex' declared but never used (File.cs:42)

ExecuteAsyncTest — Run tests with real-time status.

You: "Run the integration tests"

AI: Running tests... 12/45 passed
    ...
    Complete: 44 passed, 1 failed
    → Failed: TestPaymentProcessing — Assert.Equal failed

GetSolutionTree — Full solution structure.
GetProjectReferences — Dependency graph between projects.
TranslatePath — WSL ↔ Windows path conversion (crucial for Claude Code users).
GetSelection / CheckSelection — Read active editor selection.
GetActiveFile — Current file and cursor position.
GetLoggingStatus / SetLogLevel — Diagnostics.

Multi-Solution: See Inside Your Dependencies

Enterprise devs don't just work on their own code. You depend on libraries — and sometimes you need the AI to understand those libraries too.

VS-MCP supports multiple Visual Studio instances simultaneously — each on its own configurable port.

Your project                         → VS-MCP on port 3010
Whisper.net source (cloned from GH)  → VS-MCP on port 3011
EF Core source (cloned from GH)      → VS-MCP on port 3012

Your AI connects to all three. Now it can:

Find how library authors intended their API to be used
Discover implementation patterns inside library source code
Trace calls across your code and library code
Understand inheritance that spans project boundaries

In your MCP client configuration, you simply set up named connections. Three options depending on your client:

Option 1: Clients with native HTTP support (Claude Desktop, Claude Code)

{
  "mcpServers": {
    "vs-mcp": {
      "type": "http",
      "url": "http://localhost:3010/sdk/"
    },
    "vs-mcp-whisper": {
      "type": "http",
      "url": "http://localhost:3011/sdk/"
    }
  }
}

Option 2: Clients without HTTP support (via mcp-remote proxy)

{
  "mcpServers": {
    "vs-mcp": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:3010/sdk/"]
    },
    "vs-mcp-whisper": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "http://localhost:3011/sdk/"]
    }
  }
}

Option 3: Codex CLI (TOML)

[mcp_servers.vs-mcp]
type = "stdio"
command = "npx"
args = ["mcp-remote", "http://localhost:3010/sdk/"]

[mcp_servers.vs-mcp-whisper]
type = "stdio"
command = "npx"
args = ["mcp-remote", "http://localhost:3011/sdk/"]

Each name tells the AI what it's connecting to. vs-mcp is your project, vs-mcp-whisper is the library source. The AI knows where to look.

No more guessing how a library works. Open the source, connect VS-MCP, and your AI reads it with compiler-level understanding.

Plus: toggle individual tools on/off and switch WSL/Windows path formats from a settings panel inside VS.

When You Need This

You don't need this for a weekend project with 3 files.

You need this when:

Your solution has 20+ projects
You have complex inheritance hierarchies
Dependency injection makes grep useless for finding implementations
You need safe refactoring across hundreds of files
Your AI assistant keeps saying "I found 47 matches for that method name"
You want your AI to understand architecture, not just read text

Installation

Install from Visual Studio Marketplace
Set your port in MCP Server Settings (default: 3010)
Add to your MCP client config:

"vs-mcp": {
  "type": "http",
  "url": "http://localhost:3010/sdk/"
}

Or via mcp-remote for clients without native HTTP:

"vs-mcp": {
  "command": "npx",
  "args": ["-y", "mcp-remote", "http://localhost:3010/sdk/"]
}

Your AI now has compiler-level intelligence

Works with Claude Code, Claude Desktop, Codex CLI, Gemini CLI, OpenCode, Aider, Cline, Windsurf, and any MCP-compatible client.

VS-MCP: 20 tools. 12 Roslyn-powered. Free.

🌐 Website →

📥 Install from Marketplace →

🎬 Watch the demo →

0ics srl — Italian software company specializing in AI-powered development tools.