РАЗРАБОТКА

Питер Норвиг: AI-кодинг уже требует новых правил разработки

25% математических препринтов на arXiv уже признают помощь ИИ: Питер Норвиг считает, что практики разработки пора менять.

✍️ Редакция iTech News | 01.10.2026 | ⏱ 4 мин | Источник: The Register
🐛

Питер Норвиг, бывший директор по исследованиям Google и один из заметных ветеранов AI-индустрии, заявил на конференции в Сан-Франциско: AI-кодинг уже достаточно зрелый, чтобы менять не только инструменты, но и правила software engineering. Для русскоязычных команд это не абстрактная дискуссия про будущее, а вопрос ближайших ревью, пайплайнов, безопасности и того, кто отвечает за код, написанный агентом.

Свою позицию Норвиг изложил 30 сентября на открывающем keynote The AI Conference, сообщает The Register. Он напомнил цепочку технологических сдвигов: AlexNet и ImageNet в 2012 году, архитектура Transformer в 2017-м, запуск ChatGPT в 2022-м, затем появление reasoning- и coding-агентов в 2024-м. Логика простая: индустрия уже несколько раз переписывала представление о программировании, когда переходила от ручной коммутации мейнфреймов к ассемблеру, потом к языкам высокого уровня. Теперь пришла очередь практик вокруг ИИ-агентов.

Норвиг не стал продавать очередную сказку про «разработчик больше не нужен». Его тезис тоньше и неприятнее для процессов: если агент умеет писать значимый объем кода, старые договоренности о спецификациях, документации, истории изменений и ревью начинают трещать. Команды привыкли, что pull request отражает относительно понятный путь мышления автора. С агентами этот путь часто превращается в набор итераций, временных файлов, правок, подсказок и промежуточных состояний, которые никто нормально не сохраняет и не анализирует.

Самый наглядный пример Норвиг привел из собственной практики. Он работал с Codex, получил код, который вроде бы выполнял задачу, и попросил отправить pull request на ревью. Коллега быстро заметил проблему: вместе с изменениями в репозиторий попали 6 тыс. временных файлов. Норвиг признал, что сам не посмотрел дифф перед ревью. Сначала вывод был человеческий и довольно болезненный: надо было проверить. Затем он задал другой вопрос: почему модель вообще решила, что эти файлы следует отправлять рецензенту?

В этой истории смешно ровно до момента, пока такое не происходит в рабочем репозитории с приватными данными, автогенерированными артефактами или тяжелыми бинарниками. Для разработчика это уже не «модель иногда чудит», а конкретный пункт в инженерной гигиене: агент должен понимать границы репозитория, правила .gitignore, политику хранения артефактов и ожидания ревьюера. И если не понимает, процесс должен ловить это раньше человека, которому прилетает pull request на несколько тысяч мусорных файлов.

Норвиг также обратил внимание на то, как быстро меняется отношение к таким инструментам внутри самой инженерной культуры. По его словам, Линус Торвальдс за последние месяцы прошел путь от скептика к осторожному пользователю, а затем к активному стороннику ИИ в разработке. Это важный маркер: когда разговор доходит до ядра Linux и его автора, вопрос уже не в том, «можно ли пробовать», а в том, какие ограничения и практики нужны, чтобы не устроить пожар в инфраструктуре.

Еще один индикатор скорости изменений — математика. Норвиг напомнил, что еще два года назад GPT-4 спотыкался на простом подсчете букв в слове «strawberry». К августу 2026 года, по его словам, уже 25% математических препринтов на arXiv признавали помощь ИИ. Это не означает, что модели стали безошибочными математиками или надежными архитекторами. Но это показывает, насколько быстро ИИ из игрушки для демонстраций переехал в реальную интеллектуальную работу, где результат проверяют люди с высокой квалификацией.

Для бизнеса главный вывод скучнее хайпа, зато полезнее: AI-кодинг требует пересборки SDLC. Нужны новые правила для спецификаций, генерации тестов, трассировки решений агента, хранения промежуточных артефактов, доступа к данным и зависимости от внешних пакетов. Старый подход «разработчик отвечает за все, что попало в PR» остается юридически и организационно удобным, но технически он уже слабоват. Если половину изменений подготовил агент, компании придется решать, что именно она логирует, кто проверяет промпты, где хранятся контексты и как расследовать инцидент спустя три месяца.

Отдельный блок — безопасность. Норвиг прямо упомянул приватность, пайплайны данных, supply chain и мониторинг систем, которые могут уходить в самостоятельные действия. The Register добавляет к этому тревожный фон: уже есть случаи, когда AI-модели взаимодействовали с внешними сайтами так, что проблемы находили только после изучения логов. Для IT-директора или тимлида это означает простую вещь: агент без наблюдаемости — это не помощник, а новый непрозрачный участник продакшен-процесса.

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

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

Поделиться: Telegram X LinkedIn