Код
Код — единственная область с мгновенным внешним судьёй: он либо работает, либо нет. Поэтому модель здесь сильнее всего и опаснее всего: «работает» и «правильно» — разные вещи.
Везде в этой сфере трудной частью была проверка. С кодом иначе: его можно выполнить. Компилятор, проверка типов, набор тестов и стектрейс — это ровно тот внешний сигнал, который восьмая статья велела прицеплять при любой возможности, и достаётся он бесплатно.
Поэтому код — самое продуктивное применение ИИ из существующих. И поэтому же он даёт самые дорогие ошибки: «запустилось и напечатало что надо» не равно «правильно», а разрыв между этими двумя невидим, пока его не найдёт продакшн.
Не вставляй код, который не можешь объяснить.
Что показали исследования
Два результата, которые стоит унести.
В 2023 году Нил Перри с коллегами из Стэнфорда провели контролируемый эксперимент: участники, решавшие задачи с элементами безопасности при помощи ИИ-ассистента, писали менее защищённый код, чем работавшие без него, — и, что важнее, чаще были уверены, что их код безопасен. Обе половины сразу: результат хуже, уверенность выше. Это предвзятость автоматизации из десятой статьи с конкретным ценником.
Рядом стоят отраслевые анализы больших кодовых баз, где по мере распространения ассистентов отмечали рост дублирования и рост «оборачиваемости» кода — написали, а вскоре переписали или откатили. Это наблюдения, а не контролируемые эксперименты, так что держи их с оговоркой, но направление ожидаемое: производить правдоподобный код стало сильно дешевле, а понимать его — нет.
Общая закономерность обоих: узкое место сместилось. Написание кода больше не дорогая часть. Дорого читать, судить и отвечать.
Где сильнее всего
Объяснить код, который писал не ты. Незнакомая кодовая база, чужая функция, язык, к которому ты подходишь дважды в год, регулярка, которую никто не может прочесть. Самое недоиспользуемое применение из списка и самое безопасное: это преобразование поданного материала, а ответ проверяется чтением.
Отладка. Вставь ошибку целиком, стектрейс и относящийся код и попроси гипотезы, отсортированные по вероятности, с указанием, как проверить каждую. Не «почини», а гипотезы. Диагноз остаётся за тобой, а она поставляет кандидатов, которых ты мог не рассмотреть.
Обвязка и шаблоны. Настройка, конфигурация, стандартные операции с данными, миграции, склейка. Густо натоптано и немедленно проверяемо — идеальный квадрант.
Тесты — с одной оговоркой. Тесты, сгенерированные по твоей реализации, наследуют её ошибки: они утверждают то, что код делает, а не то, что он должен делать. Генерируй тесты из требований либо пиши тесты первыми и проси код, который их проходит. Тогда тест — настоящий внешний сигнал, а не зеркало.
Ревью. «Проверь это по списку: краевые случаи, обработка ошибок, конкурентность, валидация ввода, освобождение ресурсов». Явный чек-лист с большим отрывом бьёт «хорошо ли это?», и это настоящая вторая пара глаз на собственной работе — тот же приём, что и чтение своего текста чужими глазами.
Рефакторинг под тестами как страховкой. Зелёные тесты до, зелёные после. Без них рефакторинг моделью — это переписывание, которое ты не можешь проверить.
Разовые скрипты — в том числе для тех, кто вообще не программирует. Переименовать триста файлов, перекроить таблицу, вытащить данные из папки с PDF: здесь «пусть напишет скрипт» заменяет полдня кликанья, и работает правило восьмой статьи — проси метод, который можно запустить, а не результат, которому надо верить.
Где больно
Тихие ошибки корректности. Счастливый путь она проходит, а по краям импровизирует: пустой ввод, один элемент, юникод, часовые пояса, конкурентный доступ, отказ той системы, к которой она обращается. Код работает. Баг уезжает в релиз.
Безопасность. Дело не только в стэнфордском результате: модель воспроизводит паттерны из корпуса, где полно небезопасных, и не имеет представления о твоей модели угроз. Аутентификация, обработка ввода, права, секреты и всё, что касается денег и пользовательских данных, читается построчно и тобой.
Архитектура. Внутри функции она превосходна, поперёк системы слаба — системы нет на столе. Структурные решения, за которые платить ещё два года, остаются твоими.
Устаревшие API. Уверенно написанные вызовы методов, объявленных устаревшими после границы знаний. Сверяйся с документацией той версии, на которой ты сидишь.
Объём. Сгенерировать больше кода, чем ты успеваешь прочитать, стало тривиально. Каждая непрочитанная строка — строка, которую ты потом будешь отлаживать, не понимая; а отладка непонятого кода стоит дороже, чем стоило бы его написать.
Рабочие правила
Малыми кусками, с запуском после каждого. По функции за раз, выполнить, потом дальше. Двести строк, принятые разом, — это двести строк, которые ты потом будешь делить пополам вручную.
Давай настоящий контекст. Реальный код, реальные версии, полный текст ошибки, ограничение, которое важно. Половина плохих ответов здесь — просто пустая графа «материал».
Никогда не вставляй то, что не можешь объяснить. Не можешь сказать, что делает строка и зачем она здесь, — ты импортировал будущую аварию. Попроси объяснение (это бесплатно) или не бери код.
Никаких секретов во вставке, а всё просочившееся перевыпусти.
Типы и тесты — это поводок. Чем сильнее автоматический сигнал, тем больше можно безопасно делегировать. Это единственное место, где вложения в проверку прямо увеличивают допустимую долю ИИ.
За поставленное отвечаешь ты. Лицензии, безопасность, производительность и сопровождение — твои, чем бы ни был написан первый вариант.
Если ты учишься программировать
Неудобная часть, сказанная честно. ИИ радикально ускоряет получение работающего результата и может радикально замедлить становление навыка — потому что убирается именно та часть, где ты доводишь непослушное до работы, а навык растёт как раз там.
Это помещает программирование ровно в категорию навыков-целей из двенадцатой статьи, пока ты его осваиваешь. Пользуйся режимами репетитора: объясни этот код, почему мой вариант неверен, что на самом деле означает эта ошибка, дай задачу и не показывай решение. Сначала всегда попытка. И держи честную самопроверку: смог бы ты написать это без помощи? Медленнее — нормально. Не смог бы — это информация.
На практике
Проси объяснить чаще, чем написать.
Отлаживай гипотезами, а не «почини».
Генерируй тесты из требований, никогда из реализации.
Проводи ревью по явному чек-листу: краевые случаи, ошибки, конкурентность, валидация, освобождение ресурсов.
Малые куски, запуск каждого.
Не можешь объяснить строку — не отправляй её в релиз.
Проверь себя
Закрой статью и ответь своими словами:
- Почему код — одновременно лучшая и самая рискованная область для ИИ?
- Что показало стэнфордское исследование про безопасность — обе половины результата?
- Почему тесты, сгенерированные по реализации, не защищают и что делать вместо этого?
- Назови четыре категории тихих провалов, переживающих «оно запустилось».
- Почему «не вставляй то, что не можешь объяснить» окупается экономически, а не только морально?
- Почему сильные типы и тесты позволяют делегировать больше, а не меньше?
Коротко
- У кода есть мгновенный внешний судья — выполнение, типы, тесты, — поэтому это самое продуктивное применение ИИ и то, где «оно работает» прячет больше всего.
- Перри и др. (Стэнфорд, 2023): участники с ИИ-ассистентом писали менее защищённый код и были более уверены в его защищённости.
- Узкое место сместилось с написания кода на чтение, суждение и ответственность.
- Сильнее всего: объяснить незнакомый код, отладка гипотезами, обвязка, ревью по чек-листу, рефакторинг под зелёными тестами, разовые скрипты.
- Слабее всего: краевые случаи, безопасность, архитектура, API после границы знаний и объём, который ты не в силах прочитать.
- Тесты по реализации зеркалят её ошибки — генерируй из требований или пиши тесты первыми.
- Малые куски с запуском, настоящий контекст, никаких секретов, а типы и тесты — поводок, который позволяет отдавать больше.
- Пока учишься, программирование — навык-цель: сначала попытка, режимы репетитора, периодическая проверка, что справляешься сам.
- Не вставляй код, который не можешь объяснить.