«RAG не умер»: GitHub разобрала пять популярных тезисов об ИИ-разработке

Хот-тейки полезны вопросами, а не ответами

18 сентября 2026 года в блоге GitHub вышел разбор пяти распространённых утверждений об ИИ-разработке из нового выпуска GitHub Podcast; материал подписала GPS, Senior Developer Experience Advocate в GitHub. Хот-тейк, по определению автора, превращает сложную тему в одно уверенное предложение: это хорошо для вовлечения, но не обязательно для понимания.

Ценность, пишет GitHub, появляется позже — когда вместо реакции начинаешь разбирать утверждение: при каких условиях оно верно, какого контекста не хватает, какие допущения в нём зашиты и что меняется при применении к реальной работе.

Тезис первый: сгенерированный код можно не читать

Ответ GitHub — нет: код читать нужно, потому что ответственность за него остаётся на разработчике. Но не каждая строка требует одинакового внимания: рефакторинг production-аутентификации и CSS-эксперимент нельзя ревьюить по одному шаблону, а кодебейз, который человек ведёт десять лет, подсказывает интуиции иначе, чем проект, открытый этим утром.

Формулировка правила в статье: ревьюить до тех пор, пока можешь объяснить результат и взять его на себя. Часть работы при этом переносится вперёд, до появления сгенерированного кода: чтение текущей реализации, карта зависимостей, разбор граничных случаев и план — тогда к моменту первой реализации уже понятно, что она должна делать и где может ошибиться. В остальных случаях основное внимание уходит на обработку ошибок, права доступа, работу с данными, производительность, доступность и тесты.

Главный вывод GitHub сформулирован так: ИИ перераспределяет усилия, но не отменяет работу, а реальный навык — понимать, где живёт риск.

Тезис второй: без ИИ не наймут

Реальность, по версии GitHub, немного сложнее: всё больше команд спрашивают кандидатов, как они используют ИИ, и это логично — инструменты становятся частью разработки. Но единый workflow, единый набор инструментов и единый уровень энтузиазма от разработчика никто не требует.

Сильный сигнал — суждение: может ли кандидат объяснить, когда использует ИИ, а когда работает вручную, как ревьюит сгенерированный код, что думает про скорость, качество, безопасность и поддерживаемость и способен ли менять процесс вслед за инструментами. Компания, которая строит ИИ-продукты, вправе считать отказ от ИИ плохой совместимостью, но полная зависимость и полный отказ одинаково редко бывают хорошим ответом.

Тезис третий: Skills убили MCP

GitHub отвечает прямо: нет, эти вещи решают разные задачи. Model Context Protocol даёт агентам стандартный способ подключаться к инструментам и данным — это важно, когда системы должны надёжно работать вместе, вызывать инструменты, забирать контекст и выполнять действия. Сам протокол описан как открытый стандарт для подключения ИИ-приложений к внешним системам, а его документация сравнивает MCP с портом USB-C для ИИ-приложений.

Skills ближе к упакованной экспертизе: навык может объяснить, как устроена работа команды, как принято менять проект, как использовать инструмент и какие конвенции важны; их часто пишут на Markdown, поэтому они читаемы и для людей. Итог в статье звучит так: MCP даёт доступ, Skills объясняют, как пользоваться этим доступом хорошо, и выбирать победителя не нужно — стандарты стоит применять для общих интерфейсов, навыки — для контекста, процесса и лучших практик.

Тезис четвёртый: RAG умер

RAG не умер — он просто перестал быть самым новым поводом для поста. Retrieval-augmented generation даёт ИИ-системе релевантную информацию за пределами обучающих данных: документацию, историю обращений в поддержку, детали продукта, внутреннюю базу знаний или контекст кодебейза.

Без хорошего поиска модель вынуждена опираться на то, что уже знает, или тратить дополнительное время на поиск контекста: это расходует токены, замедляет работу и делает неполные ответы более вероятными. Полезный retrieval, наоборот, сужает пространство поиска и привязывает ответ к информации, которая действительно важна.

Агенты, Skills, MCP и RAG при этом уживаются в одном процессе: агент может через MCP получить доступ к инструменту, следовать навыку с проектными инструкциями и через retrieval найти нужный опорный контекст.

Тезис пятый: fine-tuning выдаёт плохой код

У дообучения модели есть обоснованные сценарии, но современные модели видели огромное количество распространённых фреймворков, паттернов, соглашений об именовании и архитектур; если модель не может разобраться в коде, есть заметная вероятность, что новый человек в команде столкнётся с тем же.

Поэтому ИИ становится ещё одним тестом на поддерживаемость — наряду с код-ревью, тестами, онбордингом и тем, кому придётся отлаживать этот код через полгода. Помогают понятная структура, единообразные имена, читаемые тесты, полезные абстракции и актуальная документация: они облегчают жизнь и агенту, и человеку, который будет код ревьюить, отлаживать и расширять.

Практика вместо спора

Вместо ещё одного хот-тейка GitHub предлагает проверить идею, собрать что-то и задокументировать результат. В статье приведены два примера такого подхода: Pollinations AI экспериментирует с генеративной платформой, где участники получают кредиты pollen за улучшение проекта — открывают и решают задачи, приносят модели и выполняют квесты, что поднимает вопросы об стимулах, качестве и масштабе.

Второй пример — Avian Visitors, лог сборки e-ink дисплея, который превращает птиц, прилетающих на балкон, в меняющуюся настенную картину: микрофон, Raspberry Pi, e-ink экран, напечатанные на 3D-принтере детали, сгенерированные изображения птиц и подробная документация.

Финальный совет GitHub собран из пяти пунктов: читать код достаточно, чтобы владеть результатом; набрать ИИ-грамотность, достаточную, чтобы объяснить свой способ работы; применять MCP там, где помогает стандартный интерфейс; использовать Skills там, где важны контекст и процесс; сохранять RAG, пока проверенная информация делает систему лучше.