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

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

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

Сразу после Saint HighLoad++ прошла Saint TeamLead, основной темой тоже было применение ИИ. Второй день принес прекрасное визионерское выступление Авенира Воронова, два тезиса.

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

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

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

В работе с AI‑кодерами постепенно меняется формат задачи. Одного промпта часто недостаточно: агенту нужно не только выполнить разовую команду, но и повторять действия до понятного результата. Например: проверить CI, прочитать лог, внести минимальное исправление, снова запустить тест, остановиться при выполнении условий.

Поводом для этой статьи стала заметка Anthropic «Getting started with loops» про циклы (loops) в Claude Code. Там термин«цикл» описывается как повторяющаяся работа агента до выполнения условия остановки.

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

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.

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

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

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

Разговор о карьере программиста часто скатывается либо в обсуждение грейдов «чем L6 отличается от L7», либо в спор «менеджмента команды против экспертной стези», как будто путей всего два. Расскажу про разработку игр и примеры моих знакомых, потому что они прямо сейчас у меня перед глазами.

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

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

У INFOSTART TECH EVENT 2026 появился сайт, а вместе с ним - новый визуальный стиль. В этом году конференция уходит в фэнтези-мир: не только на картинках и баннерах, но и в оформлении площадки, навигации, сувенирах, интерактивах, вечеринке и игровых механиках. Конференция пройдет 8–10 октября 2026 года в Санкт-Петербурге. Это событие для тех, кто работает с 1С, корпоративными системами, архитектурой, инфраструктурой, тестированием, интеграциями и управлением разработкой.

Для TECH EVENT выбран образ Старого Города. Это мир сложных систем, устойчивости, технологий и людей, которые отвечают за то, чтобы все работало. В целом, довольно точное описание жизни 1С-специалиста: старый код, архитектурные развилки, интеграции, нагрузка, баги, требования бизнеса и задачи, которые редко решаются с первого захода...

Я плотно работаю с финтехом и ритейлом, а это как раз те сферы, где грядёт подключение к платформе цифрового рубля. Готовиться начал заранее, так как 1 сентября 2026 года тестовый контур уже обязан быть в порядке. Полгода собирал базу, расспрашивал знакомых из финтеха, ходил на вебинары – даже на те, что делали для бухгалтеров. Я даже прочитал документы Банка России. В итоге сложилась нормальная методологическая основа.

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

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

Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье расскажу, какие гипотезы мы проверяли при внедрении ИИ, почему рост использования чатов и кодинг-агентов не равен росту скорости, какие метрики помогали отделять привычку от результата и как мы пришли к идее Agentic Engineering.

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

В этой статье разберём, как на ArchiMate 4.0 собрать первую рабочую модель предприятия с нуля — на примере интернет‑магазина, с понятной логикой доменов, связей и проверок, которые помогают не превратить диаграмму в клубок стрелок.

Меня зовут Дианова Анастасия, я — Lead Delivery Manager в Lenta Tech («Группа Лента»). Я отвечаю за скорость поставки новых фич в приложение для заказа продуктов онлайн. В статье расскажу, как мы переосмыслили роль Delivery Manager’а, когда столкнулись с жесткими ограничениями.

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

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

Я работаю более 6 лет системным аналитиком и порядка трёх лет на продуктах по внедрению LLM в бизнес. И меня категорически не устраивает AI-зрелость большинства моих коллег в этих ИИ-проектах!

Есть мысль, что часть проблемы в отсутствии у системных аналитиков общепризнанного подхода к AI‑усилению, подобного тому, что уже сформировался у разработчиков. Но при этом я часто встречаю в вакансиях требования «опыт написания документации AI‑native», «AI‑центричная аналитика». И я согласен с таким запросом рынка — давайте уже подстраивать пайплайн под эксперта! А эксперты в процессе написания кода — это наш разработчик + AI. Очевидным и логичным решением будет писать аналитику сразу в текстовом формате, постепенно уходя от Miro и Draw.io.

Первое время я даже считал, что придумал новый фреймворк, и даже придумал ему красивое название — Analysis‑as‑Code, но оказалось, что существует Spec‑Driven Development — подход, в котором «спецификация» становится центральным документом, а ИИ использует её в реализации задачи.

В этой статье я хочу разобрать Spec‑Driven Development (SDD) с оглядкой на роль системных аналитиков в России и СНГ и понять, как их меняется их роль при таком подходе.

Я аналитик, а не разработчик. Весь код для созданной нами платформы написал Claude Opus через Claude Code. Рассказываю без хайпа: как выглядит реальный workflow, где нейросеть незаменима, где она бесполезна, и какая инженерная дисциплина обязательна, чтобы это не превратилось в тыкву на боевом.

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

Я не умею писать продакшн‑код. Я аналитик: читаю код, рассуждаю о системах, проектирую поведение — но профессионально не кодю. Тем не менее у нас в проде работает нетривиальное веб‑приложение, и каждую строчку кода написала нейросеть (Claude Opus, агент Claude Code). Моя роль — архитектор, продакт и QA. Второй ключевой специалист по разработке — дизайнер вебинтерфейсов, также освоивший Claude.

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

Работа в IT до 2025 года была устроена так, что компания получала дорогостоящих сотрудников интеллектуального труда, которые приносили компании убыток всё время, пока они не приносят какое-то вэлью либо через новые продукты (фичи), которые продаются клиентам, либо через оптимизацию какого-то процесса (и компания получает вэлью через сокращение издержек).

Все обсуждают модели: GPT, Claude, Codex, Gemini, Opus. Но в реальной работе побеждает не только самая сильная модель, а правильно собранная система вокруг неё. Эта система называется agent harness — харнесс. В статье разберём, что это такое, из каких компонентов он состоит и как я собираю свой рабочий AI-сетап: Orca, GitHub, VPS, Pi Agent и кастомный pipeline для разработки.

0.86.0-beta.1 - это большой бета-цикл: агент получил единый дом в интерфейсе, у Yttri появился первый плагин (интеграция с Obsidian) и сама платформа плагинов, на Mac с Apple Silicon заработал альтернативный локальный движок MLX, а голосовой ввод и запись прошли через плотную серию фиксов стабильности. Ниже - по разделам, что из этого видно пользователю.

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

Ответьте себе на вопрос: где проходит ваша граница доверия с вашим агентом? Что вы готовы ему простить? А что для вас жесткий ред-флаг?

Готовы ли вы делегировать агенту задачу, в которой вы не разбираетесь, и взять за это ответственность, если что-то пойдет не так? А если наоборот, все будет очень хорошо — искренне признать, что по факту это не совсем ваш труд?

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

У меня есть несколько смешных кейсов, которые я вам сейчас расскажу, но смеяться вы скорее всего не будете.

Сэнди Петерсен, геймдизайнер и дизайнер уровней Doom и Quake:

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

AI Engineer World's Fair 2026 уже прошла, а по-русски её так никто и не разобрал. В официальном расписании 560 сессий: воркшопы, кейноуты, доклады. Глазами это не осилить.

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

Все доступные доклады с русскими саммари, таймкодами и тематическим навигатором я собрал в отдельном SPA.

Улучшенный Spec-driven-dev. Это SDD + handoff’ы — передний край лучших мировых практик как для соло-разработки, так и для небольших команд. Это не история про рой агентов, которые в абстрактном цикле «план → код → ревью → тесты → деплой» самостоятельно везут продукт, синхронизируясь друг с другом через воркфлоу. У нас нет личного датацентра или полумиллиона долларов на токены.

В конце будет ссылка на репозиторий-шаблон, который можно скачать, или просто указать, и сказать Opus’у (Fable’у): «сделай мне такую же систему спецификаций» — дальше он справится сам.