AI-програміст, який пише за архітектурою з розумом

Обов’язково подивіться відео, воно вбудоване прямо в цю статтю: у ньому я на живому прикладі показую, як ми розробляємо складні веб-системи з використанням 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 щось бадьоро нагенерував. Хороший софт — це коли ваш бізнес перестає жити в режимі постійної пожежі.