ребята, на фоне очередной истерии, как вам такой (мой) взгляд на вещи: 1. ИИ находит микроскопическое кол-во новых глобальных 0-day уязвимостей, и никакого тектонического сдвига в количестве взломов не случилось, и не случится 2. нарратив "взломать можно всё" - буллщит, потому что количество уязвимостей - конечно. новых серьёзных 0-day в крупных проектах почти не обнаруживали, потому что у них давно были щедрые bounty-программы, и они действительно хорошо проверены 3. будет период в 1-2 года (и он уже идёт), когда кол-во обнаруженных уязвимостей вырастет в 3-4 раза (тупо потому что можно поставить 10к агентов 24/7 искать дыры, и это на порядки больший effort, чем мясные white/black hats могут выдавать), но их позакрывают, да и всё 4. в будущем кол-во локальных уязвимостей уровня "дыра в коде приложения" будет раза в 2-3 больше, чем сейчас (просто из-за вайб-кодинга и радикального увеличения кол-ва нового кода), а кол-во глобальных уязмостей уровня "брешь в ядре Linux" будет раз в 30 меньше, чем сейчас и в итоге никакого cybersec-коллапса не случится, да и вообще всё будет идти своим чередом. понимаю, вау-заголовок "всё пропало" с такими взглядами не напишешь, но всё же... 🙂

Все вокруг теперь программисты Короче, у Gergely Orosz в The Pragmatic Engineer вышла интересная статья про новый тренд: крупные компании начали создавать собственные аналоги Lovable для сотрудников. И нет, не для разработчиков! А для менеджеров, маркетологов, финансистов и прочих ребят, которые хотят сделать себе какой-нибудь инструмент, но писать код не умеют. Вот вам два примера. 1. Ramp и их Glass Ребята собрали собственную платформу для вайб-кодинга внутренних приложений. Причём первую версию сделали всего два инженера за несколько недель. Теперь любой сотрудник может описать, что ему нужно, подключить корпоративные источники данных и получить работающее приложение. Например, маркетолог собрал себе CRM с более чем 50 полями и фильтрами. И знаете, что самое интересное? В Ramp создание первого инструмента через Glass уже стало частью онбординга новых сотрудников! А 13 октября компания вообще вывела Glass на внешний рынок. 2. Stripe и их Harbor Здесь ещё интереснее. Один инженер за 40 дней создал внутренний инструмент для генерации интерактивных прототипов. И вот результаты с мая 2026 года: • Более 12 000 созданных прототипов. • Более 3 000 сотрудников воспользовались инструментом. • 25% сотрудников Stripe создали хотя бы один прототип. Причём используют его не только дизайнеры. Финансисты собирают интерактивные отчёты вместо презентаций, продавцы калькуляторы ROI, аналитики - дашборды. А самое интересное технически: Harbor интегрирован с другими AI-инструментами Stripe через MCP. То есть прототип можно передать coding-агенту для дальнейшей реализации. Оооокей! А зачем делать свой Lovable, когда уже есть готовые? Orosz выделяет несколько причин: 1. Данные. Корпоративную информацию не хочется отправлять в сторонние сервисы. Своя платформа позволяет контролировать доступ к ней. 2. Интеграции. Можно сразу подключить внутренние API, базы данных и другие системы компании. 3. Стандарты. Генерируемые приложения используют корпоративную дизайн-систему, а не выглядят как результат очередного хакатона. 4. Стоимость внедрения. Иногда собрать собственный инструмент оказывается сопоставимо по усилиям с выбором вендора, согласованием безопасности и последующим внедрением. 5. Компетенции. Инженеры заодно учатся строить собственную AI-инфраструктуру. А теперь моя любимая часть! Кажется, мы наблюдаем довольно интересную трансформацию роли инженерных платформ. Раньше у нас был внутренний заказчик, который приходил к разработчикам и говорил: - Ребята, сделайте мне дашборд, форму или какой-нибудь маленький инструмент! Разработчики брали это в бэклог, приоритизировали, обсуждали, оценивали… А через полгода сообщали, что в этом квартале ресурсов нет. 😁 Теперь этот же сотрудник может собрать себе нужный инструмент самостоятельно. И вот тут возникает интересный вопрос. Если создавать приложения сможет каждый, кто будет отвечать за весь этот зоопарк? Кто управляет доступами? Кто контролирует стоимость исполнения? Что делать, когда автор приложения увольняется? И кто гарантирует, что какой-нибудь вайб-кодер не откроет доступ ко всей корпоративной базе? Кажется, ответ опять - платформенные команды. Только теперь их задача не просто делать удобные инструменты для инженеров, а создавать безопасную среду, в которой приложения могут создавать вообще все сотрудники. И, на мой взгляд, это куда более интересная история, чем очередное ускорение написания кода на 30%. Потому что мы меняем не скорость разработки. Мы меняем то, кому вообще нужна команда разработчиков для создания программного обеспечения.

История двух проектов или как вайб-кодинг хороший код подсматривал Последнюю пару недель я кодил как не в себя. Причем вел одновременно два противоположных по духу разработки проекта. Один - честный agentic harness coding, второй - полный vibe coding. И сегодня выяснилось, что второй позаимствовал много из первого. Первый - платформа с материалами по AI Native разработке. С контролем качества, исполняемыми спеками, придирками к качеству кода и вылизыванию интерфейсов - ею не только будут пользоваться люди, но я и планирую показывать исходный код на видео сессиях. Выкатили, люди используют. Второй - виртуальная машина с версионированием для совместной работы агентов. Я дописывал ее прямо на бегу во время конференции и в код не заглядывал ни разу. Имело значение только то, что архитектура внятная, она держит нагрузки и работает как надо. Это тот самый проект, где Fable 5.1 сказал “такое успеть невозможно”, а Astra сказала “теоретически можно успеть, если урезать весь функционал”. Успели и провели. 20 сотрудничающих агентов, 700 изменений виртуальной машины, только один побег из песочницы (агент залез в историю изменений машины глубже, чем ему полагалось) А сегодня я заглянул в код, чтобы разобраться как все это работает, и как это масштабировать. Я был готов к ужасу вайб-кодинга и каше из файлов (ибо там под капотом 4 разных рантайма, не считая Web UI), а увидел нормальный проект. Даже скучный (скину скриншот папки в комментарии) Когда я начал пытать историю Codex-a на тему - “а почему оно такое аккуратное?”, то всплыло три факта: (1) Этот проект был результатом очередного эксперимента, где код переписывался с нуля. К тому времени мне надоело заводить проекты в Codex на каждый эксперимент, и я просто запускал их из одного control centre (это папка на диске с локальными ссылками на другие проекты и глобальными инструкциями). (2) Идеи и код таскались между проектами под влиянием инструкции piecemeal growth, или того, что от нее осталось: “Add abstractions, concurrency and configuration only when a present requirement needs them.” В процессе ненужное отваливалось, а нужное кристаллизовалось. (3) Codex при перетаскивании подсматривал и в другие проекты, в том числе и вылизанный код платформы. Натащил оттуда те идеи, которые соответствовали духу piecemeal growth В общем, получился интересный вывод. Результаты яростного вайб-кодинга становятся лучше, если агент может брать пример с хорошо организованных проектов на диске. Хороший код - иногда работает лучше в качестве инструкций, нежели куча нагенерированного слопа в markdown. Теперь уже не так жалко времени, которое я потратил на вылизывание кода платформы. Ваш, @llm_under_hood 🤗

До вайб-кодинга оставалась четверть века… Контроллеры австрийской B&R, на которых в стране собрана куча автоматики, после ухода вендора купить нельзя, а через серый импорт один такой стоит от полумиллиона до трёх с половиной миллионов рублей. И так при каждом отказе. Инженер, оставшийся единственным разработчиком в компании после банкротства, придумал менять не всё, а только «голову», ставя вместо контроллера обычный мини-ПК в десятки раз дешевле. Загвоздка в том, что родные стойки общаются по протоколу жёсткого реального времени с циклом в две миллисекунды, а открытый стек под него забросили в 2019 году. Раньше под такую задачу искали бы редкого специалиста на месяцы работы за те же миллионы. Драйвер, шлюз и разбор проекта заняли меньше недели, и первый же длинный прогон дал почти триста тысяч циклов обмена без единого пропуска. Выясним, почему оно заработало там, где интернет почти ничем не помогает.

Люди без кода делают продукты У нас в компании начинают кодить всё больше людей, которые раньше код в глаза не видели и имели только базовое представление о работе наших продуктов. Менеджеры, дизайнеры начинают напрямую заниматься разработкой продуктов. Через прослойку в виде вайб-кодинга.Это меняет привычные процессы. Меняет и невероятно ускоряет! Раньше был длинный цикл: дизайнер рисует в Figma, верстальщик переносит, бэкендер подключает. На каждом этапе нужны разговоры и корректировки. Теперь дизайнер иногда может сам скорректировать существующий функционал — агент правит код, создаёт MR, а разработчик просто проверяет, что всё в порядке. Я поэтапно внедряю наши же разработанные инструменты для вайбкодинга всем сотрудникам. Некоторые фичи стали долетать до прода за 1 час вместо 2-4 дней. Оптимизация процессов выходит на совершенно другой уровень. Можно смело констатировать: заказной разработке, такой, какой она была последние годы, наступает конец.

Как доводить проекты до ума и фокусироваться в эпоху ИИ. На чем сейчас фокусируется Бог (если он есть) и какими проектами занят? У вас ведь тоже теперь 100 незавершенных проектов из-за вайб-кодинга и Claude Code? Хуже того, в какой-то момент я заметил, что лишние возможности (как и лишние инвестиции) убивают продуктивность. Легко переключаться на другой проект, как только один забуксовал. Легко погрузиться в прикольный вайб-кодинг, вместо того, чтобы заниматься чем-то по-настоящему важным (продажами, например) И тут я задал себе один неожиданный вопрос: раз мы теперь все такие всемогущие и все можем делать по щелчку мышки, мы теперь практически боги (в интернет-вселенной), а раз так — на чем сейчас фокусируется Бог и какими проектами занят сегодня? (не важно, верите ли вы в него или нет) Оказалось (deep research помог), что вопрос о том «чем сейчас занимается Бог и на чем он фокусируется сегодня» занимал великие умы от Аристотеля, до Фомы Аквинского и далее по списку. А самое интересное, что ответы, которые нашли великие философы, очень подойдут и нам, менее великим вайб-кодерам, терзающим Claude Code по ночам. Не буду терзать вас цитатами Фомы Аквинского и других теологов (вы ведь и сами можете сделать такое исследование), напишу лишь как я понял это лично для себя, в виде эдакой современной шпаргалки, которую не грех распечатать и повесить рядом с монитором. 1. Ограничения. Если ты можешь все, то ты не будешь делать ничего. И поэтому Бог себе сам придумал ограничения, в случае нашей вселенной — законы физики, внутри которых приходится решать разные противоречия. Короче, заставьте себя придумать ограничения. Вот мои 2 первых: а)пока не продал/не показал кому-то, дальше не разрабатывай б)любой кусок работы от идеи до презентации/продажи должен укладываться в 4 часа, если не укладывается, значит ты плохо понял задачу и плохо раздробил. 2. Начинай любую задачу с чистого листа. По одной древнееврейской легенде, Бог, перед тем как сотворить все вокруг, сжался в точку и очистил все вокруг, то есть «очистил контекстное окно». Я стараюсь все главные задачи писать просто от руки на листе бумаги и каждую новую задачу в LLM начинать с чистого листа и с собственной формулировки. Короче, если я не могу сформулировать от руки (вне LLM) задачу, то я и принять ее не смогу. А во-вторых, от руки много не напишешь, приходится упрощать. Поэтому важно сохранять некий «суверенитет» собственного мозга в постановке и в приемке задач и периодически закрывать все вкладки, выходить в офлайн и пытаться решить задачу вне LLM, пересказывая ее устно, например. 3. Помни кто ты, зачем ты это делаешь и какой твой тезис. Платон утверждал, что фокусировка определяется не объектом, на который ты смотришь, а системой ценностей того, кто смотрит. По мнению Платона, Спинозы и Аристотеля — Бог смотрит прежде всего на самого себя, а не на свои творения, которые являются лишь его отражением (тенями от костра, но не сами источником - костром). Короче, мир вокруг (в том числе проекты, которые мы навайбкодили) — это просто наше отражение, с некой задержкой (1-5-10 лет, эта инерция в последнее время сильно сократилась). Что делать, если обнаружил что вокруг тебя хреновые проекты, война и злые люди? Тут ориентир один — любовь. Прекратить заниматься тем, что не любишь и делать только то, что любишь и что нравится. Не делать из страха или нужды. Это самый сложный пункт, потому что большинство делают проекты из-за нужды денег, давления инвесторов или клиентов, ходят на работу из-за ипотеки и т.п. Как это победить? Как минимум, чаще напоминать себе об этом (во всех религиях это называется молитва) Есть еще много нюансов, но эти 3 главные. Вот так все просто, но не очень-то легко: люби, упрощай, ограничивай. А вам что помогает?

🧑‍💻 3 проблемы, которые вредят вашему стартапу. А вайб-кодинг их лишь усугубляет Сейчас SaaS-решения все чаще создают с помощью нейросетей, и я понимаю почему. Ведь так можно за пару дней запилить MVP и сразу начинать продажи, допиливая продукт по дороге. Но не все так радужно. Я прочитал пост, автор которого уверен: вайб-кодинг не помогает бизнесу. Перевел текст и принес вам - предлагаю обсудить. Вот его мнение 👇 Я разрабатываю SaaS-приложения для разных клиентов, и с появлением вайб-кодинга стал замечать одну и ту же картину. Фаундер создает в нейросети приложение, радуется, как оно классно работает, а потом запускает его и… продукт никто не покупает. Человек думает: “Наверное, не хватает функций” и добавляет темную тему, панель управления, интеграцию. Людям все еще неинтересно, а предприниматель продолжает считать, что с продуктом что-то не так. ✋ На самом деле, проблема не в продукте. Он вообще никогда не был единственной точкой притяжения клиентов. Просто с появлением вайб-кодинга это стало в 100 раз очевиднее - ведь создать MVP или добавить в него функции теперь можно самому. А основатели так увлеклись ИИ-разработкой, что перестали замечать вещи, которые реально вредят бизнесу. Вот что они делают. 1️⃣ Пытаются продавать всем. К примеру, создают продукт, который помогает бизнесу автоматизировать работу. Но не уточняют, какому именно бизнесу - в итоге теряются среди таких же сервисов. Чтобы люди вас заметили, нужно определить: кому именно продаете. Я делал один и тот же продукт дважды: для широкой аудитории и для конкретной группы людей. Так вот, версия для узкой ЦА продалась в 22 раза лучше. 2️⃣ Не предлагают ничего уникального. Основатели часто создают продукт, который хотят сами, а не тот, что нужен аудитории. В итоге получается сервис, который выглядит, как 40 других и ничем не цепляет. Ну а покупатели в этом единообразии просто выбирают самый дешевый вариант. Чтобы люди захотели именно ваш продукт, узнайте, какую проблему они хотят решить. А потом создайте понятный и простой в использовании сервис. 3️⃣ Не составляют план по заработку. Стартапы получают доход с текущих клиентов и радуются выручке, но не учитывают, например, расходы на рекламу. И работают себе в убыток. А когда денег на продвижение не хватает - решают, что новые клиенты сразу придут, как только они добавят пару функций. Но так это не работает. Какая из этих трех ошибок кажется вам самой опасной? Заходите в комментарии - обсудим. 👉🏼 Подписывайтесь на «Телеграмму...» в Максе: max.ru/yumaks #СОВЕТЫ #СТАРТАП #ИИ

Задачи, которые годами лежали в столе, теперь решаются за вечер В агентствах давно копились задачи, которые не окупали полноценную разработку — слишком мелкие, слишком разовые, чтобы звать программиста. Сейчас их делать вайб-кодингом стало экономически разумно. Когда есть смысл браться: задача локальная, результат виден сразу, данные можно восстановить, а поломка не остановит работу ни агентства, ни клиента. Проще говоря, то, что можно безболезненно выбросить, пересобрать заново или в крайнем случае сделать руками. Что реально можно сделать: 🔵 Прототип сайта или личного кабинета для проверки гипотезы. Можно быстро собрать черновик, поиграть со шрифтами и провести первый раунд согласований без лишних затрат. 🔵 Сборщик отчётов. Экспорт данных из рекламных кабинетов и любых других источников, который раньше менеджер собирал руками, теперь можно завайбкодить как автоматический скрипт. 🔵 Дашборд для проекта в цветах брендбука. 🔵 Заполнение проекта "рыбой". Если сайт перед сдачей выглядит пустым, ИИ отлично добавит тестовые материалы и картинки — гораздо приятнее глазу, чем lorem ipsum. 🔵 Очистка и импорт данных. Конвертировать форматы, переделать таблицы под вставку, поменять формат чисел. С этим справится любая современная модель. 🔵 Проверочные программы. Сравнить данные в нескольких местах и прислать сообщение в мессенджер при несовпадении. А вот если задача критична для бизнеса клиента и ошибка приведёт к потере денег и остановке работы, или если код придётся дальше поддерживать и развивать, то тут лучше уже подключать программиста. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵