ERP своими руками: купить, выстрадать или навайбкодить с ИИ

Подробности изложены в материале первоисточника. Привет, друзья! Меня зовут Сергей Багров. Последние пятнадцать лет я профессионально занимаюсь развитием систем складского учета, и сегодня я хочу разобрать популярный тренд: можно ли полностью навайбкодить свой софт с помощью нейросетей вместо покупки готового?

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

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

Что получится хорошо, а где нужен человек

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

Решения, а не код: правила учета

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

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

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

Реальные кейсы и запрет продаж в минус

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

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

Российская специфика и масштаб проекта

Отдельная боль при разработке учетных систем — это российские реалии: НДС, УПД, обязательная маркировка, требования к ККМ и электронному документообороту. Здесь нейросеть напишет код, который выглядит формально корректно, но обязательно ошибется в деталях.

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

Объем кода и архитектура

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

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

Первые полгода эксплуатации и ответственность

Любая бизнес-программа приобретает реальную зрелость только после столкновения с «живыми» данными. Накопленная годами обвязка не пишется заранее — она постепенно нарастает в процессе ежедневной эксплуатации.

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

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

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

Рациональные компромиссы и итоговые выводы

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

Что же в итоге? Если вам нравится экспериментировать с вайбкодингом или вы не хотите зависеть от программистов ради добавления простой колонки в отчет, но при этом нуждаетесь в надежном фундаменте — выбирайте зрелую систему учета, развернутую на вашем хостинге. Она открыта для кастомизации, и при наличии времени вы можете дорабатывать ее самостоятельно. А если ваше истинное призвание заключается в развитии бизнеса и предпринимательских идеях, доверьте написание и поддержку кода профессионалам. Нравится — вайбкодьте, но исключительно поверх фундамента, за который кто-то несет реальную ответственность.