Build a Local AI Dev Environment · 30 min · Continue.dev · VS Code · Ollama

Local Code Assistant in VS Code

The same Ollama server you've been curling since Lesson 2 is what powers autocomplete in your editor -- there's no separate 'AI coding' infrastructure, just another client of the same local API.

Real-world application: Wiring a local model into your actual editor -- not just a chat window -- is what makes a local AI stack part of your real daily workflow instead of a separate tool you occasionally open.

What you will learn

Connect a VS Code AI assistant extension to your local Ollama models
Configure the coding-focused model for completions, distinct from the general chat model
Test both inline completion and the chat panel on a real project

Objective

What you're building

The exact same Ollama server from Lesson 2, now feeding autocomplete and a chat panel directly inside VS Code — the point where this stops being "a local AI project" and starts being part of how you actually write code.

Continue.dev configuration

{
  "models": [
    {
      "title": "Local Chat (Qwen3)",
      "provider": "ollama",
      "model": "qwen3:8b"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Local Autocomplete (Qwen3 Coder)",
    "provider": "ollama",
    "model": "qwen3-coder:7b"
  }
}

Two separate model entries, deliberately: tabAutocompleteModel is the fast inline-completion path (fires constantly as you type, so latency matters more than raw capability), models is the chat-panel path (fires on-demand for real questions, where you'd rather have Qwen3-Coder or even the general model's stronger reasoning than raw speed). This mirrors the exact "different models for different jobs" principle from Course 07's Planner/Specialist model split -- coding assistants aren't one model doing everything.

Verify Continue.dev is still the right choice when you read this
Local coding-assistant tooling moves fast -- Continue.dev is a solid, actively maintained choice as of when this course was written, but check the current landscape (Continue.dev, Cursor with an Ollama backend, aider as a terminal-based alternative) before assuming this is still the best option. The actual skill transferring here is "connect an editor tool to your local Ollama server," which applies regardless of which specific extension wins next year.

Test it for real, not with "hello world"

You test the inline completion on a genuinely complex function in a real project and it's noticeably worse than what you're used to from a cloud-hosted coding assistant. Is this a sign something is misconfigured?

This is the same honest tradeoff from Lesson 1 and Lesson 2, now showing up in code quality instead of just tokens/second: a 7B-class local model is genuinely less capable than a frontier cloud model on complex reasoning, in exchange for total privacy, zero API cost, and offline capability. Knowing where this tradeoff is worth it (routine completions, private/sensitive code) versus where you'd still reach for a cloud tool (genuinely hard problems) is the actual judgment this course is building, not something to engineer your way out of with local hardware alone.

What you're building today

continue_config.json: Continue.dev configured with 2 model entries (autocomplete using the coding model, chat panel using the general model), tested with real inline completions and one real chat-panel debugging question on an actual project — not a toy snippet.

The Problem

A convincing demo can still depend on hidden state, permissive defaults, curated input, or a failure path nobody exercised. This milestone isolates local code assistant in vs code and makes its real operating boundary visible before the next component depends on it.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Build, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account — the opening phases of 29 of 35 courses are free, no credit card.