Finally, this article took me ~ 2 months to write-up 📅 - mostly because coming up with Nichebench, creating test-cases and running slowly the tests against many existing LLMs.
Let’s start with this - not all LLMs are created equally. The data they are trained on, the formatting of the data, the labelling, the used underlying architecture and many other parameters - heavily influence the final result. Some LLMs might be good at coding 🧑💻, but when prompted about Drupal 10 or Drupal 11 implementation, might creep-out some Drupal 7-flavor solutions - or plainly hallucinate some slop as a reply 😵
Most of us get around these issues, by just throwing more money at this problem - i.e. picking Claude Sonnet 4 (or Opus) - or using up Github Copilot’s paid credits.
Very few of us play with smaller LLMs (be it via OpenRouter, Together.AI, groq or Ollama) - and that’s understandable, because after a few tries, you’d quickly realize that they are performing pretty poorly - specifically in the Drupal 10/11 setting.
You normally end-up re-prompting and explaining in-details what you want the AI Agent to achieve - constantly thinking “wouldn’t it be faster if I’d just do it myself?”. And, you continue re-prompting, like "Do it, or..."
As a part of my experiment (started in this article) - I want to fine-tune a niche-LLM, one that would focus on Drupal 10/11 knowledge and recent best-practices, and see if I could reach (or even outperform) current SOTA models.
The next stepping stone on this journey is to find a good, solid, open-weight model to build upon - enter Nichebench by HumanFace Tech👇
To test how well AI models know Drupal 10-11 - we’ve cooked 🧑🍳 Nichebench.
I originally wanted to base it on LightEval - but quickly realized that LLM-as-a-Judge multi-turn complexity, didn’t allow me to proceed as I wanted, so, instead, I embraced DeepEval.
Using DeepEval offered us:
Although I didn’t stay 100% loyal to the framework → I wanted to have my own formatted outputs / CLI tool, so I had to go ‘around’ the traditional deepeval CLI tool (which handles concurrency and other stuff) - but it’s ok (maybe I’ll reverse this in the future).
Nichebench so far supports 2 types of tests (there’s a 3rd but I’ll ignore it for now): quiz & code_generation.
Quizzes are simple - they usually have: A, B, C, D, E, F answers - and we STILL use LLM-as-a-Judge to verify the answer. Why - some LLMs might give random explanation or blabber, and then say “Okay, so, saying all that - I think the actually answer is A” - and I’d like to have an LLM to figure that out.
Code Generations are a bit more complex - they have a detailed system prompt, then a context of a task at hand, then what’s expected from the MUT (model under testing), then the model completes the end-to-end implementation and forwards this to LLM-as-judge (usually gpt-5@medium in my case) - and the Judge also sees a list of criteria & judge hints - what to look for and why.
⚠️ NOTE: I didn’t ship the actual quiz & code tasks as a part of this repo, because I don’t want newer models to use my questions / answers for their training (so the folder will be empty) - but you can ask me and I can add you to the private repo, if you’re interested (or if you wish to contribute).
Here’s the result - top to bottom (best to worst):
I did test a lot of models - because in general, this test is relatively fast and cheap (unless it’s a reasoning model). You’ll see that some SOTA models didn’t get 95-100% but 90-91% - and that’s fine. It’s not about absolute perfect score, it’s about relative score - that’s why I tested also proprietary SOTA models: gpt-5 and claude sonnet 4.
My take-away from this test:
Some models scored better than others, also because of recency - some tests (both Quiz & Code Gen) that I have include relative fresh Drupal 11 APIs (but a small %). Sure, that might NOT be relevant as we’ll use fine-tuning to solve those - but wouldn’t we rather start with a model that already is better at some of those?
Here’s the result - top to bottom (best to worst):
Now this test tells a totally different story. Important to note - this is NOT agentic, this is 1 time output (multiple file changes in 1 textual output) test.
These tests run long-time and are pretty expensive. For reference - GPT-5@Medium (judged by GPT-5 itself) scored 75%. I think Claude Sonnet 4 or GPT-5@High would probably get 80-90%.
And now let’s switch focus back to our open-weight models → and the GAP is HUGE. Take-aways:
I know people complained about gpt-oss models NOT being amazing or up to their expectations - but somehow these models did pretty well on my tests.
One IMPORTANT thing to note here - gpt-oss models were pretty weak generating complex properly escaped function calls (JSONs), that’s a normal thing for smaller models but somehow it really sticks badly in gpt-oss models (120B ofc performs way better, but even it screws up)
RAW results can be found in this spreadsheet 📊.
After these tests - heavier relying on the results of code generation tests → here’s the analysis of 4 smallish LLM models.
| Model | Arch | Context (native) | License | Tool Use | JSON/YAML/XML Gen | Coding Specialization |
|---|---|---|---|---|---|---|
| GPT-OSS-20B | MoE | 128K | Apache-2.0 | Native function calling, browsing, Python tools — but flaky reliability (JSON/tool-call errors reported) | JSON/YAML supported, but frequent parsing errors 👎 | Generalist; decent coding & reasoning, not coding-specialized |
| Phi-4 (14B) | Dense | 16K (32K reasoning variant) | MIT | Supports function calling (basic) but limited depth; better in small iterative tasks | Good structured extraction, less reliable for complex JSON | Strong at math & reasoning, weaker at repo-scale coding |
| Qwen3-32B | Dense | 128K | Apache-2.0 | Standard tool calling, reliable & stable | JSON/YAML generation very consistent 👑 | Balanced — not coding-only, but very stable all-rounder |
| Qwen3-Coder-30B-A3B | MoE | 256K 👑 (up to 1M with YaRN) | Apache-2.0 | Advanced agentic tool use (XML format for calls; more reliable on quantized runs) 👑 | Excels in structured output for dev workflows (JSON/YAML/XML) 👑 | Specialized for repo-scale coding, strong at multi-file agentic workflows 👑 |
👉 Another ‘down-fall’ of Phi-4 is its tiny context window, and basic tool-use (less agentic) than newer models.
👉 GPT-OSS-20B still looks good in many regards - but we WILL need to address the JSON/XML/YAML serialization issue. Bad side of it is that it’s generalist - but even so it outperformed qwen3-coder-30b-a3b in both test-types.
👉 I like both Qwen3 models but for different reasons - MoE flavor is code-specific, agentic → I’d expect exceptional tool-use, serialization and other aspects (also a huge context-window); while the dense one generally outperforms in many regards, even if it’s generalistic.
—
I also favor a bit GPT-OSS-20B because of its guardrails 🛡️, I know OpenAI team invested a lot into it, so per general I’d feel safer playing with it. Another reason is its huge popularity (at least for now) - which means I could throw my LoRAs onto almost any server and have it running - and at very fast speeds. And finally, I also want to consider LATER the option of transferring the fine-tuning to its larger brother: 120B.
And, here's a full video covering the article:
Building on top of Fine-tuning article - next step would be to generate proper synthetic data, I’m talking about 10k-20k of proper technical Drupal-related tasks and solutions, properly described, annotated, labelled and what not.
And then, we start cooking a proper NicheAI - Drupal AI LLM, and see if we can reach SOTA-quality level.
Here’s what to expect:
If these articles are useful and/or entertaining for you - please consider supporting the effort ☕ via Ko-Fi donations 👇




%20.png)