Поступить в вуз мечты и не платить за учёбу? Это реально!

Центральный университет — российский вуз нового типа, внедряющий STEM-подход в высшее образование. Университет создан в партнерстве с более чем 70 крупнейшими компаниями и организациями: Сбер, Авито, VK, Яндекс, Т-Банк и другие.

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

А еще каждый студент может получить грант до 100% на весь срок обучения.

Хочешь узнать подробнее? Приходи на МЕГАДОД 2026!

24 мая, с 12:00 до 15:30.
Очно в кампусе Центрального университета (Москва, м. Маяковская).

На мероприятии ты:
• узнаешь про программы бакалавриата и магистратуры, процесс обучения и карьерные перспективы;
• услышишь выступления академических руководителей и преподавателей;
• узнаешь про новые программы 2026;
 • увидишь кампус изнутри, пообщаешься со студентами, посетишь мастер-классы и интерактивные станции.

Не упусти возможность учиться в одном из лучших вузов сферы! 

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

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

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

Так вот, трое очень классных менеджеров, которых я часто цитирую в этом канале и чьими подкастами делюсь, организовали закрытое сообщество для руководителей Management Hub – и своей целью они видят именно помочь справиться вот с этим одиночеством. Это Евгений Антонов из Яндекса, автор канала "Тимлид Очевидность", Виктор Корейша из Ozon и Ольга Елисеева из Инфосистемы Джет.

Как работает сообщество:

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

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

🔗Ссылка на сообщество

Почему использование AI в разработке ведет к выгоранию

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

С этим выгоранием можно попробовать бороться. Часть советов – на картинке, а все детали – в статье.

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

Мы в работе очень сильно полагаемся на существующие опенсорсные проекты. Как показывает невероятно выросшее в последний год количество 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 кому-то, то либо предложите этому человеку самому спросить своего агента, либо добавьте сюда немного вашего труда – вычитайте ответ, уберите то, во что не верите сами, и обязательно сделайте явным, где здесь именно ваше мнение.

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