When a language model shifts from snippet companion to co-pilot of a real application, the gap between code generation and architectural sense becomes abruptly painful. That is the account of a developer who, after integrating Qwen3.6-27b into the development of a commercial software project exceeding 100,000 lines, found herself wrestling with an assistant prone to churning out elephantine classes, bloated interfaces, and a total disregard for test automation. Not an occasional bug, but a systematic pattern: the LLM writes just enough to satisfy the immediate request, while completely ignoring maintainability, separation of concerns, and any best practice essential for growing code without spiraling complexity.

The frustration in the original post is not isolated – it signals a structural crack. Models like Qwen3.6-27b are trained primarily on public repositories, where architectural quality is uneven and system-level context is absent: short functions, isolated scripts, and pull requests that rarely show the evolution of an entire codebase dominate. Local inference – often chosen for data sovereignty, cost control, or compliance constraints – amplifies the problem because it loses the implicit feedback of cloud platforms where the model can draw on extended contexts or pre-calibrated retrieval-augmented generation mechanisms. Locally, the prompt is everything, and unless the user obsessively specifies architectural constraints, the system reverts to its lowest common denominator: producing code that works but is structurally fragile.

The result is a paradox for those who have invested in dedicated hardware and self-hosted stacks. On one hand, they gain privacy and predictable operational costs; on the other, they generate a hidden technical debt made of “superman” classes that mix data access, business logic, and presentation, and of interfaces that balloon with every iteration. The cost is not immediate: it surfaces weeks later, when a change in requirements forces a refactoring of a tangle that no team member can decipher anymore. In Total Cost of Ownership terms, the savings from cloud APIs risk being eroded by the time spent correcting, rewriting, and “training” the model to remember principles like single responsibility or dependency inversion.

The developer’s call for a set of SKILL.md files – documents that would inject architectural knowledge directly into the model – is telling. It points to the need for a new engineering layer: if the LLM has not internalized software design, someone will have to provide it each time, in the form of persistent guidelines, prompt templates, or even targeted fine-tuning. For teams managing on-premise deployments, this changes the TCO calculation: it is no longer enough to size the GPU to hold the model weights; one must also invest in context pipelines that bridge the gap between the developer’s intentions and the raw capability of the LLM. And it is not a one-off cost, because architecture evolves with the project.

Lurking behind this is an uncomfortable truth for the entire open-model ecosystem: code generation is becoming a commodity, but software design remains a skill that training data does not easily transmit. Local distribution, which promises independence and control, ends up widening the gap, turning every developer into a part-time trainer of their own assistant. The search for SKILL.md is not just a file request; it is the symptom of a broader need for tools that transform a language model into a true design partner, one capable of seeing the forest beyond the single tree.