Почему общие пилоты кодирования ИИ терпят неудачу при разработке данных

Второй пилот, который не знал того, чего не знал Несколько месяцев назад я наблюдал, как инженер по обработке данных попросил помощника по программированию с использованием искусственного интеллекта провести рефакторинг сценария преобразования, который объединял пять таблиц и вычислял скользящий показатель дохода. Помощник создал чистый, хорошо отформатированный код за считанные секунды. Он также молча заменил LEFT JOIN на INNER JOIN, потому что переписанная версия выглядела более идиоматично. Никто этого не заметил, пока три недели спустя в отчете ниже по течению не начали показываться цифры, которые не согласовывались. Это не история о плохом инструменте. GitHub Copilot, Cursor и подобные помощники действительно полезны для того, для чего они были созданы: завершения функций, предложения шаблонов, выявления очевидных синтаксических ошибок. Проблема в том, что многие команды потихоньку начали относиться к ним как к универсальному решению для работы с данными, и описанный выше режим сбоя — это именно то, что происходит, когда вы это делаете. Почему тот же подход не применяется Разработка программного обеспечения и разработка данных на расстоянии выглядят одинаково. Оба включают в себя написание кода, его проверку, тестирование и развертывание. На этом сходство заканчивается, и различия имеют огромное значение для того, что инструмент ИИ может безопасно автоматизировать.