Как локальная LLM может стать вашим личным патинг-инженером: опыт модификации open-source

Проблема: между «хочу изменить» и «могу изменить» лежит пропасть контекста

Вы нашли отличный open-source проект, но он не совсем соответствует вашим нуждам. Нужно добавить фичу, исправить баг под ваш кейс или адаптировать под другую ОС. Классический путь: изучать код, разбираться в архитектуре, писать патч... На это уходят часы, а иногда и дни. Но что если у вас есть персональный ассистент, который знает код лучше автора, работает в вашем окружении и никогда не отправит ваши данные в облако?

Почему именно локальная LLM? Три кита приватного workflow

Облачные модели вроде ChatGPT прекрасно справляются с общими задачами по программированию. Но для модификации open-source есть три критических преимущества у локального подхода:

• Полная приватность: Исходный код проекта, ваши модификации, бизнес-логика — всё остаётся на вашем железе. Никаких соглашений о конфиденциальности не нужно.
• Работа с полным контекстом: Локальная модель может читать всю кодовую базу проекта (десятки мегабайт), а не ограничиваться окном в 128K токенов. Вы загружаете в контекст все исходники и получаете анализ, основанный на полной картине.
• Интеграция с инструментами разработчика: Как мы писали в статье про идеальный стек, локальную LLM можно подключить напрямую к вашей IDE, системе контроля версий и CLI-инструментам.

Подготовка: выбираем инструменты для работы

Прежде чем начать, нужно собрать рабочий стек. Вот что я рекомендую после тестирования десятков комбинаций:

Выбор LLM: код — это язык, и модель должна его знать

Для задач патчинга я использую две категории моделей:

Как мы обсуждали в обзоре LLM с Tool Calling, именно эта технология превращает LLM из советчика в активного участника workflow. Модель с Tool Calling может самостоятельно запускать тесты, применять патчи и делать коммиты.

Инфраструктура: запуск и взаимодействие

Для запуска моделей я предпочитаю Ollama — она проста, но мощна. Альтернативы — LM Studio или прямой llama.cpp. Для взаимодействия:

• Continue.dev — расширение для VS Code, которое превращает IDE в центр управления LLM.
• Instructor — библиотека для структурированного вывода, идеальна для генерации патчей в формате diff.
• Simple-llama-framework — минималистичный фреймворк для создания автономных агентов.

Workflow патчинга: от идеи до пул-реквеста

Вот как выглядит идеальный процесс модификации open-source проекта с локальной LLM:

1. Анализ кодовой базы: Загружаем весь проект в контекст LLM, получаем архитектурную сводку.
2. Спецификация изменений: Формулируем задачу на естественном языке, модель предлагает план реализации.
3. Генерация патча: Модель создает diff-файл с изменениями, объясняя каждую модификацию.
4. Тестирование: LLM запускает тесты (через Tool Calling) и анализирует результаты.
5. Итерация: При необходимости — уточняем, исправляем, перегенерируем.

Пошаговый план: модифицируем реальный проект

Давайте рассмотрим конкретный пример: добавим поддержку нового формата экспорта в утилиту для обработки текста.

1Подготовка окружения

Скачиваем проект и устанавливаем зависимости:

git clone https://github.com/example/text-processor.git
cd text-processor
pip install -r requirements.txt
# Запускаем Ollama с нужной моделью
ollama pull deepseek-coder:latest

2Анализ проекта

Создаем промпт для анализа структуры:

# prompt_analysis.py
prompt = """
Проанализируй структуру проекта text-processor:
1. Какие основные модули и их назначение?
2. Где находится логика экспорта данных?
3. Как добавлены существующие форматы экспорта?
4. Предложи архитектуру для добавления нового формата JSON Lines.

Проект:
"""
# Добавляем содержимое ключевых файлов
with open('src/exporter.py', 'r') as f:
    prompt += f"\n\nФайл exporter.py:\n{f.read()}"

3Генерация патча

Используем библиотеку Instructor для получения структурированного ответа:

from instructor import patch
from pydantic import BaseModel
import ollama

class CodePatch(BaseModel):
    description: str
    diff: str  # unified diff format
    files_affected: list[str]
    tests_needed: list[str]

# Патчим клиент Ollama
client = patch(ollama.Client())

response = client.chat.completions.create(
    model="deepseek-coder",
    response_model=CodePatch,
    messages=[{"role": "user", "content": prompt}]
)

print(f"Дифф:\n{response.diff}")
with open("jsonlines_export.patch", "w") as f:
    f.write(response.diff)

4Применение и тестирование

Применяем патч и запускаем тесты:

# Применяем патч
git apply jsonlines_export.patch

# Запрашиваем у LLM создать тест
ollama run deepseek-coder "Создай unit-тест для нового формата JSON Lines в exporter.py. Учти существующую структуру тестов в tests/" > test_jsonlines.py

# Запускаем тесты
python -m pytest test_jsonlines.py -v

5Итерация и рефакторинг

Если тесты не проходят, отправляем ошибку модели и просим исправить:

error_output = """
Тест test_jsonlines_export завершился с ошибкой:
AssertionError: Expected 10 records, got 9
"""

fix_prompt = f"""
Патч вызвал ошибку в тесте:\n{error_output}\n\nИсправь код в exporter.py, чтобы тест проходил.
Вот текущая реализация метода export_jsonlines:
"""

with open('src/exporter.py', 'r') as f:
    fix_prompt += f.read()

Нюансы и возможные ошибки

Даже с мощной LLM есть подводные камни:

FAQ: частые вопросы о патчинге с LLM

Заключение: от потребителя к созидателю

Локальная LLM превращает вас из пассивного потребителя open-source в активного участника экосистемы. Вы больше не зависите от дорогих облачных сервисов или доступности авторов проекта. С правильным стеком инструментов и workflow вы можете адаптировать любой проект под свои нужды, сохраняя полный контроль и приватность.

Начните с малого: выберите простой проект, попробуйте добавить небольшую фичу или исправить баг. Как показывает наш опыт и обзор open-source инструментов, сегодняшние локальные модели уже достаточно мощны, чтобы стать вашим персональным патинг-инженером.

Следующий шаг — интегрировать этот workflow в вашу повседневную разработку. Удачи в модификациях!