Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом
У меня 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 для ускорения работы — разумеется под моим строгим контролем.