Claude може побудувати сайт. Він не може побудувати розуміння. Поки що.

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

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

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

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

ДЕ ЗНАХОДИТЬСЯ PERETZ

Нотатка про те, де реально знаходиться Peretz

Це не опис того, чим ми займаємось у Peretz. Генерація лендингу чи шаблонного корпоративного сайту через ШІ за вечір, не наш профіль, і не те, на чому ми конкуруємо.

Ми реально будуємо кастомні e-commerce платформи, лендинги, корпоративні сайти, і той тип бізнес-архітектури, що розібраний в інших місцях цього сайту, частини бізнесу, що реально занадто складні, занадто специфічні, чи занадто стратегічно важливі, щоб віддати одному промпту.

Ця стаття не піч того, що ми продаємо. Це чесний погляд на те, де реально знаходиться ширший ринок, станом на вересень 2026 року. Інструменти ШІ в цій сфері рухаються достатньо швидко, що частина цього може читатись інакше вже до листопада. Це не застереження. Це просто точність.

ВАРТІСТЬ СТАРТУ

ШІ змінив вартість старту

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

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

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

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

Це не так.

ПРОМПТ НЕ СПЕЦИФІКАЦІЯ

Промпт, це не специфікація

Є конкретний патерн, що я продовжую бачити. Хтось копіює промпт у "експерта," вставляє його в Claude чи Cursor, отримує щось вражаюче на вигляд, і зупиняється. Інтерфейс існує. Кнопки працюють у демонстрації. Сторінка виглядає готовою. Тож проєкт здається готовим.

Але промпт, це стартова інструкція, не специфікація. Специфікація описує, що система реально має робити. Це дуже різні речі.

Промпт може сказати: побудуй систему бронювання для консалтингового бізнесу.

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

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

КОД ПРАЦЮЄ СИСТЕМА НІ

Коли код працює, а система ні

Тут ШІ-згенерований софт може стати оманливим. Окремі частини можуть працювати ідеально. Форма може відправлятись. API може відповідати. Компонент може рендеритись. База даних може містити записи. Автентифікація може працювати.

І все ж система може бути погано спроєктована.

Без архітектурного мислення за побудовою, ШІ-згенерований код може схилятись до тієї самої проблеми, що зʼявляється в поспішній людській розробці: частини, що технічно працюють, зшиті разом без узгодженої моделі під ними. Одна частина слідує одному патерну.

Інша частина слідує іншому. Нова функція вводить ще одну структуру даних. Інтеграцію додають прямо в компонент, що її потребує.

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

Кожне додавання коштує більше за попереднє, бо систему ніколи не проєктували поглинати зміни.

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

ШІ ПАТЧИТЬ СИСТЕМУ

Коли ШІ патчить систему, яку не розуміє

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

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

Що я продовжую помічати, це конкретна форма технічного боргу, що накопичується найшвидше саме тут: патч, написаний на Python, прикручений до сайту, реально побудованого на PHP, бо саме це модель обрала за замовчуванням, і ніхто не впіймав невідповідність до релізу. Це не розширення початкової системи. Це створення другої, непов'язаної системи поруч з першою, що тримається разом якимось клейовим кодом, що патчать наступним, щоб змусити їх розмовляти одна з одною.

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

НЕ ЗАВЖДИ ДЕШЕВІ КЛІЄНТИ

Не завжди це дешеві клієнти

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

Результат має знайому форму. HTML-оболонка існує, але ніхто не знає, що робити далі. Немає адміністративної панелі. Форми виглядають підключеними в інтерфейсі, але реально нікуди не відправляють дані, і людина, що це побудувала, щиро вірила, що це готово. Лише коли хтось сідає написати реальну специфікацію на основі того, що вже існує, стає ясно, що початкова ідея була зовсім іншою, що побудова тихо пішла від реального задуму десь по дорозі, і ніхто це не впіймав, бо ні в кого не було словника, щоб помітити, поки це відбувалось.

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

ДЖЕРЕЛО ІСТИНИ

Проблема джерела істини

Одне з питань, що ШІ-згенеровані проєкти часто уникають, оманливо просте: де живе істина?

Клієнт може існувати в CRM. Замовлення може існувати на платформі e-commerce. Оплата може існувати в Stripe. Підписка на email може існувати десь ще. Аналітика може містити ще одну версію клієнтського шляху. Сайт може мати ще одне представлення тієї самої інформації.

Всі ці системи можуть працювати окремо. Але бізнесу все одно потрібно знати, яка система чим володіє.

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

ДЕМО НЕ СЕРЕДОВИЩЕ

Демо, це не середовище

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

Ми впіймали саме таку проблему на власному сайті нещодавно. CSS-правило, написане для галерей портфоліо і hero-зображень, елементів, що завжди сидять всередині контейнерів з фіксованою висотою, ненавмисно застосовувалось і до звичайних картинок всередині контенту статей. Chrome і Firefox деградували вишукано. Safari ж рендерив ці картинки в їхньому нативному пікселному розмірі, видимо їх обрізаючи. Ніхто не написав цей баг навмисно. Ніхто б не виявив його з початкової реалізації. Комусь довелось реально використати систему в іншому середовищі.

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

Саме для цього потрібна верифікація.

ВЕРИФІКАЦІЯ КЛЮЧОВИЙ НАВИК

Верифікація, це новий ключовий навик

Складною частиною побудови з ШІ ніколи не було написання промпту. Генерація стала дешевою. Верифікація ні.

Чи реально форма відправляє дані. Куди ці дані йдуть. Що відбувається, коли запит провалюється. Чи провалюється інтеграція гучно чи тихо. Що відбувається, коли ввід не зовсім такий, яким його передбачала демонстрація. Що відбувається, коли користувач робить те, про що модель не просили передбачити.

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

Це змінює роль людини, що будує з ШІ. Тобі не обов'язково писати кожен рядок коду самому. Але тобі потрібно достатньо розуміння, щоб допитати те, що вивела модель. Тобі потрібно знати, які питання ставити, що виглядає підозріло, і що реально означає "працює."

ПЕРША ВЕРСІЯ ДЕШЕВША

ШІ може зробити першу версію дешевшою

Є поширений аргумент, що будувати з ШІ просто дешевше, ніж наймати розробника. Іноді це так. Для лендингу, ймовірно так. Для прототипу, часто так. Для маленького внутрішнього інструменту, це може бути значно дешевше.

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

Склади цей час чесно, і економіка може виглядати дуже інакше.

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

І це, ймовірно, найнедооціненіша перевага побудови з ШІ: це може зробити навчання через практику значно дешевшим. Помилка, це припускати, що раз генерація стала дешевою, розуміння стало необов'язковим.

ХТО ВОЛОДІЄ СИСТЕМОЮ

Хто реально володіє системою?

Є ще одне питання, що стає важливішим по мірі того, як ШІ спрощує генерацію софту. Хто володіє тим, що ти щойно побудував?

Не лише вихідним кодом. Хто володіє репозиторієм, доменом, хостинг-акаунтом, базою даних, API-обліковими даними, аналітикою, процесом деплою, моделлю даних, і знанням, необхідним, щоб це підтримувати, точно та карта володіння, що розібрана у що ти володієш проти орендуєш. І хто може внести значущу зміну через шість місяців.

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

ШІ не усуває цю залежність. Іноді він спрощує її створення.

ПИТАННЯ ПЕРЕД ПОБУДОВОЮ

Питання, що варто поставити до того, як будувати

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

Перш ніж просити ШІ побудувати це

1. Що конкретно ця система має робити? Не як має виглядати головна сторінка. Який бізнес-процес система реально відповідає виконувати?

2. Що власнику потрібно змінювати без дотику до коду? Контент, товари, користувачів, ціни, воркфлоу?

3. Де реально живуть дані? Що є джерелом істини?

4. Що відбувається, коли інтеграція провалюється? Продакшн-система не може припускати, що кожен API завжди відповість.

5. Хто володіє інфраструктурою? Домен, хостинг, репозиторій, база даних, облікові дані, аналітика.

6. Як система буде верифікована? Не просто чи працює демо. А чи працює система, коли реальність перестає слідувати демонстрації.

7. Що відбувається, коли бізнесу потрібна його десята функція? Саме тут архітектура стає видимою.

8. Що відбувається, коли людини, що це побудувала, більше немає поруч? Саме тут технічне володіння стає бізнес-питанням.

ШІ може згенерувати проти що все ще потрібно спроєктувати людині

ШІ ВІДЕО ДЕМО ГУЧНІШЕ

ШІ-відео-демо, та сама історія, лише гучніше

Соцмережі повні ШІ-побудованих сайтів, представлених через відполіровані ШІ-згенеровані відео. Якість продакшну може бути по-справжньому вражаючою.

Але відполірована демонстрація доводить одну річ: що щось можна змусити виглядати реальним. Вона не доводить, що базова система існує у формі, що може працювати, еволюціонувати, чи підтримуватись.

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

НЕ ПРИБРАВ ІНЖЕНЕРІЮ

ШІ не прибрав інженерію. Він її перемістив

Це, ймовірно, найважливіший зсув. Роками розробка софту була сильно обмежена вартістю виробництва коду. ШІ атакує це обмеження напряму, і це дуже добре.

Але по мірі того, як генерація коду дешевшає, інші частини процесу стають відносно важливішими: вимоги, архітектура, дані, верифікація, безпека, операції, контент, вимірювання, підтримка.

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

РЕАЛЬНА МОЖЛИВІСТЬ

Реальна можливість

Саме тому я не думаю, що цікаве питання в тому, чи може ШІ побудувати сайт. Очевидно може.

Цікавіші питання, який сайт має існувати, яка бізнес-система стоїть за ним, чим компанії реально потрібно володіти, що відбувається, коли бізнес змінюється, і хто розуміє систему, коли демо давно закінчилось.

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

Але нижча вартість генерації робить різницю між згенерованим артефактом і реальною системою важливішою, не менш.

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

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

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

ШІ зробив будівництво дешевшим. Він не зробив розуміння необов'язковим.

Чи може Claude або Cursor реально побудувати робочий сайт?

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

У чому різниця між ШІ-згенерованим прототипом і продакшн-готовою системою?

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

Чи реально будувати сайт з ШІ дешевше, ніж найняти розробника?

Іноді. Для простих проєктів і прототипів, часто суттєво. Економіка змінюється, коли включаєш час, потрібний зрозуміти, верифікувати, підтримувати, і експлуатувати реальну бізнес-систему.

Чому ШІ-згенерований софт часто відчувається зшитим по мірі зростання?

Бо без архітектурного мислення, кожне нове додавання може слідувати власному патерну. Це може працювати на малому масштабі, стаючи все дорожчим розширювати.

Що варто спитати, перш ніж генерувати сайт з ШІ?

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

Чи реально ШІ-згенеровані відео-демо сайтів нова техніка?

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