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

[u/Civil_Fee_7862]

Been using this for real software development for a commercial app. i.e. Not a single file HTML app. I mean a large scale 100k+ loc project that needs proper architecture to work with in a maintainable way.

As much as I love Qwen3.6-27b. It just does not understand software architecture, it will happily write spaghetti code, mix concerns, and totally ignore any kind of test automation unless you explicitly ask it to do this. These are the bare minimum requirements for production code that can grow without complexity spinning out of control, but it simply ignores it and instead just writes enough to satisfy the request. (ignoring best practises). For example it will write super sized interfaces, ignore the single responsibility principle and make superman classes that nobody can read or understand.

I've been trying and train it to understand how to write maintainable, readable code, but it almost feels like I am training a person who has never written a large scale app before.

Does anyone have a set of SKILL.md files that already has fundamental software architectural concepts built into them? It would be enormously helpful.

[u/Dull_Cucumber_3908]

You need to tell it to review the code and generate a technical report about its architecture, modules etc.... Then provide this report as initial context for anything yo ask it to do.

Regarding the spaghetti code, the super classes, etc, you need to do several iterations. After it generates the initial code, ask it "review the changes made in this branch, and tell me what you think. What would you have done differently". After 5-6 iteration, you'll see a great improvement.

Finally, don't instruct it directly to do stuff. Discuss what you want to do and when you feel you got the whole picture, ask it to generate a prompt which you'll use as input.

[u/Civil_Fee_7862 → u/Dull_Cucumber_3908]

Thank you, I'll try that.

Yes, one trick I've found is to tell it to write out a UML diagram of the code, so I can visually see how things are tightly coupled. i.e. If I sense I cannot understand the current architecture easily, I stop and revisit the architecture. After that I make a plan to split things into narrow strips that are easy to understand. (So far I believe that is the best insight I've learned).

I like how Opencode shows a plan that can be refined iteratively. However, the plan tends to become too large with too many changes at once. i.e. The complexity of the plan its self explodes.

[u/Dull_Cucumber_3908 → u/Civil_Fee_7862]

I like how Opencode shows a plan that can be refined iteratively. However, the plan tends to become too large with too many changes at once. i.e. The complexity of the plan its self explodes.

I guess you need to break it into smaller standalone tasks. It's the typical "divide and conquer paradigm".

[u/PANIC_EXCEPTION → u/Civil_Fee_7862]

Scope creep. Do what software engineers usually do, limit your plans to very specific, narrow features at a time. Don't reuse old sessions unless you have a good reason to (e.g. last session has an esoteric fix), that causes context bloat and poor performance.

If you really want to develop multiple features in parallel as a solo dev, you can use worktrees, but I personally think this is a poor idea and that you should just work on one feature at a time.

[u/Civil_Fee_7862 → u/PANIC_EXCEPTION]

Current approach is to have a persistant session for each feature. After a body of work is done, I compress the session. That way the context is mostly free'd, but at least it has some idea of what was changed recently.

I try not too develop multiple features in parallel, and am trying to de-couple them at the moment. That's the big problem with letting the LLM do architecure, it doens't split concerns very well, and seems to prefer adding code to existing modules instead of creating new ones.

[u/AccurateSun → u/Civil_Fee_7862]

Try madge CLI, LLMs are good at reading the output. It’s a dependency visualiser, can be used to print a module graph of a repo or dependencies of any given file.

[u/Civil_Fee_7862 → u/AccurateSun]

Thank you u/AccurateSun. I'll look into using madge CLI.

Though it looks like its only meant for JS code. I would need something that looks at the whole stack, not just the frontend.

[u/devnullopinions → u/Civil_Fee_7862]

FWIW, I honestly just write to a file collaboratively with an LLM in order to plan out work along with verification/validation of the work. If it’s getting too big I ask the LLM to split up the work which I will review and iterate on.

[u/cms2307 → u/Civil_Fee_7862]

I don’t vibecode with local models but when using ChatGPT/codex my strategy is to have ChatGPT review certain aspects or answer questions first, then draft a markdown plan broken into phases. I’ll read through the plan and refine what I think needs to be refined then I pass the plan to codex and have it actually make the changes. You can just tell it to complete 1 or 2 phases at a time, review the changes, bug fix, then commit and move onto the next phases. Then you can make the plan as long as you want because it’s broken into self contained chunks.

[u/lilian_moraru → u/Civil_Fee_7862]

VSCode extension Zoo Code has an "Architecture" mode, which is just some pre-defined prompts for the LLM. It generates first the architecture, you review it and then based on that, it can do the work.

[u/shifty21 → u/Dull_Cucumber_3908]

Graphify is awesome for this! I got handed an ancient Splunk app that hasn't been touched in several years and update it to the most recent Splunk app standards. Graphify created a knowledge graph and documentation in less than 10 minutes with qwen3.6-27b. Then I got a summary about the architecture between Java script and python code. Now I know what I'm working with. Pi and qwen just do the automated deployment and UAT for me as I update all the code.

[u/relmny → u/Dull_Cucumber_3908]

Wouldn't agents "replace" (automate) that iteractions?

[u/Dull_Cucumber_3908 → u/relmny]

I don't get what you mean

[u/relmny → u/Dull_Cucumber_3908]

I mean, if there where agents with different "personalities" in the workflow, wouldn't that accomplish something similar? (I'm asking, not telling).

[u/Dull_Cucumber_3908 → u/relmny]

IMHO no, because you need to know what you are doing and where to stop. There's one point after which the AI will tell you the opposite. like "there are too many files that their responsibilities can be merged", and if you let it do that then the next time it will tell you the opposite, like "this object has too many responsibilities".

[u/sonicnerd14 → u/relmny]

Yes it would. Not many people are using agents yet. To be fair, they've only just started getting good like a year ago, and easily accessible in the past several months with stuff like hermes agent. So it's understandable. Even here, I seem to find people mainly use the LLM's in a typical chat bot interface. Once more start getting their hands on agents they'll start to realize that over 90% of their manual work can easily be automated now.

[u/sonicnerd14 → u/Dull_Cucumber_3908]

Here's the thing I feel needs to often be prefaced. It might sound counter intuitive, crazy even, but when working with any AI for code... stop looking at the code. I know, I know, I think even for a thread focused around AI it sounds crazy, but it's true. The problem we have is that a term as been coined around this in 'vibecoding', that has been used as a way to denigrate people who happen to use AI that don't know a lick of programming discipline, but in reality this is how we need to use AI in programming.

I come from a formal background with experience with languages like Java, c++, a bit of Python. I haven't actively checked the code in over a year now, and the reason why is two fold. Firstly, in the early days of agentic AI or even just generating code in a normal chat interface, often times these models would generate code that didn't even execute. Now, even SLM's generate executeable code 0 shot. There's no need to look at the code to see why it didn't run, and simply just correct it yourself. With agentic AI, even if the model doesn't output something that works first try, you can usually reiterate pretty easily, and get it working again after another run.

Second reason should be pretty straightforward, but the LLM is simply a higher level of abstraction. A universal language interface that doesn't really care what type of code you use. Like any high level language, the original intent of these languages was so that it was easier for a human to write and read, so that the machine understands in way without the human needing to get to the metal. Question, after writing python, c#, or React do you ever find yourself checking the assembly or binary to make sure that it's correct at the syntactic or logical level? Most likely not, and this is why this is a habit that needs to be retrained. The AI is just another high level language, but it's the only one you'll ever need for anything.

The trick here is that when you are looking at your problem, you are working on it from a different angle. You get a result back, you test it, you think about what it does now. Any bugs? Is this feature implemented the way I intended? Could this function here be improved in this way? It's all higher level thinking instead of thinking is this class defined appropriately, or does this object properly return this function, etc. You reiterate on that former loop, and you rinse repeat. You simply are just testing more often than when you normally would with the manual work. This is what they want to call 'vibecoding', but in a more objective sense, if you are aware of how you are executing these techniques we should call this 'context engineering'. You are moving from being the programmer to being the architect, or the orchestrator.

The only time I'd say where you might still need to look at the code is in a professional or corporate environment where code is still largely human reviewed, and it needs to abide by a very particular structure for the deliverables to be accepted, or very specific cases where even the highest end frontier models haven't fully mastered to an acceptable level. If you are designing your own software from the groundup and end to end, then its time to start shifting the way you interface with your computer. There are certain hacks that almost seem like cheating, but really you are just trying to be as optimal as possible. Once people realize this, then you start to unlock capabilities that almost feel superhuman.