← Writing

The difference between AI-assisted and agentic development — and what a real TDD-first agentic build actually looks like in practice.

Most developers are using AI as a better autocomplete. A small group is using it as a second engineer.

Here’s what the second approach actually looks like in practice — using lspforge as a worked example.

Three Modes of Building with AI

Not all AI-assisted development is the same. It’s worth naming the modes clearly:

Vibe coding: rapid exploration, throwaway prototypes. You’re not really building — you’re sketching. The AI generates, you react, nothing is meant to last.

AI-assisted development: you write the code, AI speeds you up. You’re still the implementer. The AI is a fast autocomplete, a rubber duck, a Stack Overflow that writes code.

Agentic development: AI implements. You own architecture, quality, and direction. Your job shifts from writing code to making decisions about what gets built and reviewing what the agent produces.

lspforge was built using the third approach.

The Problem lspforge Solves

Language servers make every AI coding tool smarter — TypeScript, Python, Rust, Go all have language servers that provide completions, diagnostics, and go-to-definition across editors and tools.

But configuring them is tedious manual work that doesn’t transfer. Copilot CLI expects one config format. OpenCode expects another. The LSP server itself needs to be installed from the right source (npm, pip, a binary release, go install — it varies). None of this is obvious. None of it is documented in one place.

I rebuilt the same setup four times across projects before deciding to automate it.

The Build Process

The methodology wasn’t vibes. It was a real engineering process:

1. Planning and market research first. I mapped the configuration requirements for the five major AI coding tools that support LSP, the installation mechanisms for the most common language servers, and what a correct config looks like for each combination. This context went into a spec document before any code was written.

2. TDD before implementation. The test suite defined the contract:

$ claude "Research LSP config formats for Copilot CLI and OpenCode.
  Write tests for: install command, config detection,
  multi-language support, cross-platform paths (macOS, Windows, Linux).
  Tests must fail first. No implementation yet."

Not “write me a CLI tool.” A scoped, testable, reviewable task.

The tests covered the installation command, config detection logic, multi-language support, and cross-platform path handling. They all failed. That was the point.

3. Implementation against the failing tests. With a clear spec and a failing test suite, Claude Code implemented the tool. I reviewed each increment, corrected course when the approach diverged from the spec, and approved what was correct.

4. CI/CD from day one. Before calling it shipped, every push was validated automatically. The pipeline ran the test suite on macOS, Windows, and Linux. Nothing landed without passing all three.

What Shipped

npm install -g lspforge
lspforge install typescript-language-server
lspforge check

lspforge installs the server, runs a real LSP protocol handshake to verify the server actually responds, then writes the correct config:

  • ~/.copilot/lsp-config.json for Copilot CLI
  • Project-root config for OpenCode

No JSON editing. No hunting through docs. Run it once per project.

The Mindset Shift

Simon Willison put it well: “Don’t commit code unless you could explain what it does.”

That’s the right frame. Agentic development isn’t about trusting the agent blindly. It’s about changing what you spend your attention on:

  • Less time writing boilerplate
  • More time on architecture and correctness
  • You stay accountable for what ships

The agent implements. You own the outcome.

What This Looks Like in Practice

The concrete experience: I spent my time on decisions. What should the install UX feel like? What happens when a language server isn’t available? What’s the right error message when the LSP handshake fails? How should the config be structured so it’s easy to inspect and debug manually?

The agent spent its time on implementation. File I/O, config generation, protocol handling, error cases, tests.

One person. One agent. Shipped product.

Source: github.com/svivekvarma/lspforge. Post 2 of 5 in the Agentic Development series.