💻 computer science

Customizing an LLM for Enterprise Software Engineering

This paper introduces Gemini for Google (GfG), a specialized large language model adapted for Google's internal software engineering ecosystem through a comprehensive end-to-end process of data curation and mid-training, which significantly improved developer efficiency and code quality in a large-scale study while providing a replicable blueprint for enterprise model customization.

Original authors: Aditya Kini, Satish Chandra, Milad Hashemi, Saksham Thakur, Aditya Pandey, Vincent Nguyen, Marc Brockschmidt, Franjo Ivančić, Danny Tarlow, Parthasarathy Ranganathan, Petros Maniatis, Ahmed Omran, Zah

Published 2026-05-21

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Aditya Kini, Satish Chandra, Milad Hashemi, Saksham Thakur, Aditya Pandey, Vincent Nguyen, Marc Brockschmidt, Franjo Ivančić, Danny Tarlow, Parthasarathy Ranganathan, Petros Maniatis, Ahmed Omran, Zaheer Abbas, Anita Gergely, Martin Sevenich, Gufeng Zhang, Amy Hua, Alexander Frömmgen

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a brilliant, world-class chef (the original AI model). This chef can cook almost anything: Italian pasta, French pastries, or Japanese sushi. They are trained on every recipe book in the public library.

However, you work in a massive, high-tech corporate cafeteria (Google's internal software ecosystem). Here, the rules are weird. You don't use standard ovens; you use custom-built, proprietary machines. The ingredients are unique, and the "recipes" (code) have specific, strange names that no one outside the building knows.

If you ask the world-class chef to cook a meal for your cafeteria, they might try to use a standard recipe. It will look good, but it won't work with your machines, and it might break the food.

This paper describes how Google took that world-class chef and gave them a specialized training camp to become the perfect chef for their specific cafeteria. They call this new chef "Gemini for Google" (GfG).

Here is how they did it, broken down into simple steps:

1. Gathering the "Secret Recipe Book"

Instead of just giving the chef more public cookbooks, the team gathered a massive library of internal documents. This wasn't just code; it was the entire history of how their engineers work:

The "Critique" Log: They looked at thousands of conversations where senior engineers reviewed code, said "fix this," and the junior engineer fixed it. This taught the AI how to accept feedback and improve.
The "Break-Fix" Log: They watched how engineers fixed broken builds (when the software stops working). The AI learned: "Oh, when this error pops up, the solution is usually to change this specific line."
The "Speed" Log: They studied how engineers made programs run faster, teaching the AI to spot slow spots and suggest fixes.
The "Chat" Log: They used internal Q&A sessions where engineers asked about weird, internal tools, teaching the AI the specific names and jargon of the company.

2. The "Mid-Training" Surgery

Usually, you either train a model from scratch (start with a baby brain) or you just tweak the end (fine-tuning). Google did something in the middle.

Think of the original AI as a student who has finished high school (general pre-training).

The Problem: If you just start teaching them advanced corporate law immediately, they might forget how to do basic math or write a simple essay. This is called "catastrophic forgetting."
The Solution: Instead of starting from the very end of high school, they went back to the student's junior year. They took the student, gave them the "Secret Recipe Book" (the internal data), and let them continue their education from that point. This way, the student kept their general smarts but learned the specific corporate rules.

3. The Results: A Smarter Assistant

They tested this new "Gemini for Google" against the standard version with 29,000 engineers. The results were like comparing a generic GPS to one that knows every shortcut in your specific city:

Fewer Back-and-Forths: When engineers asked for help, the standard AI needed about 23% more conversation turns to get the job right. The specialized AI got it right the first time more often.
Better Code Survival: Code written by the specialized AI was 17% more likely to survive the review process and actually get used in the final product. It was less likely to be rejected or broken.
Real-World Wins:
- The "Time Travel" Migration: They used the AI to update a decade-old system to a new one. It did 80% of the work automatically, cutting the time in half.
- The "Smart Paste": When an engineer copied code from one file to another, the AI automatically fixed the imports and variable names so it worked instantly, saving thousands of keystrokes.

4. What They Learned (The Lessons)

The paper highlights three big lessons for anyone trying to do this:

More Data Isn't Always Better: Just throwing everything at the AI can confuse it. They had to carefully pick the right mix of data, or the AI would learn the wrong habits (like talking too much when it should just act).
Don't Fight the Format: They learned it's easier to shape their internal data to look like the AI's original training style, rather than forcing the AI to learn a new, weird format.
Real Tests Matter: You can't just test the AI on a multiple-choice quiz. You have to watch it work in the real world. Did the engineer actually accept the code? Did it survive the review? That's the real score.

The Bottom Line

This paper isn't about inventing a new type of brain. It's about taking a very smart, general-purpose brain and giving it a specialized internship inside a specific company. By feeding it the company's own history, mistakes, and successes, they created an AI that doesn't just "know code"—it knows their code, their tools, and their way of working.

Technical Summary: Customizing an LLM for Enterprise Software Engineering

Problem Statement

Enterprise software development is a continuous evolutionary process involving incremental additions, architectural revisions, and rigorous maintenance within proprietary ecosystems. While frontier Large Language Models (LLMs) excel at generating greenfield code for algorithmic challenges, they often lack exposure to the unique data distributions of large organizations—specifically internal libraries, architectural patterns, and domain-specific languages.

Standard approaches to bridge this gap, such as Retrieval-Augmented Generation (RAG) or low-rank adaptation (LoRA), present limitations. RAG results are mixed and dependent on retrieval quality, while LoRA lacks the representational capacity for large-scale domain adaptation on trillion-token corpora. Training models from scratch on enterprise data is often prohibitively expensive and time-consuming. Consequently, there is a need for a methodology that specializes foundation models to understand specific enterprise semantics without sacrificing their general reasoning capabilities.

Methodology

The authors introduce Gemini for Google (GfG), a specialized adaptation of the Gemini foundation model designed for Google's internal software engineering ecosystem. The development process follows a four-stage blueprint:

1. Data Curation

The team curated a trillion-token proprietary dataset capturing diverse artifacts from the software development lifecycle. The data is categorized into six primary domains to provide distinct supervision signals:

Change-Generation: Code review data (initial code, comments, final code) to model "critique-and-refine" dialogues.
Knowledge: Internal technical documentation, API references, design documents, and Q&A repositories.
Issues and Fixes: Data on bug fixes, build errors, and test failures. A key contribution is the Build Fixing dataset, which uses fine-grained IDE instrumentation to reconstruct developer sessions, identifying code changes that transition a build from failure to success.
Code Generation: Code written by developers in various formats (e.g., Fill-in-the-Middle) to support completion tasks.
Logs and Performance: Production metadata, efficiency edits, and distributed tracing data (e.g., Dapper) to teach the model about runtime behaviors and performance anti-patterns.
Activity Timelines: Coarse-grained workflow data mapping tool usage and search patterns.

2. Data Formatting

To handle heterogeneous tasks, the authors designed specific data representations:

Instruction-Guided Code Editing: Modeling code changes as a diff ( $\Delta$ ) given an original code snippet and an instruction.
Automated Program Repair (APR): Treating compiler errors or static analysis warnings as "automated review comments" to unify human and machine feedback.
Context-Aware Infilling (FIM): Using Prefix-Middle-Suffix formats to enhance the model's ability to generate code within existing files.
Multi-Turn Agentic Trajectories: Reconstructing latent development paths (e.g., using ReAct frameworks) to capture iterative problem-solving.

3. Mid-Training Intervention

Instead of training from scratch or applying post-training only, the authors employed a mid-training intervention. This strategy branches off from a foundational checkpoint (before the final convergence phase of the base model) and injects the curated enterprise dataset. This approach preserves general reasoning capabilities while injecting deep domain knowledge.

Two model variants were trained: Gemini-Flash (optimized for low-latency code completion) and Gemini-Pro (optimized for complex reasoning and refactoring).
To mitigate catastrophic forgetting, the authors utilized Data Replay (mixing original pre-training data into the enterprise mixture) and Mid-training intervention (branching from an earlier checkpoint rather than the final one).

4. Post-Training

Following mid-training, the model underwent Supervised Fine-Tuning (SFT) using high-quality internal datasets derived from crowdsourced validation and anonymized interaction logs. This phase optimized the model for downstream applications like code transformation, migrations, and NL2SQL.

Key Contributions

Framework for Enterprise Adaptation: A comprehensive blueprint for building specialist foundation models from internal engineering data, covering data curation, training dynamics, and deployment.
Mid-Training Intervention Strategy: A novel approach to bridge the gap between general pre-training and post-training, effectively adapting model weights for a specific ecosystem while retaining general intelligence.
Enterprise-Scale Evaluation: A large-scale blind A/B study involving 29,000 developers demonstrating the practical utility of the customized model.

Results

Offline Evaluation

Coding Benchmarks: GfG outperformed the baseline Gemini 2.5 Pro on most coding benchmarks, including a 13% improvement on the Aider "Edit Block" format and a 5% improvement on SWE-bench Verified.
General Reasoning: Despite the trillion-token injection, GfG maintained or improved performance on non-coding benchmarks (e.g., ARC AGI, GradQA, MMMU-Pro), confirming that fundamental intelligence and multimodal reasoning were preserved.

Online Evaluation (A/B Study)

In a blind, randomized experiment across 29,000 developers, GfG significantly outperformed the baseline:

Efficiency: Reduced the mean number of conversational iterations per turn by 23.1% and turn latency by 8.9%.
Quality: Increased the hunk acceptance rate by 4.5% and code line acceptance by 4.5%.
Impact: Increased code submission rates by 11–14% and improved the code survival rate (persistence of accepted code in final submissions) by 16.8%.

Industrial Case Studies

The model was deployed in several high-value scenarios:

Migrations: Successfully migrated legacy codebases (e.g., 32-bit to 64-bit IDs, JUnit3 to JUnit4), reducing manual effort by 50% and authoring 80% of code changes in some cases.
Code Efficiency: The "Efficient Code Optimizer" (ECO) system synthesized optimization patches, saving an estimated 500,000 normalized CPU cores per quarter.
In-IDE Assistance: Features like "Smart Paste" and "Transform Code" achieved high adoption rates (45% and 70% acceptance, respectively), saving developers thousands of keystrokes and accounting for over 1% of all code produced.

Significance and Lessons Learned

The paper posits that this methodology offers a replicable path for organizations to unlock the full potential of their internal engineering data. The authors emphasize that "more data is better" is not a universal rule; careful data composition is required to avoid negative transfer (e.g., verbose reasoning traces interfering with tool use). Furthermore, aligning internal data formats with the base model's pre-training distribution is crucial to minimize "syntax shock" and regression.

The work concludes that direct specialization of foundation models via mid-training and full-parameter fine-tuning is a viable and effective strategy for creating enterprise experts capable of addressing the full spectrum of development tasks, from maintenance to architectural evolution, without the prohibitive costs of training from scratch.