Local LLM development is about control, not cleverness
Local LLM development is the practice of running large language models directly on a developer’s own machine, wired into their filesystem and tools, so they can read, analyze, and edit entire projects without sending code or documents to remote cloud servers.
The industry conversation around AI coding has obsessed over model quality and benchmark scores, but that misses the real shift: developers are moving work from cloud AI assistants to local LLM tools because they want control more than cleverness. Claude Code’s story proves how powerful a well-integrated cloud assistant can be. It began as a command-line tool that required people to change their workflow, and “you had to want it, find it, install it, and change your working pattern around it”. Once it showed up as a native extension inside the dominant editor, it exploded in use. Yet even with that success, a growing slice of developers now default to local LLM setups when the work touches sensitive codebases, knowledge vaults, or personal folders.
Claude Code won distribution, but not everyone’s trust
Claude Code’s rise shows how fast an AI code assistant can become routine once it lives where developers already work. After Boris Cherny, a former Meta engineer, took over Claude Code in September 2024, Anthropic launched it publicly in February 2025 alongside Claude 3.7 Sonnet. The crucial shift was moving from a terminal product to a native Visual Studio Code extension, so “developers who had ignored the CLI could now treat Claude Code as another part of the editor” rather than a separate habit to remember.
That bet paid off in usage. According to figures from SemiAnalysis, Claude Code was tied to roughly 135,000 public GitHub commits a day in early February 2026, about 4% of the public commit stream, with a single March day hitting 326,731 commits. Those numbers prove cloud assistants are compelling when they are convenient. But they also hide a quieter resistance: many developers will not feed certain codebases, internal documents, or personal archives into a system where every file is streamed to a third-party server for processing.
AI code assistant privacy: why local beats the cloud
The cloud model has a structural privacy problem. By design, every file a tool like Claude Code touches “gets read into the conversation and sent to Anthropic's servers as part of that session, which is how it works and how any cloud tool has to work”. For generic code folders, many developers accept that tradeoff. For a folder of tax paperwork or medical PDFs, “the arrangement gets a little harder to love”. This is the heart of AI code assistant privacy: the smartest suggestion is not worth the queasy feeling of streaming your life to someone else’s GPU cluster.
Security worries sharpen that discomfort. There has already been at least one reported prompt-injection exploit against Claude’s Code Interpreter path. The incident should not be exaggerated, but it “reinforces the case for keeping personal folders local”. The result is a growing rule of thumb among privacy-conscious developers: some files are probably best kept on your own hardware, even if that means giving up a bit of speed or sophistication. Local LLM development turns from a fun experiment into a policy decision.
Filesystem access coding tools turn local LLMs into real coworkers
Most people who tried local LLMs started with a simple pattern: open a chat window, drop in a file, get a response. Helpful, but limited. The turning point is filesystem access. A filesystem MCP server gives whatever model you are running tools for “actually touching files inside a folder you specify. Reading, writing, editing lines with diff previews before anything commits, moving, renaming, searching, pulling metadata, listing the directory tree, the list goes on”. In other words, the model can read your whole project, understand its structure, and propose concrete edits instead of commenting from the sidelines.
This is implemented through the Model Context Protocol (MCP), exposed by a small Node.js server published as @modelcontextprotocol/server-filesystem and maintained by Anthropic’s MCP team. Point it at a directory and it becomes a sandbox: the model only sees that path, but within it, it can rewrite markdown notes or YAML frontmatter, refactor config files, or bulk-update an Obsidian vault with new templates. Before adding filesystem MCP, one user described their local model as “a chatbot in a box”; once enabled, “the same models” turned into agents that “actually do things on my disk”.
Why developers now reach for local LLM tools first
Once filesystem MCP is in place, local LLM tools become a credible Claude Code alternative for many day-to-day tasks. Claude Code has become the tool many people reach for to handle work that “isn't really coding,” from renaming files in bulk to cleaning up markdown notes or organizing messy folders. But when every touched file is streamed to a cloud provider and potentially retained for thirty days or five years depending on settings, the defaults begin to flip. For one user, “the privacy thing is where I want to start because it's the one that actually changed my defaults”.
With MCP configured in tools like LM Studio via a single mcp.json edit and restart, or enabled in other local environments, developers find that many tasks no longer justify calling out to the cloud. Model choice matters—tool calling is a specific skill and families like Qwen 3.5 9B or Gemma 4 handle multi-step sequences well—but they do not need to beat frontier cloud models to win. For “look at this folder and tell me what's in there, then sort it into categories,” a local model with filesystem access does the same job at zero cost, data transfer, or rate limits. Control and data sovereignty outweigh raw model quality for these privacy-conscious workflows.
