Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом
У меня 25 лет опыта в веб-разработке. Я видел, как появлялись и умирали десятки инструментов, фреймворков, "революций" и "новых парадигм". Я устал повторять, что я не нео-луддит. Я не против прогресса. Но есть момент, когда вместо прогресса тебе продают иллюзию простоты, замаскированную под инновацию.
Так вот, теперь наш CEO влюбился попал под очарование Lovable и хочет, чтобы мы начали использовать его или Base44 для ускорения разработки и быстрого внедрения новых фич. По его задумке, дизайнер "набрасывает интерфейс" (в этих визуальных платформах для сборки UI/UX дизайнером), а мы "допиливаем чуть-чуть на бэке" (через API, Карл!), и всё - фича в проде. Time-to-Market стремительно сокращается, мир спасён, а мы свободны от "лишней инженерии".
Я против. Категорически. И да, это война.
Мне есть что терять - но я не буду "вайб-кодить"
Я серьёзно: если это станет нормой, я готов уйти. Не потому что капризничаю, а потому что не хочу быть заложником криво сделанных решений, за которые потом же сам же и буду отвечать.
Что удивительно - многие в команде согласны со мной. Но вслух этого не скажут: боятся идти против начальства, выглядеть "староверами", или просто "не быть командным игроком".
Я не боюсь. Потому что я уже видел, как заканчиваются такие истории.
Как работает Lovable - и почему это боль
У нас продукт вышел на плато стабильной работы после последних пары лет кропотливой работы. Микросервисы синхронизированы, пайплайны проверены годами, багов всё меньше и меньше, а инфраструктура отлажена. Мы дошли до той редкой точки (не побоюсь этого слова! (с)), когда команда не тушит пожары, а развивает систему (спасибо мне, хорошему, что не шёл всегда на поводу у продакт менеджеров). Но теперь всё это начинает рушиться - только потому, что кто-то наверху решил "догнать тренды" и внедрить модную визуальную платформу.
Lovable - это low-code/no-code инструмент. Что-то между Figma, Retool и Wix на стероидах. Ориентирован на дизайнеров: рисуешь блоки, задаёшь поведения, подключаешь условные данные. Далее - разработчики якобы подключают API, и всё "работает". При первом знакомстве с ним - он просто гипнотизирует, особенно тех, кто никогда серьёзно не программировал.
Наш директор показывает нам на собраниях как он сам (sic!) "запилил" за пару дней крутую фичу, остаётся только интегрировать её в основной продукт.
Но только в теории.
На практике:
У нас одна часть проекта на PHP, другая на FastAPI (Python), фронт на VueJS.
Lovable использует React, а у нас он применяется всего в одном небольшом подпроекте. Интеграция его в основной стек вызывает вопросы даже на уровне сборки и CI/CD.
У Lovable своя логика, свой способ работы с событиями и данными.
Стыковка с нашим API - постоянная борьба. То CORS не так, то структура не та, то Lovable кэширует ответы.
Тестировать это через CI? Удачи.
Дизайнер хочет "подключить" форму — но она не валидирует поля, не логирует ошибки и не обрабатывает edge-кейсы, он говорит — я "навайбил" всё, что можно, теперь это ваша забота.
В итоге разработка занимает столько же, сколько обычная (и даже больше), только теперь ты ещё борешься с визуальным Frankenstein-интерфейсом.
Отдельная боль - это стыковка разных технологий внутри одного продукта. Когда в одном флоу у тебя PHP-сервис, Python-бэкенд, фронт на Vue, а теперь ещё и на React от Lovable с непредсказуемыми зависимостями, ты теряешь управляемость. Это не гибкость - это хаос.
Вот только несколько реальных проблем, с которыми мы уже столкнулись:
При обновлении Lovable нарушаются зависимости с Python-сервисом: авторизация по токену ломается из-за несовпадения форматов в кэшах.
Из-за того что часть написанная на Lovable запускается в отдельном контейнере, приходится городить отдельные правила для CORS. Всё это ломается при каждом редеплое.
Общая сборка требует как минимум трёх разных пайплайнов: один для PHP, второй Python + Vue, ещё одни - для Lovable. Общие тесты невозможны без костылей.
Логирование разнесено: что-то в Sentry, что-то Kibana, что-то в stdout внутри Lovable - где искать ошибку, решает удача.
Сначала данные сохраняются в промежуточный слой - Superbase. А потом, как только всё "заработало", возникает новый этап: переписать всё под PostgreSQL, на которой держится остальная часть продукта. Миграции, синхронизации, инциденты - это не "ускорение", это повторение работы.
На проде это особенно болезненно.
Ещё больше примеров боли
SPECS больше не нужны — ведь всё уже "набрано"
Один из самых опасных эффектов: продакт менеджер перестаёт писать внятные требования. Зачем описывать бизнес-логику, предусматривать сценарии, если визуальный интерфейс уже "готов"? Теперь у нас исчезают product-specs и нормальные требования, потому что всё делается "по ходу" в Lovable. А потом мы неделями разбираем поведение, которое никто не документировал, либо это поведение "красиво написано" при помощи GPT.
Firefox не отображает форму
Причина - кастомный шрифт через их CDN. Почему не грузится? Нигде не написано. В логах - тишина. Надо фиксить.
События обрабатываются на стороне клиента
Отладить невозможно. Иногда форма говорит "успешно отправлено", а запрос не ушёл. Где баг? Гадать - не перегадать, будем фиксить.
Поддержка - ад на земле
Ты не знаешь, где логика: в Lovable или в твоём коде. Что-то ломается - дебажишь всё подряд. Плюс - надо разобраться в коде, который "наREACTил" наш любимый (уж простите за тавтологию) Lovable.
Контраргументы руководства - и почему они не работают
"Это цунами, и мы должны его оседлать, иначе оно нас сметёт"
Нет. Это не цунами - это хайп. Настоящее цунами - это накопленная техническая сложность, которая накроет команду, если сейчас подменить инженерные процессы визуальной магией без контроля. Оседлать волну - значит понимать, куда она нас несёт. А слепое следование трендам - это утопия, а не стратегия.
"Вам же остаётся чуть-чуть допилить"
Каждый раз, когда слышу это — мне хочется найти киянку (молоток такой из твёрдого дерева, если кто не знает) и долбануть им… куда придётся. Ведь я знаю: нужно будет делать всё заново, плюс разбираться в визуальной сборке.
"Это современный подход!"
Современный - не значит зрелый. Быть в тренде - не цель разработки. Цель - рабочий, масштабируемый, поддерживаемый продукт. Моя жена — любит следовать моде и быть “в тренде”, но она - женщина и ей это идёт (более того, она знает в этом толк), но мужчина ответственный за стабильность продукта - не может себе такого позволить (простите меня, дамы - не хочу никого обидеть).
"Другие компании так делают"
Мы - не стартап из презентации на Product Hunt. У нас не одноразовый лендинг, а зрелая система. И blind copying - худшее, что можно сделать.
"Нам нужно идти в ногу с рынком"
Следовать рынку - это не копировать визуальные инструменты, а строить устойчивые процессы и архитектуру. Если все строят из дерева, а ты из пластилина, ты не прогрессивный, ты хрупкий.
"Это быстрее!"
Только если это прототип и в первый раз. А потом - борьба с ограничениями.
"Дизайнеры смогут сами делать интерфейсы"
Они сделают то, что выглядит как интерфейс. Но это не UI с UX, логикой и адаптивностью. Это макет.
Где граница допустимого?
No-code не зло. Но у него есть пределы применения, и за ними начинается вред:
Когда заменяет документацию. Нельзя строить интерфейс без четких требований и продуктовых ожиданий.
Когда отрезают от CI/CD. Если инструмент нельзя протестировать и включить в pipeline - он вне production-стека.
Когда нарушает границы ответственности. Дизайнер - не backend-инженер. Frontend - не бизнес-логика. Продакт-менеджер - ни б-г, ни царь и не герой. Путаница здесь приводит к катастрофам.
Когда ограничивают масштабируемость. Вырасти на no-code можно, но упереться в потолок - очень быстро и больно.
Я не против no-code как класса:
Для прототипов - окей.
Для MVP - с натяжкой, но возможно.
Для продакшена, где важна масштабируемость и надёжность? Нет.
Особенно пугают попытки завернуть всё это в обёртку "универсального решения". Посмотрите, например, на Base44 - визуальный пайплайн, который обещает объединить UX, API и бизнес-логику в одном потоке. Звучит круто, пока не окажется, что он закрыт, недоступен для отладки и зависим от десятков "магических" связей внутри платформы. Сложность уходит с экрана - но не из системы. Она просто становится невидимой.
А что вместо этого?
Итак, no-code это не зло - но и не серебряная пуля. Если хочется ускорения и гибкости без потери контроля, есть зрелые альтернативы:
Figma + Storybook - дизайнер создает UI-макет, а разработчик превращает его в живой компонент с контролем над логикой, состоянием и тестами.
Code-first, UI-assisted инструменты — вроде Plasmic, которые позволяют начать визуально, но всегда с возможностью контроля через код.
Я хочу, чтобы мы серьёзно задумались о том, где мы и что мы. Давайте честно:
Любой серьёзный продукт требует контроля над кодом.
Прозрачность, тестируемость, архитектура - это не побочный эффект, это основа.
Разработчик - не обслуживающий персонал.
Строить архитектуру из блоков без понимания её жизни через 6 месяцев - опасно.
Заключение
Наш начальник хочет no-code. Я - нет. И я готов уйти, если мы всерьёз не свернём с этой дороги. Потому что подмена инженерной культуры удобством - это путь к краху.
Я не ретроград. Я не против новых инструментов. Я - за вменяемость. Если вы, как и я, устали "допиливать чуть-чуть" после визуальных экспериментов - знайте: вы не одиноки.
Мы на фронте. И пока - не сдались. Спасибо, что дочитали до конца.
P.S. Наверное вышло слишко эмоционально, просто наболело и захотелось выплеснуть это всё на бумагу HTML.
P.P.S. Если вам тоже приходится объяснять, почему визуальные платформы - это не silver bullet, поделитесь статьёй с менеджером. Или распечатайте и положите на стол.
P.P.S. Чтобы не показаться предвзятым. В данный момент я разрабатываю прототип для одной NLP идеи, при этом вполне себе использую и Сlaude и Windsurf для ускорения работы - разумеется под моим строгим контролем.