Я написал ERP-систему за два месяца

Внимание, заголовок — кликбейт. Я 20 лет в автоматизации торговли, пятнадцать лет разработки собственной ERP, а 2 месяца занял переход с Delphi на PHP + JavaScript. Но статья не об этом. Она о том, что происходит, когда стоимость написания кода перестаёт быть главным ограничением.

Я занимаюсь автоматизацией торговли с 2005 года.

За эти годы я успел побыть обычным системным администратором, потом IT-директором крупной региональной сети супермаркетов, а с 2009 года вместе с командой разрабатываю собственную ERP-систему.

И вот это, пожалуй, важная оговорка: я не вчера пришёл в программирование и не решил попробовать «понавайбкодить saas».

Я 20 год наблюдаю за тем, как автоматизируется реальный бизнес. И последние пятнадцать лет мы делали свою ERP. Успешно. Нашлась своя ниша, появились клиенты, продукт много лет используется в реальном бизнесе. Конечно, лавров 1С мы не снискали, но крепко стоим на ногах.

Меркурий-ERP – так мы называемся – написан на Делфи. Соответственно программа устанавливается на сервера клиентов, работает через удаленные рабочие столы, и вот это вот все. Конечно, у этой схемы есть свои плюсы. Клиенты-параноики довольны, да и мне не приходится содержать большое серверное хозяйство.

Но есть и минусы. Основной – это необходимость клиенту арендовать RDP сервер только для того, чтобы иногда зайти в программу из дома. И таких клиентов было большинство… Мало того, они и 10 процентов от возможностей программы не использовали. Это как иметь в гараже Феррари и не заводить её.

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

У меня работают замечательные программисты. Они прекрасно ориентируются в существующей кодовой базе, не хуже меня разбираются и в предметной области. Помнят наизусть названия больше полутысячи таблиц в БД. Но они делфисты. Они знают и любят Delphi. Знают и любят Firebird. За 15 лет в этом проекте они набили тысячи шишек, наступили на сотню граблей, и в итоге все преодолели.

Но современный web stack — это уже другая история. Тут моя команда откровенно плавала. Конечно, Hallo World сделать было по силам, но ничего большего…

Можно было нанять новую команду.

Можно было собрать web-разработчиков и поручить им написать новый продукт.

А потом несколько лет платить двум командам одновременно: одна продолжает развивать существующую ERP, вторая пытается сделать новую.

И где-то в конце этого пути обнаружить, что мы построили ещё один продукт, которому предстоит конкурировать с уже существующими облачными системами.

Экономика выглядела так себе.

Особенно если вспомнить, что на рынке уже был, например, МойСклад.

Поэтому идея веб-версии много лет лежала на виртуальной полке.

С надписью: «Когда-нибудь».

А потом я купил подписку на Cursor…

Изначально я вообще не ставил перед собой задачу перенести всю систему.

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

Начал с дизайна. Скормил курсору наши дизайнерские фигмы и попросил реализовать интерфейс в вебе. И у него получилось с первого раза!

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

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

Пятнадцать лет мы разрабатывали исходную систему.

И около двух месяцев понадобилось, чтобы сделать её веб-вариант.

Сразу оговорюсь, чтобы не было неправильного вывода.

Это было бы глупо.

За этими двумя месяцами стояли многие человеко-годы опыта и наработок:

Предметная область была изучена.

База данных существовала. (ну конечно она серьёзно переработана, но основные принципы не изменились)

Все основные алгоритмы уже были придуманы.

Функциональность была проверена на реальных клиентах.

У нас был работающий продукт, а не пустой Git-репозиторий.

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

И это, пожалуй, даже интереснее самого переноса.

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

Какие-то решения были прекрасными в 2017 году.

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

Какие-то механизмы больше никто не использует.

Какие-то настолько сложные, что уже трудно вспомнить, зачем они вообще были сделаны именно так.

Поэтому при переносе я начал безжалостно выкидывать лишнее. Что-то упрощал. Что-то переделывал. Что-то добавлял.

В итоге получилась не просто «та же ERP, только в браузере», получился новый продукт.

И тут стало особенно интересно.

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

Конечно, я про ИИ…

В новой версии Меркурия появились ИИ-ассистенты.

ИИ-Товаровед.

ИИ-Технолог.

ИИ-Финансист.

ИИ-Ассистент.

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

Зачем кластеризация – расскажу на примере. Допустим у вас в магазине есть молоко «Простоквашино» и «Домик в деревне». И «Простоквашино» закончилось. Классический автозаказ заметит это и закажет еще «Простоквашино». А умный автозаказ увидит, что полки переполнены точно таким же «Домиком в деревне» и коней попридержит.

Теперь важная часть, без которой статья была бы рекламной сказкой.

Cursor ошибается.

Причём иногда довольно забавно.

И самое интересное — он регулярно ошибается в одних и тех же местах.

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

Cursor прекрасно способен написать длинный миграционный скрипт.

А потом забыть поставить COMMIT там, где он необходим.

Например, сначала создать таблицу, а следующим запросом попытаться её заполнить.

Без COMMIT между операциями скрипт не работает. Firebird захлёбывается.

Возвращаешься к Cursor: Ты забыл COMMIT.

Он: да, вы правы.

Исправляет.

А через какое-то время может сделать примерно то же самое в другом месте.

Причём дело не в том, что он не знает, что такое COMMIT.

Он знает. Просто в длинной последовательности операций периодически теряет из головы особенности конкретной среды.

Для человека, который знает Firebird, это мелочь. Посмотрел ошибку. Понял. Добавил COMMIT. Поехали дальше.

В силу сложившихся обстоятельств, на моём сервере стоит php 7.4. И Cursor с завидным упорством добавляет мне конструкции из восьмой версии. Приходится чуть ли не в каждый промпт добавлять ему предостережение об этом.

С дизайном тоже бывает.

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

Но здесь ситуация уже другая. Я могу сказать:

Нет. Это убери. Вот это перенеси. Таблицу сделай шире. Кнопку поставь сюда. На мобильном вообще спрячь.

И через несколько итераций получить то, что мне нужно.

В последнее время таких промахов стало меньше.

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

Он не пишет.

Главное — насколько быстро исправляется ошибка.

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

Он может забыть COMMIT.

Может не с первого раза попасть в дизайн.

Всё.

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

Мой случай очень специфичен.

Но именно это и заставило меня задуматься.

За овер-двадцать лет в автоматизации я привык считать разработку примерно так.

Есть задача. Она занимает, допустим, 100 часов. Есть два программиста. Значит, получим примерно через несколько недель.

Хочется сделать ещё десять таких задач?

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

Это было фундаментальное ограничение нашей отрасли.

Мы даже перестали воспринимать это как ограничение.

Оно просто было. Как гравитация.

А теперь происходит странное.

Стоимость создания первой рабочей версии функции резко снизилась.

Можно попробовать.

Не понравилось? Выкинуть.

Получилось? Развивать.

Появилась идея? Проверить.

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

И тогда ограничение начинает смещаться.

Это, пожалуй, самый неожиданный вывод из всего эксперимента.

Раньше я часто думал: было бы неплохо сделать вот такую штуку, но сколько это будет стоить?

Теперь я всё чаще думаю: А почему бы просто не сделать?

Это совершенно другая постановка вопроса.

Конечно, между «сделать прототип» и «выпустить промышленную систему» огромная разница.

Но расстояние между «у меня появилась идея» и «я могу посмотреть на работающий прототип» стало намного меньше.

И это меняет саму экономику разработки.

Здесь есть важная оговорка.

Как бы устрашающе не звучала аббревиатура ERP, по сути, это просто большая база данных. Курсовик-переросток. И ИИ справляется с ней на раз-два.

Но всех программистов ИИ не заменит. В этом я уверен.

Не знаю. И я думаю, что это нормальный ответ.

Я не хочу писать очередную статью в стиле: «Программисты больше не нужны». Это неправда. По крайней мере мой опыт этого совершенно не показывает.

Но и делать вид, что ничего не произошло, тоже невозможно.

Произошло.

Я это буквально вижу в своём рабочем процессе.

Раньше большая часть стоимости идеи была в том, чтобы превратить её в код. Теперь код становится гораздо дешевле.

Значит, дорожает другое. Понимание предметной области. Архитектура. Умение поставить задачу. Умение отличить правильный результат от неправильного. Умение увидеть, что вообще стоит построить.

И ответственность за конечный результат.

ИИ может написать мне функцию. Но он не знает, нужна ли она моему клиенту.

Он может создать таблицу. Но не знает, зачем бизнесу эта таблица.

Он может переписать Delphi на JavaScript. Но не знает, какую часть старой системы лучше вообще выбросить.

Это по-прежнему должен решить человек.

Если бы в 2016 году мне сказали: через десять лет ты возьмёшь огромную ERP, которую десять лет разрабатывал на Delphi, и примерно за два месяца сделаешь её веб-версию с помощью ИИ.

Я бы, наверное, рассмеялся.

Если бы добавили: причём основные проблемы будут заключаться в том, что ИИ иногда забудет COMMIT в миграции Firebird и периодически напишет синтаксис PHP 8 для сервера с PHP 7.4.

Я бы решил, что собеседник вообще не понимает, как разрабатывается корпоративный софт.

А теперь это просто мой рабочий день.

И вот это меня по-настоящему впечатляет.

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

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

Всем спасибо что дочитали, а кто хочет посмотреть, что у меня получилось – заходите на https://mercury-ai.ru