Главный вывод простой: ни один из трёх громких тезисов не выдерживает буквального прочтения. Код читать нужно, но глубина проверки должна зависеть от риска изменения. RAG не умер — он перестал быть универсальным ответом на любую задачу с контекстом. Skills не убили MCP, потому что эти механизмы находятся на разных уровнях: один описывает доступ к инструментам и данным, другой — правила работы и накопленную экспертизу.
Именно такая трактовка следует из материала GitHub Blog AI & ML, посвящённого выпуску GitHub Podcast. Но у неё есть важное ограничение: это редакционная позиция компании, а не сравнительное исследование с единым набором тестов. Поэтому полезнее проверить тезисы на архитектурах, которые уже доступны в открытых репозиториях, и отделить заявления авторов проектов от независимых наблюдений.
Код читает не тот, кто написал его вручную
Формула «если код сгенерирован, его всё равно нужно прочитать» звучит банально, но спор обычно скрывается в слове «прочитать». Полный построчный аудит каждого изменения не является автоматически более профессиональным подходом. Он может оказаться дорогим ритуалом, который отнимает время у действительно опасных мест.
GitHub предлагает более практическое правило: разработчик должен проверять код до той степени, пока способен объяснить и принять на себя последствия результата. Это не освобождает от ревью, а переносит внимание с происхождения строк на профиль риска.
Условный эксперимент с двумя изменениями показывает, почему это важно:
- небольшая правка стилей без доступа к данным обычно требует проверки результата, совместимости и тестов интерфейса;
- переработка аутентификации затрагивает права доступа, хранение секретов, обработку ошибок, миграции, журналирование и обратную совместимость.
Оба изменения может написать один и тот же агент, но цена ошибки у них различается на порядки. В первом случае разумно начать с diff, локального запуска и визуальной проверки. Во втором сначала нужно понять существующую реализацию, карту зависимостей и границы доверия, а уже затем оценивать предложение агента.
Это не только мнение GitHub. В препринте «3100 Opinions on Code Review in an AI World» авторы описывают модель, в которой ревью становится точкой управления последствиями работы кодингового агента. В их материале анализируются 38 709 документов из инженерных блогов и Reddit, а содержательно кодируется выборка из 3 100 документов. Эти числа относятся к методике самого исследования, а не к измерению качества AI-кода. Авторы отдельно подчёркивают, что наблюдаемые тренды нестабильны: выводы могут меняться в зависимости от исследовательских решений.
Из этого следует более узкая, но полезная мысль: скорость генерации не превращает ревью в формальность. Она может сделать его узким местом. Если команда принимает изменения быстрее, чем способна понять их, система становится уязвимой не потому, что модель обязательно плоха, а потому, что контроль не успевает за производством.
Чтение кода начинается до генерации
У AI-разработки есть неприятная особенность: самая ценная часть чтения часто происходит до появления первой строки нового кода. Нужно выяснить, где находится текущая логика, какие модули от неё зависят, какие инварианты не записаны в документации и что считается ошибкой.
Практическая последовательность для опасного изменения может выглядеть так:
Сформулировать ожидаемое поведение и список запретов.
Найти точки входа, вызывающие модули, схемы данных и тесты.
3. Попросить агента сначала описать текущий путь выполнения, не меняя файлы.
4. Сверить описание с кодом и журналами.
5. Только после этого разрешать реализацию.
6. Проверить diff, негативные сценарии, права доступа и обратную совместимость.
Такой порядок уменьшает риск «правдоподобного ремонта» не того места. Он также даёт человеку возможность обнаружить проблему в постановке задачи до того, как агент быстро создаст десятки согласованных, но неверных изменений.
Однако требование понимать каждую строку не всегда означает одинаковую глубину. Для экспериментального скрипта допустим один уровень доказательств, для платёжного сервиса — другой. Граница должна проходить не между «человеческим» и «сгенерированным» кодом, а между низким и высоким ущербом ошибки.
На практике полезно фиксировать для pull request три пункта: что изменилось, какие риски проверены и что осталось за пределами проверки. Это лучше, чем утверждение «код просмотрен», которое ничего не говорит о качестве контроля.
RAG не умер: он потерял статус универсального ответа
Тезис о смерти RAG обычно возникает из-за изменения контекста. Современные модели умеют работать с большими объёмами текста, агенты могут вызывать инструменты, а Skills позволяют загружать инструкции по мере необходимости. На этом фоне классическая схема «разбить документы на фрагменты, найти похожие, передать их модели» выглядит не единственным вариантом.
Но «не единственный» не означает «ненужный».
Retrieval-augmented generation нужен там, где ответ зависит от внешнего, изменяемого или частного набора знаний: внутренней документации, истории обращений, каталога товаров, исходного кода и эксплуатационных записей. Его сильная сторона не в том, что он делает модель умнее, а в том, что сокращает область поиска и подаёт модели контекст, которого не было в обучающей выборке.
Открытый проект umbertogriffo/rag-chatbot даёт удобный пример классического конвейера. Он принимает Markdown-файлы, делит их на части, строит векторные представления с помощью Sentence Transformers и сохраняет их в Chroma. При вопросе система сначала может переписать запрос, затем извлекает релевантные фрагменты и передаёт их локальной модели. Проект также описывает инкрементальное обновление индекса при изменении документов и предупреждает, что при замене embedding-модели индекс нужно строить заново.
Это не доказательство превосходства RAG и не промышленный бенчмарк. Зато оно демонстрирует, какую конкретную проблему решает retrieval: не генерацию инструкций и не вызов операций, а поиск подходящего материала в корпусе.
Слабое место RAG тоже хорошо видно из этой схемы. Ошибка может появиться на любом этапе: документ плохо разбит, запрос неудачно переписан, embedding не отражает смысл, в индекс попал устаревший текст, а модель уверенно обобщила неподходящий фрагмент. Поэтому вопрос «есть ли у нас RAG?» менее полезен, чем вопросы:
- какую коллекцию система индексирует;
- как измеряется полнота и точность поиска;
- как обрабатываются устаревшие документы;
- что происходит, если релевантный фрагмент не найден;
- можно ли показать пользователю основание ответа.
RAG действительно может быть избыточен для короткой, стабильной инструкции, которую проще держать в системном контексте или Skills. Но для меняющейся базы знаний он остаётся рациональным механизмом. Его будущее зависит не от моды на термин, а от качества поиска и стоимости ошибок.
Skills и MCP отвечают на разные вопросы
В дискуссии о Skills и MCP возникает ложный выбор: будто одна технология должна вытеснить другую. В материале GitHub MCP описывается как стандартный способ подключения агента к инструментам и данным, а Skills — как упакованная экспертиза, процесс или набор правил проекта.
Разница становится яснее на примере.
MCP отвечает на вопрос: «Как агент может обратиться к этой системе?» Это может быть вызов инструмента, получение данных или выполнение операции через стандартизированный интерфейс.
Skill отвечает на вопрос: «Как именно следует пользоваться этой возможностью в данном контексте?» В нём могут быть соглашения команды, порядок действий, ограничения, образцы, критерии готовности и ссылки на дополнительные материалы.
Иными словами, MCP может предоставить доступ к базе, а Skill — объяснить, какие таблицы допустимо читать, как проверять результат и что запрещено менять напрямую. MCP — интерфейс возможности; Skill — контекст её корректного применения. В реальной архитектуре они могут работать вместе, а не конкурировать.
Первичное свидетельство этого подхода — репозиторий claude-skills/CLAUDE.md. Его авторы описывают библиотеку из 388 готовых Skills в 20 доменах, 727 инструментов на Python, 842 справочных руководств, 118 агентов и 150 slash-команд, распределённых по 99 marketplace-плагинам. Это заявленные счётчики самого репозитория; они не являются независимой оценкой качества или полезности пакетов. В том же описании сказано, что счётчики выводятся скриптами из дерева проекта и проверяются автоматически.
Даже если принять эти числа только как характеристику масштаба проекта, пример показывает важную вещь: Skill — это не волшебная память модели. Это управляемый артефакт, который нужно версионировать, тестировать и пересматривать. Большая библиотека плохо написанных Skills способна увеличить путаницу так же легко, как большая библиотека инструментов.
Независимое описание паттерна progressive disclosure, опубликованное в LinkedIn, предлагает загружать сначала краткие метаданные Skill, затем полный SKILL.md и только после этого справочные документы. Это разумный способ экономить контекст, но пост в социальной сети не доказывает, что подход стабильно улучшает качество агента. Он лишь формулирует архитектурную гипотезу, которую можно проверить.
Проверка на кодовой базе: где место MCP, а где retrieval
Особенно наглядно различие видно в инструментах для исследования репозитория. Проект DeusData/codebase-memory-mcp заявляет, что индексирует кодовую базу, строит граф функций, классов, вызовов и маршрутов, а затем предоставляет 15 MCP-инструментов. Авторы также заявляют поддержку 162 языков и локальную обработку без отправки кода на внешний сервис.
Это именно заявления проекта, а не подтверждённые редакцией результаты. В описании также приводится собственный бенчмарк на 31 репозитории: 83% качества ответов, в 10 раз меньше токенов и в 2,1 раза меньше вызовов инструментов по сравнению с исследованием файлов по одному. Без исходных наборов задач, базовой линии, протокола и независимого повторения эти числа нельзя переносить на «AI-кодинг вообще».
Но сама архитектура полезна для анализа. MCP здесь служит транспортом и интерфейсом доступа к структурированному представлению кода. Векторный RAG мог бы найти похожие фрагменты по смыслу, но не обязательно восстановил бы цепочку вызовов, типовую связь или маршрут запроса. Skills, в свою очередь, могли бы объяснить агенту, как интерпретировать граф, какие зависимости считать критичными и в каком формате готовить отчёт.
Небольшой воспроизводимый тест для команды может разделить эти роли:
- взять 10 вопросов о репозитории: «где проверяется право доступа», «какие функции вызывают обработчик», «что произойдёт при пустом поле»;
- сравнить поиск по файлам, векторный поиск и структурный граф;
- записывать не только правильность ответа, но и число вызовов, объём переданного контекста и время;
- отдельно проверить, указал ли агент источник вывода;
- повторить тест после изменения схемы или переименования функций.
Метод ограничен: десять вопросов не дают статистически надёжного результата, а качество ответов зависит от конкретной кодовой базы. Зато он предотвращает подмену инженерного решения рекламным сравнением. Если задача структурная, граф может выиграть. Если нужно найти описание бизнес-правила в документации, retrieval окажется естественнее. Если нужно соблюдать процесс команды, решающим будет Skill.
Чистая кодовая база стала частью контекста
GitHub делает ещё один вывод: если модель не может разобраться в кодовой базе, проблема может быть не только в модели. Новому человеку такая система тоже, вероятно, дастся тяжело.
Это не означает, что fine-tuning никогда не нужен. В узких доменах с устойчивой терминологией и достаточным набором качественных примеров дообучение может иметь смысл. Но перед ним стоит проверить более дешёвые причины непонимания:
- устаревшие или противоречивые документы;
- имена, не отражающие назначение;
- чрезмерно большие модули;
- тесты, проверяющие детали вместо поведения;
- неявные зависимости;
- отсутствие примеров типовых сценариев;
- смешение инфраструктурной и бизнес-логики.
С этой точки зрения AI-агент становится ещё одним инструментом диагностики сопровождаемости. Если для простой задачи ему нужно скормить половину репозитория, это сигнал проверить архитектуру, границы модулей и качество навигации. Агент не заменяет ревьюера, но может показать, где намерение автора не выражено явно.
Здесь важно не сделать обратную ошибку и не объявить понятный модели код автоматически хорошим. Модель способна уверенно понять плохую архитектуру и воспроизвести её в новом месте. Читаемость — необходимое условие контроля, но не доказательство корректности.
Как выбирать технологию вместо победителя в споре
Для практической команды полезнее не голосовать за RAG, MCP или Skills, а составить карту задач.
Если требуется найти факты в изменяемом корпусе документов, начинать стоит с retrieval и оценки поиска. Если агенту нужно вызывать базы, файловые системы или внешние сервисы, нужен контролируемый интерфейс инструментов — здесь уместен MCP или иной протокол. Если критична последовательность действий, локальные соглашения и доменная экспертиза, нужны Skills или аналогичный слой инструкций.
Комбинация может выглядеть так: агент получает через MCP доступ к репозиторию и системе задач, через Skill — правила изменения проекта, а через RAG — релевантные документы и историю решений. Затем человек проверяет результат по уровню риска.
Что может изменить этот вывод? Независимый бенчмарк, где одни и те же задачи решаются с MCP, Skills, RAG и их комбинациями; открытые тестовые наборы; измерение не только точности, но и стоимости, задержки, числа вызовов, безопасности и удобства ревью. Если окажется, что Skills стабильно заменяют retrieval для широкого класса меняющихся знаний, RAG придётся сузить до специализированных случаев. Если структурный MCP-поиск будет хуже простого чтения файлов на разных языках, заявления о преимуществах потребуют пересмотра.
Пока доступные свидетельства говорят о другом: AI-разработка не движется к одной универсальной технологии. Она собирает слои. Код нужно понимать настолько глубоко, насколько велик риск. RAG остаётся механизмом поиска контекста. MCP предоставляет стандартизированный доступ. Skills передают правила и опыт. А качество всей системы определяется не самым модным компонентом, а тем, способен ли человек объяснить, проверить и при необходимости отменить результат.