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

Рассказали мне историю. Поучительную, спешу поучить.

По АйАйному нетелеграму пронёсся хайптрейн про СУПЕРСИЛЫ, которые дадут вам СУПЕРСИЛЫ. Открывается вращением. Обещается набор скилов для вашего Клода, который поднимет культуру разработки на недосягаемую высоту, внедрит полный фарш передовых опытов SDL прямо в контекст агентов и сформирует вам персональную инжиниринговую армию из бренштормов, продактов, фасилитаторов, SDD, TDD, ИТД.

Знакомец повёлся.

Красиво загрузил. Красиво запустил. Красиво поговорил с продактом и архитектором, получил миллион страниц красивых букв и красиво сказал — выпекай. Seven Agent Army ушла в глубокий red-green-refactor с элементами пурпура, написала доков, тестов и кода ещё на миллионы токенов, кряхтела, шуршала два дня — но так и не выдала ничего, что просто работало бы и отдалённо напоминало задумку или хотя бы документ. Тесты при этом моргали зелёным. Архитектура была в полном SVG.

Не работало.

Знакомец расстроился. Он два дня смотрел с удовольствием и предвкушением, как оно сократически бренит и стормит, руткозит и вот это вот всё, и ждал чуда. Чуда не случилось. Токены сгорели, караул устал.

Он чуть не в слёзы — сейчас, говорит, уйду программировать руками на асме, как деды.

Для меня — ожидаемо. Знакомец, как оказалось, не сталкивался с модными блестящими бадишопами, которые в соответствии с передовыми практиками жгут человеко-часы тайма и матирьяла передового опыта, не выдавая почти ничего. С этой точки зрения СУПЕРСИЛЫ отработали отлично. Хотел как у людей — получил как у людей.

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

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

ИИ не устранил необходимость в менеджменте. Он устранил часть оправданий.

OpenAI выпустил Codex CLI 0.128.0 с командой /goal — автономным режимом, в котором агент сам пишет код, тестирует, рефлексирует и долбит цель часами. На практике первое, что замечаешь — счётчик токенов скачет в 3-5 раз непредсказуемо. Не вдвое — в пять. Месяц использования в команде. Главные находки: исследователи подхватили первыми (а не разработчики). При упирании в quota wall MCP-вызовы молча отваливаются. Соседняя команда /side неожиданно стала использоваться для расшифровки англицизмов GPT-5.5. В статье: разбор архитектуры /goal (5 слоёв, инжекция системного промпта против proxy signals), реальный публичный кейс — +25% fps за час в GPT-5.5 xhigh, грабли с непредсказуемыми токенами и quota walls, когда /goal стабильно ломается. Антипафос. Никакого AI-евангелизма.

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

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

На первый план выходит вопрос: «зачем я это делаю?». И здесь становится очевидным, что настоящий профессиональный потенциал раскрывается только при резонансе ценностей человека со средой, в которой он работает. Не с системой грейдов, не с OKR и не с планами на спринт, а именно со средой - с тем, как принимаются решения, как реагируют на ошибки и как выстроены коммуникации.

Если склонности (модель HEXACO) отвечают на вопрос «как вы работаете?» - быстро или вдумчиво, индивидуально или в команде, с готовностью к риску или по инструкции, - то ценности дают ответ на вопрос «зачем?». Ради чего специалист встаёт утром и открывает пул-реквест.

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

«У нас было два пакета findings SAST’а, семьдесят пять CVE с критичностью — Critical, пять дублей одной и той же CVE в разных сервисах, пол солонки false positive и целая россыпь уязвимостей всех сортов и расцветок: SQLi, XSS, SSRF, RCE, IDOR, утекшие секреты, misconfigs в Kubernetes, написанные человеком, который явно не планировал дожить до аудита.

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

Не то чтобы это был необходимый запас для управления безопасностью приложений, но если уж ты решил строить ASPM через агрегацию всего подряд, рано или поздно ты оказываешься именно в такой машине — на полной скорости, без карты, с разработчиками на заднем сидении, которые только и спрашивают: “Что из этого реально надо исправлять?”». 

Всем привет! Меня зовут Артем Пузанков, я руководитель отдела консалтинга безопасной разработки в Бастионе. Сегодня хотелось бы порефлексировать с вами про управление состоянием безопасности приложений, ASPM, AI-generated код и AppSec.

Эта статья о том, почему будущее ASPM не в том, чтобы собрать все дефекты в «единое окно», а в том, чтобы сопоставить обнаруженные находки, проверить достижимость и отделить реальные угрозы от шума (читай технического долга).

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

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

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

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

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

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

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

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