Планирование, отслеживание и контроль
Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в 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 секция будет посвящена работе с требованиями, данными и знаниями, описанию сложных систем, взаимодействию со стейкхолдерами и повышению качества анализа.
ИИ-агенты ускоряют разработку, но привычное код-ревью быстро превращает этот выигрыш в новое узкое место. Код генерируется быстрее, изменений становится больше, а разбираться в них всё равно приходится людям. В итоге возникает перекос: поручить задачу агенту почти ничего не стоит, тогда как проверить результат — полноценная инженерная работа.
В статье разберем этот конфликт через проблему «принципал — агент» и узнаем, почему особенно остро он проявляется в больших компаниях и 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 участников. Первый день посвятили деловой программе, второй - командной регате в Финском заливе.
Главной темой стала экономика искусственного интеллекта. Участники обсуждали уже не столько возможности технологии, сколько практические вопросы: где ИИ действительно сокращает затраты и сроки, как оценивать эффект внедрения, что можно передать агентам и какую часть процесса по-прежнему должен контролировать человек.