Как визуальные платформы ломают культуру разработки и зачем нам нужен контроль над кодом
У меня 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 для ускорения работы - разумеется под моим строгим контролем.
Комментарии (242)
Rob1nZon
06.06.2025 13:20очередное нытье деда с завышенным ЧСВ с супепупер по его мнению важным продуктом.
Arioch
06.06.2025 13:20Вам же остаётся чуть-чуть допилить
А вы это раньше никогда не слышали, если про дедов рассуждаете?
Фразочка-то сама с длинной бородой.
Вариант её, который мне лично сильнее всего запомнился:
- а вот я хочу работать с RedMine, мы в банке с ним работали, я к нему привыкла. Уберите ваш сервер и поставьте RedMine
- это, наверное, хорошая программа, но она использует Linux, PostregSQL, Ruby и Ruby-on-Rails. Это, наверное, хорошие программы, но каждая из них очень сложная, а я на профессиональном уровне не знаю ни одной из них, и при возникновении любых проблем не только не смогу за конкретный срок их решить, но даже не смогу понять в какой их них четырёх эта проблема случилась.
- глупости вы говорите, у нас никогда в банке проблем с ним не было! Но если вы такой неуверенный, я приглашу мужа. Он хороший специалист, он вам на сервере всё поставит, а вы просто будете ни за что получать деньги
- у вас просто отличный муж. А ещё у вас замечательная семья. Давайте так и сделаем, но ещё мы устроим вашего мужа на четверть ставки - на обслуживание этого сервера, он будет ничего не делать и ваша семья будет ни за что получать деньги!
- вы совершенно испорченный человек, с вами невозможно работать!!!Дальнейшее было тоже забавно. Она всё же нашла, где поставить свой Redmine, и кто будет за него номинально отвечать (аутсорсник. То есть вопросы типа "не работает! все отделы стоят! Исправить за 5 минут!!!" будут равнодушно покрываться договором с "3 дня на реакцию". именно на реакцию, а не на исправление. Там тоже умеют писать договора).
Потом она запретила пользоваться старым сервером, потому что все по привычке писали туда. Потом она запретили на новом баг-трекере писать "техническую муру", потому что "директору это непонятно и не интересно. Пишите когда будет готово и кто за задачу отвечает, а мусор ваш сюда не тащите!". Но "тащить мусор" на старый сервер запретила ещё жестче.
randomsimplenumber
06.06.2025 13:20Плакали всей маршруткой ;)
Так в результате контора закрылась то? Если нет - начальница все правильно сделала. Как удобно ей.
Arioch
06.06.2025 13:20начальница все правильно сделала. Как удобно ей.
Это безусловно. Но зачем они она такие подлые интриги устраивала (в частности она заставила кадровичку нарушить ТК и влепить мне штраф по окладу за то, что я сорвал сроки по задаче, которая не входила в мои обязанности, и для которого другое юр-лицо мне должно было дать доступ, который - думаю вы уже угадали - дали после дедлайна).
А я все ждал, что она вспомнит, что такое быть честным человеком, подойдет и просто скажет: "увольняйся, у меня есть человек на твое место и я тебе все равно съем". Я бы уволился, не то место было, чтобы держаться вопреки замдиру. Мы оба бы съэкономили кучу времени и усилий!
Но видимо в банке людям действительно удаляют мозг и вместо него вставляют слизня...
При том, что лично она, в отличие от некоторых её фавориток, вовсе не халявщица и не дура была. В финансовой сфере она реально работала как лошадь и даже больше. Правда, нюанс, на отдельном договоре, а не на окладе.
И ещё момент забавный был. Обсуждали какие-то принципиальные, структурные недостатки проекта, и я сказал что-то вроде того, что у нас нет тех-лида для рискованных переработок проекта от самых его оснований (а там не то, что тех-лида не было... После недружественного поглощения соседним отделом нам цены в три раза уменьшили под обещание привести в 10 раз больше покупателей. На герметичном рынке, где один новый подписчик был событием... Про это даже программеры знали, а уж владельцы-финансисты обязаны были... Так что реально близко к грани работали по деньгам даже после жёстких сокращений). И прозвучало что-то такое ободряющее типа "О! Я совершенно в вас уверена. Ваш опыт однозначно позволяет вам взять на себя обязанности тех-лида!". Я в тот момент её любил, восхитительная точность формулировок!
Смешно, что пока я там был, мне со всех сторон говорили, что этот проект себя не окупает, что надо его закрывать... Меня почему-то считали каким-то секретным бойцом во внутренних интригах замдиректоров, и все пытались уничтожить, потому что "не на моей стороне? ну значит точно на чужой!"
контора закрылась то?
да нет, тилипается себе, рассказывает, как будто нейронки прикручивать к финансовым данным, и сделает самого экспертного эксперта.
там, как бы, соскакивать особо некуда. один конкурент умеет намного меньше, другой стоит намного дороже, и оно всё катится по накатанной, ну или так оно было во времена ковидные
в принципе, тот наш проект он и в лучшие дни не был основной cash cow конторы, а уж после того "обесценивания" и вовсе. Я совершенно серьёзно ожидал, что когда меня уйдут, проект и в самом деле закроют. Вот выпустят моё дембельское - и сразу рубильник дёрнут.
Что проект живым-то держали для того, чтобы я там оставался полу-программистом БД и десктопов, полу-админом, полу-веб-сайтером, полу-поддержкой. Когда вроде каждый отдельный пункт недостаточно большой, чтобы целого человека на него ставить. Закрыть этот ненавистный (якобы) проект, выгнав последнего человека из его команды, было бы самым логичным шагом, и я этого ждал. Его наработки, возможно, можно было бы раздербанить на несколько специализированных программ с одной простой функцией и системой монетизации "за каждый документ", а не "за месяц/год/бессрочно". Потому что такое уже начиналось, и вопреки моему скепсису показало себя неплохо. Логично бы было пройти эту дорогу до конца.
через полгода после моего увольнения выпустили обновление, из двух пунктов, одним из которых была половина моего дембельского аккорда. Вторую половину так и не выпустили, хотя я уходя минимум трем начальникам передал черновик договора на бесплатное, хотя и с условиями, использование чужого API. Видимо, этот черновик очень мешал продолжать просвещать директоров про "самого бесполезного человека в компании". А может быть я слишком хвастаюсь, но когда тот самый директор перед моим увольнением проходя мимо спрашивал, чем я занимаюсь, и я сказал что вот почти готовы две новые фичи, у неё лецо знатно перекосилось, и она тогда быстро перевела разговор на важные и неотложные срочные проблемы :-) Подозреваю, что они так и осталась в исходниках и в бинарниках, но в скрытом состоянии.
Ещё через год был релиз, в котором, я подозреваю, была наконец сделана видимой функция, которая там была уже лет 5 (поддержка Libre/Open Office), но которую запрещали делать видимой, чтоб не пугать и не путать пользователей. Хотел скачать и посмотреть по обоим пунктам, но обнаружил, что начисто забыл внутренние пути WWW-сервера, по которым всегда можно было скачать релиз "без СМС и регистрации", а имевшиеся у меня материалы компании я на самом деле стёр в день увольнения. Так и осталась эта небольшая загадка навечно неразгаданной.
Последнее, что я слышал - ещё раз, это всё про проект, который "даже тебя одного не окупает, в убыток работаем"! - звонок с просьбой подсказать, как его собрать без HASP-защиты, чтобы продавать для Линукса. Не думаю, что у них это получится, но если им не жаль пытаться - мне тоже не жаль.
randomsimplenumber
06.06.2025 13:20Специфика жанра .. Всё огорожено, никаких новых конкурентов. Ваши фичи начальству не нужны, им и так есть что на крутон намазать.
Arioch
06.06.2025 13:20вою, рыдаю, огорчаюсь, смиряюсь... И все равно не понимаю.
подлости-то зачем делать и людей подставлять?
я ведь на тот момент уже задокументировал несколько нарушений ТК, оставалось только заказное на почте оправить. Если бы не выдали налом украденное на окладе - отправил бы. А отвечала бы в первую очередь трудовичка, которая эти нарушения исполняла. Неплохой, в принципе человек, хотя "мне приказали" не оправдание. А потом, возможно, пришлось бы отмазывать бузгалтершу и на взятках отдать больше, чем украли у меня.И вся эта дрянь вместо того, чтобы после корпоратива новогоднего сказать мне "уходи, у генералов есть свои дети" и я бы гораздо проще и даже быстрее ушёл.
Нет, опыт по своему интересный был, и пару анекдотов утащил для маршрутки. Но - не понимаю :-) "Зачем делать сложно то, что проще простого?" :-)
kalitkinvlad
06.06.2025 13:20подлости-то зачем делать и людей подставлять?
Потому что удовольствие от таких действий ни за какие деньги не купишь.
Rive
06.06.2025 13:20Не стоит пытаться найти сложный план в рефлексах балансирования на клоунском колесе в The Clown World.
Делают, потому что могут.
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Вы работали с АСУ ТП системами? После них дизайн любой дичи вам покажется милым зоопарком.)
...про хайп, что бы довести до абсурда нужно вайбкодинг внедрить на каких-нибудь чувствительных АСУ ТП, АЭС например - мигом поубавится рвения для внедрения "новых фич" с конкретной фамилий автора-руководителя)
Wesha
06.06.2025 13:20Вот вам карта, Билли!
FluffyFeline
06.06.2025 13:20Если это про нейронки, то скорее в конце 3-го этапа или выше. Всё остальное уже было
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Да, но я бы использовал нейронку для локальных кусков кода. Имхо с позиции моего опыта - архитектуру сложного приложения ей давать нельзя.
Artyomcool
06.06.2025 13:20А по моему опыту и с локальными кусками так себе выходит. Но мне помогает гуглить "то не знаю что", в т.ч. образцами кода, которые я в 95% случаев полностью переписываю в итоге (хотя иногда у меня таки поднимается бровь, когда оно что-то вменяемое действительно генерит).
Ещё у меня коллега мой код ревьюит в т.ч. с помощью chat gpt. И я вам скажу, выходит неожиданно круто.
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 животных.
Мы бы больше сочувствовали бы автору статьи, если бы у него уже не было зоопарка. Но в данном случае у него уже есть зоопарк, он научился за ним ухаживать, но категорически против нового животного, т.к. "у нас и так все хорошо", а это новое "ходит не так, кушает не то, рычит по другому".
И еще вопрос - а почему раньше автор не был против зоопарка? Почему это случилось именно сейчас?samako Автор
06.06.2025 13:20У Вас серьёзный аргумент. Конечно, частично это так, я привык к своему зоопарку и пытаюсь отбрыкаться от новых экзотических животных. Но в оправдание скажу, что этот зоопарк достался нам в наследство и его архитектуру разрабатывали не мы. Я лишь потратил более 3-х лет, чтобы привести его в нормальное рабочее состояние и выстроить все процессы фактически с нуля. Не только в команде, но и между различными отделами.
Раньше он был гораздо более "зоопаркистей" - это легаси... и легаси очень древнее. С другой стороны - с легаси можно жить, а вот с тех.долгом - весьма сложно. Поэтому пару последних лет у нас ушло на уничтожение сорняков - годами копившийся тех.долг, огромный бэклог багов, очистку авгиевых конюшен в виде огромных пластов "мёртвого кода" и написание сотен страниц технической документации. И это совершенно потрясающий опыт, имеется ввиду - приведение легаси в рабочее состояние. По факту - это наш "бэби" (мой и моей команды), поэтому я и принимаю в штыки любую попытку опять всё вернуть в состояние хаоса.Arioch
06.06.2025 13:20"бэби" это хорошо, тут почему-то ютюб про "самого говорливого кота" вспомнился. Но это еще и ловушка, после такого ОЧЕНЬ трудно отрываться от самого проектf и от людей, от команды, даже если верхушка конторы начинает делать дикие глупости и/или подлости. Боль почти физическая.
Rive
06.06.2025 13:20Поэтому в пет-проектах есть определённый смысл.
Отобрать их значительно сложнее, и даже если они не приносят прибыли, владеть ими гораздо приятнее.
playnet
06.06.2025 13:20Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
Вот и ответ, "почему монолит". Тем более, "созревший". И тут надо смотреть на стоимость переделки (новые хотелки, новые законы итд) и стоимость просто поддержания работы при росте нагрузки. Представь, что каждый месяц клиентов х2 (для понимания, это прогрессивная шкала). Через сколько кончится ваш сервер с монолитом? Через сколько кончится "топовая" железка? И что дальше? У меня такой опыт есть. (веб, фронт+бэк в одном). Где был 1 сервер с монолитом, их уже 20, раскидывание по ендпоинтам "этот набор запросов сюда, этот туда", через nginx, апстримы - минимум по 2 сервера, за счёт одного кода можно балансировать (что-то у нас этот блок перегружен, докинь сюда пару серверов незагруженного блока)
Живём? Нет, самое слабое место уже давно стала БД. Добавляем proxysql, все запросы на чтение без предварительной записи кидаются на слейвы, их можно поднять хоть 100, но мастер тоже не бесконечен. Плюс нужен dba, контролирующий запросы, индексы итд.
Но проблема понятна была уже 2 года назад, и идёт постепенный распил на микросервисы, часть уже вынесена, что позволило чуть меньше беспокоиться. Правда, база по прежнему одна, но и в этом направлении продавливаю изменения.
samako Автор
06.06.2025 13:20Согласен, это если каждый месяц клиентов х2, но у нас пока х+2. Когда проблема появится на горизонте, начнём ещё решать, пока ещё этой проблемы у нас нет.
izibrizi2
06.06.2025 13:20Чел, ты немного устарел. Монолиты снова в моде, так как с микросервисами наигрались ;)
Drucocu
06.06.2025 13:20Перевожу: "вы все дураки и не лечитесь, а я одна умная, в белом пальто стою красивая".
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 не хранить историю запросов и сидов, в место кода.
Потому что промпты сами по себе не описывают состояние, а описывают запросы на изменение.
Возможно скоро появятся какие-то промпто-подобные способы описания текущего состояния приложения. Чтобы из набора фраз "А теперь добавь кнопку!" "А теперь перекрась её в зеленый" генерировалось состояние "Зеленая кнопка слева по центру", из которого уже потом будет генерироваться полное приложение.TemaAE
06.06.2025 13:20Ну так конечное "скопмилированное" состояние всех запросов - это текущее состояние кода.
Только нужно грамотно его интерпретировать назад в прикладные смыслы и формулировки.
edogs
06.06.2025 13:20По приданию, во времена золотой лихорадке больше все обогатились производители лопат.
По "преданию".
На всех хайпах в айти, больше всего вижу появление всяких фирм, которые предлагают какие то чудо утилиты, которые обязательно перевернут процесс программирования.
Имхо, это все же не лопаты. Лопатами можно было копать и добывать золото. Это были работающие рабочие инструменты.
Современный хайп ИИ у нас вызывает больше ощущения "посоленого рудника", застолбили рудник, насобирали там немного золота (или добавили) и продают как будто там исследованная золотая жила без каких-либо проблем.
В некоторых случаях покупка такого рудника реально оправдана (и тогда можно сбабахать сайт за пару недель с затратами в 10 раз меньше и рубить бабло, пока конкуренты год пилят сурьезный проект), но во многих выливается в эпик фэил (и что самое обидное - выясняется это уже в конце пути, когда время и деньги уже потрачены).
Rive
06.06.2025 13:20. На рубеже веков это были визуальные редакторы кода. Это типа когда не надо писать код, а только мышкой диалоги собираешь, ну и код можно писать, если хочешь.
В итоге блюпринты стали вполне нишевой штукой в дизайне и геймдеве, почему бы и нет? Мне (и многим другим) удобнее собрать воркфлоу из нод в ComfyUI, чем писать такой же код на питоне и потом постоянно рыться в папках, пытаясь найти что в итоге сгенерилось.
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-диаграма тоже может в текстовый файл сохраняться, наработки есть же. Правда, разницу глазами в таком формате может быть неудобно смотреть.
TemaAE
06.06.2025 13:20Все эти визуальные игры заканчиваются тем, что визуал - обычно плоские схемы, а структура ПО минимум трехмерная по ощущениями, а то и 10^n-мерная по своим вложенностям.
playnet
06.06.2025 13:20а вот сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема.
Идея для стартапа! )
А что за "нажал и оно развернулось"? Мне такое очень нужно
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.
Чтобы не превратиться из человека в безмозглый придаток БЯМ, например. Кончится инторнет и всё, вайб-кодер превратился в тыкву.
И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Действительно, зачем думать?
Rive
06.06.2025 13:20Чтобы не превратиться из человека в безмозглый придаток БЯМ, например. Кончится инторнет и всё, вайб-кодер превратился в тыкву.
А против этого сценария надо присматривать локально развёрнутые LLM и видеокарту помощнее.
BorisTheAnimal
06.06.2025 13:20А я вот прямо сейчас наблюдаю, как хорошие в прошлом разработчики, подсев на LLM (в частности из-за того, что менеджмент форсирует скорость разработки), начинают терять навык критического мышления и не могут решить элементарную проблему самостоятельно (когда LLM тоже не помогает). И это очень пугает, так как я ожидал, что подобное может произойти где-то в будущем, но не думал, что даже текущие синьоры начнут так активно деградировать. Наблюдаю это в организации с более чем 2000 разработчиками, так что выборка неплохая такая.
bak
06.06.2025 13:20Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
BorisTheAnimal
06.06.2025 13:20как не пишите код на ассемблере, а пользуетесь одними компиляторами?
переход на компиляторы не забрал алгоритмические задачи с разработчика. Да и и с переходом на компиляторы и сам вектор того же дебага поменялся. Редко когда вы одновременно использовали компилятор, но возвращались в ассемблер для дебага и т.п.. То есть, ваш пример будет работать, когда разработчики смогут 100% переключится в AI как среду для разработки / отладки. Тогда сменится и парадигма самой работы и мышления под эту работу.
Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
Никогда не работали в энтерпрайзе? Ну и как, держат десятки тысяч индусов, которые пишут спагетти-код, работающий буквально на честном слове и на пределе серверных мощностей? Кодовая база через пару лет становится настолько нечитаемой, что проще всё переписать с нуля, чем пытаться что-то исправить.
В результате код, который при хорошем подходе мог бы служить основой 10–15 лет, устаревает уже через 3–4 года. Просто из-за решения менеджмента сэкономить и использовать дешёвые ресурсы — будь то недорогие индусы или, как сейчас, AI. Потому что большинство менеджеров в современном мире ориентируются на годовые результаты: сэкономили в этом году миллион — отлично.
Они не думают(ну или все же думают - но такие уж правила игры) о том, что через два года из-за этого решения операционные издержки вырастут на тот же миллион в год, а через пять лет придётся вложить 2–3 миллиона в полное обновление. Это уже будет “проект”, на который выделят деньги, и никто даже не задумается, что никакого проекта не потребовалось бы, если бы изначально не пытались сэкономить.
Это комплексная проблема. Я сейчас смотрю на AI как на замену индусам для MVP. Видел это ещё в конце нулевых и в десятых: клиенты нанимали индусов, те быстро набрасывали хоть как-то работающий продукт, а потом, если бизнес выстреливал и требовал масштабирования, наступал затык. Индусы исчезали, а разработка отдавалась западным разработчикам, которые всё переписывали с нуля.
Есть у меня и примеры, когда код изначально писался по всем правильным принципам, но потом передавался в поддержку дешёвым командам — и за 1–2 года код просто убивался в ноль.
Поэтому все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки. И не стоит потом удивляться, что на собеседованиях всё равно будут проверять реальные навыки программирования, а не «вайб-кодинг» — и вы просто не сможете пройти такое собеседование.
bak
06.06.2025 13:20переход на компиляторы не забрал алгоритмические задачи с разработчика. Да и и с переходом на компиляторы и сам вектор того же дебага поменялся.
Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов, целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Переход на вайб кодинг так же не забирает алгоритмические задачи с разработчика, вам по прежнему нужно понимать какой алгоритм вы хотите, нужно мочь объяснить это LLM, нужно понимать что вам нагенерировали, как оно работает какая тут сложность и т. д.
Просто из-за решения менеджмента сэкономить и использовать дешёвые ресурсы — будь то недорогие индусы или, как сейчас, AI.
Не надо смешивать мухи с котлетами. Желать менеджеры могут что угодно, мы сейчас не на стадии когда LLM заменят разработчиков. Мы сейчас на стадии что LLM это инструмент для разработчиков.
Я сейчас смотрю на AI как на замену индусам для MVP.
Не правильно смотрите. Генератор MVP это лишь одно из применений. Другое применение - это инструмент для разработчиков ускоряющий написание кода.
все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки
У вас очень странное представление об LLM. В вашем мире есть две крайности. Крайность 1 - я луддит разраб и всё пишу руками. Крайность 2 - я тупой менеджер и отдал разработку некоему "AI".
По 1-му пункту - ну ок каждый пишет как он хочет но зачем? LLM тупо экономят время, писать те-же тесты руками - зачем, карл, зачем???
По 2-му, сейчас нету полноценных "AI" которым можно "отдать разработку". Ну ок тебе пообещали что некий "AI" заменит всю команду - ну уволь свою команду и купи мега-про-подписку, но нет, начинается какая-то х*ня описанная в статье когда "AI всё сделал надо только пофиксить мелкую багу"
Arioch
06.06.2025 13:20конвенции вызовов,
Смеюсь. Как раз потребовал знать.
Вот в ассемблере их знать не надо. Как хочешь - так и делаешь. А в компиляторах ты должен уметь прочитать объявление функции и несколько флагов компиляторов и по ним распознать что и куда будет помещено при вызове функции. Иначе на первом же вызове DLL можно словить очень интересные эффекты. Особенно, если она написана на другом языке.
Тот же COM/Automation, ошибки в вызове какой-нибудь функции Excel можно искать весьма долго, если не знать, как оно должно работать "внизу".
Нет, конечно в Hello World всего этого не нужно. Но для того оно и в ассемблере не нужно. Один макро-вызов и всё.
...и это я еще не сказал про ошибки в библиотеках и самих компиляторах. Вот их без "CPU panel" отловить иногда на порядки сложнее, чем сверить команды процессора с тем, какие должны были быть.
архитектуру процессора
Из недавнего. Комитет C++ исключил из стандарта слово volatile и потребовал от комитета C сделать то же самое (иначе обратная совместимость нарушится). Программисты всяких embedded-железяк на Cи взвыли - у них там половины программа на этом слове держатся. В ответ на что им сказали, что слово это было временной заплаткой и кое-как работало на тупых компиляторах и тупом железе 1980-х, а сейчас и то и другое стало умным, и это слово перестало по факту работать. На что эмбедщики сказали, что с железяками работают они, и если бы прямо вообще все сломано, то они первые бы заметили.
На самом деле весьма интересная дискуссия, стоит чтения просто из общего интереса. Как раз и про компиляторы и про архитектуры.
А ещё есть всякий там gamedev с его упарыванием по cache locality...
Ну и еще можно вспомнить про возврат значения из функции, через return (в C и более поздних) или привоения функции (Фортран, а из него Бейсик и Алгол-Паскаль). Казалось бы, чистой воды абстракция и вкусовщина, а на само деле прямое отражение архитектур тогдашних компьютеров. Впрочем, практической пользы такая археология, в самом деле, наверное не несёт.
целую кучу разных оптимизацией
...убило развитие процессоров: теневые регистры, суперскалярность и внеочередность и прочее обумнение когда-то простых железок. Так что старые оптимизации внезапно стали затормаживать программы, хотя лет 30 назад ускоряли.
и целую кучу специализированных алгоритмов.
...убило появление стандартных документированных библиотек. Не было бы библиотек - писали бы вы те же алгоритмы на модных новых языках. Есть библиотека - не надо знать про алгоритм, вызывай готовую функцию. И опять же, без разницы откуда вызывать, из ассемблера, плюс-плюса или шарпа.
bak
06.06.2025 13:20Вот в ассемблере их знать не надо. Как хочешь - так и делаешь.
Ага, а расскажите пожалуйста как это самое "как хочешь" будет потом работать при линковке с другим бинарем написанным другим разрабом который тоже делал "как хочешь". Сейчас вы можете extern C написать и ни о чем не думать. И это еще без учета разных архитектур где вообще всё по разному, сейчас вам ваш тулчен соберет что под x86 что под arm, а раньше это всё руками приходилось переписывать.
...убило развитие процессоров: теневые регистры, суперскалярность и внеочередность и прочее обумнение когда-то простых железок.
Зачем ходить глубоко? Возьмите те-же inline, rvo (nvro), оптимизация хвостовой рекурсии, сейчас это всё компилятор делает. Раньше вы сами это были вынуждены делать руками. Если вы написали функцию в которую вы идете через call никакой ассемблер вам её автоматом на инлайн не подменял.
Arioch
06.06.2025 13:20Сейчас вы можете extern C написать и ни о чем не думать
какая милая добрая уверенность...
если не ошибаюсь, zlib под win32 (или ssleay, или еще кто, не помню) собирается в трёх не совместимых по ABI вариантах, и все они типа extern "C"
Как раз extern "C" вот вообще ничего про конвенции не говорит, а только отсутствие name mangling
Так-то во всех стоящиx рассмотрения макроассемблерах есть аналоги extern "C". Более того, есть даже макросы для ООП-вызовов. Любители под win32 графические программы на таких пишут, по сути такая ассемблерная программа почти не отличается от старого способа написания Win32/C++, где разбор сообщений делался мега-switch'ем на препроцессорных макросах.
при линковке с другим бинарем написанным другим разрабом
да как и со своими функциями - берем ассемблерный исходник этого другого бинаря, смотрим по каким регистрам и адресам памяти он распихал параметры, и повторяем в точке вызова
или вы хотите сказать, что тот другой бинарь писался не на ассемблере? но тогда это как раз мой пойнт! именно появление компиляторов (в той другой либе) вместо асма заставило вас учить конвенции выхзова
Раньше вы сами это были вынуждены делать руками.
Да, но я не считаю, что это "убило оптимизацию", я считаю ровно наоборот.
На асме я её или пишу или нет. Нет даже самого понятия хвостовой оптимизации! либо я запилил цикл (которым хвостовая рекурсия является) - либо не запилил. Мне просто нафиг не надо знать, что такая теоретическая концепция бывает. Я циклы пишу. Или не пишу.
Максимум мне нужно освежить школьный урок про переписывание рекурсивный функции в цикл, но я в свое время и сам догадался, тут ничего сверхсложного.
Все просто и определённо, или я написал цикл, или нет.
А вот именно в случае с компилятором мы начинаем играть в лотерею. То ли захочется компилятору оптимизнуть, то ли не захочется. И так в сотне мест программы.
В зависимости от левой пятки компилятора у меня теперь - именно теперь, а не на асме - может получиться 2^N разных программ из одних и тех же исходников.
И вот именно теперь - именно из-за появления компиляторов и привносимой ими случайности! - мне надо знать про существование таких оптимизаций, потому что неопределенность повысилась в разы, и чтобы бороться с неопределённостью (или не бороться, там где не мешает) мне нужно знать, откуда может прилететь неожиданная чужая модификация программы. И какие у неё могут быть последствия. И стоит ли про это думать, или последствия неожиданных изменений моей программы в данном конкретном месте меня не огорчат. И вот чтобы все это понимать теперь мне надо учить возможные типы оптимизаций, чтобы оценивать в какое месте программы какая бомба может прилететь, и где нужно заранее строить защитный бункер, а где пусть прилетает не жалко.
Как раз на асме всего этого нет. Там правда и много чего другого нет. Поэтому в целом компиляторы выгоднее, само собой. Но эта выгодность имеет цену. И одна из частей этой цены, что теперь сборка программы стала случайным процессом, и чтобы контролировать эту случайность надо учить типы оптимизаций вообще и конкретно под использованный компилятор.
bak
06.06.2025 13:20если не ошибаюсь, zlib под win32 (или ssleay, или еще кто, не помню) собирается в трёх не совместимых по ABI вариантах, и все они типа extern "C"
Вот чтобы не иметь себе мозги и делают более высокоуровневые языки. Но конечно есть люди которым нравится мозго*ство, у них еще и утиный синдром обычно они предпочитают заниматься им на том уровне который был когда они входили в профессию, а каждый новый уровень считается "для лохов" и "деградацией".
Maccimo
06.06.2025 13:20Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов
Вы, очевидно, не понимаете что пишете. Ассемблер если и видели, то на картинках. Возможно даже, что и на компилируемых языках никогда не разрабатывали.
целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Перечислить эту кучу вы, естественно, не сможете.
bak
06.06.2025 13:20Вы, очевидно, не понимаете что пишете.
Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора. На лицо абсолютная деградация. x86 и ARM совершенно разные! Чтобы printf позвать надо сискол сделать на x86 это int 80 или syscall на арм это svc.
Перечислить эту кучу вы, естественно, не сможете.
Вот вам несколько примеров:
Ручное управление регистрами
Ручно разворачивание циклов (чтобы избежать лишних cmp jmp на коротких циклах)
Замена медленного деления на эквивалент
Ветвление без условий через setcc, cmov, and, xor
Ручной prefetch данных
Ручное выравнивание кода и данных
Оптимизация под конкретные CPU
Очевидно вы ничего из этого не знаете и даже не подозреваете о существовании. Теперь расскажите, мешает ли вам ваша деградация работать разработчиком или нет.
Maccimo
06.06.2025 13:20Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора.
Вы абсолютно правы.
Для того, чтобы убедиться в полной моей некомпетентности достаточно прочитать мою последнюю статью :)Вот вам несколько примеров:
Хоть бы автовекторизацию вспомнили для приличия, а то «замена медленного деления на эквивалент» в 2025 году. Словно у LLM спрашивали.
Что из перечисленного «специализированные алгоритмы»?
То, что оптимизирующий компилятор пытается оптимизировать это секрет Полишинеля. Когда производительность действительно важна, приходится по-старинке делать всё самому. Так же, как и 30 лет назад.
bak
06.06.2025 13:20Когда производительность действительно важна, приходится по-старинке делать всё самому.
Это 0.01% случаев. Большинство разработчиков в ассемблер залазит примерно 0 раз за всю карьеру. Это не означает что они деградировавшие идиоты. Это означает что для большинства задач это не нужно.
Wesha
06.06.2025 13:20> Когда производительность действительно важна, приходится по-старинке делать всё самому.
Это 0.01% случаев.
Ну то есть Кармак прав.
vkni
06.06.2025 13:20Ну конечно прав. Об этом говорит распространённость Питона (это сразу минус десятичный порядок от производительности), например. И многое другое.
То есть, пресловутый военный Эльбрус 300МГц вполне себе должен пойти в качестве офисной машинки/домашнего кинотеатра.
bak
06.06.2025 13:20Что из перечисленного «специализированные алгоритмы»?
Прочитайте определние порятия "алгоритм". Что из вышеперечисленного не подходит под "алгоритм"? Или по вашему алгоритм это только quicksort или A* а остальное это не алгоритм?
Те же вопросы на манипуляции битами вообще раньше на собесах спрашивали, сейчас это уже почти нигде не надо.
Maccimo
06.06.2025 13:20Что из вышеперечисленного не подходит под "алгоритм"?
С точки зрения программы на ассемблере не подходит абсолютно всё.
Пункты 2 - 7 это рефакторинг и/или оптимизации, которые погромисты делают ручками во время разработки. Довольно базовые, к слову. 1 — декларации переменных в ЯВУ никуда не делись.сейчас это уже почти нигде не надо.
Вы не видели, значит не нужно, понял. Потом будете сидеть удивляться что это вам чатгопота какой-то
x & -xнагенрировала.
playnet
06.06.2025 13:20MVP
Индусы исчезали, а разработка отдавалась западным разработчикам, которые всё переписывали с нуля.
Если так, то всё хорошо. "сделать прототип и с нуля написать нормально" это суть мвп. Чаще же "ну мы вот уже сделали что-то максимально быстрое, а теперь это нужно отрефакторить до нормального кода". Не учитывая, что начинать там нужно вообще с архитектуры, по итогу того как выстрелил мвп. И выбора подходящего языка. И вот тут "тянуть код" - в корне неверно, если не сделан полный анализ и "язык сохраняем, архитектуру меняем тут и тут, эту половину кода переписать с нуля, тут мертвые фичи выкидываем", и всё это планом работ.
Rive
06.06.2025 13:20Поэтому все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки. И не стоит потом удивляться, что на собеседованиях всё равно будут проверять реальные навыки программирования, а не «вайб-кодинг» — и вы просто не сможете пройти такое собеседование.
Вполне резонное опасение, но в LLM уже содержатся рекомендации по архитектуре тоже, люди очень много об этом писали и в итоге датасеты сформированы на эту тему вполне удовлетворительные.
Достаточно время от времени спрашивать ИИ-ассистента, хорошая ли в проекте архитектура - и можно получить в ответ рекомендацию использовать определённый паттерн проектирования, совет разрезать большой класс на части, порядок в документации или расстановку приоритетов в большом количестве запланированных фич.
Т.е. подход дробления проекта на фичи и очень раннее планирование с помощью ИИ себя вполне может окупать, если это не какие-то слабоизученные экспериментальные области или что-то, защищённое патентами и НДА с минимумом доступного кода в открытом доступа.
Ну а те кто не задают таких вопросов, с большой вероятностью не интересовались ими и без LLM, так что он их не испортит, а просто раскроет слабые стороны и даст им набросать лапши побыстрее.
Wesha
06.06.2025 13:20И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
А я теперь пишу дизассемблеры!
sanyvaa
06.06.2025 13:20Это рутина, зачем набирать код самому если это может делать LLM.
а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.
основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.
bak
06.06.2025 13:201 процент времени - это значит вы за 8-ми часовй день набираете код меньше 5 минут. Верю, я поверил.
tsbt
Глубокие соболезнования вашей компании в том, что принимать технические решения и руководство разработкой доверили людям, которые не понимают элементарных принципов, на которых базируется управление качеством продукта и все смежные процессы.
Похоже, что у вас формальный руководитель, который занимает чужое место и уверен, что любая дичь ему будет прощена.
spirit1984
А может и не формальный, а засланный конкурентами. Мне кажется, что сейчас самый простой способ в IT-компаниях избавиться от конкурента - это через засланного казачка убедить руководство конкурента оседлать хайп AI и перейти на nocode/lowcode/vibe.
dyadyaSerezha
Это же классика - как MS заслал казачка а Нокию. И всё. Нокии не стало.
Maccimo
А Нокия-то и не в курсе. Продала отдел мобильных телефонов и дальше себе работает.
dyadyaSerezha
Если вы про тот микропрыщик, который остался от всемирного гиганта, то да, работает себе.
Maccimo
Вы правы, микропрыщик.
BugM
Падение с 70 в 2007 до 20 в 2025. При инфляции доллара 50 процентов.
Всего-то в 5 раз упали.
Astroscope
Альтернативная история: выкачиваем все деньги из прибыльного инфраструктурного подразделения на бессмысленное поддержание на плаву тонущего потребительского подразделения и в результате теряем все. Не знаю, как по мне - так они блестяще вышли из ситуации, сбросив проблемные активы и выйдя в стабильный плюс. Мне хочется порассуждать о том, как можно было не допустить эпических масштабов катастрофы когда-то важнейшего потребительского подразделения, но это к успешному спасению здорового инфраструктурного подразделения на самом деле не относится.
BugM
Точно бессмысленного? Нокия была царем и богом на рынке телефонов. Рынок телефонов в тех пор вырос на порядки. И этот рост уже тогда ожидался.
Я бы тоже отдавал все чтобы остаться царем и богом на рынке телефонов. Это же буквально половина всех денег мира.
А то что спасли какую-то мелочь не стоящую внимания. Почему это кому-то может быть интересно? Это небольшой ни на что не влияющий в мире бизнес. Пусть живет. Или пусть умрет. Кому какое дело?
vanxant
"Нокия была царем и богом на рынке телефонов"
Только практически никто из тогдашних царей не выжил. Моторола, Сименс, Сони, Эриксон - все облажались. Выжили корейцы (лыжа и сумсанг), которые в начале нулевых были во второй-третьей линии.
BugM
Это говорит о том что те кто не выжил плохо работали. Или не туда работали. И еще всяких ошибок понаделали. Но не о том что правильно было еще тогда складывать лапки и отдавать гигантский растущий рынок.
R0bur
Недавно прочитал версию о том, что Nokia уступила в конкурентной борьбе с Apple, потому что её руководство верило в традиционные кнопочные телефоны и не верило в сенсорные экраны. Выходит, что они работали «не туда».
hochbar
А 2к лет назад Римская империя не знала себе равных.
Просто пришли два короля- Apple и Google и порвали всех в клочья, в том числе Блэкбери. У Нокии был единственный вариант если клепать андроид смартфоны. Но тогда он был бы один из многих. Будь там Элоп, не будь там Элопа- все одно, поезд уехал.
BugM
Вы же слышали про Самсунг? Они совсем не "одни из". Они держат огромный сегмент телефонов. И хорошо на этом зарабатывают.
Оправдания вида "да все равно ничего нельзя было сделать, рынок так изменился" для слабых. Проиграли рынок значит проиграли. Другим стоит учиться на их ошибках.
Wesha
Хорошая книжка в тему
hochbar
Элоп пришел в 2010, Нокиа тогда уже упала до 56, если посмотреть график видно, что падение началось до Элопа.
А теперь погуглите в каком году айфон появился.
BugM
А теперь напишите к чему вы это? И как это связано с сообщением на которое вы отвечаете?
dyadyaSerezha
Хорошо, я имел ввиду их телефонный бизнес, который сошёл на нет и который, да, они продали. На телефонный бизнес и нацеливалась MS.
D_Dementy
утверждать, что Noikia == телефончики - это такое... как Smasung == телевизоры
dyadyaSerezha
Второй раз, имелся ввиду именно телефонный бизнес Нокии.
Если бы кто-то развалил телефонный бизнес Самсунга, можно было бы написать "всё, и нет Самсунга", подразумевая телефонный бизнес.
kalitkinvlad
В нулевых Нокиа только на телефонах и поднялись.
BorisTheAnimal
Это было бы не точное определение. Нокиа это компания со более чем 100 летней историей. В нулевых она просто приобрела большую известность среди обычных потребителей, за счет производства мобильных. Что в свою очередь стало возможным за счет того, что они сосредоточились на радиосвязи, начиная с 60х годов. И до бума потребительской мобильной связи они активно поставляли решения как для военных, так и для бизнес потребителей. Включая первый базовые станции для мобильной связи. Да и сами мобильные они с 80х производят.
kalitkinvlad
Легко не ищется, но бОльшая часть дохода у них была от продаж мобильных телефонов.
past
Казачок из MS пришел в Нокию уже на пожар. На тот момент, она со своим maemo уже проиграла Apple с Айфоном и Google с андроидом
Astroscope
В тред вызывается Ведущий Мобильный Аналитик. А пока, давайте, попробуем вспомнить, в каком состоянии были Nokia на тот момент, когда начали искать спасение в сотрудничестве с Microsoft. Состояние было, иносказательно, таким: неуправляемое пике из экзосферы - поначалу запас высоты был настолько огромен, что курс на практически неизбежную коллизию почти никто не мог и точно никто не хотел видеть, а значит продолжали радостно держать штурвал от себя, по некоторым вполне объективным метрикам видя, что высота все еще огромна, и беспокоиться на перспективу ближайшего десятилетия вроде как не о чем. Второй момент заключается в том, что Microsoft искали аппаратного производителя носителей собственной (уже тогда очевидно провальной) операционной системы, к которой никто из крупных вендоров, включая значимых и успешных в свое время производителей устройств под WinMobile, интереса не проявил, а значит Microsoft точно не были заинтересованы в утоплении Nokia. Тем не менее, на тот момент Nokia уже были в тупике, глупо пропустив очевидную тогда тенденцию перехода на смартфоны - они не смогли своевременно предложить вменяемые аппараты с сенсорным экраном, а историческая завязка на Symbian, который совершенно уже не соответствовал изменившимся обстоятельствам, так и не дала возможности включиться в смартфонную гонку на равных с аппаратами на Android, который тогда тоже не сказать, что был отполирован до идеального блеска, а значит не оставлял шансов другим игрокам не просто вклиниться, а серьезно откусить долю рынка. Но этот тупик еще не был так явно заметен со стороны, да и выйти из него гигантской Nokia ресурсов хватило бы не на одну попытку. Занимательное в этой истории не то, как она закончилась, а то, как невероятно быстро она закончилась. Too big to fail Nokia по самым пессимистичным сценариям должны были упасть на дно, но оставаться в категории "другие" еще многие годы, как это было с куда как менее значимыми для рынка телефонов Sony, например.
dyadyaSerezha
Интересно, этот текст написан на телефоне или компе? Думаю, что на компе)
По сути же, вроде всё верно, но. Если держать всё время руль от себя, то теоретически сделаешь мертвую петлю, только головой вовне. Но казачок, навязав свою мертворожденную ОС и упорно не меняя её, поставил руль прямо точно в момент полностью вертикального падения и так его и держал всю дорогу до матушки, понимаешь, земли.
Shaman_RSHU
Очень много компаний, где принимают решения в лучшем случае хорошие финансисты и менеджеры и не разбирающиеся в бизнес-процессах, которые приносят компании прибыль. Сейчас вайб-кодинг ещё не так распространен, чтобы о нем знали все. Но, как мне кажется, то ли ещё будет..
ED-209
Согласен. Вся фундаментальная проблема в том, что бизнес в использовании ИИ-помощников видит не увеличение доходов (вау, эта фича при текущих показателях даст нам буст 1000%), а видит как исключительно уменьшение, сокращение расходов. Концептуально. Базово. Это уже на костном уровне, в мозге. Не помощник, а дешевая замена. Основа всего получается в итоге: на этом можно сэкономить. Т.е. давайте сократим 10 программистов и заменим их на ИИ-подписку за 20$/мес. Как по мне, сколько ни встречал схожих подобных ситуаций, где начинали "резать, кроить и пороть", в большинстве случаев означался приход "эффективных менеджеров".
Shaman_RSHU
Чисто финансово-менеджерский подход руководителей: мы же покупаем услугу, которая дешевле, чем держать программиста. А то, что сами иногда продают "гнилую колбасу" забывают. Услуга тоже может быть не идеальна.
ED-209
Да, но в данном случае у автора мир кардинально перевернулся с вайб-кодингом и с требованиями руководства:
Как виделось future в голове у автора: программист пишет код, затем скидывает в ИИ "проверь на ошибки, плиз".
Как вышло на самом деле: ИИ пишет код, скидывают программисту "проверь на ошибки, плиз"
Shaman_RSHU
Но всё таки ИИ можно доверить писать не код "под ключ". Принимать архитектурные решения он не должен, иначе будет SkyNet :)
ED-209
Косяк в том, что то самое "решение" о запуске SkyNet будут принимать люди максимально диаметрально противоположные от ИТ.
RichardMerlock
Всегда так было. Инженеры в ящике пилят царь-бомбу. Кнопку жмет генерал.