Posts

Окно источников: 10 августа 2026, 08:00 — 17 августа 2026, 08:00, Asia/Yekaterinburg. Всем привет. С вами Human Loop Weekly — еженедельный разбор того, как AI меняет инженерный менеджмент. Я читаю десятки рассылок и проверяю сильные тезисы исследованиями и первоисточниками. В этом выпуске — путь задачи после локального ускорения: где возникает ожидание, как увидеть очередь и какие проверки помогают выпускать изменения без лотереи. В материалах этой недели повторяется один мотив. AI может за минуты подготовить черновик решения, кода или тестов. После этого возникает более практичный вопрос: когда изменение дойдёт до пользователя и что потребуется команде, чтобы выпустить его уверенно? ...

Неделя 3–9 августа 2026 Всем привет. С вами Human Loop Weekly — еженедельный дайджест о том, как AI меняет менеджмент в инженерных командах: структуры, стоимость, процессы, метрики. Я подписан на десятки рассылок и исследую свежие данные каждую неделю, чтобы приносить вам самое важное про AI в инженерке и менеджменте — без воды и хайпа. В этом выпуске: почему 84% разработчиков используют или планируют использовать AI, а доверяют его точности лишь 29%; как команды из 8 человек превращаются в команды по 3–5 сеньоров с агентами; где спрятан реальный ROI (~10%, не 3×); и почему ревью кода стало дороже самого кода — и что с этим делать. ...

Когда IT-команда сопротивляется AI, причина редко только в головах людей. Чаще это сигнал о слабом месте в системе работы: размытая цель, тревога за роль, слабый инструмент, неудобный официальный путь, неясная ответственность или очередь, которая переехала в ревью, QA, релиз и проверку бизнес-результата. На митапе я собрал эту логику в практический разбор для руководителей инженерных команд, технических руководителей, лидов доставки, лидеров изменений и руководителей AI-трансформации. ...

Мы прошли путь от первых пользователей LLM-инструментов до массового использования чатов и кодинг-агентов. На дашбордах всё выглядело правильно: люди заходили, пробовали, возвращались, приносили примеры, показывали демо, техлиды учили команды. Метрики потока при этом долго не двигались. Lead Time не снижался системно. Throughput не рос так, чтобы это было видно на уровне инженерной организации. Defect Rate не давал уверенного сигнала, что качество стало лучше. Эта статья — большая версия двух моих постов на Habr: части 1 про рост использования и метрики результата и части 2 про Agentic Engineering и AI-first команды. Здесь я собираю логику целиком: от первых LLM-чатов до следующего слоя измерения, который оказался важнее обычного дашборда внедрения. ...

Agentic Engineering не начинается с оргчарта. Он начинается с момента, когда команда видит полный путь задачи и умеет безопасно отдавать часть работы агентам. Красивая картинка AI-native команды — 2–3 человека, E2E-ответственность, агенты в инженерном процессе, быстрый путь от идеи до продакшена. В большой организации эта картинка сразу встречает годовые цели, бюджеты, стратегические проекты, регуляторные контуры и уже собранные команды. В этой статье — три безопасных маршрута, которые можно запускать внутри текущей структуры: агентизировать нудный run-процесс, выделить 2–3 агентных практиков или собрать микро-юниты внутри команды. ...

Баги — неизбежная часть разработки. В MetaMap мы внедрили Zero Bug Policy и за месяц сократили бэклог с 77 до 18 багов. 60 багов из 77 до старта не имели даже примерной даты исправления. Через месяц таких осталось 11. Главный результат — не красивая цифра. Support и CSM получили реальные сроки для клиентов, разработчики — ясные правила, клиенты — предсказуемость. Проблема: баги по принципу «кто громче» ...

TL;DR: эффективная команда делает три вещи: Достигает бизнес-целей Сохраняет психологическую безопасность и мотивацию людей Предсказуемо доводит работу до результата через стабильные flow-метрики Три вершины. Один треугольник. Исходная история Две финтех-команды три месяца параллельно строили системы управления лимитами. Одна — для кредитных карт, другая — для текущих счетов. В каждой команде 7–8 человек, стоимость — около $100K в месяц с учётом полной нагрузки на инженерную команду. На квартальном ревью выяснилось: 70% функциональности пересекается. ...

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

Прогнозировать сроки по Throughput проще, чем кажется. Нужна история завершённых элементов, понятные WIP-лимиты и честное отношение к вероятности. Хороший прогноз звучит так: «с вероятностью 50% закончим за 39 дней, с вероятностью 85% — за 50 дней». Это честнее для команды и полезнее для стейкхолдеров, чем дата «ровно через 6 недель». Это продолжение статьи про Throughput как метрику потока. База по метрике остаётся в первой части. Здесь — как превратить историю завершённых элементов в прогноз, вокруг которого можно принимать решения. ...

Русская версия подготовлена на основе моей статьи на Хабре: «Throughput: как научиться перестать гадать сроки и начать их предсказывать через симуляцию Monte-Carlo». Throughput — базовая метрика, с которой начинается разговор о предсказуемости команды. Сначала нужно научиться читать сам поток: по периодам, вариативности и типам работы. Прогнозирование через Monte Carlo — следующий шаг, которому посвящена отдельная статья. Преамбула Заходишь убитый в пятницу в бар. Заказываешь пивной сет. Официант обдумывает в голове: “За последний час у нас было приготовлено 12 заказов, сейчас в работе 4 заказа, новый сет будет пятый в очереди”, а потом информирует нас: “Ваш заказ подадут через 20–25 минут.” ...