I used local Qwen 27b to build a harness and replace OpenCode

Sharing my harness for running local LLMs that I built using Qwen 3.x 27B (> 90% locally built) under my supervision - not vibe-coded. Its free, no telemetry, and open-source (AGPL). Works on Windows, Linux (sorry, no Mac yet). I use it for my own coding + mixed workflows. How its different from others Just-in-Time code review before tool calls using guardrails make it easy to review code before edit is approved. Agents and user can both chat in sub-agent threads , making it a three-way chat. Also any chat conversation can be made into a sub-agent conversation for another main chat - nested conversations. You can annotate with voice dictation . Speaking is always faster than typing, hence more productive. You can compile llama.cpp from any git-hub branch - and use a recipe script to do so, making it a nice little automation with a customizable UI. Overall features Server Manager . Can run LLMs here and use with Open-Code/Claude Code etc. Built-in MCP Tools - Filesystem, web fetch, code graph, To-Dos, and more. Extensible by external MCPs. Use Sub-agents to split & offload your tasks, use other conversations as source of information. Review all AI messages using a second adversarial AI, and avoid potential pitfalls as per your rules. Voice-chat with AI - dictate with speech and get answers by TTS - annotate and comment without leaving voice mode. Use work-modes to change AI behavior between planning, building, researching, or reviewing. Fully customizable. Custom-compile llama.cpp backends for your system, GPU-agnostic - works with CUDA/ROCm/Vulkan. Website: warpdrv.ai GitHub: github.com/mikjee/warpdrv Appreciate your feedback, (or stars). Thanks :) And, yes - I used this harness to build this harness :D Which hardware was used : Strix Halo 128GB (FEVM FAEX1) + RTX Pro 5000 48GB --- Some things I observed & learnt through this experience - One chat per feature/bug - I keep conversations grounded to the current topic. If there are multiple topics, I make a separate chat for each rather than talk about it all in the same chat. Keeping the chat highly focused on one topic produces much better quality results. - Exploration takes a good chunk of time in large codebases - Initially I started by providing a description of the project and all its features in CLAUDE.md. But then I saw that the AI would struggle while exploring or preparing the list of relevant files to explore, leaving out important files, especially when planning for a new feature. So instead, I decided to include only a short description of the project, and not about all the features, additionally I appended a complete list of all the project's files and folders (by using a script to recursively generate a nested tree structure) in the CLAUDE.md file. This was far more useful in letting the model know upfront which files can be relevant, by their names and also provided an idea of the project just by the folder hierarchy. - Just like normal coding, starting is easy, but gets harder as the codebase grows - The decisions made upfront in the beginning matter a lot. Local development requires at the very least a watchful eye to guide or nudge the model in the right direction - full unattended "vibe-coding" is for Cloud models making apps that have little scope for growing beyond initial requirements. If your app is to be made for serious use at any level, senior-dev level coding experience is absolutely necessary. - Do not pollute your context - If you have a good overview of the codebase, I suggest you routinely reject file-read requests for files that the model thinks could be useful, but YOU KNOW are actually unrelated. Keeping the model contained within your well-knowing guidance can avoid a lot of unnecessary exploration. - Fix bad practices upfront - Bad code, anti-patterns are always carried over. If you leave a bad code pattern and accept it as a tech debt, the model will read that and use it again. Models tend to follow established codebase patterns, and that one bad code that you accepted as tech-debt will multiply to every new feature you build. - Aim to increase productivity - Coding using AI requires a fine balance between autonomy and control. More autonomy degrades code quality, whereas more control requires more of the human's time. Always review edits before they are made. Better, use a Just-in-Time review. I created guardrails feature for this very purpose - I can give it specific instructions and it will form a layer between an edit request and me approving the edit. Also breaks the bad habit of sub-consciously clicking 'Allow' as a reflex. --- Let me know what you think of the project, and your own experience with using Qwen locally. Thanks :)