Громкие заявления превращают сложные темы в одно уверенное предложение. Это отлично подходит для вовлечения аудитории, но не всегда помогает разобраться в сути.
На первый взгляд они не имеют большого значения. Вы соглашаетесь, не соглашаетесь, делаете репост, спорите пару минут и двигаетесь дальше. Иногда такое мнение оказывается верным по направлению. Иногда это полнейшая чушь.
Ценность громких заявлений заключается в том, что происходит, когда вы перестаете реагировать и начинаете разбирать их по косточкам. При каких условиях это верно? Какой контекст упущен? Какие допущения заложены в основу? Что меняется, когда вы применяете это в реальной работе?
В этом и заключается глубина. Хорошее смелое утверждение дает вам нечто достаточно острое, чтобы поставить под сомнение. Именно через вопросы вы находите полезные идеи.
Мы исследуем все это и многое другое в новом эпизоде подкаста GitHub!
Еще не готовы погрузиться в тему? Вот несколько распространенных спорных мнений об ИИ, которые мы обсудили, и то, что из них можно извлечь.
Горячая тема № 1: «Вам не нужно читать код, сгенерированный ИИ»
Да, нужно. Вы по-прежнему несете ответственность за этот код.
Но это не значит, что каждая сгенерированная строка требует одинакового уровня внимания.
Рефакторинг кода авторизации для продакшена заслуживает иного процесса ревью, чем эксперимент с CSS. Кодовая база, которую вы поддерживаете уже 10 лет, настраивает ваши инстинкты иначе, чем та, которую вы открыли сегодня утром. Притворяться, что каждое изменение несет в себе одинаковый риск — это не строгость. Это просто пустая трата времени.
Простое правило: делайте ревью до тех пор, пока не сможете объяснить результат и взять за него ответственность.
Иногда эта работа начинается до того, как агент что-либо напишет. Вы читаете текущую реализацию, сопоставляете зависимости, выявляете краевые случаи и составляете план. К моменту появления первой реализации вы уже понимаете, что она должна делать и где может пойти не так.
В других случаях сам сгенерированный код требует большей части вашего внимания. Вы проверяете обработку ошибок, права доступа, работу с данными, производительность, доступность и тесты.
ИИ перераспределяет усилия. Он не заставляет работу исчезнуть.
Настоящий навык заключается в понимании того, где таятся риски.
Горячая тема № 2: «Компании не наймут вас, если вы не используете ИИ»
Реальность выглядит немного сложнее. Все больше команд спрашивают кандидатов о том, как они используют ИИ. И это логично. Эти инструменты становятся частью разработки программного обеспечения.
Но никто не считает, что у каждого разработчика должен быть одинаковый рабочий процесс, те же инструменты или тот же уровень энтузиазма.
Куда более сильным сигналом является здравый смысл и способность принимать решения.
Можете ли вы объяснить, когда вы используете ИИ, а когда работаете вручную? Можете ли вы описать, как вы проводите ревью сгенерированного кода? Можете ли вы честно говорить о скорости, качестве, безопасности и сопровождаемости? Можете ли вы менять свой процесс по мере изменения инструментов?
Если компания создает продукты на базе ИИ или активно использует его в своей инженерной работе, отказ прикасаться к ИИ может сделать вас неподходящим кандидатом. В этом нет ничего спорного. Но как тотальная зависимость, так и полный отказ редко бывают правильным ответом.
Лучший ответ — это четкое объяснение того, как вы работаете, чему вы доверяете инструментам и где оставляете за собой контроль.
Такой уровень владения инструментом становится частью профессионального мастерства.
Горячая тема № 3: «Скиллы убили MCP»
Нет. Они решают разные задачи.
Протокол контекста модели (Model Context Protocol) предоставляет агентам стандартный способ подключения к инструментам и данным. Этот стандарт важен, когда вы хотите, чтобы системы работали вместе надежно. Агентам нужны структурированные способы вызова инструментов, получения контекста и выполнения действий.
Скиллы (Skills) ближе к упакованной экспертизе. Навык может объяснить, как работает команда, как следует изменять проект, как нужно использовать инструмент или какие соглашения имеют значение. Поскольку скиллы часто пишутся в формате Markdown, люди тоже могут их читать. Эта удобочитаемость является частью их ценности.
MCP может предоставить доступ. Скиллы могут объяснить, как правильно использовать этот доступ.
Вам не нужно выбирать победителя. Используйте стандарты для общих интерфейсов. Используйте скиллы для контекста, процессов и лучших практик.
Их комбинация гораздо интереснее, чем сам спор.
Горячая тема № 4: «RAG мертв»
RAG не мертв. Просто это уже не самая свежая тема, о которой все хотят написать пост.
Генерация, дополненная выборкой (Retrieval-augmented generation), предоставляет ИИ-системе актуальную информацию за пределами обучающих данных модели. Это может включать документацию, историю поддержки, детали продуктов, внутренние знания или контекст кодовой базы.
Без качественного поиска модель вынуждена полагаться на то, что она уже знает, или тратить больше времени на поиск контекста. Это растрачивает токены, замедляет работу и делает неполные ответы более вероятными.
Хороший поиск помогает модели начать ближе к ответу. Он сужает пространство поиска и обосновывает ответ информацией, которая действительно имеет значение.
Агенты, скиллы, MCP и RAG могут сосуществовать в рамках одного рабочего процесса. Агент может использовать MCP для доступа к инструменту, следовать навыку для получения инструкций по конкретному проекту и использовать поиск для нахождения подходящего вспомогательного контекста.
Эти вещи не борются друг с другом. Относится к ним так — значит не понимать, как люди на самом деле создают продукты с помощью ИИ.
Горячая тема № 5: «Если вам нужно дообучать модель под вашу кодовую базу, ваш код плох»
Существуют веские причины для дообучения (fine-tuning) модели. Тем не менее, современные модели видели огромное количество распространенных фреймворков, паттернов, соглашений об именовании и архитектур. Если модель не может разобраться в вашей кодовой базе, велика вероятность, что и у нового члена команды возникнут с этим трудности.
ИИ становится еще одним испытанием на прочность для сопровождаемости кода — наряду с код-ревью, тестированием, онбордингом и несчастным коллегой, который будет отлаживать этот код через шесть месяцев.
Четкая структура помогает. Понятны имена помогают. Читаемые тесты, полезные абстракции и актуальная документация — все это помогает.
Эти вещи облегчают понимание кодовой базы для агента, но, что еще важнее, они облегчают человеку проведение ревью, отладку и расширение кода.
Разработка с поддержкой ИИ вознаграждает кодовые базы, в которых намерения очевидны.
И это прекрасно.
Реальная работа интереснее дебатов
ИИ продолжит вызывать бурные мнения, потому что инструменты меняются быстро, и мы все еще осваиваем наши рабочие процессы.
Вам не нужно выбирать постоянную сторону в каждом споре.
Лучшая реакция на интересное мнение — это не другое мнение. Проверьте идею. Создайте что-нибудь. Задокументируйте то, что произошло. Дайте всем что-то реальное, из чего можно извлечь уроки.
Pollinations AI делает это, экспериментируя с платформой генеративного ИИ, где участники могут зарабатывать кредиты (называемые пыльцой), улучшая проект. Люди могут открывать и решать задачи, вносить свой вклад в виде моделей и выполнять квесты. Проект поднимает реальные вопросы о стимулах, качестве, масштабе и о том, как может выглядеть вклад в открытый исходный код, когда ИИ снижает барьер для участия.
Avian Visitors делает это совершенно по-искусственному, но иному пути. Это журнал сборки для дисплея на электронных чернилах для прослушивания птиц, который превращает птиц, посещающих балкон квартиры, в меняющееся настенное искусство. Он объединяет микрофон, Raspberry Pi, экран на электронных чернилах, напечатанные на 3D-принтере детали, сгенерированные изображения птиц и продуманную документацию.
Эти проекты не разрешают все споры об ИИ. Они делают кое-что более полезное: они создают доказательства, обнажают компромиссы и дают другим людям точку опоры для старта.
Читайте достаточно кода, чтобы нести ответственность за результат. Развивайте достаточную грамотность в сфере ИИ, чтобы уметь объяснить свою работу. Используйте MCP, когда помогает стандартный интерфейс. Используйте навыки (skills), когда важны контекст и процесс. Применяйте RAG, когда обоснованная информация делает систему лучше. Если ваш код ставит в тупик как людей, так и модели, рассматривайте это как проблему сопровождаемости.
Самое главное — применяйте на практике то, чему учитесь.
Подкаст GitHub: подпишитесь, чтобы не пропустить ни одного выпуска!
Автор
GPS — старший адвокат по работе с разработчиками (Developer Experience Advocate) в GitHub. Она помогает сделать GitHub лучше для разработчиков посредством общения с сообществом, выступлений на конференциях, практических семинаров, полезных демо-материалов и здоровой порции мемов. В свободное время она создает популярные учебные материалы по облачной инженерии на сайте learntocloud.guide.
Узнайте больше от GitHub
Документация
Все необходимое для освоения GitHub в одном месте.
Перейти к документации
GitHub
Создавайте будущее на GitHub — месте, где каждый и откуда угодно может создать что угодно.
Начать разработку
Истории клиентов
Познакомьтесь с компаниями и инженерными командами, которые создают продукты с помощью GitHub.
Узнать больше
GitHub Universe 2026
Присоединяйтесь к нам 28–29 октября в Сан-Франциско или онлайн на GitHub Universe — нашей главной конференции для разработчиков, объединяющей людей, агентов и мировой код.
Зарегистрироваться