Почему предприятиям по-прежнему нужны люди-разработчики, даже если код сгенерирован искусственным интеллектом

Что происходит, когда предприятия чрезмерно полагаются на код, написанный искусственным интеллектом

Чрезмерная зависимость от кода, написанного ИИ, не приводит к громким провалам. Постепенно это выходит из строя. Системы незаметно накапливают долги, а бреши обнаруживаются только под давлением:во время инцидента, аудита или нарушения безопасности.

1. Технический долг

ИИ генерирует код, который работает для подсказки, а не для системы. Без архитектурного решения, определяющего каждый результат, в базе кода накапливаются противоречивые шаблоны и избыточные абстракции, которые являются приемлемыми на местном уровне, но дорогостоящими в глобальном масштабе.

И это происходит быстро. Долг, создаваемый темпами развития ИИ, приходит быстрее, чем любая команда может поглотить.

Команды, которые спешат выпустить продукт, не принимая во внимание проектные решения, в конечном итоге получают кодовую базу, которую никто до конца не понимает, и рефакторинг которой обходится дороже, чем написание.

2. Тихие неудачи

Код, сгенерированный ИИ, имеет тенденцию хорошо обрабатывать счастливый путь и плохо справляться с неудачным путем. Пограничные случаи, которых не было в приглашении, просто не обрабатываются, и в отличие от синтаксической ошибки, отсутствующий режим отказа не объявляет о себе до тех пор, пока условия не станут совершенно неправильными.

Скрытые сбои — самый опасный класс корпоративных ошибок. Платеж, который обрабатывается дважды, запись, которая записывается частично, оповещение, которое никогда не срабатывает:все это не проявляется при тестировании.

Они не запускают мониторинг. Их обнаруживают по последующим последствиям, обычно спустя много времени после нанесения ущерба.

3. Риски безопасности

Модели генерируют код на основе шаблонов своих обучающих данных, включая небезопасные шаблоны, устаревшие библиотеки и устаревшие подходы. Если разработчик активно не моделирует угрозы, уязвимости поставляются вместе с функциями:поверхности для внедрения SQL, секреты жестко запрограммированы, проверка входных данных пропускается.

Более тонкий риск — ложная уверенность.

Код ИИ, прошедший проверку кода и автоматическое сканирование, по-прежнему может содержать архитектурные уязвимости:нарушение границ доверия, открытые маршруты повышения привилегий, раскрытие данных, заложенное в дизайн. Это требует соображений безопасности человека, а не проверки.

4. Потеря понимания системы

Самый большой риск не технический. Это организационно.

Когда разработчики используют ИИ для создания кода, они не читают, не обсуждают и не владеют им полностью, институциональные знания о том, как работает система, перестают накапливаться.

Со временем разработчики теряют способность рассуждать о системе в целом. В результате получается кодовая база, которую никто не понимает и которую никто не может безопасно изменить.

Некоторые предприятия уже принимают контрмеры:обязательные проверки понимания кода, парное программирование вместе с инструментами искусственного интеллекта, ужесточение стандартов PR.

Но без целенаправленных усилий это остается структурной хрупкостью, которая постепенно накапливается, пока что-то не заставит команду противостоять ей.

Как меняется роль корпоративных разработчиков

Роль корпоративного разработчика меняется от написания кода к его управлению и от ручной реализации к оркестровке с помощью искусственного интеллекта, основанной на суждениях и ответственности, которые может обеспечить только человек.

1. От написания к проверке

Основной результат работы разработчика — это уже не строки кода; это решения о коде. Это означает, что нужно критически читать результаты, созданные искусственным интеллектом, выявлять, чего не хватает или что-то не так, утверждать только то, что подходит для производственной системы и иметь реальные последствия, а также выявлять бреши в безопасности, упущения в крайних случаях и архитектурные несоответствия перед отправкой.

Это требует большего, а не меньшего суждения. Разработчик, который не умеет писать код, определенно не способен его проверить.

2. От реализации к организации

Разработчики все чаще берут на себя ответственность за составление систем из компонентов, созданных искусственным интеллектом, сторонних сервисов и внутренних платформ. Работа по внедрению уменьшается; увеличивается работа по интеграции и координации.

Это означает управление контрактами и интерфейсами между собранными компонентами, обеспечение согласованного поведения систем, созданных из разных источников, устранение сбоев в местах соприкосновения компонентов и нарушение предположений, а также координацию действий между командами, поставщиками и платформами, а не разработку каждого уровня.

Ремесло переходит от авторства к архитектуре и от исполнения к дизайну.

3. От скорости к безопасности и устойчивости

ИИ увеличивает скорость создания кода. Задача корпоративных разработчиков — следить за тем, чтобы скорость не ставила под угрозу безопасность. Это означает владение:

• Наблюдаемость :приборы и журналирование встроены в конструкцию, а не модернизированы.
• Восстанавливаемость :пути отката и границы ошибок определяются до того, как они потребуются.
• Защита :архитектурные решения, которые выдерживают проверку регулирующих органов или посмертную проверку.
• Скорость :знать, когда нужно притормозить, потому что этого требует профиль риска.

Ценность разработчика в среде, дополненной искусственным интеллектом, не в скорости. Именно суждение не позволяет скорости стать ответственностью.

Когда ИИ должен помогать разработчикам, а не заменять их

ИИ обеспечивает реальное влияние, когда он действует как инструмент под руководством человека. В тот момент, когда к нему относятся как к лицу, принимающему решения по архитектуре, безопасности или соответствию требованиям, предприятие заменяет подотчетность автоматизацией, а суждение - вероятностью.

Применение искусственного интеллекта

ИИ наиболее ценен в тех частях разработки, которые требуют большого объема работ и не требуют больших усилий с первой попытки. Сильные примеры использования:

• Создание шаблона: формирование шаблонов, операции CRUD, повторяющиеся шаблоны в разных сервисах.
• Написание тестов :создание модульных и интеграционных тестовых примеров из существующих сигнатур функций.
• Документация :создание встроенных комментариев, документации API и содержимого README из контекста кода.
• Помощь в проверке кода :выявление очевидных проблем, противоречивых шаблонов и нарушений стиля.
• Поддержка рефакторинга :реструктуризация понятного кода с четкими намерениями до и после.
• Ускорение отладки :сужение источников ошибок и предложение возможных исправлений.
• Прототипирование :быстрое изучение того, как может выглядеть решение, прежде чем переходить к конкретному подходу.

Во всем этом ИИ сжимает время. Разработчик по-прежнему владеет результатом, но достигает его быстрее.

Где человеческое суждение не подлежит обсуждению

Существует четкий набор решений, согласно которым удаление человека не просто создает риск. Это устраняет структуру подотчетности, от которой зависит предприятие:

• Проектирование системы и границы обслуживания: решения, которые будут ограничивать кодовую базу на долгие годы.
• Архитектура безопасности :моделирование угроз, границы доверия, дизайн привилегий.
• Решения о соответствии: какие данные собираются, как они хранятся, кто может получить к ним доступ.
• Производственные инциденты :диагностика, эскалация, откат вызовов под давлением.
• Интеграция устаревших версий :управление недокументированным поведением и минимизация радиуса взрыва.
• Решение компромисса :выбор между конкурирующими ограничениями без однозначного ответа.
• Вскрытие и обучение :извлечение институциональных знаний из неудач.

Это не те задачи, с которыми ИИ справляется плохо. Это задачи, в которых решение человека само по себе является частью того, что требуется предприятию.

Почему на предприятиях важен человеческий фактор

В потребительском программном обеспечении неправильное решение, принятое ИИ, приводит к ошибке. В корпоративном программном обеспечении это может привести к нарушению нормативных требований, инциденту безопасности или сбою в работе с договорными последствиями. Ставки меняют то, что должен содержать цикл.

Участие человека в корпоративном контексте означает, что ни один код, созданный ИИ, не поступает в производство без разрешения разработчика. Это означает, что архитектурные решения предшествуют реализации с помощью ИИ, а не наоборот.

Каждое системное решение принимается конкретным инженером, который его понял и одобрил. Результаты ИИ рассматриваются как черновик, а не как результат. А мониторинг, оповещение и реагирование на инциденты по-прежнему разрабатываются и выполняются людьми.

Цель не в том, чтобы замедлить работу ИИ. Это делается для того, чтобы скорость, которую обеспечивает ИИ, не разрывала связь между решениями и последствиями, на которой построено корпоративное программное обеспечение, регулирование и доверие организации.

Заключение

Команды разработчиков по-прежнему важны, поскольку самые сложные части строительных технологий (архитектура, подотчетность, институциональная память) всегда требовали принятия решений человеком.

Новая реальность проста:улучшайте инструменты, доступные разработчикам, а не заменяйте их. Используйте ИИ для обострения мышления, а не для его замены. И развертывайте его с пониманием того, что в конечном итоге результат будет принадлежать кому-то.

Организации, которые создадут самое надежное программное обеспечение в следующем десятилетии, не будут создавать больше всего кода. Они будут теми, кто сочетает скорость ИИ с человеческим суждением и точно знает, где должна проходить граница между ними.

Если вам нужен реалистичный партнер, который поможет вам выяснить, где ИИ является положительным моментом в вашей инженерной организации, а где он представляет риск, команда Imaginovation может помочь вам составить эту дорожную карту.

Давайте поговорим.