GitHub и исследовательская программа Йельского университета по вопросам коммуникации о климате опубликовали совместное исследование о том, как разработчики относятся к климатическим рискам, искусственному интеллекту и эффективности программного обеспечения. Опрос показал высокий запрос на практические инструменты, метрики и рекомендации, которые помогут уменьшить лишнюю вычислительную нагрузку и связанный с ней экологический след.
В опросе участвовали 1039 пользователей GitHub из США, которые ранее согласились получать маркетинговые сообщения. Респондентов спрашивали о климате, ИИ, эффективности софта и роли технологических компаний. Авторы подчёркивают, что выборка носит непредставительный характер и отражает мнение участников опроса, а не всех разработчиков или пользователей GitHub.
80% опрошенных заявили, что заинтересованы в инструментах, помогающих писать более энергоэффективный код. Почти столько же хотят получить практики по снижению экологического влияния программного обеспечения. Около 75% респондентов заинтересованы в способах измерять воздействие своего кода или процессов разработки.
При этом только 10% разработчиков считают, что стиль их разработки и написания кода сильно влияет на личный экологический след. Ещё 28% оценивают это влияние как умеренное, а 63% — как небольшое.
Ответы показывают, что многие разработчики уже задумываются об экологических последствиях создаваемых систем. В вопросах, которые дублировали общенациональный опрос Climate Change in the American Mind, пользователи GitHub выразили более высокую обеспокоенность изменением климата, чем взрослое население США в целом.
По данным исследования, 86% пользователей GitHub уверены, что глобальное потепление происходит (против 68% взрослых в США). Для 82% это хотя бы отчасти личная тема (65% среди всех взрослых), а 68% ожидают как минимум умеренный личный ущерб (45% среди взрослых). 82% прогнозируют ощутимый вред для будущих поколений (68% у взрослых), а 79% говорят, что переживают из-за глобального потепления (66% среди взрослых.
Авторы отдельно поясняют, что различия с данными по населению США связаны как с составом выборки, так и с методологией опросов. Результаты не оценивают реальный экологический след ИИ или отдельных программных систем, а описывают только взгляды респондентов.
Разработчики в открытых ответах запросили инструменты, которые помогают оценивать:
- энергопотребление репозиториев и CI/CD-пайплайнов,
- лишние запуски GitHub Actions,
- неэффективный код и сценарии его оптимизации,
- вклад использования ИИ по сравнению с другими источниками нагрузки на вычислительные ресурсы.
Часть респондентов также предупредила о риске необоснованных «зелёных» заявлений. Авторы отчёта подчёркивают, что само по себе ускорение работы кода не доказывает снижение энергопотребления или выбросов. На итог влияют тип и характеристики оборудования, сценарий нагрузки, география, время выполнения и источник электроэнергии. Поэтому разработчикам нужны прозрачные метрики, которые соответствуют заявляемым эффектам.
Эффективность программного обеспечения уже считается частью качественной инженерной практики. Оптимизация кода способна снизить затраты на инфраструктуру, повысить производительность, уменьшить задержки и освободить ресурсы. Если улучшение сокращает объём вычислений при сохранении результата, это может снизить потребление энергии.
В отчёте предлагается начинать с поиска измеримых потерь в четырёх направлениях: код, данные, сеть и ввод-вывод. Конкретный показатель зависит от характера изменений. В качестве приближённых метрик авторы предлагают использовать:
- время выполнения,
- загрузка CPU,
- объём потребляемой памяти,
- размер сетевого трафика.
Каждый из этих показателей имеет ограничения, поэтому важно чётко указывать, что именно измерялось и что не оценивалось.
В качестве примера приводится пул-реквест, который заменяет поиск с вычислительной сложностью O(n²) на использование хеш-таблицы. Такой запрос на изменения должен содержать измерения «до» и «после» для репрезентативной нагрузки, команды для воспроизведения тестов и описание компромиссов, например по памяти или поддерживаемости. Это даёт более убедительное инженерное обоснование, чем заявление о «зелёности» без данных.
Авторы признают, что поиск задач по повышению эффективности в крупных репозиториях может быть медленным. Для автоматизации части работы GitHub предлагает использовать Agentic Workflows и открытый workflow Daily Efficiency Improver.
Daily Efficiency Improver анализирует репозиторий и ищет возможности для улучшений в пяти направлениях: код, данные, сеть, ввод-вывод и фронтенд-производительность. Он отдаёт приоритет изменениям, которые можно измерить, запускает тесты репозитория и может создавать черновики пул-реквестов с указанием доказательств и компромиссов для рассмотрения мейнтейнерами. Самостоятельного слияния изменений в основную ветку этот workflow не выполняет.
Перед включением расписания для такого workflow GitHub рекомендует внимательно изучить его разрешения, конфигурацию, использование моделей, частоту запусков и возможные вычислительные затраты. Начинать советуют с подходящего тестового репозитория или ручного запуска. Любые рекомендации следует рассматривать как гипотезы, пока их не подтвердят бенчмарки и тесты.
С точки зрения инженерной практики самые сильные пул-реквесты должны отвечать как минимум на пять вопросов: что изменено, зачем, как измерен эффект, какие есть компромиссы и как воспроизвести результаты. Конкретный перечень вопросов в тексте не расшифровывается, но акцент делается на воспроизводимости и доказательствах.
Авторы отмечают, что ИИ может помочь разработчикам искать, проверять и документировать потенциальные улучшения, однако финальные решения о том, насколько убедительны доказательства и стоит ли включать изменения в кодовую базу, принимают люди.
Работа по эффективности легче встраивается в процессы, когда использует знакомые для разработчиков инструменты и форматы: репозиторные workflow, черновики пул-реквестов, бенчмарки и тесты. В такой схеме workflow подсвечивает возможность улучшения, черновой пул-реквест предлагает решение, испытания подтверждают или опровергают результат, а мейнтейнеры принимают, дорабатывают или отклоняют изменения.
Таким образом, создаётся цикл, который даёт разработчикам то, чего они добивались в опросе: инструменты, измерения и понятный путь от обеспокоенности к конкретным изменениям в коде.
Полный отчёт Software Developers on Climate Change, AI, and Sustainable Software подготовлен GitHub совместно с Yale Program on Climate Change Communication. В нём подробно описана методология опроса, результаты и рекомендации, а также предлагается попробовать workflow Daily Efficiency Improver на подходящем репозитории и оценить его выводы.
Источник: GitHub, Yale Program on Climate Change Communication.
