ecom.tech compares evolutionary fine-tuning of Qwen3-4B with SFT and GRPO for Kotlin tests

The ecom.tech team tested whether a small model, Qwen3-4B-Instruct, can be taught to write useful unit tests for a Kotlin backend not through ordinary SFT but through an evolutionary algorithm, Evolution Strategies. The practical result was strong: on test generation, the approach beat both supervised fine-tuning and GRPO on final reward and coverage. But alongside the gain in specialization, the researchers saw a downside: the better the model was tuned to the narrow task, the more of its general capability it lost.

The motivation for the experiment was practical. Inside the team's code generation service, they kept running into a typical problem: an LLM first produces working code, then writes tests for it that look plausible but ignore internal conventions and do not always check the business logic that actually matters. To see whether fine-tuning could fix this, the researchers built a dataset of 1,500 examples: 1,300 for training and 200 for testing. The model received not only the class under test but also the full surrounding context, assembled by an agent based on qwen-code, and had to output a ready-to-use file of unit tests.

Two metrics were used for evaluation. The first is Coverage, not in the usual sense of line coverage but as functional coverage: how far the generated test reaches the same public functionality as the reference test. The second is CodeBLEU, a metric that looks beyond token overlap to the syntax and data flow of the code. Because standard CodeBLEU does not support Kotlin, the team had to add that support separately via tree-sitter-kotlin and its own set of keywords. The reward function was kept simple: 0.6 weight went to CodeBLEU and 0.4 to Coverage, to account for both the form of the code and its practical usefulness.

Evolution Strategies worked like this in the experiment: instead of gradient updates, the team took about 30 perturbed copies of the base model by adding Gaussian noise to the weights, had each copy generate an answer in deterministic mode, and scored it with the reward. The base weights were then shifted toward the changes that produced the best results. This approach is easier to parallelize, does not require storing heavy gradients and, in the authors' view, is less prone to reward hacking.

The team built on the open-source Evolution Strategies at Scale project with vLLM acceleration and trained the model on a cluster of 8 H100s. Because a full pass over the dataset on every iteration is expensive, they introduced batching: 32 examples were picked at random each time.

The experiment showed a noticeable gain after just 500 iterations. By the end of training, CodeBLEU was up 21.3% over the base model and Coverage was up 18.6%. The best ES run reached a coverage of 0.7381 and the highest final reward; on the chosen metrics it beat not only SFT and GRPO but even the much larger Qwen3-Coder-480B. The picture for the competing methods was telling: SFT produced syntactically tidy tests but rarely hit the right logic, while GRPO in this setup actually degraded on both metrics. For a narrow engineering task the conclusion is straightforward: evolutionary fine-tuning can be a working tool, even for a relatively small model.

Then came the less pleasant part. Prompted by recent work on catastrophic forgetting, the team separately checked what happens to the fine-tuned model's general knowledge. They ran the ES version of Qwen3-4B-Instruct through GPQA, a difficult science benchmark. Accuracy fell by 2.1% on average in zero-shot and by 5.3% in five-shot chain-of-thought. The ability to use contextual hints dropped especially sharply: the benefit from few-shot examples shrank by 41–72%. The hypothesis matches what other studies show: ES makes dense changes to nearly all of the model's weights, so it solves the target task better but drifts further from the base state and forgets some of its earlier skills.

What does this mean in practice? Evolution Strategies looks less like a universal replacement for RL and more like a powerful specialized tool for companies that care more about squeezing the maximum out of a model for one specific pipeline. If you have a clear reward function, enough compute and can accept a trade-off in general capabilities, ES can already deliver a tangible gain. For product teams it is also a reminder: improving quality on one task is not free, and the next contest will be not only over new metrics but over ways to fine-tune models without losing their basic flexibility.