Привет, Хабр.

Я Алексей Арустамов, директор компании-разработчика  платформы продвинутой аналитики.

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

Мне стало интересно. Весь интернет завален роликами типа «как за 5 минут составить план поездки» или «написать скрипт». Это создает опасную иллюзию: кажется, что точно так же можно решать абсолютно любые задачи — принимать стратегические решения в компаниях или автоматически управлять продажами.  

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

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

Клон Enterprise-системы за 48 часов. Как все началось

В качестве подопытного программного продукта договорились взять нашу платформу. Почему бы и нет? Это полноценный и сложный корпоративный продукт со множеством источников данных, сложными связями, параллелизмом, асинхронным пользовательским интерфейсам, тяжелыми математическими алгоритмами и специфичной логикой обработки потоков данных. 

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

Правила игры

Правила были простыми:

• Время: 48 часов.

• Входные данные: подробно изложенные на нашем сайте принципы работы, пользовательская документация, вики, руководства и демо-примеры. За скобками остались: исходный код, архитектурные схемы, оптимизации работы с памятью и обработка граничных условий (edge-cases).

• Задача: «Вот документация нашей платформы. Сделай примерно так же».

Эксперимент проходил в несколько циклов доработки: генерация, ручное тестирование, передача замечаний апологету ИИ и перегенерация. Мы не ограничивались одним промптом, хотя признаюсь: довольно быстро надоедает делать работу по тщательному тестированию, которой, по идее, «быть не должно». Оценивали результат по классическим для любого ПО критериям: функциональность, удобство (UX), производительность, надежность и безопасность. Тестирование проводилось в два этапа: ручной прогон на реальных данных (включая массивы до 50 млн строк) и передача замечаний на доработку.

Отмечу, что мы не ставили целью эксперимента создание клона платформы. Целью была проверка требований к классу продуктов продвинутой аналитики. Чтобы критерии были понятны и архитекторам, и джунам, мы свели их в таблицу.

Хотелось бы уточнить, что мы не стали верить автоматическим отчетам ИИ о «пройденных тестах». Мы глубоко убеждены, что реальные ошибки видны только при ручной проверке сырых данных и при отклонении от базового сценария. Уже не раз мы видели один и тот же шаблон: на вопрос «вы тестировали?» следует ответ «ИИ сам сделал тесты, и все они прошли». Мы проверяем шаг влево, шаг вправо — система падает. Мы указываем на ошибку, её «правят», и снова говорят, что все тесты пройдены. Опять проверки, опять падения и так по кругу. Мы сравниваем разное: они проверяют факт прохождения тестов (практически всегда написанных самим ИИ), а мы проверяем, работает ли система так, как надо в реальности.

Первое впечатление: «Пора закрывать бизнес»

Итак, 48 часов прошли. Нам показали сгенерированную систему (утрированно это рис. 1). Я был, конечно, безразмерно впечатлен, появилась мысль: «Все, приехали, надо закрывать бизнес». За столь короткое время ИИ выдал интерфейс и функционал, который команды иногда шлифуют годами:

• Современный веб-интерфейс с темной темой (которую наши пользователи просят уже несколько лет).

• Пошаговые визарды настроек с подсказками.

• Быстрый просмотр промежуточных результатов на каждом узле без пересборки всего сценария.

• Специфичная визуализация: ROC-кривые, метрики бинарной классификации.

• Автоматически сгенерированная справка и демо-примеры.

Более того, ИИ добавил функционал, которого не было в оригинале: узел поиска аномалий (Anomaly Detection). Он самостоятельно решил, что для такой платформы эта фича логична, и реализовал её. То есть путь, который люди проходят за годы, машина преодолела за пару промптов. 

Будущее уже наступило, казалось бы. 

Краш-тест или как выветривается магия

Итак, система выглядит почти идеально. Для проверки надо подать в нее реальные данные и попробовать отойти в сторону от демосценария или проверить дойдет ли этот сценарий корректно до конца. Тут всё и началось... 

Галлюцинации функционала: узлы-пустышки

В интерфейсе красовались узлы для выполнения JavaScript и Python кода. Выглядело отлично: перетащил кубик, связал потоки, написал скрипт.

Но по факту эти узлы не были интегрированы в поток данных, а только для этого они и нужны. В нашей архитектуре узел лениво забирает данные из потока, обрабатывает их и возвращает обратно. ИИ же создал кнопку «Выполнить», которая запускала код в вакууме (схематично — рис. 2). Функционал был объявлен, но архитектурно отсутствовал. 

Математические галлюцинации

Мы построили OLAP-куб (сводную таблицу). Визуально он работал, но при сверке с эталоном выявились расхождения:  

• Куб показывал строго 1000 записей, остальной объем данных он проигнорировал. Смысла в визуализации такого объема данных просто нет. 

• Итоговые суммы не сходились с реальностью. Например, в одной из сводок у демосистемы фигурировали только «частные лица», хотя в исходном CSV было много юридических лиц. Куда они пропали? А, ясно, нейросеть столкнувшись с тем, что в документации не всё описано максимально подробно (а если описывать всё, документация вырастет в 10 раз), правдоподобно, но без всякой для аналитики пользы заполнила сей пробел собственной интерпретацией.

Big Data: все сведено к SQL в DuckDB

Во время демо упомянутый выше апологет ИИ заявил, что демосистема умеет работать с большими данными. Окей, пойдем, проверим. Мы сознательно взяли самый примитивный сценарий: загрузка из csv-файла 50 миллионов записей, фильтр и группировка. Опять — ой. 

Продвинутая аналитика предусматривает комбинацию разных источников (базы, веб-сервисы, ответ ИИ, файлы и т. д.), предобработку, сложные алгоритмы и многое другое.

ИИ же в «режиме больших данных» работал по упрощенной схеме: брал данные, складывал их в локальную базу DuckDB и транслировал все действия в обычные SQL-запросы (SELECT, GROUP BY). Но оно так с бигдатой не работает. 

Во-первых, для простого селекта отдельная система не нужна — можно просто взять обычную СУБД, она справится лучше. Реальная продвинутая аналитика всегда выходит за рамки оператора SELECT.

Во-вторых, при попытке загрузить 50 млн строк (а тут стоит отметить, что вся визуальная часть была на JS) вкладка браузера падала с ошибкой Out of Memory (рис. 3). Ожидаемо, ибо не было реализовано серверное ленивое вычисление или подкачка данных.

Параллелизм, которого нет

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

Игнорирование граничных условий (edge-cases) 

Написать алгоритм сортировки или кластеризации «в лоб» несложно, готовых решений на GitHub тысячи. Но ведь промышленная разработка — это же не сам алгоритм, а ответы на множество мелких и пограничных вопросов типа: 

• Что делать, если при чтении файла типы данных не совпали?

• Как система поведет себя при малом объеме памяти?

• Что если клиент-сервер отвалился во время переобучения модели? и т.д. и т.п.

ИИ написал код только для «удачного сценария». Любое отклонение от идеальных условий ломало демосистему (рис. 4). Замечу, что мы даже близко не подобрались к тому, что можно было бы назвать «копнуть глубоко» — мы лишь проверяли результаты, которые были на поверхности, и уже там находили косяки. 

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

Инженерная рефлексия

Замечу, что мы не ставили целью «разгромить» технологию. Однако, на мой взгляд, эксперимент четко и наглядно обозначил границы ее применимости.

1. Да, ИИ радикально удешевил первое приближение. То, на что раньше уходили недели работы аналитиков и фронтенд-разработчиков, теперь делается за часы. И это бесспорно отличный инструмент для прототипирования.

2. Сложная система обладает эмерджентными свойствами. Это свойства, которые возникают на стыке компонентов, а не внутри них. Интеграция фронтенда и бэкенда, управление памятью, обработка исключений — это не то, что можно вывести из пользовательской документации. Как верно заметил мой оппонент-евангелист в ходе дискуссии: «20 лет инженерного опыта невозможно скачать из документации за 2 дня».

3. Опасность технического долга. Vibe-coding создает иллюзию: «я попросил, и оно случилось — заработало». За скобками между тем, остается то, что каждый непроверенный промпт невиданными ранее темпами генерирует скрытый технический долг на годы вперед. 

Как это происходит? ИИ выдает код, который компилируется и выглядит рабочим, но не прошел глубокой архитектурной проверки.

Кто будет его ревьюить? Если это делает конечный пользователь или неопытный разработчик, продукт превращается в минное поле. Когда всплывает ошибка, «апологет» просто просит ИИ её исправить. Но ИИ же не понимает контекста всей системы, — он просто генерирует новый кусок кода. В итоге на один слой непроверенного, «грязного» кода наслаивается другой (рис. 5).

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

В сухом остатке

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

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

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

Согласен на все 100%. Это касается любого продукта или проекта, который должен долго эволюционировать. 

Сложные системы — не сумма простых систем. Нельзя взять одноэтажный домик, который ИИ построил за 5 минут, и просто поставить 100 таких домиков друг на друга, чтобы получить 100-тажный небоскреб: уже после третьего в высоту домика первый этаж рискует развалиться (рис. 6).

Для сложных корпоративных систем предъявляются требования (безопасность, отказоустойчивость, управление памятью), которые совершенно избыточны для простых скриптов, но критичны для продакшена. Сложную систему нельзя построить одним, даже самым изощренным промптом. Нужно еще и внимание к деталям, тестирование и понимание того, как компоненты взаимодействуют друг с другом в реальных, неидеальных условиях.

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

P.S. Мы готовы поделиться сценариями тестирования и методикой проверки с теми, кто захочет повторить этот эксперимент и самостоятельно убедиться в результатах. Уверен, что код и данные говорят громче любых презентаций.