Заменит ли вайбкодинг корпоративное ПО?

Это личное мнение директора компании — разработчика корпоративного ПО. На истину в последней инстанции не претендую. Сразу обозначим очевидное: да, у меня здесь профессиональный интерес.

ТриггерТриггер

За последние пару недель несколько раз встретил похожие истории.

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

На другом конце спектра — небольшая компания в области ИТ-консалтинга, человек на 50 в штате. «Ваш финансовый учёт нам не подходит. Мы сами навайбкодим систему под свои процессы».

И меня триггернуло на текст. Сначала для сейлов — как-то с этим надо работать. Но не пропадать же буквам — пусть будет и для всех.

ИИ и история вопросаИИ и история вопроса

Немного контекста. К концу школы взапой читал Бьёрна Страуструпа, изучал C++ и вообще хотел быть программистом. Так вышло, что потом всё время работал в ИТ, но программистом не стал. И где-то программистам завидовал: казалось, у них всё понятно, им не надо иметь дело с капризными и нелогичными формами жизни.

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

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

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

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

Критическая проблема ПО, или В чём мотивацияКритическая проблема ПО, или В чём мотивация

Она была всегда. В шутку в старые времена её формулировали так: «У этого ПО критическая проблема — его написал не я!»

Я много раз видел эту историю. Отдельные люди и компании делали собственные системы на low-code, на 1С, да хоть на FoxPro. Инструменты менялись, желание сделать всё по-своему оставалось.

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

Иногда авторы такого высказывания правы. Если у человека сильный аналитический и системный ум, опыт нескольких успешных проектов, хорошее понимание предметной области, упорство и усидчивость — он действительно может сделать что-то хорошее. А иногда ещё и лучше доступных готовых решений.

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

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

ИИ в этой истории выглядит как меч короля Артура. Наконец-то появился инструмент, с которым всё станет иначе.

Работает ли ИИ?Работает ли ИИ?

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

Расскажу на своём примере. Вот мне нужен новый отчёт в системе.

1. Я открываю Codex и обсуждаю, как этот отчёт должен работать и как его реализовать.
2. Обсудили — вот его описание.
3. Раньше я кидал текст аналитику: пусть посмотрит, добавит задачу. Потом возьмём её в спринт, программисты сделают, QA проверят — и в продакшен.
4. Теперь я пишу: «Ну, делай». И он пишет код. Я хорошо понимаю архитектуру, быстро читаю код — на проверку такой доработки мне нужно минут десять.
5. Потом пишу: «Создай задачу, включи в следующий спринт, описание кинь в канал dev со ссылкой на задачу». Моя работа на этом закончена. Проверку и выпуск доработки это не отменяет.

Всё? Программисты, аналитики и прочие больше не нужны?

А вот и нет.

Почему у меня получается так работать? Десять лет опыта с продуктом и полная самостоятельность. Я сам хорошо знаю, что мне надо как менеджеру продукта, досконально знаю его архитектуру, а задача типовая. Здесь я сам закрываю аналитическую часть, а ИИ делает типовую реализацию по знакомым образцам. Гонять такую задачу по цепочке «аналитик — программист» теперь дольше, чем сделать. QA вот оставляю на всякий случай: не всё покроют автотесты.

Получается ли так работать у других в компании? Нет. Да, они стали продуктивнее, но все специалисты — архитектор, программист и дальше по списку — как были нужны, так и нужны. А вот потребность в джунах у нас отпала: более опытные сотрудники с ИИ успевают больше. Это отдельная боль и отдельная история.

Могу ли я сам заменить всю компанию? Нет, конечно. Во-первых, это был бы катастрофический bus factor: один человек выбывает — и приехали. Во-вторых, просто нет. Задача не всегда понятна, и кому-то надо пойти поговорить с клиентом. Кому-то надо обсудить с ИИ логику и техническую архитектуру. Кому-то — дать инструкции для написания кода, а потом проверить результат.

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

И есть ещё работа, которая вообще предшествует написанию кода. Возьмём финансовый учёт проектов. По какой ставке считать себестоимость труда? Что делать, если ставку изменили задним числом? Когда признавать выручку? Как учитывать исправления в закрытом периоде? ИИ поможет реализовать выбранные правила. Но сначала кто-то должен их определить, согласовать и понять, как проверить результат.

Поэтому дашборд поверх Jira — хороший результат, но пока не доказательство, что так же легко получится заменить всю ИСУП. Данные, права доступа и часть бизнес-логики уже обеспечивает Jira. При собственной разработке эта работа тоже станет вашей.

Экономика вопросаЭкономика вопроса

А теперь — к экономике. Для той самой небольшой компании прикинули затраты на собственный инструмент.

Сейчас у клиента три пользовательские лицензии Timetta Finance. Речь об управленческом учёте экономики проектов.

Голые цифрыГолые цифры

Возьмём скромный сценарий: небольшой инструмент под свои процессы. Час сотрудника условно оценим в 2 000 ₽. Ускорение от ИИ уже заложим в оценку трудозатрат.

Это пример расчёта, а не смета и не оценка разработки полного аналога Timetta Finance. За 80 часов мы предполагаем получить небольшой инструмент с ограниченным набором сценариев. Получится ли — зависит от задачи и исполнителя.

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

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

Риски, кстати, тоже естьРиски, кстати, тоже есть

Своя разработка, хоть с ИИ, хоть без ИИ, — не гарантия успеха. Результат зависит от постановки задачи, способностей аналитиков, понимания финансовой модели и качества проверки.

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

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

Компания должна сознательно принять эти риски: назначить ответственного, выделить время на проверку и бюджет на сопровождение. Заранее решить, кто подхватит систему, если автор уйдёт или переключится на другую задачу.

«Сейчас сделаем, а дальше оно само» — довольно смелая стратегия для финансового учёта.

ВыводыВыводы

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

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

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

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

ИИ как меч короля Артура — вещь полезная.
Но королевством всё равно надо кому-то управлять.