How Local AI Can Edit Code Directly: Tools, Models, Hardware, and a Practical Guide

🛠️ Cline: The Easiest Place to Start

• Cline can read project files, search the codebase, apply patches, create files, and run terminal commands. For a task such as “add a Remember Me option to the login flow and run the tests,” it can inspect the front end, authentication logic, and API, then revise the implementation based on the results.
• Plan mode is suitable for researching problems and designing solutions first, and then Act mode will actually implement them. If the Agent only analyzes but does not modify the files, first confirm whether it is still in Plan mode and whether the "Edit project files" permission has been turned on.
• Auto Approve lets the agent work continuously, but it also increases the risk of file changes and terminal commands. Keep manual approval enabled at first, then gradually allow low-risk operations after the model behaves consistently.
• Run Cline CLI from the project directory, for example: cline "Check the project and fix failing tests". It provides a Codex- or Claude Code-style terminal workflow while retaining Cline's agent capabilities.

🧰 Roo Code: More flexible permissions and roles

• Roo Code groups its capabilities into read, edit, command, and MCP tools, covering file access, shell execution, and external integrations while using a local model.
• It is very close to Cline's basic capabilities. If you prefer to use it out of the box, you can choose Cline first; when you need more detailed mode, permissions and role settings, Roo Code is usually more convenient.
• Start either extension with a small test. Once the model calls tools reliably, move on to a real repository and multi-file changes.

🧠 Continue: A Full Local Copilot Alternative

• Chat mode is used for conversations, Plan mode reads and analyzes projects, and Agent mode has complete tools for creating files, modifying files, and running terminal commands.
• Continue can assign different jobs to different models: a lightweight model for autocomplete, a larger model for agent tasks, and a separate embedding model for code retrieval.
• Some Ollama models claim to support tool use but still fail in Agent mode. Check the model's capability declaration, provider configuration, and whether tool_use is enabled correctly.

🧩 VS Code Native Agent: A Successful Connection Does Not Guarantee Stable Tool Use

• Local models can participate in VS Code’s Chat and Agent workflows, but tool invocation, reasoning, and visual capabilities depend on the specific model. Being able to chat normally does not prove that it will call Edit File.
• If you ask it to edit login.ts and it only prints replacement code without changing the file, the current setup is still functioning as a chat assistant.
• When the local BYOK model is used for agent-style modification, it will not automatically replace VS Code's native tab completion. If you want to keep the completion locally, you need an extension such as Continue that can connect to the local Autocomplete model.

🧪 Codex + Ollama

• Install Codex CLI with npm install -g @openai/codex, then run ollama launch codex. You can also use codex --oss to select a local model.
• Once launched inside a project directory, Codex operates directly on that repository, so you can use any editor. Codex App can also connect through ollama launch codex-app if you prefer a graphical interface.
• Agent sessions include tool definitions, project code, command output, and action history. A context window of roughly 64K is a sensible starting point.

🧭 Claude Code + Ollama

• Run ollama launch claude to connect the Claude Code agent shell to Ollama, or use claude --model qwen3.5 to select a local open model.
• Agent program and model source are two different things. Using Claude Code's project operation capabilities does not necessarily mean that you are calling Anthropic's cloud Claude model.
• Because file contents, tool definitions, and multiple debugging rounds all consume context, configure at least about 64K when the hardware allows it.

🌐 OpenCode, Copilot CLI and Cline CLI

• Use ollama launch opencode for an open terminal workflow, or ollama launch copilot to let Copilot CLI use a model served by Ollama.
• Terminal Agent is especially suitable for Linux, SSH and server environments. As long as you enter the correct project directory, it can read the repository, modify files, and execute tests independently of the editor.
• Don't just look at the name when choosing a tool, check whether it also has Read File, Edit File or Apply Patch, Terminal, Tool Calling and Agent Loop.

📏 Parameter Count and Real Agent Capability

• Models in the 3B–4B range behave more like advanced code completion and are poor choices for complex agent tasks. Models in the 7B–9B range can edit individual files, add small features, and fix simple bugs, but long loops remain unreliable.
• At about 14B, models begin to deliver meaningful productivity. The 24B–30B range is especially important for local coding agents because it can handle repository understanding, multi-file edits, debugging, refactoring, and test loops more seriously.
• Just because the model can write code does not mean it can be an agent. Real tasks also require it to choose the right tool, fill in parameters, analyze tool output, maintain long-term goals, and judge when to stop, so Agentic Coding ability is more important than a single code benchmark score.

📚 Do Not Choose a Context Window by Its Advertised Maximum Alone

• An agent's context contains the system prompt, tool definitions, the request, project files, terminal output, Git diffs, and previous actions. An 8K window may be enough for chat, but 32K is a more realistic starting point for a coding agent.
• Cline and Roo Code can start at 32K. Long-running terminal agents such as Codex, Claude Code, and OpenCode are better served by 64K or more. Increase it further only for large repositories or broad refactors.
• A model's advertised 256K limit does not mean you should immediately set num_ctx to 262144. Larger windows increase KV-cache use and can exhaust VRAM or RAM, reduce speed, and delay the first token.

🗜️ How to choose between Q4, Q5, Q6 and Q8

• Q4 is more heavily compressed, producing smaller files and lower VRAM requirements, usually with faster inference but a modest loss in quality. Q8 stays closer to the original model but consumes substantially more RAM and VRAM.
• Q4_K_M is a practical starting point for a local coding agent. Loading the entire model with a useful context window is usually better than choosing a higher-precision quantization that repeatedly runs out of memory.

🎮 Why VRAM Comes First

• Performance is usually best when the entire model fits in VRAM. If it does not, some layers spill into system RAM. The model may still run, but transfers between CPU memory and the GPU can slow every step of the agent loop.
• Pure CPU operation is not completely unfeasible, but the Agent will request the model multiple times in a row for one task. Waiting tens of seconds for each step can make debugging, testing, and fixing processes unwieldy.
• A 19GB Qwen3-Coder 30B Q4 file does not leave a guaranteed 5GB free on a 24GB GPU. The KV cache, runtime, and context all require additional memory; 32GB or 48GB of VRAM provides more headroom.

💾 How to Prioritize RAM, SSD Capacity, and CPU

• 64GB of RAM is much more comfortable for sustained development because Windows, VS Code, browsers, Docker, Node.js, databases, Ollama, and development servers all compete with the model for memory.
• Individual model files commonly occupy 6GB, 15GB, 19GB, or far more. A collection can quickly consume hundreds of gigabytes, so use at least a 1TB SSD; a 2TB NVMe drive is better for long-term use.
• Of course the CPU is important, but when you're on a budget, it's usually not worth dropping 24GB of VRAM to 16GB for a small CPU boost. For local large models, GPU memory has higher priority.

🍎 How to choose unified memory for Apple Silicon

• Apple silicon uses unified memory shared by the CPU and GPU, so the usual PC split between system RAM and dedicated VRAM does not apply. A 16GB Mac is limited to smaller models, while 32GB can run a model such as Devstral 24B Q4 more seriously.
• With 64GB of unified memory, a Mac is well suited to local coding agents in the 24B–35B range. A 128GB model supports larger models and longer contexts. High-unified-memory Macs are especially attractive if local AI matters more than gaming.
• As a rough guide, pair about 8GB of VRAM with a 16K context, 16GB with 32K, and 24GB or more with 64K. Actual usage varies by model architecture and quantization.

1️⃣ Install the Runner and Download a Suitable Model

• Install Ollama, then choose a model that fits the hardware. With 24GB of VRAM, try ollama pull qwen3-coder:30b or ollama pull devstral-small-2:24b. On a smaller GPU, start with ollama pull qwen3.5:9b.
• If you prefer a graphical interface, LM Studio makes it easy to find, download, and load models. Ollama is generally more convenient when coding agents and automation are the primary goal.

2️⃣ Install Cline and Connect It to Ollama

• Install Cline in the VS Code extension store, enter Settings, and set the API Provider to Ollama.
• The local endpoint is usually http://localhost:11434. Select the model you downloaded and give the agent a reasonable context window.
• Do not enable automatic approval for every terminal command at first. Start by allowing project reads, workspace edits, and explicitly safe commands.

3️⃣ Verify the Agent Pipeline with a Minimal Test

• Create test.txt containing hello. Tell the agent not to print the replacement text, but to edit the file directly so it contains hello world.
• If the file changes, the edit tool worked. If the model merely says that it “should be changed to hello world,” the mode, permissions, model, or tool configuration still needs attention.
• Next, ask it to create hello.py, run the script, and confirm the output. Creating the file, executing it, and reading the result verifies the file tools, terminal tools, and tool-calling pipeline.

4️⃣ Move On to a Real Software Task

• Choose a small or midsize project with tests or a reliable build. Ask the agent to find and fix TypeScript errors, run npm run build, and continue until the build succeeds.
• State the goal, allowed scope, required verification commands, and stopping condition. That produces more stable results than a vague request such as “help me fix it.”

🐛 Bug Fixes and Build Errors

• If login state disappears after a page refresh, the agent can search the authentication code, inspect localStorage and token handling, edit the relevant files, and run tests.
• When npm run build reports several errors, the agent can read them, find the affected files, make changes, rebuild, and repeat until the build passes. Tasks with objective feedback are where agents add the most value.

🧱 Add Features and Modify Multiple Files

• When adding a bookmarking feature to a blog, an agent can update the database, API, backend, frontend, styles, and tests instead of generating one isolated function.
• Define the data structure, user flow, compatibility requirements, and acceptance commands so the agent can stop based on verifiable results rather than a subjective judgment.

♻️ Refactoring, Dependency Upgrades, and Test Loops

• When splitting a 2,000-line Python file, the agent can analyze dependencies, create modules, move functions, update imports, and run tests continuously—provided the project already has reliable test coverage.
• For a React upgrade, it can update package.json, install dependencies, replace deprecated APIs, and verify compatibility through builds and tests.

🔍 Understand Unfamiliar Repositories and Build Projects from Scratch

• In an unfamiliar project, ask the agent how to start it, where login is implemented, where the database is initialized, and how requests flow through the system. Repository search and cross-file analysis are often faster than reading every file manually.
• For a new personal-finance app, the agent can create the directory structure, frontend, backend, database, and API, then launch the project and fix errors. A developer still needs to choose the architecture and review the security boundaries.

❌ The Model Cannot Use Tools Reliably

• The model must select edit_file, read_file, or a terminal tool and supply the correct path and parameters. A model that only produces natural language can offer suggestions but cannot perform the edit.
• Small models often become confused by many tool definitions, project files, conversation history, and complex requirements. Even a 3B or 7B model that nominally supports tools may fall back to plain-text answers during a long task.

🔧 Incorrect mode, permissions or provider configuration

• Chat and Plan modes usually do not perform real modifications and should be switched to Agent, Act or Code mode. No matter how smart the model is, it cannot write to the file when editing permissions are turned off.
• Confirm the Ollama endpoint, model name, context window, and capability declaration. Some integrations require an explicit tool_use capability; without it, the model may never receive the available tools.
• Do not use a complex repository as the first diagnostic target. The test.txt hello test quickly separates a tool-use problem from a project-understanding problem.

🔁 The Agent Repeats Itself or Loses the Goal on Complex Tasks

• A local 9B model may choose the wrong file, repeat an action, fix one bug while introducing another, or lose the original goal during a long loop. A complete toolset does not make it as capable as the strongest cloud models.
• Break large requests into small, verifiable tasks. Limit the directories or files it may edit and require tests at each stage; this is more reliable than asking it to “refactor the entire project” in one pass.
• When the context begins to accumulate irrelevant logs, it is more effective to reopen a focused task than to blindly expand the context window to the maximum.