Codebase getting larger - Qwen3.6-27B starting to compound issues - how to work smartly with this model?

Reddit r/LocalLLaMA News

Summary

A developer reports that using Qwen3.6-27B for vibe coding introduced subtle bugs in their codebase and asks the community for best practices to reduce errors when working with the model.

I had initially hand coded a small chat bot to interact with llama server with tool usage. But then started vibe coding with Qwen3.6-27B and was blown away. Obviously I added a ton of features since then and the codebase has blown up in size. But I'm now noticing that there are a lot of tiny tiny bugs in the code that I'm having to review manually and fix. Things which should have been obvious (to a junior dev I feel). Thank goodness I'm doing this in Python which I have many years of professional experience. But this lead me to thinking that maybe I'm not using it correctly. Maybe there is a better way to use this model. My approach so far has been: 1. Start pi 2. Prompt - "Read the current project". This takes up about 50% of the current available context (out of 128K) 3. Implement this feature or Fix this bug. 4. Context hits 80% or above, run /compact. But after seeing all these bugs, I'm tracing through the code trying to patch one by one. I use a new conversation for every change, and instead of reading the entire workspace, I ask it to focus on exact functions or even lines ex: lines 670-650. And then ask it to read and confirm specific bugs and fix them exactly how I want them. I have also removed all kv quantization in hopes of mitigating the bugs. This is the command I'm using now (My specs are 5090 w 64GB RAM) /home/lenny/myp/llama.cpp/build/bin/llama-server \ -m ~/myp/models/unsloth_mtp_Qwen3.6-27B-UD-Q5_K_XL.gguf \ --temp 1.0 --top_p 0.95 --top_k 64 \ -c 131072 -t 16 -ngl 99 --flash-attn on \ --host 0.0.0.0 --port 8080 \ --spec-type draft-mtp --spec-draft-n-max 4 --parallel 1 Obviously this is now taking a lot more time to build and debug features. **My question is - are there other approaches I can take to minimize bugs when using this model?** PS: Example bug: There's a feature to schedule a task at a specific time or recurrence. This takes execution\_time as a param. The bug I found goes like this: try: parse time in UTC. except: logging.error("failed to parse") Insert into DB which should have been: try: parse time in UTC. except: logging.error("failed to parse") return "Tool call failed - incorrect time format" Insert into DB I now have 1000s of lines of code which may or may not have such issues ready to happen at any time.
Original Article

Similar Articles

Is anyone getting real coding work done with Qwen3.6-35B-A3B-UD-Q4_K_M on a 32GB Mac in opencode, claude code or similar?

Reddit r/LocalLLaMA

A user shares their experience running Qwen3-35B-A3B quantized model on an M2 MacBook Pro with 32GB RAM for coding tasks via opencode and llama.cpp, finding that the 32K context window limit causes critical memory loss during compaction, making complex coding tasks impractical. They conclude that meaningful agentic coding with this model likely requires at least 128K context, exceeding what their hardware can support.

Qwen 3.8 27b is strong even at Q3_xxs

Reddit r/LocalLLaMA

The user finds Qwen 3.8 27b in Q3 quantization highly effective for coding tasks with fast inference speeds, outperforming previous models, despite minor issues in general conversations.

Qwen3.6-27b does not understand software architechure.

Reddit r/LocalLLaMA

A user reports that Qwen3.6-27b fails to grasp software architecture concepts for large-scale projects, producing unmaintainable spaghetti code and ignoring best practices, and requests SKILL.md files to improve its code generation.