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

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

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

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

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

Меня зовут Сергей Ладыгин, я делаю Scruma - сервис онлайн-ретроспектив. До собственного инструмента я пару лет вёл ретро в таблицах и на досках общего назначения, и главный вывод из тех лет неудобный: ретро чаще всего умирает от рутины. Сбор карточек, ручная группировка, подсчёт плюсиков и протокол съедают именно то время, ради которого встреча собиралась. Ниже - зачем ретро вообще нужно (первая треть статьи обходится без моего сервиса), прикидка на пальцах, куда уходит час встречи, и карта «проблема команды и что с ней делает специализированный инструмент».

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

В статье разберем этот конфликт через проблему «принципал — агент» и узнаем, почему особенно остро он проявляется в больших компаниях и open source.

Как описывать не только сервисы и связи, но и реальные бизнес-сценарии внутри распределённой системы? Показываю Magic Flows в Viaduct: пошаговые потоки данных, визуальный плеер на C4-модели, автоматическая sequence diagram и документация, привязанная к конкретному процессу.

ИИ‑агент не должен получать больше автономности только потому, что выглядит компетентным. Автономность должна расти тогда, когда система вокруг агента умеет надежно обнаруживать его ошибки.

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

Этой теме посвящена глубокая статья «Переосмысление профессии разработчика ПО в эпоху ИИ», которую написали корифеи ИТ-рынка: Марк Руссинович – технический директор Microsoft Azure, прославившийся созданием мощных системных утилит (набор Sysinternals) для белого хакинга Windows, и Скотт Хансельман – вице-президент и член технического совета Microsoft CoreAI и GitHub. Материал показался нам настолько интересным, что мы перевели его целиком, без купюр, чтобы вы могли сами ознакомиться с идеями авторов.

Спойлер: в статье есть о чем подискутировать.  

Привет, Хабр! Я Денис Макрушин, работаю в Яндексе, и вместе с командой SourceCraft Security строю платформу для безопасной агентской разработки, а в свободное время ищу уязвимости в ИИ‑агентах и иногда рассказываю об исследованиях в своем блоге. Чем дольше этим занимаюсь, тем лучше вижу тенденцию: индустрия обсуждает, что агенты умеют делать, но реже говорит о том, какие решения и как проще внедрять, чтобы сделать агентскую инфраструктуру безопаснее. Вместе с моими коллегами Ратмиром Самархановым и Андреем Погирейчиком мы решили проверить гипотезу: «наши ИИ‑агенты в разработке могут быть скомпрометированы и существуют простые средства для контроля их безопасности». Расскажем о первых результатах.

Я построил автономную систему с ИИ-продактом и командой агентов-исполнителей, которая круглосуточно в несколько потоков закрывает задачи продуктового бэклога. Делюсь опытом, как я пришёл к такой схеме, что из этого получилось и при чём тут "Весёлая ферма".

Представьте ситуацию: вы выкатываете новую фичу, а бэкендер спрашивает вас: «Слушай, а почему вместо событий — пустой объект?». Вы в шоке: «Как так — пустой объект? У меня же TypeScript, всё типизировано, такого не могло быть!». Спойлер — могло. 

Меня зовут Денис Платонов, я старший разработчик интерфейсов в Телемосте и я отвечаю за on-premise развёртывание веб-клиента Телемоста в инфраструктуре заказчика. В этой статье я расскажу о том, как безобидный на первый взгляд Omit превратил наш аккуратный тип событий в пустой объект. Заодно разберём, как работает дистрибутивность типов в TypeScript и поделимся, чему нас научил этот кейс.

Раньше инженера растили на задачах, которые сейчас называют «рутиной»: написать автотесты, собрать первичную аналитику, разметить датасет или составить документацию. Эта черновая работа была естественным тренировочным полем. Пробираясь через нее, новичок совершал контролируемые ошибки, проходил код-ревью и формировал профессиональное суждение (engineering judgment) — интуитивное понимание того, как система ведет себя в реальности. 

В классической инженерии этот этап называют «накоплением насмотренности»: нельзя спроектировать надежный мост, не изучив сотни типовых узлов и чужих ошибок. Похожий принцип десятилетиями поддерживал живучесть ядра Linux: Линус Торвальдс и команда топ-мейнтенеров годами заставляли новичков вручную переписывать патчи, чтобы те ментально «проросли» в архитектуру подсистем и переняли культуру инженерных решений.

Генериративный ИИ автоматизировал рутинные задачи — написание тестов, разметку данных, — которые раньше служили тренировочным полем для развития инженерного суждения. По мнению исследователей Microsoft, этот сдвиг к 2026 году остановил традиционный конвейер передачи опыта, создавая риск «кадрового дефолта» в IT. В исследовании Microsoft говорится, что AI Drag (эффект торможения) становится главным вызовом, требующим перестройки обучения специалистов.

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

Меня зовут Игорь Кузнецов, я ИТ-директор компании «Эрегион». Мы развиваем ИИ-продукты и консультируем бизнес по внедрению ИИ в рабочие процессы.

Недавно в качестве эксперимента я решил проверить, можно ли полностью передать продуктовые и ИТ-задачи ИИ-агентам. В итоге собрал систему из 13 агентов, которые сами разбирают задачи, распределяют работу, проверяют друг друга и фиксируют результаты.

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

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

Сегодня профессия разработчика ПО находится в эпицентре потрясений. Никто не знает, к чему нас приведёт ИИ-революция, но ясно одно — многие аспекты работы и повседневной жизни изменятся, в том числе программирование.

В последнее время я часто слышу утверждения, которые сводятся к двум основным идеям: «LLM могут хорошо писать код, но программная часть никогда не являлась самой сложной» и «Программировать легко — сложно понять, что именно требуется напрограммировать».

Как по мне, так это явное оскорбление для всех программистов.

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

Часть тезисов пропущена через нейросеть, а если у вас аллергия на подобные решения — краткие тезисы ниже:

TL;DR

Что: ИИ‑конвейер из 14 агентов и трёх моделей — путь от чата до оркестратора, для команды из 1 человека.

Главный вывод: нейронка умеет только генерировать правдоподобный текст, интеллект (даже искусственный) не равен надёжности.

Главная боль: синхронизация репозиториев внутри продукта — три агента чтобы не терять данные между репозиториями.

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

Что работает: проверки и синхронизация — на формальной логике, нейронкам — только генерация и анализ. Спецификация — единственный источник правды.

Кому не подойдёт: если хотите уволить команду и заменить её конвейером — не сработает. Ключевой продукт с риском для прибыли — пока рано.

Мы создали и выпустили первую версию, MVP - альфа-релиз Платформы GameDevAdvisor! Инструмент полного цикла сопровождения игрового проекта. От витрины, где можно заявить о своем проекте, понять его риски, рассчитать фин. модель и найти эксперта в команду, до запроса юридического сопровождения, оформления права собственности на IP. *В настоящее время Платформа работает в тестовом режиме.

Данная статья является продолжением ранее опубликованной статьи об управлении рисками в индустрии GameDev. В этой части я расскажу о дальнейшем развитии проекта GameDevRiskAdvisor, в частности о причинах создания, запуске MVP и развитии Платформы GameDevAdvisor.

14–15 августа в Санкт-Петербурге прошел INFOSTART CIO CAMP 2026 - закрытая двухдневная встреча ИТ-директоров, руководителей ИТ-подразделений и центров компетенций 1С. В этом году мероприятие собрало более 70 участников. Первый день посвятили деловой программе, второй - командной регате в Финском заливе.

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

Coding agent может написать технически правильный код и всё равно сделать неправильное изменение. Причина не обязательно в модели или промпте. Репозиторий может содержать несколько правдоподобных источников, неявный ownership, устаревшие артефакты или доказательство, которое относится не к той ревизии. Для человека часть этих противоречий компенсируется контекстом команды. У агента этого контекста может не быть.

Разбираю, почему репозиторий становится частью среды исполнения, где заканчиваются возможности AGENTS.md и файлов инструкций и как из этой проблемы появился open-source framework AIRepo.

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

Четыре года назад технический директор Google заявил, что к 2025 году ИИ обеспечит переход на четырёхдневную рабочую неделю.

В начале этого года, всего через год после прогноза того технического директора, компания OpenAI приняла этот вызов. Она официально призвала компании начать тестирование четырёхдневной рабочей недели (без изменения заработной платы), утверждая, что ИИ вскоре сможет настолько ускорить человеческий труд, что корпоративный мир должен к этому подготовиться.

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

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

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

Другие компании также продвигают идею о том, что ИИ эффективно сократит количество часов, которые людям нужно работать — к лучшему или к худшему. Компания Anthropic похвасталась тем, что её популярный инструмент для программирования и чат‑бот Claude способен работать самостоятельно в течение семи часов без перерыва, что по сути соответствует полному рабочему дню в компании. Марк Цукерберг из Meta заявил, что его компания находится в середине того года, когда «ИИ начинает кардинально менять наш подход к работе», и что такие инструменты позволяют гораздо меньшему числу сотрудников выполнять больше работы — гораздо больше, чем они когда‑либо могли бы сделать раньше.

Самое сложное в ИТ — не технологии, а люди. Без них не получится ничего большого, но они сопротивляются, сомневаются, по-разному воспринимают изменения и далеко не всегда делают то, что казалось очевидным на схеме.

Поэтому эта история будет не только про очередной ИИ-инструмент, но и про команду из 16 человек, которая за несколько месяцев изменила привычный способ работы и перестроилась в пять микроюнитов.

Привет, Хабр! Меня зовут Сергей Чистяков, в ИТ я с 2006 года. Веду канал в телеграм. Сейчас работаю техлидом в Райффайзен Банке и строю систему автоматизации бизнес-процессов, в которой вместе работают люди и агенты. Расскажу про воркшоп, на котором никто не научился писать автотесты, двухдневный дофаминовый шок и пять маленьких команд, которые начали проводить задачи через весь цикл разработки и построили для этого собственный workflow поверх нескольких репозиториев.