GitHub выпустил новый выпуск GitHub Podcast, посвященный «горячим» тезисам про ИИ в разработке. Авторы обсуждают популярные упрощённые мнения об ИИ-инструментах и разбирают, как они работают на практике, в том числе через примеры реальных проектов.
По мнению авторов, краткие «горячие» тезисы удобны для вовлечения, но плохо подходят для понимания. Польза появляется, когда такие утверждения разбирают по условиям, контексту и скрытым допущениям. Вопросы «когда это верно?», «что упущено?» и «как это работает в реальных задачах?» помогают извлечь из них полезные идеи.
Одна из тем выпуска — ответственность за код при использовании генерации. Разработчик по-прежнему отвечает за результат, но уровень проверки должен зависеть от риска изменения: масштабный рефакторинг аутентификации требует одного процесса ревью, небольшой эксперимент с CSS — другого. Авторы предлагают простое правило: проверяйте код до тех пор, пока можете объяснить и «принять на себя» итог.
Подготовка иногда начинается ещё до работы агента: разработчик изучает текущую реализацию, зависимости и крайние случаи, а уже потом оценивает сгенерированное решение. В других случаях основное внимание уделяется самому коду: обработке ошибок, правам доступа, работе с данными, производительности, доступности и тестам. ИИ меняет распределение усилий, но не убирает саму работу.
Выпуск затрагивает и тему найма: растёт число команд, которые спрашивают кандидатов, как они используют ИИ-инструменты. Ожидания при этом разные: никому не нужен одинаковый набор инструментов и подходов у всех разработчиков. Все больше ценится умение объяснить, когда вы используете ИИ, как проверяете результат и как учитываете скорость, качество, безопасность и сопровождаемость. Полный отказ от ИИ в компаниях, где он критичен для продуктов и процессов, может стать минусом, но столь же проблематична и полная зависимость от него.
Авторы называют такую осознанную «грамотность» частью профессионального уровня: уметь описать свой процесс, зону доверия к инструментам и точки, где человек обязан оставаться в контуре принятия решений.
Отдельный блок обсуждения посвящен Model Context Protocol (MCP) и так называемым skills. MCP описывается как стандартный способ для агентов подключаться к инструментам и данным, а skills — как «упакованный опыт»: знания о том, как работает команда, как менять проект, использовать инструмент и соблюдать правила. Skills часто пишут в Markdown, поэтому их могут читать и люди. MCP даёт доступ к ресурсам, skills помогают использовать этот доступ осмысленно. Авторы подчёркивают, что не нужно выбирать «победителя»: стандарты подходят для интерфейсов, skills — для контекста и процессов.
RAG (retrieval-augmented generation) в подкасте называют по‑прежнему актуальным подходом, хотя он уже не в трендах обсуждений. RAG позволяет модели использовать внешние по отношению к обучающим данным источники информации: документацию, историю поддержки, детали продукта, внутренние базы знаний и контекст кода. Без качественного поиска модель опирается только на собственные знания или тратит лишние токены на поиск, что замедляет работу и повышает риск неполных ответов. Хорошая выборка приводит модель ближе к нужному ответу и «приземляет» генерацию на релевантных данных.
Авторы подчёркивают, что агенты, skills, MCP и RAG отлично сочетаются в одной цепочке: агент может использовать MCP для доступа к инструменту, опираться на skill с инструкциями по проекту и задействовать RAG для получения нужного контекста. Противопоставлять эти подходы некорректно, они решают разные части одной задачи.
Ещё один важный тезис связан с дообучением моделей на коде. В подкасте признают, что у дообучения есть оправданные случаи, однако современные модели уже видели огромное число типовых фреймворков, паттернов и соглашений по именованию. Если модель не может разобраться в кодовой базе, высока вероятность, что новый разработчик тоже столкнётся с теми же трудностями. Это превращает ИИ в дополнительный тест на сопровождаемость: вместе с кодревью, тестированием и онбордингом.
Хорошая структура проекта, понятные имена, читаемые тесты, полезные абстракции и актуальная документация облегчают жизнь и агентам, и людям. Авторы делают вывод: разработки с ИИ поощряют код, в котором намерения ясны из структуры и текста.
Подкаст отмечает, что «горячие» мнения об ИИ будут появляться и дальше, так как инструменты быстро меняются, а команды продолжают искать рабочие процессы. Слухачам предлагают не занимать жёсткие позиции, а проверять идеи на практике: строить прототипы, фиксировать результаты и делиться ими.
В качестве примеров приводятся два проекта. Pollinations AI экспериментирует с генеративной платформой, где участники зарабатывают кредиты (pollen), улучшая проект: решают задачи, добавляют модели, проходят «квесты». Это поднимает вопросы мотивации, качества, масштабирования и того, как может выглядеть вклад в открытые проекты, если ИИ снижает порог входа.
Проект Avian Visitors демонстрирует другую грань. Это лог разработки e‑ink‑дисплея, который превращает птиц на балконе квартиры в меняющееся настенное оформление. Он объединяет микрофон, Raspberry Pi, e‑ink‑экран, 3D‑печатные детали, сгенерированные изображения птиц и подробную документацию. Такие инициативы, по оценке авторов, не закрывают споры об ИИ, но создают реальные данные, показывают компромиссы и дают другим отправную точку.
В финале выпуск подводит практические выводы: читайте достаточно кода, чтобы отвечать за результат, развивайте ИИ‑грамотность, используйте MCP там, где помогает стандартный интерфейс, применяйте skills для контекста и процессов, сохраняйте RAG там, где важна опора на фактические данные. Если код запутан и для человека, и для модели, это сигнал к работе над сопровождаемостью. Главный совет — превращать полученные знания в действующие решения.
Ведущая выпуска — GPS, Senior Developer Experience Advocate в GitHub. Она занимается улучшением работы разработчиков с платформой через общение с сообществом, доклады, практические воркшопы, демонстрации и образовательные материалы.
В анонсе также упоминаются другие темы GitHub Podcast: объяснение терминов ИИ в разработке, снижение стоимости разработки и рост стоимости владения кодом, перенос рантайма Copilot‑агента на крупный продакшен‑проект на Rust, автоматизация рабочих процессов команды маркетинга в регионе APAC и использование приложения GitHub Copilot для удобной проверки кода, запуска команд и предпросмотра веб‑приложений.
Источник: материалы GitHub и GitHub Podcast.
