rinum

Путь к промышленному вайб-кодингу

Сейчас вокруг AI-разработки существуют две крайности.

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

Другие считают, что все разговоры об AI Coding сильно преувеличены, а реальные возможности ограничиваются генерацией простых скриптов и учебных проектов.

Мне захотелось проверить вайб-кодинг на практике.

Не на Todo-приложении.

Не на очередном чат-боте.

Не на демонстрационном проекте.

А на реальной задаче клиента.

Исходная задача

Заказчику требовалась небольшая интеграционная система.

На первый взгляд требования выглядели достаточно просто:

  • отслеживать появление новых файлов в каталоге;
  • читать данные из CSV;
  • выполнять преобразование и сопоставление данных;
  • создавать документы в ERP-системе;
  • обрабатывать ошибки;
  • обеспечивать повторную отправку при сбоях.

Полное описание занимало примерно две страницы.

Перед началом работ я решил провести небольшой эксперимент и попросил несколько моделей ИИ оценить трудоемкость такой разработки.

Полученный диапазон оказался довольно широким:

от 100 до 240 часов разработки, тестирования и отладки.

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

Что обычно происходит в подобных проектах

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

Появляется задача, которую опытный разработчик оценивает примерно так:

«Это на пару часов работы».

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

И проблема тут обычно кроется не в написании кода.

Проблема заключается в том, что большая часть сложности находится не в коде.

Она находится в:

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

Именно эта часть работы чаще всего недооценивается.

Мой эксперимент

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

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

Получившаяся структура выглядела примерно так:

  • конфигурация;
  • отслеживание файлов;
  • обработка CSV;
  • детекция событий;
  • сопоставление данных;
  • подготовка документа;
  • интеграция с ERP;
  • механизм повторной отправки;
  • оркестрация процесса.

Каждый компонент имел четко определенные входы, выходы и набор тестов.

Что получилось

В результате была создана рабочая система, которая:

  • обнаруживает новые файлы;
  • обрабатывает данные;
  • выполняет сопоставление;
  • формирует документ;
  • передает его в ERP-систему;
  • корректно обрабатывает ошибки.

И самое главное — система была запущена на реальном проекте клиента.

Не в песочнице.

Не в демонстрационном окружении.

Не на учебном примере.

А в реальном контуре.

Финальный результат одного из прогонов выглядел так:

files_scanned = 1 files_processed = 1 rows_processed = 1 rows_failed = 0 writebacks_success = 1 writebacks_failed = 0 retry_enqueued = 0

Документ был успешно создан в ERP-системе.

Что удивило больше всего

Самым интересным результатом оказался не выигрыш по времени (на все ушло примерно 10 часов).

Самым интересным оказалось другое наблюдение.

В процессе разработки практически не возникало ситуаций вида:

  • «забыли важную сущность»;
  • «нужно переделывать архитектуру»;
  • «этот модуль должен был знать о другом модуле»;
  • «придется переписывать предыдущую часть системы».

Каждый следующий компонент вставал в заранее определенное место.

По сути, большая часть проектирования была выполнена до начала генерации кода.

Именно это оказалось главным источником ускорения.

Возможно, мы не там ищем причину роста производительности

Сегодня основное внимание обычно уделяется самим моделям.

Какая модель пишет код лучше?

Какая модель пишет код быстрее?

Какая модель проходит больше тестов?

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

Возможно, основная проблема современной разработки находится не между человеком и кодом.

Возможно, она находится между требованиями и кодом.

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

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

А как вы считаете: где сегодня находится главный источник потерь времени в разработке — в написании кода или в преобразовании требований в архитектурные решения?