Главные уязвимости агентских приложений

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

1️⃣Подмена цели – атакующий манипулирует тем, какие задачи преследует агент, или тем, как он принимает решения.
2️⃣Эксплойты тулов – агент оперирует в изначально установленных пользователем рамках, но использует один из предоставленных ему тулов не так, как предполагалось – например, для удаления ценной информации, вызова дорогого API, выборочной передачи приватной информации.
3️⃣Абьюз систем IAM – здесь много всего, начиная от использования привилегий агента в злонамеренных целях, заканчивая кражей учетных данных.
4️⃣Уязвимости цепочек поставок – тоже большой класс уязвимостей, к которому можно отнести как дырки, заложенные в веса моделей или логику агентов, так и взлом через установку агентом скомпрометированных библиотек в ваши приложения.
5️⃣Выполнение небезопасного кода – то самое, что в первую очередь приходит на ум. Агент пишет код, вы его исполняете, а где-то в нем оказывается написана логика по выдаче рутового доступа к вашему серверу кому-то со стороны.

Как менять поведение систем

Донелла Медоуз – автор очень известной книги про системное мышление "Thinking in Systems". Есди вы ее не читали, то вот это ставшее уже классическим эссе про то, какие рычаги для изменения поведения систем существуют, даст довольно хорошее представление о материале.

Фальшивые догмы

Некоторые правила разработки менеджеры слепо повторяют друг за другом, хотя, если задуматься, они имеют мало смысла. Вот несколько примеров:

👉Не переизобретайте колесо и берите готовые библиотеки. На самом деле, это трейд-офф, на другой стороне которого – ценность хорошего понимания кода, и безопасность от supply chain атак.
👉Каждый PR кто-то должен заревьюить. Цена обязательных ревью очень высокая, поэтому, хоть они и поднимают качество кодовой базы, не нужно доводить это правило до абсолюта и ревьюить тривиальные вещи.
👉Все современные команды должны работать короткими спринтами. Не всегда тот факт, что вы работаете по спринтам, делает вас гибкими. Более того, не вся разработка должна быть гибкой.
👉Каждая фича должна быть за флагом. Точно нет, так как огромное количество флагов усложняет даже самый тривиальный код, а ценность от них есть не всегда.

Полезные правила работы с календарем

👉Решайте конфликты между накладывающимися друг на друга встречами максимально рано. Чем раньше вы отклоните один из них, тем удобнее будет для всех его участников.
👉Используйте цветовое кодирование для митингов разного типа. Например, их можно делить по требуемому уровню фокуса, формату, решаемой проблеме, роли или еще чему-то, что имеет смысл именно для вас.
👉Используйте эту категоризацию для бюджетирования времени – например, на уровне одной недели можно поставить ограничение на количество собеседований.
👉Бронируйте слот на обед.
👉Делайте события в календаре редактируемыми всеми участниками по умолчанию, так их будет проще переносить.
👉Если у вас есть и личный, и рабочий календарь, слоты в которых пересекаются, используйте Reclaim для их автоматической синхронизации.
👉Забронируйте первый день после отпуска под то, чтобы снова въехать в контекст и разобрать все накопившееся, иначе встречи не дадут этого сделать.

Почему нанимать джунов стало выгоднее

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

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

Красная линия на графике – профит от джуна. Первое время он отрицательный, и, если вам повезет, когда-то выйдет в плюс. Сократить эту отрицательную область можно с помощью правильного онбординга и обучения, которые будут помогать быстрее приносить пользу, поддерживая достаточный уровень качества. Так вот, AI как раз с этой частью отлично помогает – если вы еще не использовали тот же Claude Code для онбординга в незнакомый код, обязательно попробуйте.

Если использовать AI правильно – задавать вопросы про кодовую базу, исследовать альтернативные варианты реализации задачи, вместе думать над упрощением кода – то он может существенно ускорить переход джуна в полноценного инженера, а вместе с этим и уменьшить риски, которые вы на себя берете. Что еще лучше – в будущем такой инженер продолжит быстро расти.

Реорг на вайбе

У реоргов есть несколько очень частых проблемы:

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

Как думать про компенсацию

Мне нравится, как автор сформулировал цель процесса компенсации:

Создать самую талантливую и мотивированную команду, которую только позволит вам ваш бюджет.

Это значит, что следующие вещи не являются самоцелями:

❌Сделать сотрудников счастливыми
❌Сохранить команду любой ценой
❌Сэкономить на ФОТ
❌Платить на уровне рынка, или на уровне какой-то конкретной компании
❌Соответствовать ожиданиям сотрудников
❌Платить всем одинаково

Если подумать над целью более рационально, то вам важно обязательно соблюдать следующее:

👉Платить самым ценным членам команды на уровне, на котором им будет сложно найти на рынке другую работу
👉Не допускать нечестной компенсации, использовать понятные и прозрачные зарплатные уровни
👉Быть готовым объяснить любое свое зарплатное решение
👉Максимизировать выравнивание интересов людей и компании через equity и performance-based бонусы

Как разные роли используют AI

Сценарии использования AI инструментов довольно сильно отличаются в зависимости от роли человека:

👉Продакты – подготовка PRD, прототипипование, коммуникации.
👉Дизайнеры – работа с исследованиям. пользователей, генерация текстового контента, генерация идей.
👉Фаундеры – помощь в принятии решений, генерация продуктовых идей, стратегия.
👉Инженеры – написание кода, архитектура, документация.

Тимлидов спросить забыли, но мы ведь понимаем, что в основном для написания перфоманс ревью!

Про мораль корпораций

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

👉Фича priority delivery, которая на самом деле не влияет ни на что, кроме флажка, отправляемого на сервер.
👉A/B тесты с замедлением скорости доставки неприоритетных заказов.
👉Автоматическое определение курьеров, которые готовы браться за заказы любой стоимости, и занижение им оплаты.
👉Чаевые, которые целиком уходят в карман платформы.

Спустя несколько дней после того, как я написал черновик поста, выяснилось, что история – не правда, а просто байт на комментарии. Но будем честными – никого не удивило бы, если бы это оказалось правдой. В большинстве крупных корпораций единственный способ оценки правильности действий – это то, как они влияют на ключевые метрики. Если активация, ретеншн или MRR растут – все замечательно. Если кого-то волнует этичность действий, система его автоматически отфильтровывает – без импакта нет повышений, без повышений нет влияния на принимаемые решения.

Очень подробно про это рассказано в вышедшей в прошлом году книге Careless People, в которой бывший топ-менеджер Meta делится байками про то, как Цукерберг и компания принимают решения и разруливают происходящий по их вине геноцид (и даже не один). Если вот эта история про доставку еды показалась вам нереалистичной, очень советую прочитать!

Так вот, расскажите в комментариях, сталкивались ли вы с тем, что ваша компания принимает решения, которые идут вразрез с вашей этикой? Как действовали?

Законы разработки софта

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

👉Закон Каннингема – Самый лучший способ получить полезный и правильный ответ в интернете – не спрашивать, как правильно, а запостить неправильный ответ.
👉Закон Стерджена – 90% чего угодно это мусор (ну получается как минимум один пост в две недели в нашем канале должен быть годным).
👉Закон Хайрума – от любого, пусть даже незадокументированного поведения вашего API, кто-то будет зависеть. Про этот закон мы пару лет назад классно поговорили в выпуске Подлодки про дизайн API.
👉Эффект Рингельмана – чем сильнее растет группа, тем сильнее снижается продуктивность отдельных ее участников.

За что инженеры ненавидят своих менеджеров

👉Бесконечные синки и митинги, которые вырывают из состояния потока
👉Нетехнические менеджеры, которые не понимают сложности задач, но при этом дают обещания по срокам
👉Менеджеры, которые присваивают себе чужие достижения, фразами вроде "вот что я зарелизил в этом квартале"
👉Фидбэк про зоны роста, который дается раз в год менеджером, который вообще слабо прелставляет себе вашу работу

Уроки 14 лет работы в Google

👉Лучшие инженеры думаю в первую очередь про решение проблем пользователей.
👉Быть всегда правым – легко. Настоящая сложность в том, чтобы прийти к правильносу решению вместе с командой.
👉В первую очередь выбирай действие – лучше сделать что-то, чем вообще ничего. Плохую фичу можно исправить, отсутствующую – нет.
👉Признак сеньорности – ясность. Сложность решения приносит накладные расходы.
👉Новизна – это кредит, который оплачивается сбоями и лишней когнитивной нагрузкой.
👉Ваш код не покажет всем, какой вы классный – это делают люди.
👉Лучший код – тот, который не написан.
👉На большом масштабе даже у ваших багов появляются пользователи, и их починкой вы кому-то навредите.
👉Проблемы медленных команд чаще всего в том, что они не выровнены с остальными.
👉Фокусируйтесь на том, что можете контролировать. Остальное игнорируйте.
👉Абстракции не избавляют от сложности. Они просто прячут ее до того дня, когда абстракция протечет, и вам надо будет разбираться, что находится под ней.
👉Письмо ведет к ясности. Лучший способ научиться чему-то – попробовать научить других.
👉Работа, которая разблокирует другую работу бесценна, и при этом невидима.
👉Если вам кажется, что вы выигрываете в каждом споре, скорее всего вы просто постепенно накапливаете сопротивление людей.
👉Когда метрика становится целью, она перестает быть честным показателем.
👉Признать то, что вы не знаете чего-то, дает больше безопасности, чем притворяться наоборот.
👉Сеть ваших знакомств переживет всю вашу смену мест работы и с вами навсегда.
👉Большая часть способов улучшения протзводительности лежит в избавлении от чего-то, а не в добавлении слоев сложности.
👉Процессы существуют для того, чтобы снижать неопределенность, а не ради бюрократии.
👉В какой-то момент карьеры ваше время станет дороже зарабатываемых денег, так что готовьтесь к этому и берегите его.
👉В накоплении знаний и опыта старайтесь не срезать углы, а наоборот, полагаться на сложный процент.

А если ваша стратегия не выдержит следующий год?

Стратоплан задумал открытую конференцию для всех, чтобы детально поговорить о стратегии (в частности, об IT-стратегии). И не просто поговорить, а совместно сформулировать принципы её устойчивости и антихрупкости

Будем разбираться:
— что на самом деле считать стратегией и почему она работает не у всех
— где и почему стратегии чаще всего ломаются
— какую роль играет AI и как измерять реальную ценность AI-внедрений
— какие инструменты работы со стратегией эффективны: стратсессии, форматы, ошибки

Что вы заберете для себя:
— поймете, где ваша стратегия уже трещит
— получите актуальные инструменты разработки и пересборки стратегии
— сможете честно проверить, насколько ваша стратегия хрупкая сегодня

29–31 января 10:00–15:00 GMT+3, онлайн
Бесплатная регистрация здесь

Среди спикеров: Никаких теоретиков! Только фаундеры, СЕО, СТО, HRD и эксперты Стратоплана, которые сами проходили через кризисы и знают, как строить стратегию на годы

Бонус:
3 онлайн-воркшопа про разработку и внедрение стратегии, в том числе от сооснователей Стратоплана — Вячеслава Панкратова и Александра Орлова.

Приходите и проверьте, действительно ли ваша стратегия устойчива

Прокрастинация, и как с ней справляться

Если кого-то и читать про прокрастинацию, так это Максима Дорофеева. В статье он постепенно выводит ее определение:

Я прокрастинирую, когда я решаю:
- сделать дело Y, показавшееся более важным, чем X,
- вместо дела X, впоследствии показавшееся более важным, чем Y и …
- испытываю неприятные чувства из-за этого

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

👉Почему вы считаете дело Х важным для себя? Важно ли оно само по себе, или является средством достижения другой цели?
👉Всегда ли вы занимаетесь разными делами вместо Х, или одним и тем же? Как они связаны?
👉В каком состоянии вы находитесь во время приступа прокрастинации? Типичное ли это состояние в момент принятия решения, что делать дальше?
👉Есть ли у вас состояние, в которгм нет приступов прокрастинации? Как вы его расходуете?
👉Какие аргументы в пользу дела У проскакивают в вашем уме во время прокрастинации?

Про парадокс инвестиций в 2026

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

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

👉Нет потери контекста при общении в команде, он весь содержится в голове у фаундера
👉Не приходится идти на компромиссы с другими людьми, пытаясь не задеть их самооценку, или из-за других политических причин
👉Нет организационной инерции, попыток переиспользовать старые решения и всего с этим связанного
👉Порядок цен, конечно, абсолютно другой – вместо $30k в месяц на зарплаты минимальному костяку команды, в самом отчаянном случае вы заплатите N*200$ за несколько подписок на Claude Code.

Начинайте митинги на пять минут позже

Редко кто заканчивает митинги на пять минут раньше обычного таймслота. Как результат, первые минуты следующего митинга несколько человек ждут, пока все добегут до нужной переговорки. Вместо этого попробуйте сделать простую вещь – назначайте все свои митинги на 5 минут позже обычного времени (12:05 вместо 12:00). Все участники точно скажут вам спасибо.

Почему не надо останавливать все плохие проекты

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

Еще один кусочек мудрости, который появляется вместе с чуйкой – это понимание, что не нужно идти воевать с каждой ветряной мельницей. Даже если вам очевидно, что какой-то проект обречен, не нужно пытаться его остановить. Почему так:

👉Компании в среднем ценят людей, которые пытаются что-то делать, а вот к тем, кто пытается замедлить работу, как раз относятся с подозрением. Если ваши сомнения не подкреплены ну очень сильными аргументами, их скорее всего пропустят мимо ушей.
👉Даже если у вас получится затормозить такой проект, кто-то может воспринять это как личное нападение – ведь из-за вас он не получит новую ачивку в портфолио или оценку на 0.1 балла выше на перфоманс ревью.
👉Если вас не послушали, но в итоге вы оказались правы и проект провалился, вас все равно не станут больше ценить как эксперта, потому что скорее всего вообще забудут этот разговор. А бегать и кричать "я же говорил" – вообще деструктивное поведение.

Вместо того, чтобы пытаться остановить все плохие идеи, относитесь к своему влиянию как к конечному ресурсу. Он пополняется, когда вы сами делаете что-то полезное – выпускаете успешный продукт, помогаете коллеге, исправляете проблемный процесс. А вот когда вы блокируете чью-то работу, вы это влияние тратите – совсем чуть-чуть, придираясь к необязательной проблеме на code review, и огромное количество, когда пытаетесь остановить очередную безумную фантазию CTO про AI. Так вот, если вы потратите все влияние на мелочи, то не сможете остановить действительно важные вещи.

Чтобы понять, на что действительно стоит тратить свой политический капитал, можно смотреть на три фактора:

1️⃣Насколько близко этот проект находится к вашей команде
2️⃣Если все пойдет по плохому сценарию, насколько сильно это повлияет на вашу команду
3️⃣Если все пойдет ну совсем плохо, как это повлияет на всю компанию

Короче говоря, pick your battles!

Стратегия — это ответ на один, но ключевой вопрос

Директор по продукту ВКонтакте Евгений Васильев про стратегию.

👉 Это рабочий инструмент, который собирается под решение конкретной рыночной задачи.
👉 Именно стратегия определяет, какая оргструктура вам нужна и на какие метрики работает команда.
👉Отсюда и простая логика: стратегия начинается не с идей и фичей, а с честного ответа на вопрос: какую бизнес-задачу мы решаем сейчас.
👉 Если стратегия не формулируется одним-двумя ясными предложениями, скорее всего, это еще не стратегия.
👉 В случае стратегии ВКонтакте - это перевод эпизодических пользователей в core-аудиторию за счет контентного и социального сценариев.

Как люди используют LLM на работе

Держите очень интересный эксперимент. В образовательную компанию на 500 человек внедряли AI. Вместо покупки подписок настроили агрегатор разных моделей с единым окном входа в них, а спустя полгода проанализировали запросы:

👉Всего AI хотя бы раз попробовало 80% сотрудников. При этом ретеншн очень высокий – 85%, кто попробовал, потом уже не бросает.
👉Если дать доступ ко всем моделям, то люди будут использовать самую дорогую для всего, даже для самых простых задач.
👉Две трети бюджета по итогам уходило на генерацию картинок. 74% сотрудников делали это хотя бы раз, даже бухгалтерия, которым, казалось бы, они не нужны.
👉20% пользователей сгенерировали 80% запросов, а топ-10 пользователей потратили 20% бюджета.
👉По сравнению со стоимость дефолтной подписки в 20$ в месяц, при работе через API вышли копейки – около 2.5$ на человека.

📊 Delivery Manager: станьте главным связующим звеном между бизнесом и разработкой!

Хотите выйти на новый уровень управления? Научитесь реалистично оценивать проекты, работать с метриками и эффективно управлять портфелем задач!

🔥 Приглашаем на 3 бесплатных вебинара курса «Delivery Manager» — познакомьтесь с программой обучения и преподавателями, задавайте вопросы и обсуждайте свои кейсы!

🔸 Вебинар 1: Почему ваши оценки проекта всегда ошибочны
📅 28 января, 20:00
Разберём, почему даже опытные менеджеры ошибаются в оценках — и как это исправить.
На вебинаре:
- поймёте, как особенности мышления влияют на планирование;
- сравните классический и Agile‑подходы к оценке;
- освоите инструменты: стори поинты, «майки», буферы рисков;
- проанализируете реальные кейсы и способы избежать срывов сроков.

🔸 Вебинар 2: Измеряя управляй. Метрики как инструмент DM
📅 5 февраля, 20:00
Узнайте, как превратить данные в систему принятия решений.
Что разберём:
- почему метрики — это не контроль, а управление доверием;
- как фреймворк PROJECT помогает говорить на одном языке с бизнесом, командой и заказчиком;
- пошаговую сборку системы контроля для устойчивости организации;
- типичные ловушки (гонка за показателями, «очковтирательство») и способы их обойти.

🔸 Вебинар 3: От проекта к портфелю: как управлять несколькими проектами?
📅 9 февраля, 20:00
Переходите на уровень Delivery Manager? Узнайте, какие инструменты и mindset вам нужны.
В программе:
- отличия управления портфелем от управления проектом;
- причины сложностей при переходе на новый уровень;
- почему привычные методы перестают работать;
- как сформировать новый набор инструментов DM.

Записывайтесь ➡️ OTUS.RU

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

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

Как поступить в этой ситуации разбираем вместе с тремя опытными менеджерами: Александром Орловым, Александром Поляковым и Игорем Цупко!

👉Весь кейс на канале "Тимлид не спит"
👉Разбор экспертов