Мой начальник хочет no-code в проде. Я против — и готов уйти

Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом

У меня 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.

Контраргументы руководства — и почему они не работают

«Это цунами, и мы должны его оседлать, иначе оно нас сметёт»
Нет. Это не цунами — это хайп. Настоящее цунами — это накопленная техническая сложность, которая накроет команду, если сейчас подменить инженерные процессы визуальной магией без контроля. Оседлать волну — значит понимать, куда она нас несёт. А слепое следование трендам — это утопия, а не стратегия.

Они сделают то, что выглядит как интерфейс. Но это не UI с UX, логикой и адаптивностью. Это макет.

«Вам же остаётся чуть-чуть допилить»
Каждый раз, когда слышу это — мне хочется найти киянку (молоток такой из твёрдого дерева, если кто не знает) и долбануть им… куда придётся. Ведь я знаю: нужно будет делать всё заново, плюс разбираться в визуальной сборке.

«Это современный подход!»
Современный — не значит зрелый. Быть в тренде — не цель разработки. Цель — рабочий, масштабируемый, поддерживаемый продукт. Моя жена — любит следовать моде и быть “в тренде”, но она — женщина и ей это идёт (более того, она знает в этом толк), но мужчина ответственный за стабильность продукта — не может себе такого позволить (простите меня, дамы — не хочу никого обидеть).

«Другие компании так делают»
Мы — не стартап из презентации на 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 для ускорения работы — разумеется под моим строгим контролем.