Евгений Колунтаев, как эксперт в области Git-решений, рассказал TAdviser, сможет ли искусственный интеллект заменить программистов.
Бизнес, где в основе комплексные ИТ-системы и разработка, – а других скоро и не будет – сегодня готов сделать ставку на то, что «искусственный интеллект заменит программистов», ему не надо будет перерывов на сон, и он не будет ошибаться. Что не так с этой концепцией? Отвечу как эксперт в области Git-решений.
Если вы не знаете, что такое Git, то постараюсь дать простое описание. Если раньше над проектом мог работать один разработчик и писать код прямо на «боевом сервере», самостоятельно искать и исправлять ошибки, тестировать гипотезы, то со временем команды стали расти, их численность стала измеряться десятками, сотнями, тысячами. Так у «ствола» кода появились «ветки». Каждое ответвление живет своей жизнью. На определенном этапе, например, добавления в продукт новой фичи, нужно делать merge request, то есть объединения разных веток кода, что может приводить – и приводит – к конфликтам и другим проблемам. Поэтому делать merge request без проверки опасно, это может привести к негативными результатам. Поэтому версии кода хранятся в специальной среде, репозиториях, наиболее распространенной, устоявшейся архитектурой которых является Git. Существуют три глобальных зарубежных проекта - Gitlab, GitHub и Bitbucket. А также продукты на их базе.
При этом рынку нужно не просто хранилище, а продукт, который позволяет выполнять code review. Это проверка кода, поиск в нем ошибок и в целом анализа Legacy, то есть накопившихся проблем, таких как дубликаты кода, цикломатическая сложность, избыточность функций и так далее. Зачем это нужно?
Во-первых, если ничего не делать вообще, проблемы в коде постоянно накапливаются, вплоть до того, что в один момент продукт вообще придется переписывать с нуля. И это будет не атака хакеров и не отключение чего-то важного западными вендорами, а именно результат организационных просчетов.
Во-вторых, если до крайности не дойдет и осознание необходимости решения проблем в коде наступит до накопления их критической массы, придется делать рефакторинг. То есть множественные исправления, которые по сложности, трудоемкости, а значит, и дороговизне, не уступают первичной разработке. При этом с точки зрения бизнес-функций никаких изменений не будет, и это в лучшем случае. Трудно объяснить владельцу или топ-менеджеру, почему он должен тратить кучу денег просто за то, чтобы продукт продолжал работать «как было». Наконец, это еще и проблема безопасности. Ведь где ошибки, там и уязвимости. Кстати, иногда хакеры, готовящие сложную, но очень громкую атаку через цепочку поставок, не сразу расставляют свои «ловушки», в том числе бэкдоры, а как бы готовят почву для них. И этот момент традиционные средства анализа уязвимостей, сканеры и другие, могут и пропустить. А вот в ходе code review эти преднамеренные ошибки будут найдены и исправлены.
При этом лучшей на данный момент можно назвать схему, в которой инструменты защиты встроены, что называется, по умолчанию.
Это работает и в обратную строну. Принцип разработки безопасного программного обеспечения (РБПО, так же известен как DevSecOps), сегодня становится все более востребованным в России, в том числе, и в силу изменений в законодательстве. При этом два из трех запросов, в адрес ведущих РБПО-интеграторов, включают в себя code review.
Все это особенно важно в условиях реально идущего процесса импортозамещения. Понятно, что в этой ситуации некоторые продукты пишутся в авральном режиме, и анализ кода на качество и уязвимости им строго необходим.
В целях экономии времени многие разработчики делегируют часть задач ИИ, и вот тут мы возвращаемся к вопросу, с которого я начал. Может ли ИИ писать код? Безусловно, если речь идет о небольшом скрипте на 20 строк. Но вот справиться с большим сложным проектом языковая модель пока объективно не в состоянии. То есть количество ошибок увеличивается пропорционально размеру и сложности кода.
А это значит, что актуальность применения практик code review в эпоху ИИ-кодинга не просто растет, она взлетает. Кстати, для проверки кода ИИ-инструменты очень полезны, они очень быстро выявляют ошибки, в том числе, незаметные «невооруженным взглядом». Но к самостоятельной работе они пока не готовы.
Одну из причин этого я хорошо вижу, потому что занимаюсь Git-решениями. Ведь нейросети, а точнее, большие языковые модели, обучаются на огромных массивах данных. И где они берут данные для обучения кодингу? Разумеется, в открытых репозиториях, в первую очередь, GitHub. А качество кода в них, мягко скажем, неровное – от выдающихся работ до скриптов, написанных джунами. Есть там и фрагменты кода с бэкдорами и прочими уязвимостями. Есть просто плохой код, его очень много. И вот это все кладбище знаний – база обучения для модели. Конечно, потом она проходит дообучение и получает другие улучшения, но избавиться полностью от «родовой травмы» крайне трудно.
Плоды чрезмерного делегирования ИИ уже заметны, например, при пополнении команд ИБ-инженеров. Мы уже наблюдаем, как на техническое собеседование приходят кандидаты, которые решают тестовые задания, и мы понимаем, что это сделано полностью с помощью нейросети. У нас был кейс, когда мы задали кандидату вопрос и попросили не пользоваться моделью. И он не смог найти ответ. Еще один уже хрестоматийный пример – студенты, которые не могли вспомнить тему диплома спустя пару дней, потому что он был написан ИИ. К удобному привыкаешь быстро, и важные компетенции как будто бы становятся чем-то рудиментарным. Последствия оптимизма не внушают.
При этом невозможно и представить, что разработка полностью откажется от использования ИИ-решений. Как и полную замену специалистов нейросетями. Важен баланс, и современные Git-решения, в том числе, контролирующие качество кода и с встроенными практиками безопасной разработки, играют одну из ведущих ролей в этой игре.
Статья на TAdviser
При этом рынку нужно не просто хранилище, а продукт, который позволяет выполнять code review. Это проверка кода, поиск в нем ошибок и в целом анализа Legacy, то есть накопившихся проблем, таких как дубликаты кода, цикломатическая сложность, избыточность функций и так далее. Зачем это нужно?
Во-первых, если ничего не делать вообще, проблемы в коде постоянно накапливаются, вплоть до того, что в один момент продукт вообще придется переписывать с нуля. И это будет не атака хакеров и не отключение чего-то важного западными вендорами, а именно результат организационных просчетов.
Во-вторых, если до крайности не дойдет и осознание необходимости решения проблем в коде наступит до накопления их критической массы, придется делать рефакторинг. То есть множественные исправления, которые по сложности, трудоемкости, а значит, и дороговизне, не уступают первичной разработке. При этом с точки зрения бизнес-функций никаких изменений не будет, и это в лучшем случае. Трудно объяснить владельцу или топ-менеджеру, почему он должен тратить кучу денег просто за то, чтобы продукт продолжал работать «как было». Наконец, это еще и проблема безопасности. Ведь где ошибки, там и уязвимости. Кстати, иногда хакеры, готовящие сложную, но очень громкую атаку через цепочку поставок, не сразу расставляют свои «ловушки», в том числе бэкдоры, а как бы готовят почву для них. И этот момент традиционные средства анализа уязвимостей, сканеры и другие, могут и пропустить. А вот в ходе code review эти преднамеренные ошибки будут найдены и исправлены.
При этом лучшей на данный момент можно назвать схему, в которой инструменты защиты встроены, что называется, по умолчанию.
Это работает и в обратную строну. Принцип разработки безопасного программного обеспечения (РБПО, так же известен как DevSecOps), сегодня становится все более востребованным в России, в том числе, и в силу изменений в законодательстве. При этом два из трех запросов, в адрес ведущих РБПО-интеграторов, включают в себя code review.
Все это особенно важно в условиях реально идущего процесса импортозамещения. Понятно, что в этой ситуации некоторые продукты пишутся в авральном режиме, и анализ кода на качество и уязвимости им строго необходим.
В целях экономии времени многие разработчики делегируют часть задач ИИ, и вот тут мы возвращаемся к вопросу, с которого я начал. Может ли ИИ писать код? Безусловно, если речь идет о небольшом скрипте на 20 строк. Но вот справиться с большим сложным проектом языковая модель пока объективно не в состоянии. То есть количество ошибок увеличивается пропорционально размеру и сложности кода.
А это значит, что актуальность применения практик code review в эпоху ИИ-кодинга не просто растет, она взлетает. Кстати, для проверки кода ИИ-инструменты очень полезны, они очень быстро выявляют ошибки, в том числе, незаметные «невооруженным взглядом». Но к самостоятельной работе они пока не готовы.
Одну из причин этого я хорошо вижу, потому что занимаюсь Git-решениями. Ведь нейросети, а точнее, большие языковые модели, обучаются на огромных массивах данных. И где они берут данные для обучения кодингу? Разумеется, в открытых репозиториях, в первую очередь, GitHub. А качество кода в них, мягко скажем, неровное – от выдающихся работ до скриптов, написанных джунами. Есть там и фрагменты кода с бэкдорами и прочими уязвимостями. Есть просто плохой код, его очень много. И вот это все кладбище знаний – база обучения для модели. Конечно, потом она проходит дообучение и получает другие улучшения, но избавиться полностью от «родовой травмы» крайне трудно.
Плоды чрезмерного делегирования ИИ уже заметны, например, при пополнении команд ИБ-инженеров. Мы уже наблюдаем, как на техническое собеседование приходят кандидаты, которые решают тестовые задания, и мы понимаем, что это сделано полностью с помощью нейросети. У нас был кейс, когда мы задали кандидату вопрос и попросили не пользоваться моделью. И он не смог найти ответ. Еще один уже хрестоматийный пример – студенты, которые не могли вспомнить тему диплома спустя пару дней, потому что он был написан ИИ. К удобному привыкаешь быстро, и важные компетенции как будто бы становятся чем-то рудиментарным. Последствия оптимизма не внушают.
При этом невозможно и представить, что разработка полностью откажется от использования ИИ-решений. Как и полную замену специалистов нейросетями. Важен баланс, и современные Git-решения, в том числе, контролирующие качество кода и с встроенными практиками безопасной разработки, играют одну из ведущих ролей в этой игре.
Статья на TAdviser
