Как умирают опенсорсные проекты

Мы в работе очень сильно полагаемся на существующие опенсорсные проекты. Как показывает невероятно выросшее в последний год количество supply chain атак, полагаемся даже слишком сильно.

В статье – полезная классификация ситуаций, которые могут привести к смерти опенсорса, на который вы положились. Вот некоторые из них:

👉Корпоративный сирота. Компания решила заопенсорсить какие-то внутренние наработки, а затем ответственный за них человек уволился или был переключен на другие задачи. README никто не обновил, проект остался существовать, но в компании про него никто никогда не вспомнит.
👉Ментейнера наняли. Проект был создан человеком в свое свободное время. Потом его наняли в компанию, условия контракта с которой не позволяют ему продолжить поддерживать проект.
👉Дедлок наследования. Основной ментейнер проекта куда-то исчез вместе со всеми правами на публикацию новых версий. Остальные ментейнеры были быи рады подхватить флаг, но экосистема либо не позволяет передать права на пакет без ведома его создателя, либо это слишком сложный процесс, в который никто не готов вписаться.
👉Ментейнер выгорел. Он все еще принимает простые правки, не требующие когнитивного ресурса, но любые серьезные изменения зависают навсегда. При этом, чем больше его пушат, тем меньше вероятность того, что что-то случится.
👉Знание о проекте ушло. Создатель проекта передал права, а новые ментейнеры не очень хорошо понимают, как он устроен под капотом. В результате он неявно переходит в ридонли режим, с только косметическими правками.
👉Протест. Владелец проекта в знак протеста с политической или социальной проблемой ломает свой проект так, что он перестает работать либо для всех, либо для какой-то части людей.
👉Теневая разработка. В опенсорсе находится только зеркало, а настоящая разработка идет в приватном корпоративном репозитории, который когда-то просто забудут продолжить подливать.
👉Не подлежащий релизу мастер. Разработка проекта ушла слишком далеко с момента последнего релиза, он гарантированно сломает обратную совместимость всем и везде, и никто за такое не хочет брать ответственность.
👉Транзитивная смерть. Умерла какая-то важная зависимость проекта, и аналога нет или переезд слишком сложный.

Идеи, законы и концепции

Хорошая библиотека кроссдисциплинарных идей вокруг принятия решений, продуктового менеджмента, менеджмента знаний, психологии и технологий.

Библиотека прямо хорошо прокурирована, мне очень зашли некоторые заметки.

Про то, как подход к измерению чего-то определяет само пространство возможностей

Physicist Arthur Eddington illustrated this with a story about fishermen who caught fish using a net with specific-sized holes. After examining their catch, they concluded there was a minimum size to fish in the sea—never considering that smaller fish simply slipped through their net undetected.
...
Our tools of measurement don't just quantify the world—they determine which aspects of it become visible to us in the first place.

Иерархия фактов

Henri Poincaré, the renowned mathematician, observed that not all facts are created equal. The most valuable ones, he noted, are those that reappear frequently—the simple facts that serve as building blocks across multiple scenarios.
...
first we establish rules by studying similarities, then we advance knowledge by investigating exceptions.

Simpson's Paradox

We're familiar with how combining data can obscure details, but less aware of how it can create entirely new—and false—effects. This statistical sleight of hand, exemplified by Simpson's paradox, occurs when individual data sets clearly favor one conclusion, yet when combined, mysteriously support the opposite. Statistician Edward Simpson documented how subsamples might consistently show A outperforming B, while the amalgamated data inexplicably shows B superior to A. The danger is that these artificial patterns can lead to false accusations or misguided decisions based on what appears to be solid evidence.

Мы креативнее, когда ходим, а не сидим

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

Так вот, в зависимости от конкретного дизайна эксперимента, от 80 до 100% участников креативили гораздо лучше, когда двигались, а не сидели на месте. Заодно проверили, что именно дает эффект – сам факт ходьбы, или прогулка на открытом воздухе. По результатам, как будто бы находиться на улице не очень важно – так что распаковываем ваши беговые дорожки, купленные во время ковида, и спрятанные куда-то под диван!

Используем AI, чтобы писать код медленнее

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

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

Автор статьи предлагает простой скилл, который как раз отделяет важные находки от неважных. Попробуйте, может и вам поможет замедлиться!

Run a Claude sub-agent, Codex, and Cursor Bugbot to find bugs in this PR ranked by critical/high/medium/low. Once they’re all done, review their findings, do your own research to rule out false positives, and write a final report.

Как не сломаться в плохих рабочих условиях

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

Держите пачку советов, которые помогут продержаться:

👉Задайте рамку рабочего дня до того, как он начался. Мозг постоянно прогнозирует, что будет происходить дальше. Если предвкушать стресс, несправедливость и усталость, вам будет намного тяжелее. Если выбрать своей целью что-то понятное и достижимое, вроде "сегодня я остаюсь спокойным, даже когда вокруг будет хаос и анархия", то вы смещаете результат в зону вашего контроля, и в итоге морально и физически будет проще.
👉Следите за физическим состоянием, особенно утром. Первый час после пробуждения очень сильно влияет на настроение на весь день. Классический набор советов от Хубермана и других – побыть на естественном свету, подвигаться, попить воды, и ни в коем случае не открывать рабочие чаты и другие источники стресса.
👉Поддерживайте свою систему стандартов, даже если у системы ее нет. Если вы недовольны качеством работы компании, то со временем это недовольство вы распространите и на себя как на ее часть. Выход – отделить свою работу от общего, задать свои стандарты качества и не нарушать их. Это поможет поддерживать самоуважение.
👉Защищайте эмоциональные границы. Не давайте работе настигать вас за ее пределами. Удалите мессенджер с телефона, отключите почту, не давайте никому свой личный номер. Старайтесь отделять рабочие проблемы и неудачи от своей самооценки.
👉Помните, что плохо будет не всегда. Вы должны верить, что лучшее будущее возможно, и что к нему можно найти путь, пусть даже он лежит через увольнение и стресс поиска новой работы.

Как мы допускаем ошибки в пермишнах для агента

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

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

Метод критической цепи в проектном менеджменте

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

Чтобы метод работал, нужно следовать двум правилам:

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

Не весь фидбэк нужно принимать

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

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

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

Другие способы замедлиться при работе с AI

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

👉Написать первую версию кода самому, потом запустить агентское ревью, и вручную пройтись по комментариям.
👉Спрашивать у агента объяснение непонятных кусков кода, и просить поднять релевантные PR и доки.
👉Использовать агента, чтобы сравнить два возможных подхода к решению задачи.
👉Начинать использовать агента только после того, как сам потратил на задачу хотя бы 20 минут.

«Как с помощью self-компетенций укрепить лидерство в 2026 году». Вебинар Яндекс Практикума и Авито Работы

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

На вебинаре 17 июня HR-эксперт расскажет, как построить личную систему устойчивости в условиях турбулентности.

💬 О чём поговорим:

— Что такое self-компетенции и зачем они нужны.
— Какие self-компетенции реально работают в 2026-м.
— Как self-компетенции руководителя влияют на карьеру руководителя и бизнес-показатели.
— Как руководители Авито Работы развивают self-компетенции (конкретные инструменты и кейсы).

👩‍🏫 Спикер: Ольга Полякова, бизнес-партнёр по персоналу в Авито Работе.

🕚 Начало: 17 июня в 11:00 мск.

→ Зарегистрироваться

Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqxFarW4

Почему корпоративный AI бот не должен отвечать в личке

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

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

👉Любой диалог с агентом можно найти в поиске
👉Люди смотрят, как другие работают с агентом, и учатся тому, как это делать
👉Смотря на примеры других, можно придумать свои собственные новые кейсы использования бота
👉В публичный тред легко призвать коллегу, который может помочь с советом, контекстом или ревью кода

Как работать вместе AI скептикам и оптимистам

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

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

Чтобы починить этот разрыв, надо следовать двум правилам:

👉Всегда рассказывайте про обе стороны медали. Хвалиться победами можно, но при этом нужно честно говорить об их цене, и текущей, и будущей.
👉Относитесь к внедрению AI как к инженерной задаче, а не идеологическому спору. Нужно не пытаться доказать друг другу, насколько AI способен выполнять задачи программистов, а сводить разговор в практическое русло – что конкретно нужно поменять в процессах и инфраструктуре, чтобы релизить сгенерированный код было безопаснее, а последствия были меньше?

Как строить свою карьеру

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

При этом с реальным удовлетворением от работы ни оди из этих факторов не имеет ничего общего. На самом деле влияют такие вещи, как ощущение собственной компетентности, чувство потока в работе, фит в культуру и команду, work/life balance.

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

Важно ли еще доменная экспертиза

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

Автор статьи рассказывает про свою экзистенциальную тревогу – последний год он наблюдал за тем, как его доменные знания перестают быть действительно важными, и он превращается в оператора агентов, которым может выступить вообще любой другой программист без глубокого знания финтеха:

👉Сначала размылась ценность доменных знаний при написании дизайн-доков и проектировании архитектуры. LLM уже довольно давно предлагала достаточно неплохие спецификации.
👉Затем размылась ценность навыков дебага распределенных систем. Агенты сейчас быстро разбирают такие баги, на которые раньше человек мог легко всадить день или два жизни.
👉Понимание архитектуры и качественного кода постепенно становится менее важным – по крайней мере доплачивать за это особо никто не готов, за качество кодовой базы тоже уже мало кто бьется, good enough is enough.

Давайте рассказывайте, что вы думаете про ценность доменных знаний? Достаточно ли нам всем быть генералистами, которых в любой момент могут заменить на другие шестеренки?

Как могут выглядеть интервью будущего

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

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

Вот вам байка из статьи, чтобы задать настроение:

At Google, rather than putting a little black desk on every interview loop, they just assumed all the interviewers had their heads up their arses (an evidence-based assumption), and they formed a committee at each site called Hiring Committee (HC). This committee acted as the final arbiter and gatekeeper on all hiring for the site.
...
Our HC group at the time was roughly fifteen strong, and included many local powerhouse Googler colleagues, including co-inventors of huge technologies, authors of interviewing book series, and people who are now very senior leaders.
We felt like we knew our shit.
One day, the recruiters gave us a special round of packets to review. In these special packets, we were able to read the interviewer notes and candidate responses. All personal details were stripped out, and we were told it was a “calibration exercise.”
...
Our group did our job, and voted not to hire about 2/3 of the packets. This was about par for the course.
But surprise surprise, this time, those were our own packets from when we had all interviewed at Google. The recruiters had tricked us into reviewing our own interview packets, and we had voted not to hire most of our own group.

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

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

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

Просишь человеческого внимания – вложи человеческий труд

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

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

Аналогично работает и в обратную сторону – не принимайте работу, в которой не видно человеческого труда, и не тратьте на ее чтение своего времени.

Готовьте развитие команды летом: в июне все курсы Яндекс Практикума доступны по старым ценам и со скидкой 15%

Хотите, чтобы команда достигала лучших результатов? В Практикуме ваши сотрудники освоят ИИ на уровне профи, повысят квалификацию и нарастят эффективность.

🎁 Выберите обучение до 30 июня и получите курс «Мастерство убеждения в рабочих коммуникациях» бесплатно.

Оставить заявку и забрать бонусы

Акция действует только для новых клиентов при оплате от юрлица. Цены вырастут 1.07.26*.

🏆 Яндекс Практикум — выбор компаний № 1, по данным Исследования предпочтений HR-менеджеров в сфере корпоративного обучения Hints, июнь 2025
*Цены вырастут на отдельные курсы. Проверьте стоимость на странице интересующего курса

Реклама, ООО Яндекс, ИНН 7736207543, erid: 2VtzqwBWfxm

Как создать в компании клуб дебатов

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

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

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

Какие вопросы задать про будущую команду на интервью

Держите несколько вопросов в копилку того, что вы и так спрашиваете:

👉Расскажите про последний случай, когда в команде кого-то запромоутили? Как это произошло, как долго человек работал в компании?
👉Какой самый долгий срок кто-либо проработал на этой должности, и чем он занимается сейчас?
👉В чем самая главная слабость команды?
👉Как команда действует, когда несогласна с решением сверху?
👉Какой план по хедкаунту на следующие 12 месяцев?
👉С кем мне предстоит больше всего работать вместе, и могу ли я с ним поговорить?
👉Как выглядят успех и провал на этой роли через полгода?
👉Когда и из-за чего был последний реорг?
👉Почему вы открыли эту роль?

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

Что поменялось в управлении разработкой

Я очень люблю статьи и книги Уилла Ларсона, поэтому к его урокам и мнению рекомендую прислушиваться.

👉Любые миграции, даже самые большие, теперь могут быть выполнены одним человеком, а не командой – причем за 10% времени. При этом цена ошибки выросла еще сильнее.
👉Качество кода больше всего зависит от харнесса – тестов, быстрого и надежного CI, удобного окружения для валидации и превью изменений. Иначе говоря, все то, что помогало ускорить разработку пять лет назад, помогает и сейчас.
👉Оптимизируйте через агентов самые частые и типовые куски процессов. Например, имеет смысл все кодревью в первую очередь пропускать через агента – ошибки допускают и люди, и машины, но хорошая модель скорее всего найдет больше проблем, чем уставший от ревью человек. При этом эдж кейсы, вроде ревью критических частей системы, имеет смысл оставлять на людях.
👉Сыгранные команды, глубоко погруженные в контекст, стали еще важнее. Пилить фичи стало дешевле, поэтому гораздо важнее понимать, какие из них действительно нужны.
👉Чтобы получить пользу от адопшна AI, нужно уметь принимать быстрые, качественные и долгоживущие решения. Если вот этот механизм не работает, то ускорившийся экзекьюшн приведет вас совсем не туда, где хотелось бы оказаться.

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