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

1) Замість юзера клієнтом ваших аплікешинів буде AI. Тобто людина буде спілкуватися з AI — а вже AI буде використовувати програми аби зробити що треба. Фактично сучасні аплікейшини мають втратити власний UI та перетворитися на AI — агентів. Їх роботою буде надавати потрібні данні та виконувати команди від AI. При цьому AI буде сам показувати інформацію юзеру у потрібному вигляді і сам приймати від юзера данні і команди також у зручному для юзера вигляді. AI стане єдиним, універсальним юзер-інтерфейсом на усіх девейсах одночасно! Юзер може сказати: «зроби мені на великому екрані презентацію з графиками, а на екран мобіли виведи текст промови» і AI буде одночасно керувати двома девайсами.

Цікаво, звідки беруться ці думки.
Чати в магазинах, де відповідають живі оператори, вже існують може з років 15 у майже всіх онлайн магазинах. При цьому замовлення не роблять через чат. Всі люблять дивитись каталоги товарів, фото, відгуки, та купувати в один клік. Спілкуються з сапортом в чаті в крайньому випадку, коли вже немає куди подітись.

Чим оператор магазину принципово відрізняється від ШІ оператору?
UI буде завжди. Тому що він банально зручніший. Люди люблять очами, а не переписками.

Це мені нагадало сцену з Термінатора 2.
Де на парковці досконалий «рідкий» термінатор намагався наздогнати застарілу модель термінатора який їхав на авто. Тобто, «рідкий» термінтатор звісно швидко бігав, але не настільки швидко, щоб догнати старе авто. Значення інструмента та рантайму спеціалізованого виконання нікуди не дінуться.

Зараз навіть цікавіша історія.
Коли ШІ досягне рівня — зрозуміти вже написаний код та вміти його переписати —
почнеться рух 95% вже колись-кимось написаного застарілого ПЗ. Не рефакторинг. Переписування. Тому що його переписати на нову архітектуру тепер значно легше.

До ШІ ери всі девелопери задовільнялись 5% пирога, там де писали нове або дописували.
Зараз ШІ частвоко зменшує ці 5%, але одночасно відчиняє інші 95% ринку легасі коду.
Роботи стає більше і це повністю корелює, наскільки ШІ стає розумнішим.

Головний плюс — це повне управління всім робочим середовищем з однієї панелі у VS Code чи Cursor, взагалі без перемикання між терміналами.

Тобто стаття вище категорично не
прочитана, та все що ти спростив собі — це перемикання між терміналами.

Це офтоп для цієї теми.

Десь в східних практиках є прекрасний вираз. Найкращий бій вигран той, що навіть не розпочався.
Ви прийшли, накидали якихось термінів, роздули кодову базу ci/cd, якимось скриптами, сервісами, зробили якусь оркестрацію, та навіть не написали навіщо то все було потрібно.

Які виводи можна з цього нам зробити?

RealWorld міряє стандартний CRUD, з яким LLM і так прекрасно впораються, де тут кастомність?

Не зовсім зрозумів. Не я цей приклад придумав.
RealWorld (conduit) це самий популярний бенчмарк на сьогодні в веб розробці серед кастомних фреймворків (82к+ зірочок на гітхаб).
Він чудовий тим, що якщо ти пишеш свою веб технологію, та хочеш її порівняти з іншими конкурентами, то просто пишеш свою реалізацію RealWorld та порівнюєш її з 100+ FE/BE/FullStack вже готовими реалізаціями на інших веб технологіях.

Мені, наприклад, більше подобається кастомний бенчмарк — написати лов код на лов код. Але ангуляр не пишуть на англуляр, а реакт не пишуть на реакт. Нема з ким цей рокет бутстрап порівнуювати.

Такий код не містить когнітивної складності для LLM.

Ну як мінімум LLM потрібно обробити в 15 разів меньше токенів (в 15 разів дешевше коштує), а людині в 15 разів меньше ревьювити коду.

Бо вирішення питань складності та кастомізації немає.

Є вирішення через CMDD
youtube.com/watch?v=...​j-35M?si=UzS2Cy9EoX_Zpbki
youtube.com/watch?v=...​yJ0zI?si=mrazpPjv95mSCuz

Також є бенчмарк RealWorld. Це спеціальна арена де більш як 100+ різноманітних веб технологій змагаються в написанні кастомного рішення.

fraplat.com/?tag=realworld

Розробка на лов код зменшує кількість коду порівняно з іншими веб фреймворками в 7-15 разів, а значить когнітивна складність для ШІ зменшується ще в надцять разів.

Єдина проблема, що такі рішення ще не розповсюджені.
Індустрія поки що грається в вайбкодінг та AI slop.
Але для нових технологій, що займуть масмаркет завтра а не сьогодні, це нормально.

low-code виник досить давно, десь в 90-ті, якщо розглядати Visual Basic, Access, PowerBulder,

А як можна оцінювати технології по їх минулому?
ШІ теж 40 років тому був ніким. 20 років тому був ніким. 10 років тому був ніким.
А зараз є всім. Не можна всі технології міряти тим, чим вони були в минулому.
Минуле існує для того, щоб лише врахувати помилки, та зробити більш якісні технології.

а якщо буде AGI, то людям точно ще будуть потрібні прості веб магазини?

Точно будуть потрібно, поки на руках є пять пальців, та зручно на тому ж телефоні мовчки дивитись картинки з товарами, свайпати та тапати.

створення DSL не така вже проста штука.

Це типова пастка архітектора.
Якщо нам потрібно вирішити задачу Х, ми маємо її на 100% описати на DSL.

Але нам не потрібно її на 100% описувати на DSL.
Нам не потрібен абсолютно універсальний DSL.

Типове архітектурне рішення — ми пишемо 80% на DSL,
а 20% або кастомізація на звичайних мовах або інтеграція з сторонніми системами.

Є вже універсальні лов-код які зможуть стати основною мовою комунікацій між ШІ та людиною. Пишеш що завгодно. Від лендінг пейдж до low-code на low-code. Рекламувати не буду, цей топік не про це.

Нехай це буде зрозуміле бачення, що очікує нас в майбутньому.

Уявімо що ми вже в 2035 році і існує AGI, який без проблем генерить код великого застосунку, з рівнем помилок середнього сініора.

Ти йому даєш промпт, він генерить код.
Наприклад це простий веб магазин, на традиційних технологіях це 50 мб сорців в архіві,
100 тисяч рядків коду.

Питання
1. Скільки токенів він має обробити ? Скільки коштувало щоб сгенерити 100 тисяч рядків коду ?
2. Як тобі проревьювити цей код, що там все вірно та немає помилок.
Нагадаю помилки можуть бути різного характеру — перформанц, архітектура, не допоняв вимоги і тд.?
3. Як цей код переписувати, якщо проєкт отримує різко півот, сквозну функціональність?

Тобто проблема не в ШІ, він буде з часом розумнішим, проблема в тому що він пише на традиційному стеку розробки.

Уявімо, що є тепер low-code. І твій магазин сгенерив знову ШІ. Але замість 100 тис рядків коду на Java/JS/TS/Bash/Whatever там вже 5 тис рядків декларативного коду і чиста архітектура.

1. Тобі це коштувало дешево, бо мало токенів опрацьовано.
2. Тобі набагато легше проревьювити цей код.
3. Тобі набагато простіше дописати/переписати цей код.

То є різниця ?

Чи навіть давай зробимо ще простіше, ти же ШІ євангеліст.
Беремо і задаємо твоєму улюбленому ШІ питання.

Як ти бачиш майбутнє розробки. Серед можливих варіантів:

Людина пише традиційним способом
ШІ пише традиційним способом
Людина працює у low-code середовищі
ШІ працює у low-code середовищі.

І отримуємо в будь-якій LLM приблизно такий вивід.

Я бачу майбутнє як еволюцію середовища, а не заміну ролей — і найбільш стійка модель виглядає так:

Людина пише традиційним способом — залишиться для ядра систем, інфраструктури, high-performance задач і нових фреймворків. Це не зникне, але стане більш нішевим і “архітектурним”.

ШІ пише традиційним способом — вже відбувається, але створює багато “AI-slop”: швидко, масштабно, з ростом когнітивного боргу. Працюватиме, але вимагатиме сильної верифікації.

Людина у low-code — стане масовим рівнем розробки для бізнес-систем, внутрішніх сервісів, MVP. Це знижує поріг входу і скорочує цикл створення продукту.

ШІ у low-code — на мою думку, це найбільш перспективна модель. Коли архітектура декларативна і обмежена метаданими, ШІ не “вигадує код”, а конфігурує систему в межах правил. Це зменшує складність і підвищує передбачуваність.

Ймовірно, майбутнє — це комбінація 1 + 4: людина визначає архітектуру та інженерні принципи, а ШІ швидко конфігурує систему в структурованому low-code середовищі. Тобто не “хто пише”, а “в яких межах дозволено писати” стане ключовим фактором.

Ще раз, в цьому тексті ШІ можна легко замінити на розробника (джуна). Питання в тому, чому це не працює для людей? Людині теж простіше правити конфіги, ніж писати код.

Чому не працює? Є купа прикладів де джуни створюють та розгортають доволі складні застосунки на лов код, майже нічого не знаючи про Computer Science.
Adalo, Bubble, Microsoft Power Apps, SeaTable, Wix, Weebly, Squarespace і багато інших.

В любій справі в нас є Виконавець та Інструмент. Зараз індустрія намагається максимально покращувати Виконаця (ШІ), ігноруючи інструменти та використовуючи все те з чим працювала людина. Але інструмент навіть важливіше покращувати ніж виконавця. Оскільки ми бачили багато прикладів з історії коли інструмент настільки спрощувався, що виконавець взагалі міг бути майже не компентентним, але завдяки покращеному інструменту робив дуже професійні речі.

Тож підсумовуючи. Так, на сьогодні ШІ погано пише код. Хтось думає що добре пише код.
Але коли покращать інструмент розробки, всі ті проблеми що в вас описані в статті будуть вже не актуальні. Умовно Шумахера (ШІ) будуть саджати не на Жигулі (купа токенів, складність, обмежений контекст, тяжкий ревью, когнітивне навантаження, багато багів і тд) а за Ферарі (Інструмент, Лов Код) і там буде повністю інший результат на складних проєктах.

Якщо це не працює для людей, то чому це має працювати для LLM? Проблема фіксу багів нікуди не зникає.

Це дає змогу не генерувати AI slop, а генерувати чіткі та компактні декларативні специфікації, які стають прозорими «кресленнями» для системи замість безкінечних і структурно заплутаних процедурних алгоритмів. Такий підхід перетворює ШІ на інструмент точного конфігурування, де замість роздутого синтаксису він створює структуровані правила, що дозволяє людині легко верифікувати логіку та зберігати повний інтелектуальний контроль над продуктом. Завдяки скороченню обсягу коду у десятки разів баги перестають ховатися під шарами машинних галюцинацій, що зупиняє накопичення токсичного технічного боргу та забезпечує системну стабільність, недоступну при звичайному «вайб-кодингу» у традиційних фреймворках.

Сучасна «субпрайм-криза коду» виникає через те, що ШІ затоплює репозиторії гігантськими обсягами низькоякісного синтаксису, збільшуючи когнітивну складність на 39%. Ми часто плутаємо швидкість друку з реальною інженерною продуктивністю, змушуючи досвідчених розробників витрачати час на розплутування машинної складності замість створення цінності.

Традиційні фреймворки провокують появу «AI slop» (кодового сміття), оскільки ШІ схильний до галюцинацій та помилок при написанні тисяч рядків взаємопов’язаного процедурного коду.
Виходом із цієї кризи є перехід до декларативних Low-Code систем, де архітектура базується на метаданих та системі «Dimensions» (вимірів). ШІ набагато точніше генерує структуровані JSON-моделі, ніж складні алгоритми, що дозволяє автоматично вибудовувати інтерфейс та правила обробки даних без ручного написання зайвого коду. Такий підхід перетворює ШІ з ненадійного «автора тексту» на точний інструмент «друку» додатків, де логіка безпеки, валідації та розрахунків відокремлена від сценаріїв.

Завдяки функціонально-аспектному програмуванню (ФАП) обсяг коду скорочується у надцять разів, що робить його компактним та легко читабельним для людини. Це дозволяє уникнути технічного дефолту, оскільки більшість системи конфігурується в runtime, а людина завжди може легко перевірити та виправити стислу бізнес-логіку. Майбутнє розробки — це симбіоз ШІ та жорсткої архітектурної платформи, яка перетворює промпти на працюючі системи без накопичення когнітивного боргу.

Junior — я не знаю як зробити цю таску
Middle — я знаю як зробити цю таску
Senior — я знаю як не робити цю таску

Ось гарна метафора щоб розібратись як співіснують ШІ та LC системи.

Якщо розробка ПЗ це таксомоторна компанія, то ШІ це спроба замінити водія, а LC це спроба вдосконалити сам автомобіль.

Ріст low-code ринку та прогноз на наступні роки:

2024 Value: USD 28.75 billion
2025 Value: USD 37.39 billion
2032 Forecast Value: USD 264.40 billion, with a CAGR of 32.2% from 2025–2032

Source: www.fortunebusinessinsights.com/...​nt-platform-market-102972