deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Apache-2.0 weights released for Qwen3.8-27B fine-tune that writes Atlassian Forge apps

An independent developer fine-tuned Qwen3.8-27B to write Atlassian Forge apps and published the weights under Apache-2.0, reporting validator pass rates rising from 0 of 25 to 14 of 25.

Apache-2.0 weights released for Qwen3.8-27B fine-tune that writes Atlassian Forge apps

An independent release, not an Atlassian product

Despite the Atlassian branding of the finished model family, the release did not come from Atlassian. According to a post on dev.to published on 17 September 2026 by an author writing under the handle mihai_leanzero and associated with the consultancy LeanZero, the project is a community fine-tune of the open Qwen3.8-27B model taught to build Forge apps and answer questions about Jira, Confluence and Jira Service Management. The author notes that Atlassian itself runs fine-tuned open models inside its own VPC but has never published weights, which is what makes this release unusual.

What is on Hugging Face

The weights are available in five artefacts, all under the Apache-2.0 licence. The headline download is the 8-bit merged model, around 31 GB, with the speculative-decoding head kept intact. Alongside it sit the rank-32 LoRA adapter (about 190 MB) for anyone wanting to continue training, the untouched 8-bit base the adapter was trained against, and 6-bit and 4-bit quantisations of roughly 21 GB and 15 GB. The author reports the merged 8-bit model agrees with the unmerged base-plus-adapter combination on 99.4% of top-1 predictions, falling to 98.26% at 6-bit and 93.88% at 4-bit. A smaller 9B member was added to the family shortly after the main release.

Measured base-versus-tuned results

The post's central evidence is a before-and-after comparison, all measured by the author on a single machine. On a probe of Atlassian-specific identifiers, the base model scored 15% and the tuned model 69%. Across 25 Forge app briefs, manifests accepted by Atlassian's official validator went from 0 of 25 to 14 of 25, and complete apps that both passed validation and compiled went from 0 of 25 to 12 of 25. The author's description of the base model is familiar to anyone who has tried this: it invents a manifest format, imports packages that do not exist, and produces plausible-looking code that cannot run. These are self-reported figures from a self-published post on a small 25-brief evaluation set, and have not been independently verified.

Training on a single Mac Studio

The training setup is a large part of the story. Full fine-tuning a 27B model was out of reach for the hardware, so the base was quantised from bf16 to 8-bit, a rank-32 LoRA was trained on top of the frozen base at 31.7 GB of active memory, and the adapter was merged back afterwards. The whole run took 26 hours of adapter training across three kept rounds on one Mac Studio M3 Ultra with 96 GB of RAM, using mlx-lm with a chunked training patch. Round selection was automated by a rule covering validation loss, identifier accuracy, app completion and looping behaviour; one round was rejected for a 0.018 regression and the final round shipped as v0.3. The author also documents a day the selection script ran incorrectly and had to be re-run manually, arguing that measured claims are only credible if the misfires are recorded too.

Data, filtering and privacy

The training corpus drew on twelve Forge apps written by LeanZero, validator-approved manifests generated from the @forge/manifest schema, UI Kit examples compiling against @forge/react 12, the Forge documentation, six Atlassian OpenAPI specifications, 1,400 vetted community question-answer pairs, and 220 public developer community threads. The decisive ingredient, per the author, was self-generated data: the model's own app attempts, kept only when they passed the validator, an allow-list and the TypeScript compiler, with failure-plus-fix pairs built from real validator error messages. The final mix was 18,189 samples, roughly 6.1 million tokens. Tenant hostnames and e-mails were rewritten before training, and a canary probe for memorised strings returned zero hits.

How novel is it

The author is careful not to claim an absolute first for Atlassian-tuned models. WizardLM-2-7B-Atlassian has existed on Hugging Face since May 2024, and several small Jira-focused fine-tunes appeared from late 2025. The narrower claim, based on searches of Hugging Face and GitHub, is that this is the first open-weights model trained specifically to write Forge apps, and the first Atlassian-tuned release accompanied by base-versus-tuned evidence on Atlassian's own validator.

Why it matters

This is a useful data point on how far consumer-grade hardware and open base models have pushed domain fine-tuning: a 27B model specialised for a commercial developer platform, trained on one Mac, and released with permissive weights. For Atlassian developers, it hints at local, offline tooling for Forge scaffolding and Jira, Confluence and JSM questions. The caveats are real — a small evaluation set, unverified numbers, a 4-bit variant not re-scored on app writing, and the author's own framing that the model is a strong assistant rather than a compiler. Still, the methodology of publishing failed rounds alongside successful ones is a standard more releases should copy.

  • #open-source
  • #fine-tuning
  • #atlassian-forge
  • #llm
  • #local-llm

Related posts