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 реально построить работающий сайт?

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

В чём разница между ИИ-сгенерированным прототипом и продакшн-готовой системой?

Прототип демонстрирует, что идея может работать. Продакшн-система должна пережить пользователей, данные, отказы, поддержку, безопасность, деплой, изменения, и время.

Реально ли строить сайт с ИИ дешевле, чем нанять разработчика?

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

Почему ИИ-сгенерированный софт часто ощущается сшитым по мере роста?

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

Что стоит спросить, прежде чем генерировать сайт с ИИ?

Где он будет хоститься и кто его поддерживает, что владельцу нужно менять без прикосновения к коду, где живут данные, какие интеграции важны, как обрабатываются отказы, как система будет верифицирована, и что происходит по мере роста бизнеса.

Реально ли ИИ-сгенерированные видео-демо сайтов новая техника?

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