A software developer spent a week replacing Anthropic's Claude with a local 9-billion-parameter model and discovered that smaller, on-device AI can handle the vast majority of real-world coding work, though some complex debugging tasks still favor cloud alternatives. The experiment reveals a growing viability gap: local large language models (LLMs) are becoming practical for everyday development, but they have distinct limitations that matter when the stakes are high.

What Worked: Local Models Handle Most Development Tasks

Anurag Singh, a tech journalist who tested Qwen 3.5-9B on an M5 MacBook Air with 16 gigabytes of RAM, found that the local model excelled at the tasks that consume most of a developer's day. The model successfully fixed a login bug that prevented one-time passwords from being sent, added a feature to export results as a report, and wrote Home Assistant automations without requiring manual coding. These weren't toy experiments; they involved working with existing applications and required the model to understand context across multiple files.

Tool calling emerged as one of the model's strongest capabilities. Qwen 3.5 was specifically trained to select tools, format function calls correctly, process outputs, and continue working through multi-step tasks. When paired with coding harnesses like Hermes or Codex, the model performed agentic work reliably. Singh also used the model to examine server logs and flag issues that required attention, a task that would normally require manual log review.

The model's native context window of 262,144 tokens (roughly equivalent to processing 100,000 words at once) gave it enough room to work with large codebases, though running the full context locally requires considerably more memory than the 16 gigabytes Singh had available.

Where Local Models Still Stumble: Complex Debugging and Refactoring

The experiment revealed two critical failure modes where Qwen 3.5-9B fell short of Claude's performance. The first involved refactoring code across multiple files. Singh wanted to move report-generation logic from an API route into a shared service so both the website and background jobs could use the same code. Qwen created the new service and updated the main route, but it failed to follow the old implementation through the rest of the project. A background job still imported the original function, tests expected the old arguments, and frontend types no longer matched the response. The model fixed each error as it appeared but then introduced another one elsewhere.

The second failure was more revealing about how local models approach problem-solving. A report remained stuck on "Processing" even though the background job had finished. Qwen initially treated it as a frontend problem and changed the polling logic. The problem persisted because the status endpoint was returning a cached response. Even after Singh showed the model logs confirming the report had been generated, it continued editing the frontend component rather than tracing the request through the API and cache.

"The tasks where Qwen 3.5 failed are what Claude does the best. It's more likely to question its first diagnosis, inspect a different part of the stack, and work backward from the evidence instead of continuing with small variations of the same fix," Singh noted.

Anurag Singh, Tech Journalist

How to Evaluate Local Models for Your Development Workflow

• Assess Your Hardware: Qwen 3.5-9B ran on an M5 MacBook Air with 16 gigabytes of RAM, making it viable for developers with modest hardware. Smaller models (7 billion parameters) work on 8 gigabytes, though performance improves with more memory and GPU acceleration.
• Test Tool-Calling Capability: If your workflow involves agentic tasks, code generation, or multi-step problem-solving, verify that the model you choose was trained for tool calling. Qwen 3.5 specifically supports this; not all open-weight models do.
• Identify Your Failure Tolerance: Local models excel at straightforward coding tasks but may struggle with complex refactoring across multiple files or debugging that requires working backward from symptoms. Determine whether your work can tolerate occasional rework or whether you need the reasoning depth of larger cloud models.
• Measure Real-World Productivity: Rather than relying on benchmark scores, test the model on actual tasks from your SaaS tool, personal projects, or development pipeline. Singh's 95% productivity rate came from real work, not synthetic tests.

The Economics of Local AI for Developers

Running a local model eliminates per-token billing entirely. Cloud-based AI services like OpenAI and Anthropic charge for every prompt and response, costs that accumulate quickly for developers running automated pipelines or iterating rapidly on code. LM Studio, a free desktop application for running local LLMs, serves models via an OpenAI-compatible API on localhost, allowing developers to prototype AI-powered applications without cloud costs during development.

LM Studio supports a range of open-weight models including Llama, Qwen, DeepSeek, Mistral, and others, all available as quantized GGUF or MLX files that run efficiently on consumer hardware. The application handles model discovery, download, inference configuration, and API serving in a single interface, eliminating the need for command-line configuration. A developer can go from zero to a running local LLM with an accessible API in under 15 minutes.

For professionals and students, this means prototyping AI applications locally before committing to cloud deployment, testing models against real workloads, and maintaining data privacy without sending code or logs to third-party servers. The trade-off is clear: local models are faster to iterate with and cheaper to experiment with, but they may require fallback to cloud models for tasks requiring deeper reasoning or multi-step debugging.

What This Means for the Local AI Ecosystem

Singh's experiment demonstrates that the local LLM ecosystem has matured beyond hobbyist experimentation. A 9-billion-parameter model running on consumer hardware can handle real SaaS maintenance, feature development, and automation tasks. The 95% productivity rate suggests that for many developers, local models are now a viable primary tool rather than a fallback option.

However, the experiment also confirms that local models have distinct cognitive limitations. They excel at tool use, code generation, and straightforward problem-solving but struggle with the kind of multi-step reasoning and error recovery that larger models like Claude provide. The practical implication is that developers may adopt a hybrid approach: using local models for rapid iteration and cost-free experimentation, then escalating to cloud models for complex debugging or architectural decisions.

As open-weight models continue to improve and hardware becomes more capable, the boundary between "local model" work and "cloud model" work will likely shift. For now, developers considering the switch should test their specific workflows rather than relying on benchmark scores or general claims about model capability.