LSP

What it is

LSP, the Language Server Protocol, is a common way for editors and tools to get live code intelligence about a project. A "language server" reads your code as you work and reports errors, type information, autocomplete suggestions, and "go to definition" links. The protocol means one language server can power many editors — the same red squiggles you see in VS Code can also drive a command-line tool or an AI coding agent.

Strengths

• Gives real, language-aware feedback: actual type errors and undefined references, not just guesses.
• Standardized, so a single server works across many editors and tools.
• Updates as you type, so problems surface immediately instead of at build time.
• Powers the everyday features developers rely on: completion, hover docs, rename, jump-to-definition.

Trade-offs

• Each language needs its own server, and quality varies between them.
• Servers can be heavy on memory and CPU on large projects.
• It tells you what's wrong, not how to fix it — interpretation is still on you (or the AI).
• Setup can be fiddly; getting the right server configured for a project takes some care.

When to use it

Any time you want trustworthy, real-time feedback on code as it's written — which is essentially always. For vibe coding it matters most as a signal source: the diagnostics a language server produces are exactly what you want flowing back into the loop.

Vibe coding fit

LSP is what lets an AI see the same problems you do. A good harness pipes the language server's diagnostics back to the agent after each edit, so the AI catches its own type and lint errors and fixes them before you ever run the code. Instead of "looks plausible," you get "the compiler agrees." Tell your agent to read the diagnostics, not just the file.

// a diagnostic an LSP server returns — feed this back to the agent
{
  "severity": "error",
  "range": { "start": { "line": 12, "character": 6 } },
  "message": "Type 'string' is not assignable to type 'number'."
}