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

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

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

В обсуждении приняли участие Ярослав Лосев, руководитель команды фронтенд-разработки «Яндекс Путешествий», Сергей Курбанов, руководитель исследований и разработок MWS, и Даниил Слюсарь, руководитель разработки PT Application Inspector в Positive Technologies.

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

При чем здесь интеллектуальная собственность?

Название организации, название бренда или название компании – это слова из обычной речи. В разговоре вы их используете без последствий для себя и своего бизнеса.

Другое дело, если вы хотите закрепить название компании исключительно за собой. С этого момента вы имеете дело с фирменным наименованием – объектом интеллектуальной собственности.

Интеллектуальная собственность охраняется законом по-особенному.

AI-агента сегодня можно собрать за несколько часов. Но это не значит, что бизнес понимает, где его действительно стоит внедрять.

Компании часто начинают с Build: выбирают модель, подключают Jira, GitHub, MCP, собирают workflow. А уже потом пытаются понять, какую проблему они вообще решили.

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

Поговорим о том, как увидеть такие проблемы в Jira, Confluence и GitHub, почему не каждую из них стоит автоматизировать и что делать после аудита.

Привет, Хабр!

Меня зовут Писарев Андрей, я руковожу отделом машинного обучения в департаменте технологий искусственного интеллекта. Мы с командой разрабатываем и внедряем ML‑решения на производственных площадках компании различной направленности.

РУСАЛ — геораспределённая компания: десятки производственных площадок по всему миру. А дата‑сайентистов в команде — единицы. Если бы для каждого объекта мы строили ML‑продукт с нуля, мы бы не вывезли. Поэтому главный фокус этой статьи — не модель и не метрики, а типовой подход к разработке ИИ‑продуктов, который позволяет одной командой закрывать много объектов. Печь спекания на Пикалевском глинозёмном заводе (ПГЛЗ) — это кейс, на котором я покажу, как подход работает вживую.

TL;DR: Решение — системный подход к ML‑продуктам на базе SinaraML и корпоративной ИИ‑платформы. Показываю, как подход работает на конкретном кейсе — ML‑сервис для управления 150-метровой печью спекания на ПГЛЗ. 3 месяца от PoC до закрытого тестирования. CatBoost: MAE = 225, R² = 0.48, RMSE = 330. Ожидаемый порядок экономического эффекта — десятки миллионов рублей в год.

Я успел побывать по обе стороны. Сначала несколько лет разбирал алерты в SOC — сидел на потоке срабатываний и решал, что из этого инцидент, а что шум. Потом ушёл в разработку и последние годы пишу сами детекты — те правила, которые генерируют эти срабатывания. И вот что забавно: пока не начал писать алерты сам, я был уверен, что понимаю про них всё. Оказалось — почти ничего.

Эта статья — про несколько вещей, которые выглядят совершенно по-разному в зависимости от того, с какой стороны экрана ты сидишь. Будет полезно и аналитикам, которые ругают «криворуких вендоров», и разработчикам, которые не понимают, почему их идеальное правило ненавидят в SOC.

ИИ уже умеет за минуты генерировать сотни строк кода, но скорость ревью от этого не выросла. Разбираем семь ошибок, из‑за которых AI Code Review пропускает реальные дефекты, создаёт ложное чувство безопасности и постепенно превращает проверку кода в формальность.

Разбираем сетевые драйверы Docker — bridge, host, overlay, macvlan, ipvlan — DNS, порты и плагины: от основ до продвинутых сценариев.

Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.

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

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

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

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

Рассмотрим: на чем основан "успех" Tiny Teams, почему он на всех не натягивается, как сложность предметной области, система, ответственность и платформа влияют на возможности создания таких команд.

Спойлер: направление скорее правильное, но доказательств эффективности нет, потому что все зависит от специфики предметной области команды и сложности системы.

ИИ-агент может за минуты подготовить изменение, на которое у разработчика прежде уходил час. Но ускорение написания кода создаёт другую проблему: растёт нагрузка на проверку. Нужно изучить diff, понять предположения агента, проверить затронутые компоненты и убедиться, что решение соответствует задаче, а не просто проходит формальные проверки.

Почему агент выбрал этот модуль? Какие связанные части системы изучил? Какие варианты отбросил? На какие требования и результаты проверок опирался? Если этот контекст остаётся в закрытой сессии, следующему участнику процесса приходится собирать его заново.

В 2026 году эту проблему сформулировал Томас Домке, бывший CEO GitHub и основатель Entire. Она звучит так: «Узкое место при выпуске кода — это ревью кода, созданного агентами». Мы в «Первой Форме» к похожему выводу пришли через собственную практику. У нас ИИ-агенты работают внутри управляемого конвейера: задача получает проверяемые критерии, агенты действуют по ролям, результаты фиксируются в артефактах, а человек сохраняет за собой продуктовые решения, финальное ревью и мёрж. Расскажем подробнее.

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

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

В управлении проектами есть довольно большой набор «базовых» вещей, которые принято считать само собой разумеющимися (и это не только «водопад» — «аджайл» — «скрам»). Ну, например, проект желательно хорошо спланировать, работы — оценить, риски — предусмотреть, сроки — поставить, людей — не забыть загрузить, а начатое, если уж оно начато, хорошо бы все‑таки закончить.

Но если почитать, что сейчас происходит вокруг проектного управления, периодически начинают попадаться идеи, скажем так, нетривиальные. Мне стало интересно собрать такие идеи в одном месте и посмотреть, не складываются ли они во что‑нибудь общее (я ж аналитик). Сразу оговорюсь, что далеко не все концепции из списка супер‑свежие, но именно в последние пару лет либо получили новое развитие, либо начали появляться в вполне серьезных исследованиях.

Если интересно, давайте пробежимся по верхам.

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

Почти в каждой достаточно большой IT-команде рано или поздно появляется человек, про которого коллеги думают примерно одно и то же: с ним тяжело.

Самое интересное, что сам он совершенно не обязательно считает себя сложным человеком. Наоборот: он прямой, принципиальный, требовательный, профессиональный и просто переживает за результат.

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

Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в draw.io и PNG. Почему диаграмма без модели быстро устаревает и как собрать архитектурный control plane из знакомых деталей: API server, графа, CMDB, diff/review и operator pattern? А может нам нужно решение с ResourceDefinition, типизированными связями, Temporal workflows и change sets.

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

В статье рассказываю о том, что происходит с техническим лидером, когда его зона ответственности растет не по дням, а по часам. О том, как приходится переосмысливать не только процессы, но и саму роль — от решения задач до создания условий, в которых другие могут принимать правильные решения. Ну и немного про Рязань, конечно 😉

Всем привет. Мы решили попробовать нестандартный формат, чтобы поговорить о важных для нас и индустрии ИТ темах. Предлагаем вашему вниманию экспериментальный детектив. Все герои вымышлены, а ситуации собирательны. Не ищите точных совпадений :)

Тема замены людей нейросетями сейчас обросла массой страхов и домыслов. Но как отсеять пустые страшилки с хайповыми прогнозами и посмотреть на ситуацию через призму реальных фактов? Один из способов — проанализировать ту сферу, куда ИИ проник глубже и быстрее всего. Речь, разумеется, о разработке ПО.

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

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

Разработчик понимает, что не успевает, но молчит до последнего. Сильный специалист не делегирует, потому что другим не доверяет. Тимлид видит, что проблема выходит за пределы команды, но боится сообщить наверх.

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

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

На INFOSTART A&PM EVENT 2026 секция будет посвящена работе с требованиями, данными и знаниями, описанию сложных систем, взаимодействию со стейкхолдерами и повышению качества анализа.