EPL + AI August 2026 Michael Korneev

Fine-Tuning Qwen 3 to Be a Middle EPL Developer

We're training a small language model to write code in our own programming language — and it should run on a $300 GPU card

Fine-tuning Qwen 3 for EPL: problem, approach, goal

We're training a small language model to write code in our own programming language — and it should run on a $300 GPU card

We built our own programming language. It's called EPL — Elastic Programming Language. It compiles to native x64 machine code (ARM32/ARM64 support is almost ready — we're finishing the self-compilation system). It has its own database queries, its own GUI widgets, its own network protocol — all as language-level constructs.

The problem: no public LLM knows EPL. ChatGPT, Claude, Gemini — they've never seen it in training data. When we ask them to write EPL, they guess based on C/C++ syntax similarity. Sometimes it works. Often it doesn't. They don't know that include_file is not #include. They don't know that V_Pipe @Pipe = new V_Pipe crashes — you must subclass first. They don't know that s_StrPos is 1-indexed, not 0-indexed.

For public models like Claude and GPT, we already have a workaround: we feed them our EPL language reference document as context, and they work surprisingly well. The reference is compact — EPL is a small, well-specified language, so the entire doc fits easily in a context window. We plan to release EPL and this documentation publicly soon, so anyone can use public LLMs to write EPL with just the reference doc in context.

But context-window prompting has limits: it costs tokens on every call, it doesn't learn from mistakes, and it can't internalize patterns the way training can. That's why we're also fine-tuning our own model.

Why Qwen 3, and why small

We chose Qwen 3 (a small variant in the 4B-8B range) for a specific reason: it needs to run on a single RTX 4060 Ti with 16GB VRAM.

Not an A100. Not a cloud GPU cluster. A $300 consumer card sitting in a workstation under a desk.

Why this constraint matters:

EPL has a small context. The entire language reference fits in roughly 50 pages. The database DSL is a few hundred lines of specification. The widget API is documented. The protocol is typed. There are no 200-dependency node_modules to understand, no framework-of-the-month to keep up with. The full context of "how to write EPL" is small enough that a small model can learn it.

This is the architectural advantage of owning your language. A model that needs to write Python must understand Python + Django + Flask + FastAPI + SQLAlchemy + Celery + Redis + PostgreSQL + Docker + Kubernetes + the 47 packages in requirements.txt. A model that writes EPL needs to understand EPL. One language. One database. One protocol.

A small model fine-tuned on a focused corpus can outperform a large general model on a narrow domain. This is well-established in the literature — and EPL is exactly the kind of narrow, well-specified domain where it should work.

The training setup

Hardware: NVIDIA RTX 4060 Ti, 16GB VRAM. One card. No multi-GPU, no cloud.

Method: QLoRA (Quantized Low-Rank Adaptation) — 4-bit quantization of the base model with LoRA adapters trained in 16-bit. This fits a 4-8B parameter model into 16GB comfortably, with room for batch processing.

Training data:

What we're NOT training on: English conversation, general knowledge, math, other programming languages. The model needs to do one thing: write correct EPL code given a specification.

What "middle EPL developer" means

We're not trying to create a senior architect. We're targeting the equivalent of a mid-level developer who:

This is not a coding assistant that suggests autocomplete. This is a model that takes a brief — "add a command handler that returns the user's project list, filtered by status" — and writes the EPL function, the registration in CmdHandlerArr, and the client-side request builder.

Why this could change everything

Right now, we run 20 AI coding agents (Claude) that build the platform daily. The AI agents are highly effective because our unified stack means they can hold the full architecture in context.

But Claude costs money. We pay Anthropic for every API call, and that adds up.

If we can fine-tune a small model that writes correct EPL at a "middle developer" level, and run it on a $300 GPU card:

We get unlimited middle-level EPL developers for the cost of electricity.

No API calls. No payments to Anthropic. A $300 card drawing 150 watts, running 24/7, generating EPL code that passes our test suite.

One card = one developer. Ten cards = ten developers. The marginal cost of the 11th developer is $300 + a power outlet.

This only works because:

1. EPL is a small, well-specified language (small training corpus, small context needed)

2. The model runs locally (no API costs, no latency, no rate limits)

3. The entire stack is one language (the model doesn't need to context-switch between 12 technologies)

4. We own the compiler (we can verify every output by compiling it — instant ground truth)

Where we are right now

We have:

We're about to start training. Very soon we'll know if a 4-8B model, fine-tuned on EPL, can reliably produce correct code. We'll test it against real tasks: "implement this command handler," "fix this bug," "add this database query." The compiler is the judge — it either compiles or it doesn't.

If it works as expected, it changes the economics of our entire operation. 20 Claude agents become 20 Claude agents + N local models, where N is bounded only by how many GPU cards we can plug in. The Claudes handle architecture and complex reasoning. The local models handle routine implementation.

Middle developers, practically for free.

We'll publish the results — pass rates, failure modes, what the model gets right and what it gets wrong — as soon as we have them. No hype, no "our model is better than GPT." Just: here's a small model trained on our language, here's what it can and can't do, here are the numbers.

We built our own compiler, database, protocol, HTTP server, and GUI framework. 9 products ship on it. Now we're training AI to write the code that runs on it.

Follow for the results: @elastcode