Искусственный интеллект пишет код, но сможет ли ваша инфраструктура справиться?

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

Я провел годы, работая над инструментами DevOps, соавторствуя исследования и помогая командам инженеров достичь их最高 возможных результатов. То, что я вижу сейчас с развитием, основанным на ИИ, – это больше, чем просто эволюция. Это раскрывает каждую трещину в наших существующих рабочих процессах.

Проблема уже здесь

Исследование 2025 GitClear показало, что почти 7% коммитов теперь содержат код, сгенерированный ИИ. Их ранее анализ 153 миллионов строк измененного кода показал стоимость: “code churn” – код, переписанный или удаленный в течение двух недель, – удвоился к 2024 году по сравнению с базовыми показателями до ИИ.

Последствия для безопасности не менее тревожны. Недавний анализ 80 отобранных задач программирования по более чем 100 крупным языковым моделям показал, что код, сгенерированный ИИ, вводит уязвимости безопасности в 45% случаев. Реальное воздействие? Одна из пяти компаний теперь сообщают о серьезных инцидентах,直接 вызванных кодом, сгенерированным ИИ.

Прирост скорости реален, но так же реальны и затраты на стабильность.

Эффект усиления

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

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

Парадокс детерминизма

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

Мой ответ? Сохранять как можно больше стека детерминированным. Если вы можете поддерживать 80% своей инфраструктуры на детерминированном уровне, ваши агенты ИИ имеют меньше переменных для управления. Они не тратят контекстные окна на “Почему эта зависимость не установлена?” или “Давайте попробуем эту команду сборки снова.” Они сосредоточены на реальной работе, которую вы просите их делать.

Подумайте об этом: когда агент пытается скомпилировать что-то, а родные привязки не удается из-за отсутствия ImageMagick, это токено-расходная поездка. Если ваша среда уже включает все необходимое (компиляторы, библиотеки, полное дерево зависимостей до libc), агент просто работает. Никакого отладочного, никакого проб и ошибок, просто прогресс.

Спецификация и проверка имеют решающее значение

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

Я заметил что-то интересное: люди с фоном в управлении продуктом или инженерии продукта часто более успешны с агентами ИИ прямо сейчас. Они уже обучены думать в терминах требований, критериев успеха и компромиссов. Они комфортно спрашивают “Почему вы сделали этот выбор?” и корректируют на основе рассуждений.

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

Доверяйте, но проверяйте (и контролируйте)

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

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

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

Что дальше

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

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

Вот мой главный совет для команд, пытающихся преуспеть в эпоху ИИ:

• Стандартизируйте безжалостно. Меньше переменных коррелирует с более высокими результатами. Заблокируйте свою технологическую стек, обеспечьте последовательные среды на всех платформах и устраните конфигурационную дрейф до того, как ИИ усилит ее. Если несоответствия версий Python вызывают проблемы сейчас, они вызовут в 10 раз больше проблем, когда ИИ будет генерировать код в большом масштабе.

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

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

Вопрос не в том, будет ли ИИ писать большинство нашего кода. Он уже делает это для многих команд. Вопрос в том, сможет ли наша инфраструктура справиться.