В статье на GitHub Blog обсуждаются пять распространённых гипотез об использовании искусственного интеллекта в разработке программного обеспечения, в том числе утверждения, что сгенерированный код не нужно читать, что RAG устарел, а Skills отменили Model Context Protocol (MCP). Автор считает, что ценность этих высказываний заключается не в их краткой формулировке как таковой, а в разборе их условий и ограничений при применении к реальной работе.
Ответственность за код не передаётся модели
Основное правило, сформулированное в статье, заключается в том, что разработчик должен проверять код до той степени, при которой он способен объяснить результат и нести за него ответственность. Это не означает, что каждую строку нужно проверять с одинаковой глубиной: изменение в производственной системе аутентификации требует иной проверки, чем простой эксперимент с CSS.
Проверка может начаться ещё до того, как агент напишет какой-либо код, — с понимания текущей реализации, определения зависимостей и крайних случаев, а также составления плана. В других случаях полученный код требует непосредственной проверки обработки ошибок, прав доступа, доступа к данным, производительности, доступности и тестов. Согласно статье, искусственный интеллект меняет место приложения усилий, но не отменяет саму работу.
Самый важный навык — здравое суждение
В статье отвергается идея о том, что компании вообще не будут нанимать людей, не использующих искусственный интеллект, однако признаётся, что всё больше рабочих команд спрашивают кандидатов о том, как они используют эти инструменты. Самым сильным сигналом, согласно изложенной позиции, является не сам по себе энтузиазм по отношению к инструменту, а способность объяснить, когда разработчик его использует, а когда работает вручную, как проверяет его результаты и как балансирует между скоростью, качеством, безопасностью и сопровождаемостью.
Отказ от искусственного интеллекта может стать препятствием в компании, которая создаёт продукты на его основе или интенсивно его использует, но полная зависимость от него не является лучшим решением. Необходимо сохранять человека в контуре принятия решений и иметь чёткое понимание того, чему разработчик доверяет, а чему — нет.
MCP, Skills и RAG дополняют друг друга
В статье проводится различие между тремя инструментами. MCP предоставляет стандартизированный способ доступа агентов к инструментам и данным и их вызова, тогда как Skills содержат упакованные знания о методах работы команды, правилах изменения проекта или принятых соглашениях. Поскольку Skills обычно пишутся в формате Markdown, их читаемость для человека является частью их пользы.
RAG, или генерация с дополнением извлечённой информацией, обеспечивает систему релевантными сведениями, находящимися за пределами обучающих данных модели, — например, документацией, журналом поддержки, сведениями о продуктах, внутренними знаниями и контекстом кодовой базы. Качественное извлечение помогает модели начинать работу с контекста, более близкого к ответу, сокращая область поиска и вероятность неполного ответа.
Поэтому автор не считает, что Skills уничтожили MCP или что RAG умер: агент может использовать MCP для доступа к инструменту, следовать Skill для применения особых инструкций проекта и обращаться к извлечению информации для получения поддерживающего контекста. Противопоставление этих компонентов игнорирует то, как они могут объединяться в рамках одного рабочего процесса.
Сопровождаемость подвергается новой проверке
В статье также рассматривается идея о том, что необходимость обучать модель на конкретной кодовой базе обязательно означает плохое качество кода. Для специального обучения существуют обоснованные причины, однако неспособность модели понять кодовую базу может выявить проблему, с которой столкнётся и новый коллега.
Понятная структура, последовательные соглашения об именовании, удобные для чтения тесты, полезные абстракции и актуальная документация делают код более понятным как для агентов, так и для людей. Редакционный вывод здесь заключается в том, что инструменты искусственного интеллекта не освобождают команды от практик разработки программного обеспечения; напротив, они могут сделать недостатки сопровождаемости более заметными.
От обсуждения к эксперименту
В завершение статьи предлагается проверять мнения на практике, а не заменять каждое мнение противоположным. В ней упоминается проект Pollinations AI, где участники могут зарабатывать кредиты под названием pollen, улучшая проект, а также проект Avian Visitors, в котором документируется электронный чернильный экран, слушающий птиц и превращающий их визиты в изменяющиеся картины с использованием микрофона, Raspberry Pi, компонентов, напечатанных на 3D-принтере, и сгенерированных изображений.
Эти проекты не разрешают все дискуссии об искусственном интеллекте, но создают свидетельства и выявляют компромиссы. Основное ограничение материала заключается в том, что он предлагает общий ориентир и примеры, а не результаты сравнительных измерений, доказывающие превосходство конкретного рабочего процесса. Поэтому к его рекомендациям следует относиться как к отправным точкам для проверки на практике, а не как к окончательным правилам.