Ertas for Code Generation

The Challenge

Software development teams are adopting AI-powered code completion, code review, and documentation generation at a rapid pace, but the productivity gains from generic code models plateau quickly on enterprise codebases. Internal frameworks, proprietary APIs, custom design patterns, and organization-specific coding conventions are invisible to models trained on public open-source repositories. The result is AI suggestions that are syntactically valid but architecturally wrong: importing deprecated internal packages, ignoring custom linting rules, or generating boilerplate that contradicts the team's established patterns.

Intellectual property is the deeper concern. Enterprise source code represents years of engineering investment and competitive advantage. Sending proprietary code to a third-party AI provider's API, where it may be logged, cached, or used in aggregate to improve the provider's models, creates IP exposure that legal and security teams are right to reject. Many organizations with strict IP policies have banned cloud-based code assistants entirely, forcing developers back to manual workflows while competitors accelerate with AI.

The Solution

Ertas lets an engineering team train a code model that knows its own codebase, then run that model on its own infrastructure. In Ertas Studio, the platform team uploads a JSONL dataset built from internal repositories (code and comment pairs, function signatures with docstrings, pull request diffs and review comments) and fine-tunes an open model with LoRA on Ertas's cloud GPUs through a visual canvas. Training uploads that dataset to Ertas, so the team decides what goes in: only the repositories its IP policy allows, with secrets and credentials stripped first. Focused models can train side by side: one for the backend services, another for the mobile codebase, a third for infrastructure-as-code templates. Each learns the internal packages, error-handling patterns and conventions of its part of the code.

When a run is good enough, the team downloads it from Hub as GGUF for llama.cpp, Ollama or LM Studio, or as full safetensors for vLLM and other server runtimes. The model runs on the company's own servers or developer machines, so completion requests, the code context sent with them and the suggestions that come back all stay inside the network. Editors reach it through any extension or gateway that works with a local or OpenAI-compatible server. The model belongs to the company and needs nothing from Ertas at runtime.

Key Features

Example Workflow

A fintech company with 200 engineers and a large Python and TypeScript monorepo wants AI code completion that follows its own conventions, while keeping its trading and risk code away from third-party AI APIs. The platform engineering team writes an internal script that extracts code and comment pairs, function signatures with docstrings and pull request review comments from the monorepo. The script skips the directories the IP policy marks as restricted and scrubs secrets, and the output becomes a JSONL dataset the team uploads to Ertas Studio. On the canvas they set up two LoRA fine-tuning runs from a Qwen 2.5 7B base, one on the Python backend examples and one on the TypeScript frontend examples, plus matching runs on Llama 3.1 8B to compare base models. All four train in parallel. The team downloads the finished models, tests them against a held-out set of internal completion tasks, and checks whether suggestions import the right internal packages and follow the team's error-handling and strict-mode conventions. The stronger model for each codebase goes onto a GPU server in the company's Kubernetes cluster, behind the corporate VPN, served through an OpenAI-compatible runtime that the developers' editor extension already supports. Completion requests and the code sent with them stay on company hardware. Over the following weeks the team tracks how often developers accept suggestions, and retrains with fresh review comments as the codebase moves on.