Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом
У меня 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 для ускорения работы - разумеется под моим строгим контролем.
Комментарии (102)
Rob1nZon
06.06.2025 13:20очередное нытье деда с завышенным ЧСВ с супепупер по его мнению важным продуктом.
Arioch
06.06.2025 13:20Вам же остаётся чуть-чуть допилить
А вы это раньше никогда не слышали, если про дедов рассуждаете?
Фразочка-то сама с длинной бородой.
Вариант её, который мне лично сильнее всего запомнился:
- а вот я хочу работать с RedMine, мы в банке с ним работали, я к нему привыкла. Уберите ваш сервер и поставьте RedMine
- это, наверное, хорошая программа, но она использует Linux, PostregSQL, Ruby и Ruby-on-Rails. Это, наверное, хорошие программы, но каждая из них очень сложная, а я на профессиональном уровне не знаю ни одной из них, и при возникновении любых проблем не только не смогу за конкретный срок их решить, но даже не смогу понять в какой их них четырёх эта проблема случилась.
- глупости вы говорите, у нас никогда в банке проблем с ним не было! Но если вы такой неуверенный, я приглашу мужа. Он хороший специалист, он вам на сервере всё поставит, а вы просто будете ни за что получать деньги
- у вас просто отличный муж. А ещё у вас замечательная семья. Давайте так и сделаем, но ещё мы устроим вашего мужа на четверть ставки - на обслуживание этого сервера, он будет ничего не делать и ваша семья будет ни за что получать деньги!
- вы совершенно испорченный человек, с вами невозможно работать!!!Дальнейшее было тоже забавно. Она всё же нашла, где поставить свой Redmine, и кто будет за него номинально отвечать (аутсорсник. То есть вопросы типа "не работает! все отделы стоят! Исправить за 5 минут!!!" будут равнодушно покрываться договором с "3 дня на реакцию". именно на реакцию, а не на исправление. Там тоже умеют писать договора).
Потом она запретила пользоваться старым сервером, потому что все по привычке писали туда. Потом она запретили на новом баг-трекере писать "техническую муру", потому что "директору это непонятно и не интересно. Пишите когда будет готово и кто за задачу отвечает, а мусор ваш сюда не тащите!". Но "тащить мусор" на старый сервер запретила ещё жестче.
Kwisatz
06.06.2025 13:20Нельзя строить интерфейс без четких требований и продуктовых ожиданий.
можно, четкие требования это миф. Это перекладывание ответственности и работы UX архитектора на другую сторону
janvarev
06.06.2025 13:20Нельзя, чтобы интерфейс строил дизайнер по принципу "я так вижу и так нейронка закодила" - а потом уже команда подстраивалась под созданный
от балдыинтерфейс.Kwisatz
06.06.2025 13:20С 1 стороны вы правы, нельзя. С другой моя команда ровно так часто и делает, хотя я могу объяснить пару сотен решений детально, но переварить это все равно люди не смогут быстрее чем за пару месяцев
janvarev
06.06.2025 13:20Давайте так - иногда так делать можно. У меня комментарий чуть ниже, я сам честно признаюсь, что, например, внутренние админские интерфейсы сплавляю делать нейронке.
С другой стороны - вам НУЖЕН архитектор/лид, чтобы он сказал, где так можно делать, а где нельзя. В хорошей, осознанной команде, где все понимают риски, иногда можно не слишком строго соблюдать границы, но в общем, это редкость, и все равно должен быть человек, который отвечает за решения - и это вряд ли UX-дизайнер (если он не лид, конечно, мало ли, может, продукт от интерфейса пляшет)
Kwisatz
06.06.2025 13:20Я докопался именно до формулировки. Делать UI нейронкой - полный бред. Но вот ставить во главу угла UX - нормально, даже UI пойдет, хотя тут я бы поправил, потому что с оговоркой на наличие проработанной модели.
anshdo
06.06.2025 13:20Ага, наша команда тоже часто так и делает, но почти всегда потом получает по лбу этими граблями: "ок, реализовано то у нас вот так, а как надо было?"
Kwisatz
06.06.2025 13:20Ну дык начните работать со своим продуктом, развивайте навык, чтобы представлять себя на месте оператора и вопросов таких не будет
hphphp
06.06.2025 13:20Вы работали с АСУ ТП системами? После них дизайн любой дичи вам покажется милым зоопарком.)
...про хайп, что бы довести до абсурда нужно вайбкодинг внедрить на каких-нибудь чувствительных АСУ ТП, АЭС например - мигом поубавится рвения для внедрения "новых фич" с конкретной фамилий автора-руководителя)
janvarev
06.06.2025 13:20Очень печально.
У меня проект по предоставлению доступа к зарубежным LLM, и я сам по факту много использую их для программирования на прод... внутренних админских инструментов и микросервисов типа "одна функция нужна". Мне, как специалисту с 20-летним опытом, очевидна грань между работой "красиво" и "устойчиво и прозрачно".
Чтож, хотя я обычно негативно смотрю на то, что кодинг с LLM называют хайпом, после этой истории вынужден признать - внедрение LLM по маркетинговым материалам без консультации со специалистом по ИИ может реально разрушить существующий продукт и процессы. А почему? Потому что техдир/продакт и пр. не может наступить себе на самооценку и сказать "Я не специалист по ИИ, может, найдем хорошего эксперта?" Не-е-ет, сольем пару месяцев команды за несколько лямов рублей, но эксперта искать не будем...
Shaman_RSHU
06.06.2025 13:20Можно программировать на прод, используя LLM, только соблюда гигиену. Только придерживаться парадигмам тестирования и использовать контуры DEV -> TEST -> PREPROD -> PROD. Но менеджеры всё время гонят, гонят time2market и некоторые этим принебрегают.
janvarev
06.06.2025 13:20Да, но я бы использовал нейронку для локальных кусков кода. Имхо с позиции моего опыта - архитектуру сложного приложения ей давать нельзя.
AlexeyK77
06.06.2025 13:20Вероятно есть истинная причина. которую не озвучивают: владельцы бизнеса ищут способы быстро вернуть свои инвестиции, а приходится содержать зрелую команду хороших специалистов, которая пройдя огонь и воду вывела продукт на плато стабильности. Теперь надо сократить расходы на ЗП, а для этого надо заменить суперзвезд на спецов подешевле, для чего надо внедрить новую "подходящую" хайп-технологию.
Поэтому у вашего босса есть кредит доверия, что бы проталкивать эту фигню. К сожалению это неизбежный этап и вероятно они своего добьются. Так что...
xSVPx
06.06.2025 13:20Ну в целом владельцы так управляющие бизнесом совершенно достойны неизбежного результата.
Но да, резюме пора обновлять. Хуже не будет...
verasokolovaip
06.06.2025 13:20Мы дошли до той редкой точки (не побоюсь этого слова! (с)), когда команда не тушит пожары, а развивает систему (спасибо мне, хорошему, что не шёл всегда на поводу у продакт менеджеров).
И потом вот:
У нас одна часть проекта на PHP, другая на FastAPI (Python), фронт на VueJS.
Перевожу: "Я великий, уникальный, никем не понятый, очень крутой разработчик, программист. Хочу быть незаменимым. Хочу, чтобы бизнес от меня зависел. Хочу, чтобы кланялись и просили. А я бы с умным видом выбирать что и как делать. А тут бизнес решил заменить говномонолит из костылей на что-то, а баба-яга против!
samako Автор
06.06.2025 13:20И почему Вы собственно решили, что он из костылей? И почему Вы обзываетесь на монолиты - монолит это не обязательно зло, если он хорошо отлажен и работает как часы. И потом, часть высоконагруженного кода у нас вынесена в микросервисы, а в остальном - всё ок, работает как по "феншую".
А насчёт бабы-яги, то да - против. А что, всёгда нужно "за", если бизнес так решил?
flancer
06.06.2025 13:20Монолит по определению не может быть одновременно и на PHP, и на Python ¯\_(ツ)_/¯
И, кстати, заставить подобный зоопарк работать - нужно быть достаточно неплохим спецом. И менять работающее приложение, пусть даже оно и "говномонолит из костылей", на что-то новенькое бизнесу никто запретить не может. Тут просто стоит вопрос - под чью ответственность :)
Да и вообще, если вдруг бизнес решил самовыпилиться таким экзотическим способом - флаг ему в руки!! Я бы уже начал искать другой аэродром, а ТС, вон, старый ещё пытается спасти.
samako Автор
06.06.2025 13:20Я не сказал, что у нас монолит и на PHP и на Python одновременно. У нас ядро на PHP (это монолит, да, но разбит на модули), а на Python основной отдельно стоящий сервис. Взаимодействие между ними через API. Плюс, есть микросервисы для высоконагруженного кода. Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
С бизнесом у меня отношения простые - его задача прибыль, но! не в ущерб инженерии, а в остальное ему нос совать не нужно. У меня у самого был свой бизнес, поэтому челом бить перед ним я не собираюсь. Просто очень часто плохую работу отдела продаж пытаются компенсивать за счёт издевательства над разработкой - типа тут результат можно почувствовать гораздо быстрее. В этой плоскости собственно драма и развивается.
Но Вы правы - запретить бизнесу самовыпилиться - никто не может. Я уже начал обновлять резюме.
edogs
06.06.2025 13:20Я не считаю такой "зоопарк" чем-то необычным
В чем тогда принципиальное соображение против добавления Lovable ? В зоопарке может быть больше 2 животных.
Мы бы больше сочувствовали бы автору статьи, если бы у него уже не было зоопарка. Но в данном случае у него уже есть зоопарк, он научился за ним ухаживать, но категорически против нового животного, т.к. "у нас и так все хорошо", а это новое "ходит не так, кушает не то, рычит по другому".
И еще вопрос - а почему раньше автор не был против зоопарка? Почему это случилось именно сейчас?
Pusk1
06.06.2025 13:20Может пора менять работу? Продукт есть и стабильно развивается. Зоопарк тот ещё. Найдя новый проект принесёшь больше пользы и научишься чему-то новому.
Команда большая, стоите дорого, фичи пилите медленно.samako Автор
06.06.2025 13:20Да, отгонял эту мысль долго, но похоже нужно начинать готовить почву для следующей станции
un1t
06.06.2025 13:20Для начала все-таки стоит попытаться донести свои мысли до начальства. Расписать плюсы и минусы, собщить во сколько компании обойдется утекшая база или верчно ломающийся прод, а также дикий неподдерживаемый говнокод из-за которого разбежится вся команда. Объяснить границы преминимости инструмента.
samako Автор
06.06.2025 13:20Я не написал это в статье, но я пытался это сделать: и объяснял и уговаривал и приводил доказательства. Увы, тяжело логикой переформатировать головы людей, влюблённых в вайб-кодинг. Да им и всё-равно - я уйду, а они останутся.
un1t
06.06.2025 13:20Да я сам влюблен в вайб кодинг. Но одно дело это прототип или пет проект, а другое дело большой стабильный проект,
Сейчас много историй как ключи утекают или счет потом сливают в минуса в навайбкоденных проектах. Возможно стоит подкинуть таких историй для размышления.
У вас же есть техдир или это вы и есть? Техдир должен принимать это решение а не CEO.
gsaw
06.06.2025 13:20Хоть и избито уже, но добавлю. По приданию, во времена золотой лихорадке больше все обогатились производители лопат.
Так и тут, На всех хайпах в айти, больше всего вижу появление всяких фирм, которые предлагают какие то чудо утилиты, которые обязательно перевернут процесс программирования. На рубеже веков это были визуальные редакторы кода. Это типа когда не надо писать код, а только мышкой диалоги собираешь, ну и код можно писать, если хочешь. Потом выясняется, что код не можно, а нужно писать. Figma вот, хорошо забытое старое.
Про блокчейны и ICO так вообще добавить нечего. Смартконтракты и прозрачность должны были решить вообще все проблемы в мире. От учета монеток, до владельцев произведенных банок сгущенки.
Потом вот помню бум стартапов, которые рождали всякие проекты, которые почему то не решали какие то прикладные задачи, а больше порождали проекты призванные чего то то там улучшить в программировании. Мне кажется тогда стали модными хакатоны. На выходных завайбкодил поделие, привлек инвесторов и свалил в закат на свой остров.Сейчас вот ИИ способное по запросу выдать код змейки или даже крестики нолики. И это будет даже работать. Имхо, почему бы в git-e не хранить историю запросов и сидов, в место кода. Экономия места же! :) Причем, через год обновили модель, она на тот же самый запрос выдаст более оптимальный и более безбажный код, с современным интерфейсом. Не надо ничего переписывать, не надо оптимизировать. Код и продукт эволюционируют со временем. Это же вообще сказка :)
Не мудрено, что и ИИ бум рождает чудо инструменты, которые решат все ваши проблемы. Главное пережить время бурления, а там и новый бум подберется со спины.
bak
06.06.2025 13:20Имхо, почему бы в git-e не хранить историю запросов и сидов, в место кода.
Потому что промпты сами по себе не описывают состояние, а описывают запросы на изменение.
Возможно скоро появятся какие-то промпто-подобные способы описания текущего состояния приложения. Чтобы из набора фраз "А теперь добавь кнопку!" "А теперь перекрась её в зеленый" генерировалось состояние "Зеленая кнопка слева по центру", из которого уже потом будет генерироваться полное приложение.
edogs
06.06.2025 13:20По приданию, во времена золотой лихорадке больше все обогатились производители лопат.
По "преданию".
На всех хайпах в айти, больше всего вижу появление всяких фирм, которые предлагают какие то чудо утилиты, которые обязательно перевернут процесс программирования.
Имхо, это все же не лопаты. Лопатами можно было копать и добывать золото. Это были работающие рабочие инструменты.
Современный хайп ИИ у нас вызывает больше ощущения "посоленого рудника", застолбили рудник, насобирали там немного золота (или добавили) и продают как будто там исследованная золотая жила без каких-либо проблем.
В некоторых случаях покупка такого рудника реально оправдана (и тогда можно сбабахать сайт за пару недель с затратами в 10 раз меньше и рубить бабло, пока конкуренты год пилят сурьезный проект), но во многих выливается в эпик фэил (и что самое обидное - выясняется это уже в конце пути, когда время и деньги уже потрачены).
Dhwtj
06.06.2025 13:20Наш начальник показывает нам на собраниях как он сам (sic!) "запилил" за пару дней крутую фичу, остаётся только интегрировать её в основной продукт
А теперь пусть выкидывает
Если ведёт себя как джун, пусть получает критику как джун
Это очень по менеджерски: закрыть ладошками глаза и повторять: "не вижу проблем, не вижу проблем"
Dhwtj
06.06.2025 13:20Ну или пусть доделывает до прода и замеряет качество и трудоемкость хотя бы год.
mixsture
06.06.2025 13:20Как по мне, у nocode подхода слабая проработка. Он может и займет свое место когда-то, но пока:
Удобная отладка и отладчик. В обычном подходе это решено, в nocode в зачаточном состоянии чаще всего. Условный возврат к отладке принтами и бесконечным логом.
Контроль за форматом передаваемых данных. Очень часто есть какая-то блок-схема алгоритма, между блоками подразумевается передача данных, а какие там данные и в каком формате - не видно. Упражнение "попробуй собери из всех вышестоящих блоков операции присвоения и запомни".
Инструменты снижения ошибок. В nocode чаще всего отсутствуют области видимости переменных - т.е. будто все переменные глобальные - и ведь когда-то так было и в обычных ЯП, но ушли, уж очень много неявных ошибок это порождает.
Инструменты управления сложностью кода и навигацией. Для обычного подхода придумали разделение на модули/пространства имен/классы с очень быстрыми переходами. Придумали разделение MVC. В nocode же часто - это бесконечных размеров блок-схема. Встречал блок-схему в 6 экранов в ширину и 10 в высоту - и вот кликаешь на ней "развернуть условный переход" - а потом минуты ищешь, куда-же от него ветки развернулись.
Контроль роста потребления ресурсов. Для обычного подхода есть много раз разобранные структуры данных с быстрым поиском/вставкой, разобранные практики, как плохо. Без этого nocode решения часто притягиваются к алгоритмам O(n^2) и поэтому при выходе из прототипа, когда n вырастает в сотни-тысячи раз - это проще выкинуть и переписать.
Системы контроля версий. Они все разрабатывались для текстов. Сравнить 2 участка кода и показать изменения - не проблема, трехстороннее сравнение - не проблема, а вот сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема.
Без этих инструментов проблематично удержать сложность сколь-нибудь большого проекта.
Anton-V-K
06.06.2025 13:20сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема
припоминаю в эпоху популярности WYSIWIG-редакторов UML-диаграм (типа Rational Rose и проч.) похожая проблемка всплывала - только часть из них умела сохраняться в струкрутированный текстовый формат (обычно самодельный), но и в нём были автогенерируемые служебные идентификаторы (типа GUID'ов), которые обновлялись при каждом чихе, так что diff между соседними версиями выглядел "полосатым" на весь экран.
По идее nocode-диаграма тоже может в текстовый файл сохраняться, наработки есть же. Правда, разницу глазами в таком формате может быть неудобно смотреть.
StasTukalo
06.06.2025 13:20Вам бы с этим текстом- да к руководству повыше того придурка-любителя "но-код-программирования"- к тому, кому есть дело именно до бизнеса, а не до своих бонусов за то что "внедрил и ускорил".. но скорее всего этот товарищ хорошо умеет в уши лить, раз с таким подходом до сих пор при должности..
В общем- всё печально, сочуствую.
Dhwtj
06.06.2025 13:20Low code для коротко живущих ad-hoc фич и точно не для core, только стандартные решения (кастомизация это очень дорого) и без возможности сопровождения или развития (проще сделать заново).
Если начальник понимает это, то ок.
Я навидался low code систем разных поколений. Всё одно и то же.
CrushBy
06.06.2025 13:20Low code для коротко живущих ad-hoc фич и точно не для core, только стандартные решения (кастомизация это очень дорого) и без возможности сопровождения или развития (проще сделать заново).
Ну мы на low-code делаем ERP-системы на lsFusion для розничной торговли (вот демка). Уже 10 лет. И прекрасно все кастомизируем под разных клиентов, имея при этом базовую версию. У самых крупных клиентов 2000 одновременно работающих пользователей, миллиарды записей и базы под 10ТБ. Что мы делаем не так ?
VitalyZaborov
06.06.2025 13:20По-моему, тут дело не в no-code ни разу. Если вы не можете договориться с менеджментом насчёт стабильности и стоимости принимаемых решений - делать в этой компании нечего. Не сломаются об no-code, сломаются ещё обо что-то.
У каждого решения есть стоимость: сейчас Вы описали, что внедрение новой технологии стоит "2 года и 2 миллиона долларов". Если бизнес считает, что это надо сделать за 2 дня и пачку доширака - вы вряд ли договоритесь.
Но если Вас всё же готовы слушать - имеет смысл доносить в терминах бизнеса: да, мы снижаем ttm, но бэкенд становится дороже вдвое, а стабильность падает, дорожает QA. Если бизнес вдруг и такое устраивает - жмём друг другу руки, нанимаем 2-3 новых отдела и с готовностью принимаем "новые вызовы".
Dhwtj
06.06.2025 13:20Видимо, для ad-hoc аналитики, 342й формы отчётности или 191го способа расчета скидки на акции low code годен. Но только там. При грамотном расчёте это всё видно (не прогнозе, а разборе результатов за год)
Arioch
06.06.2025 13:20нанимаем 2-3 новых отдела
Вы все перепутали. Не нанимаем два отдела, а увольняем половину отдела.
Вам же Главный Начальник сказал: "Вам же остаётся чуть-чуть допилить"
А если вы сделаете вид, что с этим не справились, то значит вы не профессионал, а луддит и саботажник. У каждой проблемы должно быть приятное и удобное имя и фамилия, они вашиVitalyZaborov
06.06.2025 13:20Ну вот раньше не надо было допиливать, а теперь надо. Нужен отдел допивания. Повторюсь: если у вас в компании у проблем не варианты решений, а имена и фамилии - в такой компании нормальному специалисту нечего делать.
sanyvaa
06.06.2025 13:20работаю на большом проекте, которому уже под 20 лет. сотни тысяч строк кода, десятки тысяч закрытых воркайтемов, пофикшеных багов.
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
разработка новой фичи - надо знать как заюзать существующий код, чтобы не изобретать велосипед и не копипастить.
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
ИИ должен стать архитектором и техлидом на проекте, чтобы эффективно работать. пока же нейронки явно не готовы для этого.
bak
06.06.2025 13:20и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
для любого изменения нужно понимать архитектуру и код проекта
Не надо делегировать LLM архитектуру. Для архитектуры есть собственная живая нейросеть, обычно неплохо работает.
LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
Для начала неплохо бы написать юнит тест который этот баг воспроизводит. Если сам уже понял шаги - заставить LLM сгенерировать код юнит-теста не проблема.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
Повторить пункт два до тех пор пока LLM и ты сам не поймешь и не убедишься в чем баг
Дальше просишь LLM сгенерировать фикс, можно для верности уточнить какой фикс ты хочешь
Профит.
sanyvaa
06.06.2025 13:20LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
вот именно что я не могу представить себе таску, которую я могу вот так описать. разработка - всегда постепенный процесс.
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор. это нафиг не надо, это времени не занимает. основное время на большом проекте занимает внедрение фичи в существующую архитектуру, поиск зависимостей, рефакторинг существующего кода.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
"фигануть дофига" это конечно хорошо, но как я уже писал в фиксе бага главное анализ истории изменений, а не сделать так чтобы он не проявлялся.
например если это креш изза доступа по null reference, недостаточно поставить проверку на null, я такой фикс обычно не пропускаю, надо понять почему раньше работало, а сейчас появился этот null.
Wesha
06.06.2025 13:20типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там.
У меня эта картинка уже на макросе
bak
06.06.2025 13:20пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор
Это рутина, зачем набирать код самому если это может делать LLM. Просто из за хейта LLM? Меня на 90% устраивает кодярник от LLM, я 50 строк кода набираю медленней чем несколько фраз.
это нафиг не надо, это времени не занимает
У меня написание юнит тестов занимало довольно существенную часть времени. Намного больше чем написать "сделай тест который проверяет кейс с такими-то шагами".
в фиксе бага главное анализ истории изменений
Чтобы не нужно было делать "анализ истории изменений" люди пишут юнит тесты. Которые отломаются если вы сломаете полезный функционал. И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Maccimo
06.06.2025 13:20Это рутина, зачем набирать код самому если это может делать LLM.
Чтобы не превратиться из человека в безмозглый придаток БЯМ, например. Кончится инторнет и всё, вайб-кодер превратился в тыкву.
И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Действительно, зачем думать?
BorisTheAnimal
06.06.2025 13:20А я вот прямо сейчас наблюдаю, как хорошие в прошлом разработчики, подсев на LLM (в частности из-за того, что менеджмент форсирует скорость разработки), начинают терять навык критического мышления и не могут решить элементарную проблему самостоятельно (когда LLM тоже не помогает). И это очень пугает, так как я ожидал, что подобное может произойти где-то в будущем, но не думал, что даже текущие синьоры начнут так активно деградировать. Наблюдаю это в организации с более чем 2000 разработчиками, так что выборка неплохая такая.
bak
06.06.2025 13:20Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
sanyvaa
06.06.2025 13:20Это рутина, зачем набирать код самому если это может делать LLM.
а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.
основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.
bak
06.06.2025 13:201 процент времени - это значит вы за 8-ми часовй день набираете код меньше 5 минут. Верю, я поверил.
vlmonk
06.06.2025 13:20фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое
Вот кстати LLM уже неплохо это могут. Поднять историю изменений в куске кода, найти нужные MR, найти и прочитать связанные тикеты в jira. Скомпоновать все вместе и выдать отчет "кто, когда и зачем это делал". И все это за 2-3 минуты пока я себе кофе наливаю.
BorisTheAnimal
06.06.2025 13:20ага, это если все вот это все нормально где-то в тикете описано. А на деле 60% информации в реальности была получена разработчиком в ходе обсуждений (записей которых нет), а даже то, что есть можно трактовать совершенно по разному.
sanyvaa
06.06.2025 13:20звучит красиво.
тут еще такой вопрос. ваша LLM работает локально или вы предоставляете доступ наружу для всего кода и документации проекта?
vlmonk
06.06.2025 13:20Claude code max + MCP
Доступ к коду / jira через агента на локальной машине. Но понятно что дальше это все летит в anthropic
bak
06.06.2025 13:20Где пункт в опросе "уже вайб-кодю и счастлив"? Но конечно не так как у автора.
Самому вайбкодить когда четко понимаешь что почему и зачем делегируешь LLM - это норм. Поддерживать то что там навайбкодил кто-то там еще без опыта разработки - не норм.
UkfdysqYfxfkmybr
06.06.2025 13:20И да, это война.
Я бы на месте начальника уволил бы такого воена. "Уходя - уходи".
Wesha
06.06.2025 13:20Я бы на месте такого воена сам ушёл: если начальник ведёт армию в пропасть — зачем идти с таким начальником?
PetyaUmniy
06.06.2025 13:20Ну может быть, например, желание посмотреть что же произойдет в конце? Особенно если ждать этого конца не придется долго.
Или произнести сакральное: "Я же говорил!". :)
olku
06.06.2025 13:20Можно посчитать TCO обоих подходов, сделать PoC и передать уровнем выше? Начальники, которые подставляют доходы владельцев не задерживаются.
0x131315
06.06.2025 13:20Не вижу проблемы. Любой велосипед требует поддержки даже больше, чем нормальные решения. Всем же очевидно, что это не более, чем велосипед? Если введут no-code, от этого процесс только усложнится: нужны будут эксперты, чтобы это поделие увязать со всеми остальными системами, потребность в разработке только вырастет. Оно еще и проблем будет регулярно подкидывать, которые в рамках no-code просто не решаются. No-code это надстройка, красивая панель управления, но чем сложнее система, тем больше обслуживающего персонала требует, и тем более дорогой и квалифицированный это персонал должен быть, это простая истина. Через пару лет посмотрят на то как все стало медленно и дорого, и выкинут этот no-code. Делов то.
geornit25
06.06.2025 13:20Проблема в том, что процесс поиска и исправления ошибок после LLM - так себе занятие. Заниматься этим целыми днями на постоянной основе - удовольствие ниже среднего, даже если платить за это будут по повышенной ставке.
Gradiens
06.06.2025 13:20Кажется, вы потворствуете такому подходу, потому что разруливаете все проблемы, который принес no-code подход.
Начальство видит: всё [почти] работает, а вы брюзжите (простите).
Если вы и так готовы уволиться, может, пора отпустить ситуацию и перестать все и всех спасать? Порветесь ведь...
Когда придет очередной баг, просто скажите "насяльника, шайтан-машина кодила-кодила, а логов нет. Не могу починить".
Когда развалится пайплайн, просто просигнализируете "насяльника, шайтан-машина пайп поломала, починить не могу".
Когда упадет прод... Ну вы поняли )
Столкнувшись с реальными проблемами, а не с вашими рассказами, быть может, начальство изменит мнение.
samako Автор
06.06.2025 13:20Ваше предложение абсолютно логично, но я человек, более того - я человек старой закалки. Я не могу плохо работать, это не моё. У меня в команде лозунг: либо мы работаем хорошо, либо.. очень хорошо. Других вариантов нет, кто не согласен - я не держу.
Но Вы правы, пора отпустить ситуацию (за пинок - спасибо). Видимо это мысль - главное, что я вынес из всех коментариев.
totsamiynixon
06.06.2025 13:20У меня в команде лозунг: либо мы работаем хорошо, либо.. очень хорошо.
Мощно. Одобрямс.
AppCrafter
06.06.2025 13:20Ваша статья напомнила классику: ))
"- Нам нужно начертить семь красных линий – продолжает Марковьева – Они все должны быть строго перпендикулярны, к тому же некоторые нужно изобразить зеленым, а ряд линий прозрачным цветом. Хочу узнать ваше мнение – это реально?
- Нет – отвечает Смешков.
- Ну, давайте не будем торопиться отрицать, Смешков – говорит Сидоряхин. – перед нами поставлена Задача, нужно найти способы ее решения. Вы же профи! Не давайте повода, считать вас непрофессионалом!"
Полный текст по ссылке, если Хабр пропустит - https://smartbluebird.livejournal.com/28979.html
geornit25
06.06.2025 13:20Основная проблема автора, насколько можно понять, заключается в том, что он и бизнес, в лице CEO говорят на разных языках. Доводы для бизнеса также должны быть в рамках, которые могут быть им поняты.
Нет смысла упирать на качество архитектуры проекта, его отлаженность и прочее. Это всё технические термины и менеджеры их могут не понимать или не воспринимать всерьёз. Тут скорее надо указать на потенциальные потери бизнеса когда продакшен встанет колом из-за очередных навайбкоденных фич. На то, что доработки станут дороже в процессе расширения присутствия ИИ-кода в кодовой базе проекта.
Было бы неплохо уговорить руководство не класть все яйца в одну корзину, а выделить для вайб-кодинга отдельный проект, не самый критичный, но чтобы эффект от него можно было прочуствовать. И там всё и протестировать, без разрушения кодовой базы основного проекта.
ALapinskas
06.06.2025 13:20а потому что не хочу быть заложником криво сделанных решений, за которые потом же и буду отвечать.
Отвечать должны:
Тот кто сделал.
Тот кто решил нанимать тех кто сделал.
Если отвечать будут не эти лица, то все печально в этой компании, давно надо было уходить!
ma1uta
06.06.2025 13:20
Вы просто ретроград и сопротивляетесь всему новому. Вон, в 90-е годы все бегали и говорили: "Разработчики скоро будут не нужны, бизнес нарисует диаграммки в UML, опишут логику в sequence-диаграммах, нажмут кнопочку, код сгенерируется и всё будет работать". А потом ещё бегали и говорили: " Нам не нужны разработчики и админы, мы утащим всё в облако, в dreamweaver нарисуем интерфейс, он нам всё сгенерирует, фронтвэы не нужны будут".
И только один Фредерик Брукс молча улыбается, наблюдая за очередным увеличением продаж его книги, которую он написал полвека назад.
flancer
06.06.2025 13:20Сложность уходит с экрана - но не из системы. Она просто становится невидимой.
Спасибо, бро! Отличная формулировка. Я впервые с невидимой сложностью столкнулся в Borland'овских IDE, где обещали мышкой научить рисовать UI. Рисовать было круто, а вот потом в той лапше кода крутиться было не очень :(
NN1
06.06.2025 13:20Мне тоже ситуация напоминает период RAD, когда говорили, что можно мышкой формы накидать и асё готово. А когда доходит до реального продукта, то не мышкой и не накидать и не готово.
Doman
06.06.2025 13:20Выглядит как недопонимание. Начальник изначально задал слишком высокую планку внедрения ИИ, а вы приняли диаметрально противоположную позицию. И теперь бодаетесь, вместо поиска компромисса.
Очевидно, что начальник видит проблему с медленным time to prod при текущем подходе. Не всегда подход "делаем или хорошо или ещё лучше" себя окупает. Иногда намного важнее быстро зарелизить MVP и захватить долю рынка, чем прийти с отличным решением когда все уже попилено. Или выпустить MVP как гипотезу, и посмотреть насколько востребовано и как пользуются, чтобы понять куда копать дальше. "Старая закалка" она же "ригидность" здесь только мешает. Могу сказать, что даже в банках для ряда фичей бизнес осознанно приоритезирует скорость над качеством, и нормально относится к негативным последствиям. Это новая реальность везде, кроме каких-то очень специфических продуктов (АЭС, Луноходы, медицина, но это не точно).
Также, при всех недостатках, AI невозможно игнорировать. LLM сделали огромный скачок за последние 3 года, а сейчас в него ещё и вложили все деньги мира. Вероятность ещё одного скачка весьма велика. Да даже и текущего уровня, при наличии нормального окружения, хватит чтобы ускорить целый ряд рутинных задач. И вашего менеджера наверняка напрягает, что "ригидный" техлид удерживает всю команду от получения продакшн опыта в очень перспективном направлении. И пока конкуренты (на самом деле почти все) активно осваивают AI, пусть даже как инвестицию, вы лишаете себя этого опыта. И если AI "выстрелит", то вся команда мгновенно устареет вместо плавной трансформации.
Наконец, внедрение AI это ещё одна сложная и интересная инженерная задача, и именно так у этой инициативе надо подходить. Понять какую проблему хочется решить (TtP), посмотреть на каких задачах можно применить сейчас, как адаптировать архитектуру под дальнейшее внедрение, какие новые метрики понадобятся для data driven решений, набросать с начальником роадмап и начинать постепенное внедрение. Ещё можно заранее посмотреть какие no-code/low-code решения есть на рынке помимо Loveable - может вам что-то больше понравится.
Конечно, воплотить такой подход в жизнь будет психологически тяжело, учитывая сколько усилий было потрачено на войну с AI. А тут, получается, назад надо сдать. Но, на мой взгляд, умение переосмыслить ситуацию, умение адаптироваться - это как раз и есть свойства хорошего инженера.
EmoRagnareks
06.06.2025 13:20Грамотные мысли, если на все это есть время: пощупать, посмотреть, оценить итд. А не CEO пытается тушить АИ-штукой проекты, что фирма не вывозит текущим штатом.
EmoRagnareks
06.06.2025 13:20Сваливайте с этой работы, фирма обречена закончиться. Когда CEO начинает лезть в разработку - это показатель, что в фирме какие-то проблемы и CEO пытается найти "серебрянную пулю". Судя по вашим расказам, он стремится сделать разработку дешевле, видимо при текущей цене фирма её не вывозит.
__
Что касается отношения к этой всей ситуации, то тут ситуация выглядит так: ваша задача донести до CEO, что использование Lovable несет риски стабильности работы, сложности внедрения (вы не знаете её апи и так далее), сложности поддержки (надо разбираться в их апи и костылить, разработчики с рынка не знают эту штуку итд).
Если CEO после этого говорит, да ничего, мол разбересь итд - значит фирма находится в такой ситуации, что получить более быструю скорость внедрения костылей сейчас важнее, чем столкнуться с проблемами дальше. А звоночек, что фирма заканчивается.
__
Если у вас есть технический директор, то вместо хабра лучше пойти с этой статьей к нему. Если вы и есть технический директор, то уточните у бухгалтерии состояние фирмы, и если там все плохо - то сваливайте первым.
tkutru
06.06.2025 13:20Автор, я бы не стал спорить с CEO, а просто вспомнил бы лучшие традиции итальянской забастовки https://ru.m.wikipedia.org/wiki/Итальянская_забастовка
Заодно можно будет максимально формализовать действующую систему, uml диаграммы, автотесты, вот это всё. Ибо работа через no/low code инструменты требует максимально чёткого и прозрачного понимания всех процессов, бизнес логики, дата флоу и пр.
hardtop
06.06.2025 13:20Понимаю вашу боль. Но может настал момент научиться защищать свою позицию. Научиться более сильно доносить аргументы: например, сделать тест с фичей из no-code и классическим методом. Показать плюсы\минусы, свести ко времени, затратам, рискам и деньгам.
tsbt
Глубокие соболезнования вашей компании в том, что принимать технические решения и руководство разработкой доверили людям, которые не понимают элементарных принципов, на которых базируется управление качеством продукта и все смежные процессы.
Похоже, что у вас формальный руководитель, который занимает чужое место и уверен, что любая дичь ему будет прощена.
spirit1984
А может и не формальный, а засланный конкурентами. Мне кажется, что сейчас самый простой способ в IT-компаниях избавиться от конкурента - это через засланного казачка убедить руководство конкурента оседлать хайп AI и перейти на nocode/lowcode/vibe.
dyadyaSerezha
Это же классика - как MS заслал казачка а Нокию. И всё. Нокии не стало.
Maccimo
А Нокия-то и не в курсе. Продала отдел мобильных телефонов и дальше себе работает.
dyadyaSerezha
Если вы про тот микропрыщик, который остался от всемирного гиганта, то да, работает себе.
Maccimo
Вы правы, микропрыщик.
BugM
Падение с 70 в 2007 до 20 в 2025. При инфляции доллара 50 процентов.
Всего-то в 5 раз упали.
dyadyaSerezha
Хорошо, я имел ввиду их телефонный бизнес, который сошёл на нет и который, да, они продали. На телефонный бизнес и нацеливалась MS.
D_Dementy
утверждать, что Noikia == телефончики - это такое... как Smasung == телевизоры
Shaman_RSHU
Очень много компаний, где принимают решения в лучшем случае хорошие финансисты и менеджеры и не разбирающиеся в бизнес-процессах, которые приносят компании прибыль. Сейчас вайб-кодинг ещё не так распространен, чтобы о нем знали все. Но, как мне кажется, то ли ещё будет..
ED-209
Согласен. Вся фундаментальная проблема в том, что бизнес в использовании ИИ-помощников видит не увеличение доходов (вау, эта фича при текущих показателях даст нам буст 1000%), а видит как исключительно уменьшение, сокращение расходов. Концептуально. Базово. Это уже на костном уровне, в мозге. Не помощник, а дешевая замена. Основа всего получается в итоге: на этом можно сэкономить. Т.е. давайте сократим 10 программистов и заменим их на ИИ-подписку за 20$/мес. Как по мне, сколько ни встречал схожих подобных ситуаций, где начинали "резать, кроить и пороть", в большинстве случаев означался приход "эффективных менеджеров".
Shaman_RSHU
Чисто финансово-менеджерский подход руководителей: мы же покупаем услугу, которая дешевле, чем держать программиста. А то, что сами иногда продают "гнилую колбасу" забывают. Услуга тоже может быть не идеальна.
ED-209
Да, но в данном случае у автора мир кардинально перевернулся с вайб-кодингом и с требованиями руководства:
Как виделось future в голове у автора: программист пишет код, затем скидывает в ИИ "проверь на ошибки, плиз".
Как вышло на самом деле: ИИ пишет код, скидывают программисту "проверь на ошибки, плиз"
Shaman_RSHU
Но всё таки ИИ можно доверить писать не код "под ключ". Принимать архитектурные решения он не должен, иначе будет SkyNet :)
ED-209
Косяк в том, что то самое "решение" о запуске SkyNet будут принимать люди максимально диаметрально противоположные от ИТ.
RichardMerlock
Всегда так было. Инженеры в ящике пилят царь-бомбу. Кнопку жмет генерал.