18 сентября 2026 года GitHub разобрал несколько популярных тезисов об ИИ из выпуска GitHub Podcast. Среди них: нужно ли читать сгенерированный код, заменили ли Skills протокол MCP и потерял ли смысл поиск по внешним данным. Общий вывод автора: эти вопросы полезнее решать по задаче и риску, а не выбирать победителя по громкому заголовку.
Для команды с собственным ботом это практический разговор. Инструкции, инструменты и поиск могут участвовать в одной работе, но отвечают за разные вещи. Убрать один элемент только потому, что появился другой, часто означает потерять нужную часть системы.
Код проверяют до понимания результата
Позиция GitHub о чтении кода простая: ответственность за него остаётся у человека. Но одинаковая глубина проверки для любого изменения не нужна. Эксперимент с CSS и переделка авторизации требуют разного внимания.
Часть проверки начинается ещё до генерации. Полезно понять текущую реализацию, зависимости, границы доступа и крайние случаи. Тогда готовый результат можно сравнить с осмысленным планом, а не просто посмотреть, запускается ли он.
В другом случае больше внимания потребует сам сгенерированный код: обработка ошибок, разрешения, доступ к данным, производительность, доступность интерфейса и тесты. Критерий автора: проверять до тех пор, пока можете объяснить результат и отвечать за него.
MCP даёт подключение, Skills объясняют порядок работы
MCP стандартизирует подключение агента к инструментам и данным. С его помощью разные системы могут согласованно вызывать функции, получать контекст и выполнять действия.
Skill хранит прикладные знания и правила. Он может описывать, как менять конкретный проект, пользоваться инструментом, соблюдать стиль команды или проверять результат. Читаемые инструкции удобны и агенту, и человеку.
Поэтому эти механизмы не заменяют друг друга. Подключённый инструмент не знает всех правил вашей команды, а текстовая инструкция сама по себе не создаёт доступ к сервису. Их сочетание позволяет отделить техническую возможность от правильного способа её применения.
Например, у помощника поддержки может быть подключение к базе обращений и инструкция о допустимых действиях. Это разные уровни. Возможность открыть обращение ещё не означает право закрыть его без согласования или отправить клиенту любой найденный текст.
RAG нужен, когда ответ зависит от актуальных данных
RAG добавляет к запросу подходящую информацию из внешних источников: документации, истории поддержки, сведений о товарах или кода. Модель получает материал, которого может не быть в её обучении.
Хороший поиск сокращает область, которую приходится изучать, и помогает связать ответ с конкретными данными. Агент при этом может использовать MCP для доступа к инструменту и следовать skill с правилами проекта. Конкуренции между этими частями нет.
Но наличие поиска само по себе не гарантирует качество. Для рабочей системы важно, чтобы находились нужные документы, соблюдались права доступа и устаревшая версия инструкции не подменяла актуальную. Это уже задачи организации данных и проверки результата.
Владение инструментом важнее крайних позиций
GitHub также обсуждает найм и дообучение. В работе с ИИ ценится способность объяснить свой процесс: где помощник полезен, как проверяется его результат и когда разумнее действовать вручную.
Потребность в дообучении не делает код автоматически плохим. Но если и человек, и модель с трудом понимают проект, полезно сначала разобраться со структурой, названиями, тестами и документацией. Читаемый проект проще сопровождать независимо от выбранной модели.
Практический вывод: сохраняйте инструменты, которые решают реальную задачу, и проверяйте эффект на своей работе. Skills, MCP и RAG могут прекрасно дополнять друг друга, а ответственность за код и действия агента по-прежнему остаётся у команды.
Как это выглядит на большом переносе: переписывание движка Copilot на Rust с помощью агентов.
