Команда AI for Devs подготовила перевод статьи о том, как быстро растущие AI-ассистенты меняют саму природу разработки. Их код выглядит безупречно — но всё чаще решает не ту задачу, что стоит перед нами. Где проходит граница между ускорением и самообманом, и какую новую ответственность это накладывает на инженеров?

Что будет, когда ваш AI-ассистент научится писать безупречно выглядящий код, который решает не ту задачу

На прошлой неделе, во вторник, случилось кое-что странное.

В командный чат ворвалась взволнованная джун-дата-сайентистка. Несколько дней она билась над задачей классификации — той самой, из реального мира, где данные упрямо ни с чем не согласуются. Потом она попробовала ChatGPT. Вставила описание задачи — и получила готовое решение: предобработка, обучение модели, оценка, даже код для визуализации. Она запустила его. Точность — 94%.

Все её поздравили. К четвергу модель выкатили в прод.

К понедельнику она провалилась с треском.

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

Когда безупречный код скрывает непонимание сути задачи

Вот что вам почти никто не скажет про AI-ассистентов для написания кода: они блестяще справляются с тем, чтобы писать рабочий код без ошибок. Но вот понять, ту ли задачу они решают, — это им не по силам.

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

Но вот чего AI не заметил — и чего никто не увидел до продакшна: в обучающей выборке были клиенты, которые уже участвовали в предыдущих кампаниях. Модель научилась предсказывать тех, кто раньше реагировал на маркетинг, — по сути, просто запомнила прошлое поведение. А когда её применили к действительно новым клиентам, она понятия не имела, что делать.

Показатель точности был реальным. Модель работала ровно так, как была написана. Просто она решала задачу «предсказать тех, кто откликался в прошлом», а не «предсказать тех, кто откликнется в будущем». А разница здесь — принципиальная.

Правдоподобный фасад компетентности

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

Вспомните, как вы пишете код, когда только разбираетесь в задаче. Он получается неаккуратным. Вы оставляете TODO, называете переменные temp и x2, пишете слишком длинные функции, потому что ещё не уверены, как их правильно разнести. Сам код показывает вашу неуверенность.

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

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

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

Вопросы, которые мы перестали задавать

До появления AI-ассистентов код-ревью означал чтение логики, проверку допущений, обсуждение выбранных решений. Вы видели, что кто-то проходит по датафрейму в цикле вместо векторизации, и спрашивали: «почему не использовать .apply()?» Вы замечали хардкод и уточняли: «разве это не должно быть параметром?»

Эти вопросы касались не только качества кода. Это была проверка понимания. Выборы, которые человек делал в процессе, показывали, насколько он вообще разобрался в задаче.

Теперь код приходит уже отполированный. Циклы векторизированы. Хардкода нет. Стиль единообразный. Все поверхностные проблемы решены.

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

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

Новая грамотность: читать то, чего не написано

Дата-сайентистам теперь нужна новая компетенция. Не умение писать более аккуратный код — с этим AI уже справляется. И даже не умение внимательнее этот код читать. Навык — в умении читать то, чего в коде нет: скрытые допущения, нерассмотренные альтернативы, крайние случаи, о которых никто не подумал.

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

AI-ассистенты не могут проверить допущения, о существовании которых они даже не подозревают. Они работают по узнаваемым шаблонам из своих обучающих данных: «задача классификации на табличных данных» → «стандартный train-test split и модель на random forest или градиентном бустинге». Этот шаблон достаточно часто приводит к приемлемому результату, поэтому он и закрепился.

Но «достаточно часто работает» — это не то же самое, что «подходит именно для вашей задачи». Вся разница — в допущениях. А допущения в коде невидимы.

Что теперь на самом деле означает валидация

Проверка решений, созданных с помощью ИИ, — это проверка не только реализации, но и самой постановки задачи.

Когда кто-то приносит вам модель, которую помог собрать AI-ассистент, вот какие вопросы действительно важны:

Соответствует ли тестовая выборка продакшну?

И речь не о том, «отложили ли мы 20% данных» — это просто методика. Настоящий вопрос: будет ли модель в продакшне видеть данные, структурно похожие на тестовые?
Если в проде клиенты ещё ни разу не участвовали в кампаниях, а в тестовой выборке участвовали, ваша валидация измеряет совсем не то.

Что на самом деле учит модель?

Прогоните предсказания на примерах, где вы заранее знаете правильный ответ. Создайте синтетические объекты, которые изолируют конкретные паттерны.
Если у вас есть клиент, полностью похожий на группу частых откликателей, но при этом он относится к новому сегменту рынка, — что предсказывает модель?
Ответ покажет, какие признаки реально определяют её решения.

Где это сломается?

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

Что будет, когда мир изменится?

Продакшн — не статичен. Конкуренты запускают новые кампании. Экономические условия меняются. Предпочтения клиентов эволюционируют. Модель, которая работает сегодня, может сломаться через месяц — не из-за багов, а потому что её исходные допущения перестали быть верными. Проверка на устойчивость — это вопрос: что должно оставаться правдой, чтобы модель продолжала работать?

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

Парадокс помощника

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

Но скорость без направления — это просто движение. Быстрота без понимания — это всего лишь способ метаться быстрее.

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

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

Учимся работать с неопределённостью

Прежний подход давал уверенность через усилие. Вы проводили дни, собирая модель, — поэтому знали её досконально. Понимали каждый выбор, потому что каждый выбор делали сами. Модель могла быть не идеальной, но вы точно знали, как и почему она работает.

AI-помощники разрывают эту связь. Теперь вы можете получить рабочую модель, не понимая её. Отсутствие усилий уже не означает низкое качество — код может оказаться даже лучше того, что вы бы написали сами. Но уверенность больше не рождается из объёма проделанной работы.

Так откуда же она теперь берётся?

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

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

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

Что теряется при «переводе» задачи

Больше всего меня тревожат не те модели, которые проваливаются очевидно, а те, что проваливаются тонко.

Очевидная поломка бросается в глаза. Нулевая точность, бессмысленные предсказания, падения в проде — такие сбои громкие. Они заставляют разбираться. Кто-то находит причину и чинит проблему.

Тонкие ошибки незаметны. Модель даёт 78% точности вместо 82%. Рекомендательная система работает, но усиливает существующие перекосы. Прогнозная модель в среднем точна, но стабильно ошибается для отдельных подкатегорий. Такие модели живут в продакшне месяцами, принимая решения, которые чуть хуже, чем могли бы быть.

AI-ассистенты особенно хорошо умеют создавать такие тонко сломанные решения. Код запускается. Метрики выглядят правдоподобно. Всё кажется нормальным, пока не копнёшь достаточно глубоко и не почувствуешь, что что-то не так. Но мы уже почти не копаем — потому что код выглядит слишком хорошо, чтобы его ставить под сомнение.

И вот в этом настоящая опасность: не в катастрофических провалах, а в медленном сползании к посредственности, которую трудно заметить, потому что внешне всё вроде бы работает.

Строим новую модель сотрудничества

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

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

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

Документируйте то, что вы проверили, а не только то, что построили.
Артефакт проекта с участием ИИ — не код, его всегда можно сгенерировать снова. Важно задокументировать, что вы протестировали, какие допущения подтвердили, какие ограничения нашли. Именно это знание делает модель заслуживающей доверия.

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

Навыки, которые действительно важны сейчас

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

Новые ключевые навыки:

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

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

Анализ сценариев отказа.
Понимание того, где и как модель сломается — ещё до того, как это случится в проде. AI-ассистенты создают модели, которые работают «в среднем» — вам нужно находить те крайние случаи, где они перестают работать.

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

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

Двигаясь вперёд, не забывать о прошлом

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

Но мы не можем позволить отполированному AI-коду убаюкать нас и заставить доверять слишком быстро. Нам нужно становиться более, а не менее скептичными. Задавать больше, а не меньше вопросов. Быть строже в валидации, а не смягчать её.

Модели становятся слишком умелыми в обмане — не намеренно, а просто потому, что выглядят настолько компетентно, что мы забываем проверить, ту ли задачу они вообще решают. Теперь наша работа — быть скептиками, задавать вопросы и ковырять решения, пока мы не убедимся, что они действительно будут работать.

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

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

И если честно? Именно там нам и место.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!