← SnapRecaps

Local AI Coding is Finally Good Enough

► 34,871 views ⏲ 22:22 Watch on YouTube ↗

Summary

Local AI coding models now handle real production codebases for compliance-restricted developers, but they lag cloud frontier models in quality and speed, requiring extra context and task management.

Executive Summary

Local AI coding models have finally reached the point where they can work on real production-scale codebases, offering a crucial option for developers blocked from cloud AI by compliance rules such as ITAR, HIPAA, and IP protections. Testing Qwen-based local models against cloud frontier Opus 4.7 on codebases like Excalidraw and Warp showed that local models genuinely complete meaningful tasks—like adding features and fixing issues—but often with rougher UX, shortcuts, or architectural mismatches, while Opus produced cleaner code yet sometimes failed the actual requirement. Across harder tasks, neither local nor frontier models fully delivered a correct, polished solution; the local model even hit compilation errors it couldn't fix, while Opus built elegant but misaligned features. The narrator emphasizes that local models have improved dramatically in the past year and can be made more effective by providing richer context, breaking tasks into smaller steps, and treating them like frontier models from a year or two ago. Since local inference is at least five times slower, the recommended workflow is to run a dual-task approach—working on one feature while the model handles another, then reviewing its code—so developers can retain full control over their code, data, and IP.

Key Points

  • ▶ 0:11 Local AI has finally become good enough at coding to be used on real, production-scale codebases — not just toy projects.
  • ▶ 0:58 Many developers cannot use cloud AI at all because of strict compliance rules (ITAR, HIPAA, IP-sensitive work, finance policies), and approved workarounds like FedRAMP still require lengthy approvals or are outright unavailable.
  • ▶ 2:04 This video is for those stuck choosing between handwriting all code or running local models themselves — and for anyone who wants to retain control over their code, data, and IP.
  • ▶ 2:32 Two local models are tested: a large quantized Qwen-3-72B MoE (~80B total params, ~3B active) and a smaller dense Qwen-3.6-27B, both run locally via llama.cpp.
  • ▶ 3:00 Opus 4.7 serves as a cloud frontier baseline, but this is a reference point rather than a fair comparison since local models run on consumer/workstation hardware.
  • ▶ 3:37 Hardware is an AMD-powered system: Threadripper 9980X CPU, Radeon AI Pro R9 700 GPU with 32GB VRAM, 128GB DDR5 RAM, ROCm acceleration, and Ubuntu 26.04; the 27B model fits fully on GPU while the 72B requires llama.cpp MoE CPU offload.
  • ▶ 5:28 Each codebase was tested with an easier task that follows existing patterns and a harder task requiring deeper architectural understanding, starting with the Excalidraw TypeScript project.

  • ▶ 6:34 For the highlighter task, both Opus and the local model passed checks and looked visually identical, but Opus stored the highlighter as a semantic property while Quinn 3.6 used a shortcut with modified normal props, so the highlighter intent did not persist in the data model.

  • ▶ 8:56 Both models also got the five-pointed star working; Opus's implementation used star-specific geometry and passed TypeScript checks, but it stole the keyboard shortcut "5" from the existing tool.

  • ▶ 11:52 The narrator notes that local AI models have improved dramatically, and a year ago they "wouldn't have even come close" to handling this kind of task.
  • ▶ 11:56 Warp's entire Rust codebase was open sourced "maybe a month or two ago," making it a fresh, realistic target for testing local coding models.
  • ▶ 12:05 The narrator introduces the testing approach: Warp is a good test case, with the first challenge being "the easier task" to compare model performance on varying difficulty.
  • ▶ 12:36 Opus 4.7 produced polished, architecturally clean code with a confirmation dialog, but it implemented the wrong behavior: /clear history deleted the entire conversation instead of clearing just the pane's history.
  • ▶ 13:55 The other model (Warp 3.6) implemented the intended behavior more closely, clearing history by truncation, but the UX was rough—requiring a double Enter and not clearing the persisted conversation after restart.
  • ▶ 15:01 Bottom line: one model failed the actual task with elegant code; the other approximated the task with messier code—neither fully delivered a correct, polished solution.
  • ▶ 15:14 The task is to implement command bookmarks, where users right-click a previously run command to save it.
  • ▶ 15:30 This requires core changes to terminal history, context menus, left panel persistence, SQLite schema, and command execution.
  • ▶ 15:45 Opus 4.7 delivered all requested components, including a bookmarks module and sidebar panel, though the implementation is gated behind a feature flag.
  • ▶ 16:20 Right-clicking a command successfully bookmarks/unbookmarks, but no visible way to open the bookmarks side panel, indicating a UI/UX issue.
  • ▶ 17:01 Root cause: Opus created a new panel type instead of integrating with Warp's existing left panel state model, so the expected toolbar icon never appears.
  • ▶ 17:29 The implementation only inserts the bookmarked command into the terminal rather than rerunning it, partially missing the original requirement.
  • ▶ 17:52 Quin 3 Coder performed worse than the previous attempt, though it targeted the right general areas like persistence, terminal view, and action wiring.
  • ▶ 18:01 The result did not compile, with 47 unresolved errors including wrong Warp UI APIs, type mismatches, missing enum variants, and moved values.
  • ▶ 18:28 After repeated failed fix attempts, the model gave up, admitting the feature had compilation errors that needed someone familiar with the Warp codebase.
  • ▶ 18:57 Despite frontier models being better, the real focus is on local models like Qwen 3.6 27B, which genuinely got work done.
  • ▶ 19:33 Get better local results by giving richer context, breaking tasks into smaller pieces, and treating local models like models from one or two years ago.
  • ▶ 20:41 Local AI is at least 5x slower, so use a dual-task workflow: work on one thing while the AI handles another, then review its code.

Video Sections

  • ▶ 0:00 Introduction: Why Local AI Matters (0:00 - 2:32) - Local AI is finally viable for coding, and local models still matter despite cloud frontier AI.
  • ▶ 2:32 Setup: Models and Hardware (2:32 - 5:17) - The models tested, local hardware, and model serving setup are introduced.
  • ▶ 5:17 Excalidraw Tests: Highlighter and Star Tasks (5:17 - 11:56) - Local and cloud models are compared on highlighter mode and five-pointed star coding tasks.
  • ▶ 11:56 Warp Rust Tasks: Clear History and Bookmarks (11:56 - 18:50) - Local and cloud models take on real Rust codebase tasks, with mixed results.
  • ▶ 18:50 Results and Closing Thoughts (18:50 - 22:23) - The video wraps up with a comparison, tips for better local AI results, and final remarks.

Exact Transcript

Load the full timestamped transcript on demand and click any time to jump in the video.