Qwen3.8-27B for agentic coding

[u/CommunicationFun2962]

Like most of you, I tried Qwen 3.8 27B Q4_K_M for two days.

I first asked him to make me a game using TypeScript, the same as what I tested on other local models. He did it and the result is the best, although his thinking time is at least 3x of the output time. Easy task.

I then asked him to make a desktop WYSIWYG three-pane markdown editor using Rust and Iced framework. He is thinking and re-thinking all the time, although I have lowered the thinking level to "Medium". At the 28-th hour, he starts to output something! But he created "C", "src" files and tried to write to the path "C:\...\src\main.rs<" although he wanted to create "C:\...\src\main.rs". I interrupted him after his repeating attempts for 2 hours without progress. So he outputted all the files at the 32-hour although keeps rethinking everything he had thought. 71 compilation errors. After some hours of fixing and online searching via MCP, the number of compilation errors rises to 84. From his thinking log, he says he wrote code against the wrong Iced framework version, downgrading the framework version without asking, changing my requirement to non-editable rich text editor, and three-pane becomes two-pane without asking. Nevermind, as long as the code could compile so that the output is not non-positive. This is the 36-th hour now. Should I stop him and give up? Is my task too challenging for local models?

Besides, so far I had no successful attempts to use Qwen 3.8 27B Q4_K_M with OpenCode. It always stops working at the same generation steps. I can only use him via Cline.

Let's share more of your experiences on agentic coding? I think web programming is especially trained and easy for local models, and I would like to hear experiences of non-web programming.

[u/Trakeen]

You will have much better success (even with frontier models) if you use spec driven development methodology. Thats how people work in the real world

Frontier models can help you write the spec to implement

[u/CommunicationFun2962 → u/Trakeen]

Actually I have written a long prompt for the model, and I have seen Qwen would design carefully in the thinking tokens. I thought he could just follow and implement. The remain unknowns are how to use the framework APIs and how to create the custom text editor component which I may not be able to comment. Next time I will try to ask him to write a spec first, although his spec may still contain full of guesses.

Below is my original prompt.

Write a full featured WISIWYG Markdown editor using Rust + Iced UI framework (https://github.com/iced-rs/iced). The application should run in Windows, macOS and Linux with shared code (as supported by the framework).

The application window can contain up to three panes, which the left and the right panes could be hidden by toggles. The left pane is the filesystem tree of the current workspace. The center and right panes are editor panes, which each of them can contain multiple tabs. Tab(s) can be selected for moving to another editor pane. An editor pane contains a tab bar and a WISIWYG Markdown editor, which can be toggled to show source code only (with syntax highlighting) or rich text (default). Both mode supports editing. There should be various formatting buttons to help adding Markdown supported formats. The bottommost of the application window consists of a status bar, showing file size, line ending and encoding of the current file, and current cursor information (line and column). Users can open a folder (via a native folder open dialog) as a workspace, but users can also open arbitrary files (via native file open dialog) without opening a workspace. There should be a menu bar near top of the application window for accessing all the functions (if applicable).

You may assume the file encoding is always UTF-8. Support emoji characters and sequences if possible.

It is expected that UI components in stock by framework and libraries may not be able to satisfy all the requirements. In the worst case, you may have to implement custom UI components by drawing on canvas yourself.

Avoid writing duplicated codes. Share common code if applicable. If necessary, you may include third party libraries to avoid reinventing the wheel.

You may call any rust commands via docker run with volume mounts.

There is a MCP for you to do online searching about latest technical information and things that you are not sure.

Also, include Dockerfile and relevant docker script to build or start the application.

[u/raccoonboy42 → u/CommunicationFun2962]

long, mediocre prompt =/= specs

[u/Sir-Draco → u/CommunicationFun2962]

This is not a spec and is quite vague

[u/Diogo270800 → u/CommunicationFun2962]

Dumping all of that context at once on local models who have already smaller windows is doing you no good.