Управление разработкой *

В боевых искусствах есть понятие боевой добродетели У-Дэ. 

武德 (У-Дэ) — два иероглифа: 武 (у) — боевой, воинский; 德 (дэ) — мораль, добродетель. Буквально: воинская добродетель.

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

У-Дэ опирается на конфуцианский фундамент, ядро которого — пять добродетелей:
仁 (жэнь) — человечность,
义 (и) — справедливость,
礼 (ли) — благопристойность,
智 (чжи) — мудрость,
信 (синь) — честность.

Добродетели определяют не только то, как ученик дерется, но и то, как он живет и взаимодействует с людьми. 

У боевого мастера есть готовый кодекс, который он впитывает. У руководителя такого нет, но есть управленческая традиция — книги, наставники, ошибки. За 7 лет руководства у меня сформировались свои принципы работы. Они зрели годами — через опыт и через ситуации, в которых приходилось принимать сложные решения. Сейчас я в той точке, когда захотелось их зафиксировать, а не держать в голове. Зачем? Чтобы видеть самой и показывать лидам. Передача культуры руководителя так же важна, как и передача мастерства в боевых искусствах. 

Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что‑то продать. Особенно если «волшебство» сводится к установке плагина в IDE.

Меня зовут Алиса Герасимова, я руковожу отделом функционального тестирования в центре разработки и машинного обучения «Инфосистемы Джет». В статье расскажу, как ИИ ускорил одну из наших команд разработки, но с цифрами из реального мира. Поговорим про метрики, разграничение ролей между человеком и ИИ, а также честно покажем, где машина больше мешает.

Статья будет полезна тимлидам, скрам‑мастерам и всем, кто устал от маркетинговых метрик без контекста.

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

Фраза «нам надо поговорить» и в жизни редко предвещает что‑то приятное. А на работе — чаще всего значит «сейчас тебя покритикуют, соберись».

Руководители используют обратную связь как инструмент давления. Или наоборот — смягчают до бессмысленности. Некоторые считают, что обратная связь вообще не нужна: «взрослые люди сами поймут».

Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)

В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе. Пишем руками, нудное это дело если честно, все равно вычитку в агента отдал в итоге.

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

Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.

Привет, Хабр. Меня зовут Кирилл Комиссаров, я работаю в IT с 2013 года, последние несколько лет — тимлидом. Сейчас руковожу командой разработки в юните саппорта в Авито.

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

Я не психолог. Я тимлид, который много лет наблюдает, как одни и те же сценарии повторяются в код‑ревью, на дейли, в разговорах об увольнении и в офферах. Эта статья — о том, что я заметил, через какие штуки прошёл сам и что в итоге начало работать.

Как AI меняют карьерный лифт в разработке: почему проблема не в исчезновении сеньоров, а в том, что рынок всё хуже выращивает новых инженеров. Разбираем автоматизацию нижнего слоя задач, AI‑потолок джунов, контур ответственности и риск разрыва воспроизводства специалистов.

Вы прочитали гайд по Cursor, посмотрели демку Claude Code, посчитали в голове экономику и решили: пора. Спускаете в команду указание — попробовать на следующей итерации. Через две недели смотрите на цифры и видите, что lead time не сократился, а вырос. Полетели странные инциденты в трекер. Двое лучших разработчиков ходят с лицами «я же говорил». На ретро звучит сдержанное «нам нужно больше времени, чтобы оценить эффект». На самом деле это значит «уберите эту штуку».

Знакомо? Это типичная картина внедрения ИИ в инженерной команде через администрирование. Проблема не в инструменте, не в моделях и не в скептиках. Проблема в том, что push‑модель (принуждение) внедрения системно не работает с разработчиками высоких грейдов — и чем сильнее ваша команда, тем хуже она работает.

В этом гайде — модель вовлечения без революций (далее pull‑модель). Что нужно построить, чтобы синьоры сами выбрали работать с агентом, а через три месяца стали евангелистами. Это не про мотивационные речи и не про премии за процент кода от ИИ. Это про инженерное решение: workflow, инфраструктура и фазы развёртывания, которые проходят фильтр опытного разработчика.

Пока команда одна — всё логично: бэклог, доска, понятный поток. Но когда команд становится пятнадцать и все работают над одним продуктом — Jira начинает вести себя странно. Product Owner открывает утро с обхода четырёх проектов, задачи дублируются, а зависимости живут в комментариях. Разбираемся, почему это не про «плохую Jira», а про конфликт моделей.

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

OpenAI выкатил гайд по промтингу GPT-5.5. Главный тезис: длинные простыни инструкций с ALWAYS/NEVER/MUST не помогают модели — они мешают. Чем подробнее зажимаешь процесс, тем хуже результат. Я полез проверять. Открыл свой рабочий скилл — process-logs, обработка логов ошибок, версия 1.9.0, продакшн. 663 строки, 36 капс-блоков: «CRITICAL REQUIREMENTS», «YOU MUST FOLLOW THESE RULES. NO EXCEPTIONS». Каждый раздел начинается с MANDATORY. Перечитал по новым правилам OpenAI и нашёл четыре проблемы в одной секции из 134 слов: дублирующиеся императивы на одну мысль, judgment-call под видом invariant, нет stopping condition. Переписал — стало 50 слов. На Opus 4.7 и GPT-5.5 короткий вариант даёт лучший фикс на одной и той же ошибке из логов. В статье: разбор 5 ключевых тезисов гайда с прямыми цитатами, диф «до/после» на реальном продакшн-скилле, эксперимент в Google Stitch, который можно повторить за 5 минут, и сверка с тем, что говорит Anthropic про Claude.

29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».

Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.

Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.

Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.

Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.

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

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

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

Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как Project Manager стриминга кино viju.ru сама в этом варюсь каждый день — десятки тредов, уточнений, синхронизаций, но в какой-то момент ловишь себя на мысли: чем больше коммуникации, тем меньше реального движения задач. 

Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.

В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.

Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту.

Сейчас вышел CodeClone 2.0.0, и это уже другой продукт.

Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP.

Эта статья не про список флагов CLI. Про флаги есть документация.

Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.

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

 BI-задачи неплохо подходят для такой проверки ввиду своей разнородности. Дашборд — это не один SQL-запрос и не одна визуализация. Нужно понять бизнес-запрос, уточнить KPI, проверить данные, спроектировать датасет, собрать чарты, собрать дашборд и на каждом этапе обеспечить соответствующие проверки.

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

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

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

 Суть эксперимента: проверить, можно ли сделать переходы между агентами управляемыми на конкретном BI-сценарии: провести задачу от входного запроса до готового дашборда в Apache Superset через команду агентов на multica — open-source платформе управления задачами с канбан доской в стиле Jira/Yougile. В multica можно создавать изолированные рабочие пространства, в каждому свои runtime и набор агентов. При этом задачи канбан доски можно назначить не только человеку, но и агенту: агент получает конкретный issue, в которой видны все его сессии, также через CLI агенту доступны комментарии, изменения статусов, создание новых задач для передачи работы дальше по конвейеру. Таким образом агенты участвует в процессе как исполнитель конкретного шага, так и как координаторы.

Эван Шпигель, сооснователь и CEO Snapchat, редко даёт интервью. Недавно он подробно рассказал, как его компания с миллиардом пользователей пережила 15 лет копирования их новых фичей конкурентами. Snapchat не просто выжили, они изобрели Stories, свайп-навигацию и AR-фильтры, которые клонировали все остальные соцсети. Шпигель объясняет, как ИИ меняет правила игры в продуктовой разработке и почему важно фокусироваться на дистрибуции продукта.

Финал серии: Agent Teams, GitHub Actions, Agent SDK, TDD, Ralph-loop на ночь и осторожный прогноз на 2027

Серия на Хабре: часть 1 - что Claude Code умеет из коробки · часть 2 - настройки, хуки и Context Rot · часть 3 - автономная работа и параллелизм.

Однажды вечером я дал Claude Code не задачу "сделай фичу", а уже написанную спеку и сложный план. Дальше работал не один чат, а цепочка: оркестратор разобрал план на независимые куски, поднял кодеров в отдельных worktree, дождался их diff'ов, потом вызвал ревьюеров на каждый кусок и собрал итоговый отчёт. Утром у меня был не "ответ ассистента", а несколько веток, замечания ревью и список решений, которые всё равно должен принять человек.

Это третья и финальная часть серии. В первой я показал что такое Claude Code и почему я называю его командой из 15. Во второй - десять настроек, которые эту команду делают управляемой: CLAUDE.md на 30 строк, permissions, хуки, совещание ботиков через Codex и Gemini, Context Rot.

Сегодня про следующий уровень. Когда конфиги настроены и работаешь каждый день, упираешься в новый потолок. Даже команда из 15 человек внутри одной сессии Claude имеет предел. Субагенты конкурируют за контекст, ветки мешают друг другу, ты переключаешься между задачами и теряешь состояние.

Дальше начинается параллелизм, автоматизация и автономия. Десять приёмов, которые превращают Claude Code из "умного помощника" в систему из отдельных агентов, scheduled tasks и CI-задач.

И в конце - честный разговор про то, куда всё это идёт в 2027 и что останется разработчику.

AI уже меняет не только то, как пишется код, но и то, как вообще надо проектировать инженерную среду вокруг разработки. Разбираем Thoughtworks Technology Radar Vol. 34 не как список модных трендов, а как сигнал сдвига: почему context engineering, zero trust, harness engineering и quality gates для coding agents становятся частью обычной практики engineering manager’ов, архитекторов и техлидов.

Четвёртая статья из серии. Предыдущие: манифест, итерация 0, итерация 4 убита.

В прошлом посте я закончил так:

> Эту работу агент не сделает. Реализовать — сделает. Придумать — моя задача.

С того поста — 20 часов и 20 коммитов. На код пришлась небольшая часть. Основная — на методику.

Что не сработало в первой версии

Схема была такая: пользователь отвечает → маленькая LLM классифицирует «вопрос + ответ» в массив сигналов с весами → сигналы накапливаются → детерминированный код назначает карту по порогу.

Технически рабочий пайплайн. Я его удалил, потому что прошёл диалог сам и увидел: это анкета, не зеркало. Адаптивный вопрос на основе предыдущих ответов — механизм, не методика. Разница примерно как между «у меня есть весы» и «я знаю, что взвешивать и почему».

Что такое методика в моём случае