Плохой менеджер Артём Арюткин

У вас в работе бывает режим «автопилота»? Ну то есть когда все задачи решаются по знакомому сценарию: тот же фреймворк, тот же подход, те же аргументы на встрече. И в целом все работает. Но иногда прилетает задача из серии «так, а это вообще как решать?» И тут внезапно обнаруживается интересная вещь: мозг начинает скрипеть как старая дверь. Потому что большую часть времени мы тренируем только харды: архитектуры, метрики, процессы, фреймворки. А вот мышцу нестандартного мышления — почти нет. Поэтому мне понравилась идея одного спецпроекта — OUT OF THE BOX от команды КРОК. Они собрали реальные нешаблонные кейсы из практики по разным направлениям. Смысл простой: чтобы их решить — придется реально вылезти из привычной коробки и посмотреть на задачу под другим углом. Причем там есть разные категории кейсов — можно выбрать что-то из своей области или наоборот пойти в противоположную сторону и проверить себя. За интересные решения, кстати, до 30 марта дают призы. Я вот думаю попробовать кейс из секции soft. Люблю такие задачи — они обычно ломают привычную логику сильнее всего. Если интересно — посмотреть кейсы можно тут

Давнееенько у нас не было обзоров книг. И тут недавно ребята из издательства Питер подогнали мне чудесную книгу по System Design «нового поколения», то есть GenAI. Книга - это попытка адаптировать классическое system design интервью под новую реальность GenAI: LLM-приложения, RAG-архитектуры, агенты, оценка качества и стоимость инференса. Полезно как структурированный чек-лист, но это скорее введение, чем глубокий инженерный разбор. Хотя как менеджер я обожаю эту серию книг, она позволяет погрузиться во множество разных тем. System Design для эпохи GenAI Все привыкли к классическим вопросам на system design интервью: - спроектируйте Twitter - спроектируйте YouTube - спроектируйте Uber Но последние пару лет компании начали задавать другой тип задач: спроектируйте AI-чат ассистента спроектируйте RAG-поиск по документам спроектируйте AI-копилота для разработчиков И вот тут многие кандидаты ломаются. Почему? Потому что классическая архитектура (API + база + кэш) внезапно превращается в: User → Gateway → Orchestrator → LLM → Retrieval → Vector DB → Tools → Evaluation И вот именно эту новую архитектуру книга и пытается разобрать. Основная идея книги Авторы говорят простую вещь: GenAI-системы - это не просто “вызов LLM API”. Это полноценная распределённая система. И в ней появляются новые архитектурные компоненты. Например. 1. Retrieval (RAG) LLM сам по себе туповат. Он знает интернет до даты обучения. Поэтому почти любая реальная система делает: Query → Embedding → Vector search → Context → LLM Книга разбирает: как хранить embeddings как масштабировать vector search как строить pipeline retrieval 2. Оркестрация моделей LLM редко работает один. Обычно это: Router → model A (cheap) → model B (smart) → tools Причина банальная. LLM дорогой. Поэтому архитектура всегда балансирует: качество vs стоимость vs latency 3. Оценка качества Самая сложная часть GenAI-систем. В классических сервисах есть метрики: latency error rate throughput А в LLM-системах появляется ад. Например: - hallucination rate - factual accuracy - grounding - response quality И это очень плохо измеряется. Книга показывает базовые подходы: LLM-as-judge human evaluation golden datasets 4. Стоимость GenAI архитектура - это экономика. Каждый запрос стоит денег. Поэтому появляются решения: кэширование ответов prompt compression routing моделей batching На интервью это любят спрашивать. Что в книге хорошо 1️⃣ Хорошая структура для интервью Если вам задают вопрос: Спроектируйте AI-ассистента книга дает простой фреймворк: User interaction Retrieval layer LLM orchestration Tools Evaluation Cost control Это полезно. 2️⃣ Понятный чек-лист архитектуры После книги начинаешь автоматически думать: где embeddings? где кэш? где evaluation? где rate limiting? 3️⃣ Актуальность Большинство книг по system design написаны до эпохи LLM. А здесь фокус именно на GenAI-архитектуре. Где книга слабая 1️⃣ Мало глубины. Например vector search объясняется очень поверхностно. Нет разбора: HNSW IVF ANN tradeoffs 2️⃣ Мало production-кейсов. Реальные системы: Copilot Perplexity ChatGPT имеют гораздо более сложные пайплайны. 3️⃣ Почти нет темы агентов А именно туда сейчас движется индустрия. Если раньше system design интервью проверяло: умеешь ли ты масштабировать сервис то теперь проверяют: умеешь ли ты проектировать AI-системы. И там появляются новые вопросы: как уменьшить hallucinations как контролировать стоимость токенов как строить RAG как оценивать качество И это новый слой архитектуры.

Менеджерские бои - практика переговоров на кейсах из ИТ • КРОК приглашает на бизнес-игру Менеджерские бои, где участники смогут прокачать свои переговорные и управленческие скилы, а также получить обратную связь от экспертов-практиков. • Будет полезно руководителям проектов, тимлидам технических и бизнес-команд • 26 марта, 18:30 (МСК) • Офлайн, офис КРОК Регистрация открыта, участие бесплатное, количество мест ограничено. Реклама. ЗАО "КРОК Инкорпорейтед". ИНН: 7701004101. Erid: 2W5zFK5qNmP

Первый магазин без продавцов появился в СССР Как вы помните в 2018 году Амазон с помпой запустил магазин без продавцов: заходи и бери. А затем с помпой мы узнали, что не было там никакого ИИ, а только много- много индусов… Однако еще в 1962 году в СССР в Москве был открыт магазин «Прогресс»: магазин полностью без людей. Офигеть? Не то слово. Отдельно мне очень нравится простота решения: по сути, стояли кастомизированные вендинговые аппараты, через которые реализовывалась продукция (молоко, хлеб, крупы и прочее). Никакого тебе ИИ, никакого тебе компьютерного зрения и вот этого вот всего. Чистая механика. В общем, сама эта история мне безумно нравится. В итоге, магазин не взлетел по нескольким причинам: 1. В маркетинг в те времена точно не умели. И о магазине газеты впервые написали через полгода после его запуска. Через полгода! Офигеть просто! 2. Вендоматы были уникальны, посетители их часто ломали и ремонт обходился дорого. Потому что для снижения костов требовалось масштабирование. 3. Ну и важная причина провала всех трансформаций - культура. Культура в те времена была такой, что продавец - важный элемент: он принимал решения кто и что получит и прочее. А раз нет продавца, то и масштабирование под вопросом.

Так много вопросов, так мало ответов… Учитывая, что подобные люди строят все свои процессы на попытках попасть в наиболее вероятные события + психология + эмпатия. То при наличии эмпатии я бы ставку делал на этот гибрид человека и ИИ 😬

Я не знал этого!!! Колитесь, кто как я? ❤️ - если не знал 😎 - если знал раньше 🦄 - впервые слышишь про инди-игры/музыку

2 недели с ридером Моя первая и последняя электронная книга была OnyxBook И она прожила со мной 10 и 11 классы, когда я гонял на электричке в школу в Москве. Читал я тогда невероятно много: садишься такой утром на электричку в 6:35 и в школе ты оказываешься в 8:30. Затем чтение было только с телефона, планшета или бумажные книги. И вот чуть больше 2-х недель назад мне достается новый OnyxBook. Короче, это кайф! 1. Вечером почитать - подсветочку мягкую включил, «теплый свет» установил и кайфуешь! 2. Книжку какую-то почитать захотел, ЛитРес или Я.Книги установил и все синхронизировалось со смартфоном. 3. Как синхронизировалось? Так ты к WiFi по красоте подключился и кайфуешь. 4. А еще глаза не устают и PDFки читать сплошное наслаждение. 5. Ну и отдельное удовольствие, что телефон у тебя где-то там сам лежит и ничто тебя СДВГШника этакого не отвлекает.

#пятничное Все мы немножко тигр…😁

Что такое Team Topologies и почему про это говорят все, кто строит платформы Если коротко: Team Topologies - это способ проектировать организацию так же осознанно, как мы проектируем архитектуру системы. Идея простая: оргструктура должна соответствовать потокам ценности. 1️⃣ Четыре типа команд 1. Stream-aligned team Команда, выровненная по потоку ценности (фича, продукт, сегмент клиентов). Это не «команда фронта» или «команда базы». Это команда, которая отвечает за ценность целиком. Главное: минимальные зависимости end-to-end ответственность быстрая доставка 👉 Это базовая ячейка организации. 2. Platform team Команда, создающая внутренний продукт для других команд. Не «саппорт». Не «инфраструктура ради инфраструктуры». А именно продуктовая платформа, которая снижает когнитивную нагрузку stream-aligned команд. Если платформа не упрощает жизнь - это фигово. 3. Enabling team Команда-ускоритель. Помогает другим командам освоить новую технологию, практику, подход. Не забирает ответственность, а прокачивает capability. Это временное взаимодействие, а не вечный костыль. Если вечный костыль - то ваши команды недостачно компетентны. 4. Complicated-subsystem team Команда для действительно сложной области (алгоритмы, ML, биллинг, компиляторы и т.д.). Создается тогда, когда сложность оправдана. Не когда «нам просто так удобнее». 2️⃣ Когнитивная нагрузка - главный враг Один из ключевых концептов Team Topologies - cognitive load. Каждая команда должна: понимать свой домен понимать систему понимать инструменты Если нагрузка превышает способность команды, то скорость падает, качество падает, люди выгорают. 👉 Задача орг.дизайна — ограничить когнитивную нагрузку. Именно поэтому: платформа скрывает сложность enabling команды помогают освоить новое, а сложные подсистемы изолируются 3️⃣ Типы взаимодействий между командами Team Topologies описывает 3 устойчивых режима взаимодействия: Collaboration Совместная работа для открытия нового. Временная. Такая проектная команда. X-as-a-Service Одна команда предоставляет сервис другой. Четкие API. Минимальные зависимости. Facilitating Помощь и прокачка capability. 👉 Важно: взаимодействие должно быть осознанным и выбранным, а не случайным. 4️⃣ Почему это важно? Платформа без продуктового мышления превращается в бюрократию. Stream-aligned команды без автономии превращаются в «ждунов инфраструктуры». Все начинают мешать всем и суть работы каждого менеджера сводится к тому, чтобы иметь побольше точке контроля для «метания всем». Team Topologies дает язык: чтобы обсуждать структуру чтобы снижать зависимость чтобы проектировать организацию под поток ценности 5️⃣ Главная мысль Вы не можете масштабировать delivery, если не проектируете команды так же тщательно, как проектируете микросервисы. Орг-структура - это архитектура. И она влияет на скорость сильнее, чем технологии. Если вы строите: продуктовую IT-организацию …и при этом не думаете про Team Topologies - вы почти гарантированно платите «налог на сложность». А как у вас там? 🦄 - ооо, все так и работает 😎 - ну мы где-то близко к этому ❤️ - пу-пу-пууу…стыдно признаться

Построение команд по модели TeamTopologies - это основной фреймворк в современной крупной организации. Почему вообще возникла Team Topologies Классическая проблема больших инженерных организаций: команды организованы по компонентам (backend team, frontend team, DB team, infra team) чтобы сделать одну фичу, нужно пройти через 5 команд результат: долгое time-to-market постоянные блокеры высокая когнитивная нагрузка Современный менеджмент утверждает, что нужно выделять платформенные команды/команды и это позволит убрать те самые узкие места, расписанные выше (и да, позволяет) уж я то про платформы знаю. Приносит ли новые задачи? Ну не без этого😁 И тут ребята из нашего PR сделали целый, блин, фильм о том, как развиваются повторы в Авито, откуда и как и почему они стали такими! Почему это важно? Я часто говорю, что все платформы проходят один жизненный цикл: нет ничего и любое улучшение радикальный буст, затем стагнация и замедление, все платформы обрастают огромным количеством фичей, затем падение и возвращение к истокам (делать меньше, но лучше). Короче, фильм по продакшену топ, ребята в кадре - топ, сама идея - огнище! Ютуб - https://youtu.be/WS27Nkx2lyU ВК - https://vkvideo.ru/video-152990965_456240085 РТ - https://rutube.ru/video/private/73a155b6d1b8cd54a5ebc000f3d3e8af

Инженеры Amazon разрешили AI-агенту изменить инфраструктуру — и получили outage AWS на 13 часов В декабре внутренний AI-агент Amazon под названием Kiro, который помогает инженерам писать и менять код, предложил удалить и заново создать часть системной среды, чтобы исправить проблему. Инженер разрешил ему выполнить это действие. В процессе что-то пошло не так — среда была удалена, и восстановление заняло около 13 часов. Всё это время часть сервисов AWS работала с перебоями. В Amazon заявили, что причина — человеческий фактор: инженер имел слишком широкие права доступа и позволил AI выполнить критическое изменение без дополнительного контроля. После инцидента компания усилила ограничения доступа и добавила дополнительные меры безопасности для работы с AI-инструментами. Это один из первых публичных случаев, когда AI-агент с production-доступом напрямую повлиял на стабильность облачной инфраструктуры. https://www.reuters.com/business/retail-consumer/amazons-cloud-unit-hit-by-least-two-outages-involving-ai-tools-ft-says-2026-02-20/

Ахахаххаха Считаю, что в условиях повсеместного вайбкодинга, эта шутка стала еще смешнее 😁 🔥 - если ты уже вайбколишь ❤️ - попробовал, но что-то не задалось 🦄 - даже не пробовал

Настоящее и будущее с исследователем из Стенфорда, изучившим работу 100 тыс. компаний. А вот и вышел в продакшен наш подкаст с Егором Денисовым-Бланшем. А началось все с того, что исследование Егора о том, что 10% инженеров ничего не делают на работе репостнул Илон Маск. Вот основные вехи, что я выделяю для себя в исследованиях Егора: 1. Как ребята из стенфорда оценили с помощью ML продуктивность разработки. 2. А потом с помощью этой же модели выяснили, что 10% инженеров или 1.8 млн. в мире не работают (100 тыс.инеженеров в 600 компаниях были изучены). 3. А потом про то, как и где лучше всего применить AI. Что говорит Егор в подкасте: 1. Если вы еще не используете AI - бегите! Если 6 месяцев назад он был не то, чтобы скептичен, но скорее предлагал искать правильные места для использования, то теперь вам пора бежать. 2. Все, кто считает, что продуктивность разработчика нельзя померить чаще всего оказываются самыми слабыми компаниями в части реальных результатов. При этом, и те, кто обвешали каждый чих метриками- не топ перформеры. Ключевая задача менеджмента найти правильный баланс. 3. Каждые 6 месяцев AI будет забирать некий кусок вашей работы. И всем нам придется научиться с этим жить. Получился невероятно кайфовый разговор! 📺 YouTube 🔵 VK 🗂 Rutube

Мечтаете не исправлять, а проектировать? Пройдите три ключевые точки роста за три бесплатных вебинара от экспертов курса «DevOps Lead». 🛡 1. Как работать с сопротивлением (Анатолий Бурнашев, SRE expert) Внедряете Kubernetes, а команда в ужасе? Узнайте, как менять процессы без войны и превращать саботаж в поддержку: регистрация ⚡️ 2. Командные конфликты – кто виноват и что делать? (Анатолий Бурнашев) Конфликт Dev vs Ops — это фича, а не баг. Научитесь управлять разногласиями, чтобы они делали команду сильнее, а не разрывали её: регистрация 🧠 3. Джедай или Ситх? Собираем идеального DevOps Team Lead (Михаил Чугунов, Lead DevOps Engineer) Senior DevOps, но команда вас не слышит? Узнайте, как прокачать себя как лидера, где Hard Skills ≠ Leadership: регистрация ⏰Готовьте свои сложные вопросы спикерам и приходите за реальными ответами. Регистрируйтесь на все три вебинара прямо сейчас — мы напомним о каждом накануне! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Ой че завтра будет 😉 А пока пробегитесь по статьям

Мечтаете не исправлять, а проектировать? Пройдите три ключевые точки роста за три бесплатных вебинара от экспертов курса «DevOps Lead». 🛡 1. Как работать с сопротивлением (Анатолий Бурнашев, SRE expert) Внедряете Kubernetes, а команда в ужасе? Узнайте, как менять процессы без войны и превращать саботаж в поддержку: регистрация ⚡️ 2. Командные конфликты – кто виноват и что делать? (Анатолий Бурнашев) Конфликт Dev vs Ops — это фича, а не баг. Научитесь управлять разногласиями, чтобы они делали команду сильнее, а не разрывали её: регистрация 🧠 3. Джедай или Ситх? Собираем идеального DevOps Team Lead (Михаил Чугунов, Lead DevOps Engineer) Senior DevOps, но команда вас не слышит? Узнайте, как прокачать себя как лидера, где Hard Skills ≠ Leadership: регистрация ⏰Готовьте свои сложные вопросы спикерам и приходите за реальными ответами. Регистрируйтесь на все три вебинара прямо сейчас — мы напомним о каждом накануне! Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

5 развилок Адди Османи о будущем разработки Addy Osmani - Google: много лет отвечал за Developer Experience в Chrome, а сейчас - Director в Google Cloud AI (Gemini/Vertex/Agent Development Kit). Короче, это не “инфоцыган”, а норм чел, который годами смотрел на разработчиков в масштабе и на то, как меняются инструменты и привычки. Статья - это 5 вопросов с двумя контрастными сценариями, чтобы подготовиться к обеим реальностям.

Опубликовано 5 января 2026.

1) Вопрос про джунов: “их правда больше не надо?” Сценарий А (пессимистичный): джун-хайринг схлопывается.

Логика простая: AI закрывает “простые” задачи, а бизнес в режиме эффективности предпочитает “1 сеньор + агенты” вместо “команда + джуны”. Итог: воронка роста ломается, а через 5–10 лет вылезает дефицит будущих сеньоров/лидов.

Сценарий Б (оптимистичный): Джуны возвращаются, но в другом виде. Софт расползается по индустриям (не только IT-компании), и появляются AI-native роли: люди, которые быстро собирают автоматизации/интеграции в конкретных доменах (медицина, производство, финансы). Что это значит: Джун - это не “зеленый инженер”, а “джун, который с AI делает как мини-команда”.

А еще он имеет: Портфолио с реальными штуками (интеграции, пайплайны, автоматизации, AI API) Умение объяснить и защитить результат, а не “мне модель нагенерила”

2) Вопрос про навыки: “мы все разучимся кодить?” Сценарий А: деградация основы. AI пишет, человек собирает. Дебаг, алгоритмы, сложность - “зачем, если есть агент?”. Потом прилетает прод-инцидент, и выясняется, что никто не понимает, что именно работает и почему. Сценарий Б: фундамент снова становится суперсилой. Если у всех есть AI, то отличает не скорость набора текста, а способность: распознать ошибку/уязвимость/неверную модель данных сделать архитектурный выбор обеспечить надежность, безопасность Практический вывод: “Промптить” станет базовым навыком, но верифицировать - станет профессией. И это прям рынок. Такой некий консалтинг для моделей. 3) Вопрос про роль инженера: “мы станем уборщиками за AI?” Сценарий А: developer → аудитор/бэбиситтер.

Ты не строишь - ты проверяешь. Меньше творчества, больше “принять PR от агента”, “прогнать пайплайн”, “не дай бог утечка/уязвимость”.

Сценарий Б: developer → оркестратор. Инженер становится “генподрядчиком”: формулирует намерение и ограничения проектирует интерфейсы распределяет работу между агентами/сервисами держит качество, этику, безопасность, ответственность 4) Специалист vs дженералист: “узкая экспертиза - это смерть?” Сценарий А: узких специалистов автоматизируют / вымывает спрос. Ставка на один стек/фреймворк становится опаснее: AI снижает ценность “рутинной глубины” там, где много шаблонов. Сценарий Б: T-shaped - новая норма. Широкая база + 1–2 сильные вертикали. Такие люди — “клей” команды: закрывают стыки, ускоряют end-to-end.

Вывод:

AI усиливает тех, кто умеет

переключаться между доменами

, а не тех, кто “20 лет крутил 1 гайку”.

5) Вопрос про образование: “диплом ещё что-то решает?” Сценарий А: университет остаётся стандартом, но всё больше отстаёт. Долгие циклы обновления программ → выпускники добирают практику сами (курсы/проекты/стажировки). Сценарий Б: модульное обучение вытесняет ‘4 года ради корочки’. Буткемпы, сертификации, портфолио, корпоративные академии, AI-тьюторы. Навык-фёрст вместо диплом -фёрст.

Тайский бокс, конечно, все one love! Борьба прямо клево, но тут) Демыч сказал, фигня и борьба круче. А как вы относитесь к таким штукам? ❤️ - если кайф и сам занимаешься 😬 - если считаешь, что от таких штук надо держаться подальше 🦄 - чем бы дитя ни тешилось)

Что будет, если в 39 лет вылететь из айтишной позолоченой клетки? Честно говоря, я Антону всегда говорю, что считаю его поступок слегка безумным. Лично я бы точно не решился. Причем не с простого карьерно паровозика спрыгнул, а там: бигтех, должность хорошая, продукт растущий. Антон короче спрыгнул год назад, чтобы делать свои проекты и развивать телеграм-каналы. Отказался от всех артефактов стабильности и успеха: зарплата, ДМС и главное — от бесконечного запаса глазированных сырков на офисной кухне. Но остались обязательства: содержать семью, кредит на другой бизнес и долг по ипотеке на 16 млн₽. А чтобы сильно не расслабляться, на половину финансовой подушки купил машину. Как сам говорит, ушёл, чтобы повзрослеть: можно быть бесконечно крутым элементом выстроенной структуры, но на что ты способен без специального человечка под каждую задачку? Интерес оказался сильнее страха. В своём канале Антон рассказывает про жизнь начинающего предпринимателя во всех аспектах: • Почему мы бежим из айтишки? • Работай с тем, что есть: как не проваливаться, когда над тобой не стоит начальник • Сотрудник рывкового типа или тупо прокрастинатор? • Обратная сторона предпринимательского майдсета • Первые финансовые успехи (спойлер — рано радовался) А ещё Антон честно пишет про работу с психотерапевтом, делает разборы популярных продуктов, рассказывает про бэкстейдж корпоративной карьеры и обучение на роль СЕО. Аутентичный контент, интересно наблюдать: @undisrupt