Имаго-кодинг: как локальные модели и LoRA-адаптация меняют процесс разработки ПО
Разработчик и предприниматель Михаил Тохабес описывает переход от использования генеративных агентов к концепции «имаго-кодинга». Новая методология предполагает не просто дообучение нейросети общими данными, а создание специализированной «модели-строителя» с помощью LoRA-адаптации, RAG и локальных вычислений. Цель — устранить проблему усреднённого кода и обеспечить безопасность данных в промышленных проектах.
# Имаго-кодинг: эволюция разработки ПО за пределы харнессов
В современном ландшафте искусственного интеллекта разработчики проходят через несколько стадий интеграции: от интуитивного «вайб-кодинга», когда пользователь просто отправляет промпт, до создания сложных агентных систем («харнесс») с инструментами и проверками. Однако, по мнению экспертов, следующий эволюционный шаг — это создание собственной сущности ИИ, глубоко встроенной в проект. Этот этап автор называет «имаго-кодингом».
От фронтендерных моделей к специализированной архитектуре
Одной из главных проблем использования публичных больших языковых моделей (LLM) является их игнорирование конкретного контекста проекта. Универсальные модели знают стандартные паттерны, но часто не понимают внутренних абстракций, схем данных или бизнес-логики конкретного предприятия. Попытка объяснить все эти нюансы в промпте неэффективна и требует огромного количества токенов.
Более того, для работы с коммерческой тайной и персональными данными отправка запросов в зарубежные облака может быть невозможна из-за правовых рисков. Решение заключается в использовании локальных моделей.
Ключевым препятствием для разработчиков является миф о том, что создание адаптеров требует колоссальных вычислительных ресурсов. Однако, благодаря методам адаптации веса моделей, таким как LoRA (Low-Rank Adaptation) и QLoRA, стало возможным обучать модели на умеренном оборудовании (например, видеокарта с 48 ГБ памяти). Это позволяет сместить распределение знаний модели: вместо того чтобы перебирать все возможные решения, как делает общедоступная нейросеть, специализированная модель «видит» тот самый путь, который уже доказал свою эффективность в проекте.
Трехслойная система: RAG, LoRA и харнесс
Система имаго-кодинга строится на синергии трех компонентов:
1. Харнесс (Harnezz): Это слой сбора знаний. Инструмент автоматически собирает информацию о проекте: скачивает свежие статьи с arXiv, анализирует документацию, схемы данных и историю коммитов Git. Вся эта информация структурируется и сохраняется для дальнейшего использования. 2. RAG (Retrieval-Augmented Generation): Система использует векторные эмбеддинги и методы поиска (BM25, RRF) для быстрого извлечения нужного контекста по запросу модели. Этот слой отвечает за актуальные факты и версии кода. 3. LoRA-адаптер: Это «привычки» системы. Модель-строителя (класса 27–35B параметров) дообучается на отфильтрованном датасете истории самого проекта и аналогичных репозиториев. Веса модели замораживаются, и обучаются лишь небольшие добавки к матрицам. Это учит нейросеть писать код в существующем стиле, использовать нужные утилиты и соблюдать стандарты компании.
Важно понимать разницу между знаниями и поведением. LoRA не столько передает новые факты (это задача RAG), сколько формирует предпочтения модели: она начинает выбирать решения, которые ранее успешно применялись, и игнорировать теоретически возможные, но неподходящие подходы. Это резко снижает вероятность того, что агент будет ходить по кругу при исправлении багов, предлагая варианты, которые выглядят разумно, но не работают в конкретной архитектуре.
Качество кода и борьба с техническим долгом
Масштабное внедрение ИИ-ассистентов с моделями общего назначения привело к росту технического долга. Аналитика GitHub за 2020–2024 годы показала восьмикратный рост частоты повторяющихся блоков кода, в то время как доля рефакторинга и повторного использования собственных решений упала. Универсальные модели часто создают рабочую «лапшу», используя усредненные паттерны, вместо того чтобы поддерживать существующие бизнес-сущности проекта.
Имаго-кодинг решает эту проблему. Специализированная модель пишет код, который вписывается в существующую экосистему: использует те же абстракции, имена и логику. Это значительно ускоряет ревью: разработчику не нужно разбираться в десятках строк, отличных от всего проекта. Если в проекте уже накоплен технический долг, процесс дообучения требует тщательной фильтрации датасета, чтобы модель не закрепляла за собой плохие практики.
Роль разработчика в эпоху имаго
Автор статьи отмечает, что переход к имаго-кодингу не означает деградации навыков программиста. Напротив, роль разработчика трансформируется из исполнителя рутинных задач в архитектора модели-строителя. Основная нагрузка смещается на подготовку и фильтрацию данных: отбор релевантных статей, очистку истории коммитов, решение, какие примеры включать в обучение, а какие отсеивать.
Этот процесс требует глубокого понимания архитектуры и кода, что позволяет сохранять и даже повышать квалификацию специалиста. В перспективе, когда модели станут способными самостоятельно отбирать данные, этот этап может измениться, но в ближайшие годы экспертиза человека останется критически важной для формирования качественного «строителя» кода.
Таким образом, имаго-кодинг представляет собой синтез локальной безопасности, специализированного обучения и автоматизированного поиска информации, который позволяет сократить сроки разработки с месяцев до недель, сохраняя при этом высокое качество и соответствие стандартам проекта.