Разработка ПО
Менеджмент
Для компаний
Для стартапов
Архитектура ПО
Обязательно посмотрите видео, оно встроено прямо в эту статью: в нём я на живом примере показываю, как мы разрабатываем сложные веб-системы с использованием AI, почему обычный вайб-кодинг годится только для мелочей, и как выглядит взрослый подход, где сначала проектируется архитектура, бизнес-логика, экраны и интеграции, а уже потом AI ускоряет разработку, делает прототипы, графики, CRM-модули и события дешевле и быстрее =)
Как мы разрабатываем сложные веб-системы с AI, но без культа вайб-кодинга =)
Сейчас рынок немного похож на шумный базар: с одной стороны все кричат, что искусственный интеллект уже вот-вот заменит программистов, с другой — бизнес по-прежнему теряет деньги на кривых интеграциях, ручной работе, зависающих таблицах и системах, которые сломались в самый неподходящий момент. Красиво звучит идея просто надиктовать чату фразу в стиле сделай мне CRM, ERP и клиентский кабинет. Но в реальном бизнесе такие трюки работают ровно до первого нормального усложнения.
Пока речь идёт о маленьком экране, простой форме, фильтре и таблице — да, современные инструменты реально ускоряют производство. Но как только у вас появляется большая предметная область, роли, события, телефония, расчёты, аналитика, очереди, статусы, история изменений, десятки экранов и интеграции, начинается уже не магия, а взрослая инженерия. И вот тут становится видно, где AI полезен, а где он просто очень бодро генерирует хаос.
Почему обычный вайб-кодинг хорош только для маленьких задач
Давайте без религиозных войн. Вайб-кодинг, no-code, low-code и прочие быстрые конструкторы не зло. Для некоторых задач они прекрасны. Если вам нужно быстро набросать MVP, интерфейс заявки, маленькую CRM-табличку, лендинг с логикой или административную форму — это может быть очень выгодно.
Но сложная система — это уже не табуретка из трёх досок. Это город с дорогами, перекрёстками, инженерными сетями и правилами движения. Тут живут бизнес-правила — то есть формальные условия, по которым компания реально работает. Тут живут интеграции — когда одна система должна корректно разговаривать с другой, а не обмениваться истериками. Тут живут сценарии состояний — когда экран ведёт себя по-разному в зависимости от роли пользователя, статуса сущности, даты, события, предыдущих действий и десятка других мелочей, которые обычно всплывают уже после первого звонка клиента.
И вот здесь наивный подход начинает трещать. Потому что AI может быстро нарисовать красивую витрину, но не всегда понимает, где у здания несущие стены. А бизнесу, как ни странно, важнее именно стены.
Где AI действительно делает разработку дешевле
Разработка правда стала дешевле. Скрывать это глупо. Но дешевле она стала не потому, что архитекторы, аналитики и инженеры внезапно стали не нужны. Наоборот. Она стала дешевле там, где раньше люди тратили часы и дни на однотипную механическую работу: повторяющиеся формы, связки экранов, типовые обработчики, типовые компоненты, рутинные шаблоны интерфейса, вспомогательные модули, обвязку вокруг уже понятной логики.
Если по-человечески, то AI хорош там, где раньше инженер работал как очень дорогой копировальный аппарат. И вот эту часть рутины теперь действительно можно автоматизировать. А вот ключевые решения всё ещё должен принимать человек, желательно не уставший и не с фантазией золотой рыбки.
Мы используем LLM (large language model, то есть большую языковую модель — условно умный автодостроитель текста и кода) как ускоритель производства, а не как шамана, которому наугад отдают весь проект. Это важная разница. Очень важная.
Наш подход: сначала архитектура, потом генерация
Вместо того чтобы просто диктовать системе хаотичные пожелания, мы выстраиваем проект поэтапно. Сначала человек описывает логику верхнего уровня. Что за сущности есть в системе. Какие у них связи. Какие роли существуют. Какие события влияют на поведение продукта. Какие интеграции обязательны. Где границы модулей. Где риски. Где места будущего роста. Где потенциальные болота, в которые обычно радостно прыгают подрядчики без системного мышления.
Дальше мы используем декларативный подход. Декларативный — это когда мы описываем, что должно существовать, а не вручную двигаем каждую гайку. Например: есть сущность клиента, есть форма клиента, есть таблица клиентов, есть карточка событий, есть график активности, есть переходы, фильтры, ограничения, действия. Мы описываем не хаос кнопок, а модель экрана.
Потом подключается генерация. Но не вместо архитектуры, а внутри уже осмысленного каркаса. То есть сначала человек строит скелет и нервную систему, а уже потом AI помогает быстро нарастить мышцы и кожу. И это намного полезнее, чем наоборот, когда сначала надувают красивый резиновый манекен, а потом пытаются понять, как бы ему приделать позвоночник.
Из каких слоёв состоит такая разработка
Чтобы не превращать продукт в цифровой сарай, мы разделяем его на понятные уровни:
- доменная модель — это описание главных сущностей бизнеса, условно кто тут вообще с кем дружит, ругается, платит и меняет статусы
- контракты — правила общения между частями системы, чтобы модули не читали мысли друг друга, а работали по договорённостям
- событийная модель — список того, что именно происходит в системе и как это влияет на другие части продукта
- интеграционный слой — шлюзы к телефонии, API, внешним платформам, аналитике, платёжкам и другим полезным взрослым штукам
- визуальная схема экранов — формы, таблицы, карточки, графики, фильтры, маршруты, состояния интерфейса
- генерация типового кода — там, где уже не нужна дорогая ручная работа, а нужен быстрый и дисциплинированный результат
Именно поэтому нам близка не идея пусть AI сам разберётся, а идея инженерного ускорения. Когда машина помогает там, где это выгодно, а человек отвечает за замысел, архитектуру и последствия.
Если вам интересен именно этот подход к ускорению производства, посмотрите также наш материал про FRACTAL — автоматизацию программирования и разработки ПО. Это как раз про тот самый переход от ручного ковыряния к более высокому уровню проектирования.
Что это даёт бизнесу, кроме красивых слов
Руководителю важна не техническая романтика, а результат. Желательно такой, который можно посчитать в сроках, бюджете, прозрачности и количестве нервных клеток, не погибших на проекте.
Архитектурно управляемая генерация даёт несколько очень практичных эффектов:
- быстрее прототипирование — можно быстро показать рабочий интерфейс, а не неделю обсуждать воздух
- быстрее согласование — заказчик видит не абстрактное ТЗ на 200 страниц, а живой сценарий
- меньше ручной рутины — типовые части продукта собираются быстрее
- выше управляемость — систему проще расширять, а не переписывать каждые полгода
- ниже риск случайной свалки — потому что логика строится сверху вниз, а не методом случайных заплаток
Особенно это важно для тех компаний, которые уже устали жить в Excel, в мессенджерах, в ручных звонках, в отдельной телефонии, в отдельной таблице по продажам, в отдельной папке с документами и в отдельном человеке, который почему-то один знает, как всё реально работает. Такой бизнес обычно очень героический, но уже утомительный.
Пример на практике: CRM, события, графики, телефония
В видео показан очень простой, почти аскетичный прототип CRM. Есть клиент, карточка, таблица, фильтры, статусы и события. На первый взгляд — ничего драматичного. Но именно в таких примерах хорошо видно, где начинается граница между детской поделкой и нормальной системой.
Пока у вас просто список лидов, задача выглядит почти невинно. Но потом вы хотите видеть историю взаимодействия, динамику статусов, события по клиенту, график активности, фильтрацию по датам, автоматические обновления после звонков, воронку, аналитику по менеджерам, сегментацию и прочие совершенно нормальные хотелки любого живого бизнеса.
И тут появляется webhook (механизм, когда одна система сама уведомляет другую, что произошло событие). Например, телефония передаёт факт звонка, а CRM уже записывает его в историю клиента, обновляет воронку, строит график активности и даёт руководителю не ощущения, а данные.
То есть продукт перестаёт быть красивой коробкой с таблицей и превращается в систему учёта и управления. А это уже другой класс задач.
Почему сложные экраны надо не просто рисовать, а осмыслять
Одна из главных проблем слабой разработки в том, что интерфейс воспринимают как картинку. Мол, есть форма, кнопка и табличка — что тут думать. Но экран в серьёзной системе — это не декорация. Это точка принятия решений, узел бизнес-процесса и поверхность, через которую пользователь взаимодействует с логикой компании.
В хорошем проекте экран связан с моделью данных, с правами доступа, с валидацией, с журналом событий, с очередями, с интеграциями, с аналитикой, с отчётностью и иногда даже с юридически значимыми действиями. Поэтому у нас экран — это не просто фронтенд. Это часть архитектуры.
Собственно, поэтому мы отдельно развиваем и CRM-направление для продаж и клиентских процессов, и решения для BPM-проектирования и управления процессами, и более широкие корпоративные платформы вроде platFORMA. Потому что компании редко страдают от нехватки экранов. Обычно они страдают от нехватки системы.
Почему не стоит ждать ещё полгода, пока всё начнёт писаться само
Есть любимая иллюзия последних лет: давайте немного подождём, и скоро системы будут писаться полностью сами. Но реальность упрямее. Даже если генеративные технологии станут в десять раз сильнее, бизнес всё равно должен быть готов. Должна быть структура данных. Должна быть карта процессов. Должны быть границы модулей. Должны быть понятные роли, правила и приоритеты.
Без этого ждать чудо — всё равно что купить реактивный двигатель и надеяться, что он сам построит самолёт. Нет, сначала всё же нужна аэродинамика, конструкция, расчёты и человек, который понимает, зачем вообще самолёт летит именно туда, а не в соседний ангар.
Поэтому правильная стратегия не ждать волшебства, а уже сейчас переводить разработку на более современный инженерный уровень. Тогда каждое следующее улучшение AI будет не страшной новостью из интернета, а вашим рабочим инструментом.
Кому подходит такой подход
Стартапам. Особенно тем, у кого есть идея, амбиция и желание быстро запускаться, но нет желания превращать разработку в бесконечную воронку расходов. Здесь важно быстро прототипировать, быстро согласовывать, быстро исправлять курс, но при этом не строить фундамент из картона.
Системным компаниям. Тем, у кого уже есть отделы, реальные процессы, накопленные ошибки, разрозненные сервисы, телефония, документы, отчёты, логистика, продажи, операционка и исторический зоопарк программ. В такой ситуации нужна не игрушка, а зрелая архитектура, которая постепенно наводит порядок.
Если ближе именно корпоративная логика, посмотрите также кейсы по платформе для управляющего холдинга и материалы по анализу eHealth-документации для медицинских систем. Там очень хорошо видно, как сложность предметной области быстро делает случайную разработку слишком дорогим развлечением.
Почему классический архитектор сейчас важнее, а не менее нужен
Чем быстрее можно что-то произвести, тем опаснее становится ошибка в замысле. Раньше неправильную идею хотя бы реализовывали долго и дорого, и у бизнеса был шанс заметить беду заранее. Теперь плохую идею можно реализовать удивительно быстро. То есть некачественное решение тоже стало масштабироваться быстрее. Прогресс, ничего не скажешь =)
Именно поэтому растёт ценность системного анализа (разбора того, как бизнес реально работает), архитектурного проектирования (организации устойчивой структуры системы) и контрактного мышления (когда части продукта взаимодействуют по ясным правилам, а не телепатически).
Сегодня сильный архитектор — это уже не человек, который сидит на троне из UML-диаграмм и запрещает всем жить. Это человек, который умеет превращать хаос требований в понятную цифровую конструкцию, пригодную для ускоренной разработки. Вот где реальная ценность.
Что в итоге
Будущее не в том, чтобы просто разговаривать с чатиком и надеяться на чудо. Будущее в том, чтобы соединить архитектуру, системный анализ и генеративные технологии в один рабочий конвейер. Тогда проект становится не набором красивых экранов, а машиной, которая умеет обслуживать бизнес, считать, интегрироваться, расти и не рассыпаться от первой нетиповой задачи.
И если совсем коротко: маленькие вещи теперь и правда можно делать быстрее. А большие вещи теперь можно делать быстрее без потери головы. А это уже не хайп. Это уже экономика, управляемость и вполне ощутимое конкурентное преимущество.
Нужна система, а не очередной цифровой аттракцион?
Если вам нужна разработка сложной веб-системы, архитектура корпоративного приложения, быстрое прототипирование SaaS, CRM с интеграциями или постепенная замена старого зоопарка программ на внятную платформу — переходите на Ingello Systems.
Там можно посмотреть отзывы, принципы работы, этапы сотрудничества и оставить заявку на бесплатную консультацию. Потому что хороший софт — это не когда AI что-то бодро нагенерировал. Хороший софт — это когда ваш бизнес перестаёт жить в режиме постоянного пожара.
