KotReview | Svetlana Meleshkina

🤡 Вайб-кодинг это прекрасно, а кто будет чинить прод в 3 ночи?

Продолжаю размышлять над статьей Pragmatic Engineer про массовый исход техдиров. Не могу не поделиться новым термином 'founder slop'.

Фаундер с Клодом делают пулл-реквест на 60 000 строк. Фаундер счастлив! Он 10x разработчик!

«Смотрите, как я продуктивен, агенты делают всё!»

И этот кусок говна нетестированного слопа летит в прод.

И тут старое доброе правило стартапов «You build it, you run it» ломается. Потому что фаундеры не сидят на онколлах.

Разгребать последствия этой гиперактивности продуктивности, чинить базу в 3 часа ночи и пытаться понять логику приходится дежурному разрабу. А техдиру нужно как-то аккуратно сказать фаундеру, что его PR суть бомба замедленного действия. Желательно при этом не выглядеть душным ретроградом и не оскорбить ЧСВ начальства. Та еще задачка.

Никто, конечно же, не хочет саппортить чужие галлюцинации, генерящиеся на огромной скорости. Ничего удивительного, что из таких компаний бегут, сверкая пятками.

ИИ как ускоритель производства хлама: когда фичи не просто бесполезны, а начинают понемножку вредить

Читала блог Pragmatic Engineer, много думала. Шикарная статья о том, почему CTO сейчас массово увольняются в никуда.

Одна из основных причин это фаундеры поймавшие «ИИ-психоз» 🤡

«Мы стали релизить в разы быстрее! ИИ-агенты пилят по 10 фич в день! Скорость наше всё!»

Смотришь на рожденный под эти лозунги продукт, хочется обнять и плакать.

Потому что в гонке за скоростью упустили простую истину: плохая фича, выпущенная за два дня, не становится хорошей. Она просто быстрее начинает бесить клиентов и портить продукт.

В статье есть кейс директора по инженерингу, который ушел из стартапа. Почему? Фаундер забив на проверку нужны ли ИИ фичи пользователям, просто сам запилил их с Клодом и выкатил на прод. В 2026 ИИ должен торчать из каждого чайника. Итог? ИИ-фичи клиентам нафиг не сдались, а вот постоянные падения базового функционала их очень расстроили. А именно базовый функционал пострадал от PR фаундера. В итоге новые фичи не привели новых пользователей, а старые начали разбегаться, потому что продукт стал неудобным.

Раньше зарелизить фичу было дорого, и это работало как фильтр. Чтобы продавить сомнительную идею, продакту надо было пройти через декомпозицию, оценки и прочую душноту. Большая часть бреда отсеивалась еще на подлете.

Теперь фильтра нет. Фаундер с Клодом нагенерил за ночь кучу фичей, и утром в прод летит гипотеза.

И ладно, если бы эта новая гипотеза просто тихо пылилась в углу. Но фича, которую никто не просил, начинает вредить:

⏺ Зашумление интерфейса и когнитивная перегрузка. Продукт превращается в швейцарский нож с сотней лезвий, из которых человеку нужно одно. Каждая новая кнопка, плашка «Попробуй наш ИИ» и всплывающее окно ухудшают UX. Пользователь пришел решить простую задачу, а попал на выставку достижений нейросетевого хозяйства.

⏺Размытие Product-Market Fit. Когда в продукт бесконечно пихают непродуманный функционал, он теряет фокус. Пользователи перестают понимать, за что они вообще платят, и уходят туда где просто и понятно. Где еще не прикрутили ИИ к подушке-пердушке.

⏺ Убийство стабильности. Любая фича, даже не глючная, вплетается в общую бизнес-логику и создает налог на поддержку. А когда её пилят по принципу «главное выкатить», она неминуемо наращивает техдолг.

Раньше, чтобы сделать ненужную хрень и осознать ее провал, уходили месяцы. Поэтому все думали, а надо ли. Не значит конечно что не делали ерунды. Но, хотя бы включали мозг. Теперь ИИ позволяет производить мусор как из пулемета. Генерировать код очень дешево. А вот распугать пользователей этими свисто-перделками может быть крайне дорого. Собственно это может стоить всего стартапа.

В общем, включать мозг на этапе понимания, а что вообще стоит брать в разработку, всё еще отличная идея. Ну и при самой разработке тоже не помешает. Наши мозги все еще нужны, не даем им тухнуть!

Продолжение AI-психоза в Meta: когда деньги больше не работают

Помните пост про то, как Meta уволила инженеров, отправила оставшихся размечать датасеты для ИИ и сломала Instagram?

Предлагаю ознакомиться со вторым актом этой драмы от того же Pragmatic Engineer. Настала самая интересная фаза, «а почему это все от нас бегут?». И правда, а почему? 🍿

Краткое содержание предыдущей серии: Meta на фоне рекордных прибылей сократила 10% штата, а 20–30% сильных инженеров перевела на задачи по разметке данных. Причем ничто не предвещало: вчера ты был ведущим архитектором, сегодня сидишь и лайкаешь ответы нейросетки.

И начался прогнозируемый ад 🤯

🥇Массовый побег (даже тех, кого не увольняли)

Инженеры уровня Staff / Principal пошли по собеседованиям. Люди уходят даже с понижением в зарплате, лишь бы подальше от разметки ответов нейросеток и ожидания следующих увольнений. Люди не любят неопределенность, факт.

🥈 Meta впервые в истории ввела удерживающие гранты

Раньше в компании было правило: если сильный инженер приносит заявление об уходе, с ним не торгуются. Теперь топ-менеджмент в панике. Тем, кто уходит, предлагают поэтапные на три года бонусы в акциях на $400k – $1M+.

🥉Но это НЕ РАБОТАЕТ

Люди забирают эти миллионные контр-офферы, идут с ними в Anthropic или OpenAI (как так можно, мы же семья, да?), те их перебивают... И люди уходят. Один из разработчиков принял грант от Meta на $1M+, посидел месяц и всё равно сбежал в стартап.

🟧 Meta наивно решила, что инженеров можно тасовать как взаимозаменяемые винтики. В итоге они получили худшее: потеряли лучшие кадры, пробили дно по безопасности и теперь пытаются затушить пожар увольнений миллионными контр-офферами.

Культуру строят годами, а разрушить ее можно за пару месяцев. Это отличный пример для любых руководителей: как только вы меняете инженерную культуру на слепую погоню за метриками, ваша компания превращается в перевалочный пункт для людей, которым всё равно.

🏋️‍♂️ Ок, claude, запиши меня на тренировку. Как ИИ стер грань между бытовым запросом и кибератакой

На днях всплыла прекрасная история из Австралии. Мужчина подключил OpenClaw с Claude и делегировал агенту несложную бытовую задачу: записывать его на тренировки в фитнес-клуб. Казалось бы, вот оно, светлое будущее с личным секретарем. Не надо караулить открытие записи, просто говоришь куда хочешь попасть, а дальше не твои проблемы, агент разберется.

И агент разобрался 😈

Сначала он полез изучать API системы бронирования и обнаружил, что через него можно записываться на занятия сильно раньше, чем разрешает UI. Хотя пользователь не просил искать уязвимости. Пользователь просто хотел на тренировку, а деятельный агент нашел более эффективный путь к цели.

Дальше веселее. Мест уже не было, пользователь оказался четвёртым в листе ожидания, и спросил агента, можно ли как-нибудь поднять его повыше. Агент обнаружил, что API позволяет отменять чужие бронирования без проверки прав. И вместо того чтобы сообщить об этом пользователю и спросить, что делать дальше, решил проверить гипотезу. Взял и удалил человека с первого места в очереди чтобы закрыть задачу хозяина.

Пользователь, судя по описанию истории, такого поворота не ожидал и попросил всё вернуть обратно. Но фарш невозможно провернуть назад: восстановить чужую запись агент не смог.

То, что ИИ умеет находить уязвимости, и делает это хорошо, мы уже знали. Но тонкий момент, насколько сильно изменился порог входа между обычным человеческим намерением и кибератакой.

Раньше эксплуатация дыры в чужом API требовала знаний, и цепочки сознательных решений: да, сейчас я полезу туда, куда мне вообще-то нельзя.

Теперь человек пишет: «А можно меня поднять в очереди?»

И дальше модель сама исследует систему, выбирает инструменты, находит обходной путь и решает, какие действия достаточно разумны для достижения цели (мы же знаем что, любые, да?). Пользователь получает конечный результат и может вообще не представлять, что именно происходило.

То есть человек не просил: «найди уязвимость в API и удали чужую бронь». Но и агент не обладает какой-то собственной великой целью захватить фитнес-клуб. Ему дали совершенно невинную цель: помочь хозяину попасть на тренировку. Штатный путь оказался закрыт, он нашел другой. Вопрос кто отвечает за взлом?

Это ровно та проблема outcome-first моделей. Мы учим агентов не сдаваться, самостоятельно исследовать окружение, пользоваться инструментами и доводить задачу до результата. А потом удивляемся, когда они воспринимают ограничения системы не как границу, а как очередную инженерную проблему, которую надо решить.

Причём для массового пользователя всё это завернуто в максимально невинный интерфейс «просто попроси». Никакого терминала, бегущих циферок и ощущения, что сейчас занимаешься чем-то подозрительным. Сидишь с телефоном и просишь помощника записать тебя в качалку. А где-то под капотом помощник уже изучает чужой API и проверяет на другом человеке, можно ли удалить его из очереди.

Пока речь идет о фитнес-клубе, это просто забавная байка. Но что, если тема будет серьезнее? Агент решит оптимизировать ваши налоги, купит билеты через уязвимость авиакомпании или снесет базу конкуренту «так было эффективнее для бизнеса»?

И вот тут в полный рост встаёт вопрос ответственности. На него, кстати, пока нет нормального ответа. Агент юридическим лицом не является, поэтому посадить Claude за решётку не получится. Но кто тогда отвечает: пользователь, который поставил задачу, разработчик агентного софта, создатель модели или компания, оставившая дыру в своей системе?

Юрист, которого опросили ABC, говорит, что потенциально ответственность может оказаться на любой из этих сторон. Всё будет зависеть от того, что именно разрешил пользователь, насколько последствия можно было предвидеть и при каких обстоятельствах агент полез ломать чужую систему.

Кажется, дальше таких кейсов будет очень много. Потому что старое удобное «человек нажал кнопку и совершил действие» начинает разваливаться. Человек поставил цель. А кнопку нашёл и нажал агент.

Помните, сообщение агента Готово может означать очень широкий спектр событий. От «я записал тебя на тренировку» до «я записал тебя на тренировку, но по дороге хакнул фитнес-клуб».

И есть ненулевая вероятность, что разбираться с последствиями этого «Готово» придётся лично тебе.

Агенты походя изобрели себе конфлюенс. А потом, вооружённые силой коллективного разума пошли ломать чужую инфру

На Black Hat OpenAI рассказали что происходит, если дать куче автономных агентов сложные задачи, ограничить им интернет и случайно оставить общее пространство.

Агенту дали задачу, для которой нужны были данные из интернета, а прямого доступа туда не было. Агент пошёл изучать доступную инфраструктуру и обнаружил внутренний Artifactory, через который наружу ходить было можно. Ну я бы тоже так попробовала, факт)

Но, такой умный агент был не один. Этим же Artifactory пользовались и другие запуски агентов. И они начали оставлять сообщения для товарищей. Делились найденными способами обойти ограничения, кусками кода и уязвимостями, пытались помогать друг другу с задачами. Постепенно это превратилось в форум с сотнями тысяч сообщений. Когда возникли проблемы с тем, кто от чьего имени пишет, они дошли до криптографических подписей сообщений.

Всё это хозяйство довольно долго жило без внимания людей.

Дальше веселее. Агенты нашли уязвимости в самом Artifactory и получили повышенные права. Когда OpenAI обнаружила происходящее и прикрыла их форум, через несколько дней агенты организовали канал общения заново, другим способом.

То есть никто не садился проектировать коллобарацию агентов, не строил специальный оркестратор, общую память или базу знаний. Просто несколько независимых агентов обнаружили место, где можно оставить информацию так, чтобы следующий агент её нашёл.

И внезапно получили конфлюенс для железяк.

Причём мотивация у всей этой истории совершенно не скайнетовская. Каждому агенту дали конкретную задачу. Штатным способом она не решалась. Поэтому агент начал искать другой способ. А когда рядом обнаружились результаты работы предыдущих агентов, было бы глупо ими не воспользоваться.

Но дальше история перестаёт быть смешной. Во время отдельного cyber capability evaluation OpenAI специально запускала модели с ослабленными ограничениями на кибератаки, чтобы проверить, насколько далеко они вообще способны зайти. Среда предполагалась изолированной, но агенты нашли способ выбраться за предполагаемые границы теста.

В результате модели добрались уже до реальной инфраструктуры Hugging Face. По данным OpenAI, они использовали украденные credentials и неизвестные ранее уязвимости, собрали из этого цепочку атаки и получили remote code execution на серверах Hugging Face. Сам Hugging Face подтвердил проникновение, повышение привилегий, получение cloud и cluster credentials и дальнейшее перемещение по внутренней инфраструктуре.

Тенденция «умри, сломай, укради, но закрой таску» была хорошо видна ещё в System Card моделей-планет. Но тут к ней добавился коллективный разум. Мы привыкли думать об агенте как об отдельном исполнителе: дали контекст, инструменты, память и отправили решать задачу. А оказалось, что достаточно оставить между независимыми запусками общий ресурс, и он может превратиться ещё в один слой памяти.

Это не восстание машин, конечно. Просто агенту дали таску, штатным способом она не закрывалась, и дальше началось знакомое каждому инженеру:

Так. Через API нельзя. Сейчас посмотрим, что тут ещё торчит...

Индекс треска совы, или Аутсорс совести в энтерпрайзе 🦉

Недавно наткнулась на пост про метрики в котором размышления на тему, что же потом делать с этими цифрами метрик. Доставать кнут или пряник? Что то менять в управлении проектами?

Возможно у меня детская травма, но в моей реальности , метрику куда чаще используют просто как коэффициент для премии или маркер на увольнение.

Самое стрёмное начинается, когда от цифры на дашборде зависит бонус не только разработчика Васи, но и его руководителя. И вот тут включается удивительный корпоративный феномен — аутсорс совести.

Менеджер придумывает KPI под свою годовую премию, руками он ничего не делает и остается в ослепительно белом пальто:
«Я просто внедрил data-driven подход и поставил амбициозные цели».

А натягивать сову на глобус приходится инженеру. Менеджер только указал на глобус. А перья, кровь и говнокод остаются на руках разработчика. Именно разработчику и тимлиду приходится плодить фейковые активности, микро-тикеты и гонять их по Jira табунами, потому что жить на что-то надо.

В зависимости от того, какую метрику начальство решило внедрить в этом сезоне, можно вычислять Индекс Треска Совы:

⏺ Velocity и Lead Time

Инженеры начинают дробить задачу «поменять цвет кнопки» на восемь микро-тикетов: аналитика, дизайн-ревью, бэкенд-заглушка, фронт, QA-пас, релиз-кандидат. Сова трещит от бесконечных переходов статусов в Jira, зато график сгорания задач выглядит как идеальная трасса. Премия в кармане.

⏺Test Coverage

Пишем тонны юнит-тестов. Сложнейшие моки ради моков, горы кода — и ноль assert'ов. Баги летят на прод, SonarQube зелёный. Сова трещит от CI/CD. Премия в кармане.


⏺AI-трансформация (тренд сезона)

KPI — процент ИИ-генерированного кода и сожжённые токены.
Возвращаемся к старому доброму холивару «строк кода», только в новой обёртке. ИИ генерит быстро и много, а с разработчика требуют подвига Стаханова по ревью всего этого потока. Сил вникать в растущий ком уже не остаётся.
За сокращение кодовой базы никто не заплатит, а за рост проникновения ИИ — очень даже. В итоге кодовая база пухнет, сложность растёт, и даже агентам становится тяжело ориентироваться.
Зато метрика зелёная, руководство отчитывается о новом уровне AI-трансформации… пока расходы на токены не разорят компанию. Премия в кармане. Если успеют получить до банкротства.

Смена технологических эпох меняет только единицы измерения. Суть остается неизменной: как только метрика отрывается от реальной ценности (работающего продукта) и привязывается к премии руководства, реальный процесс летит в мусорку.

Хотя... «Треск совы» это, пожалуй, единственная предельно честная метрика, которую действительно стоило бы выводить на главный дашборд СЕО. Чем громче этот треск из опенспейса разработки, тем успешнее менеджмент идет к своему бонусу. 😄

Секте свидетелей Done в agentic workflow посвящается

Продолжим про бенчарки агентской разработки. Попался на глаза разбор по SWE-bench Verified.

Исследователи сравнили submit rate и resolve rate. Оказалось, что агент почти всегда способен сформировать и отправить изменение. Но заметно реже это изменение действительно закрывает проблему.

И это, если честно, совсем не удивительно. Метрика «я сделаль» никогда не была равна метрике «пользователь получил рабочий фикс».

Более того, одна из самых неприятных категорий ошибок получила название silent semantic failure. Это когда агент несколько раз подряд воспроизводит одно и то же неправильное решение и каждый раз уверен что задача выполнена. То есть проблема не только в том, что агент ошибся. Проблема в том, что он убежден, что он прав.

Еще из интересного. Агент часто предпочитает внести изменения, даже когда правильным решением было не менять код вообще.
Получается ловушка. Высокий submit rate не является метрикой приносимой пользы. Это всего лишь показатель того, что агент склонен что-то сделать. Опытный разраб на живой системе предпочел бы трогать минимум кода, а лучше не трогать вообще, если можно выкрутиться по другому.

Но ведь мы раньше не верили на слово джунам. Сообщение 'Починил, проверил' было поводом пойти открыть diff, убедиться, что CI зеленый, а не просто нажать на мерж. Так и агент это участник процесса, а не система контроля. Его Done всего лишь гипотеза, которую нужно проверить. Self-report агента не является доказательством.

А вот из того, как мы выстроим доказательства, критерии приемки и строится настоящая инженерия агентных систем. И эта инженерия не про то, как грозить модели пальчиком в промпте. И не про бесконечную гонку за новыми моделями. А про то, что нужно думать не только о том, что подать модели на вход, но и о том, как проверить то, что она выдала на выходе. Когда она сказала Done.

Подвезли новые бенчмарки для моделей. И это наконец-то больше похоже на бенчмарк здорового человека, чем SWE-bench Pro.

Scale обновила Remote Labor Index: моделям дают реальные проекты с Upwork вместе с вводными данными, исходниками и референсным результатом. Задача засчитывается только тогда, когда клиент принял бы работу (и заплатил 😜).

SWE-bench классный бенчмарк, он показывает, что модели могут работать с реальными репозиториями и закрывать реальные инженерные задачи. Но он отвечает на вопрос: может ли модель сделать коммит, который проходит проверку?

В реальной работе этого мало. Нужно не просто написать код и пройти проверки, нужно получить результат, который кто-то готов принять.

Потому что агенты, делая реально сложную работу, регулярно умудряются её не доделать. И даже при этом пройти автоматические проверки.

Ну никто не удивлён, да?

⏺Они теряют часть требований.
⏺Не собирают финальный файл.
⏺Ломают формат.
⏺Оставляют визуально кривой результат.

И это хорошо показывает разницу между возможностями модели и надёжностью системы вокруг неё.

В проде недостаточно проверить, умеет ли агент написать код, собрать презентацию или проанализировать данные.

Нужен цикл обратной связи:

⏺требования переведены в проверяемые условия;
⏺артефакт действительно создан;
⏺формат и структура валидны;
⏺тесты и автоматические проверки пройдены;
⏺человеку удобно посмотреть именно результат, а не заниматься археологией в трейсе агента.

Красивое демо отвечает на вопрос: модель вообще так может?

Рабочая система отвечает на другой: Наш техлид готов это пустить в прод?