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

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

У нашего ИИ-оркестратора более девяноста инструментов: работа с таблицами, документами, почтой, задачами, веб-страницами, презентациями и т.д.

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

Наш оркестратор умеет работать как с большими облачными моделями, так и с маленькими, которые помещаются на бытовой видеокарте. Минимальный рабочий вариант: RTX 3090 24Gb + Qwen3.6 27B.

Цель - заставить минимальный рабочий вариант выполнять корпоративные задачи с приемлемым качеством и с приемлемой скоростью.

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

Обычно оркестратор показывает модели весь список инструментов и она уже решает какой нужно выбрать для ответа на запрос. Так делают Hermes, OpenClaw и Ouroboros. Ни один из них не выбирает инструменты по тексту запроса. У некоторых для слабых моделей и маленького контекста есть режим, где модели дают только каталог — имя и короткое описание — и инструмент «подключить», так что нужное она находит и загружает сама. Эти агенты рассчитаны на фронтир-модели уровня Claude и GPT-5, которые держат сотню инструментов без потерь. Моя задача другая: работать на локальной 27B в закрытом контуре. Для неё узкий набор измеримо лучше.

Как устроен узкий набор

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

Отправить команду на переработку, нанять дорогих специалистов или пересмотреть план - каждое решение меняет ход проекта. На INFOSTART A&PM EVENT 2026 участники смогут проверить такие решения в бизнес-симуляции ИТЕРРА: за 2,5 часа им предстоит спланировать работу, распределить ресурсы и столкнуться с последствиями собственных действий.

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

AI-ревьюер для GitLab, который проверяет не отдельный merge request, а всю задачу сразу, во всех сервисах, которые она задела. И почему для этого понадобился агент, а не анализ diff через API.

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

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

Привет, Хабр! Меня зовут Алина Сычёва, я около трех лет работаю в МТС Линк. В компанию я пришла на позицию middle QA, а сейчас руковожу одной из команд разработки. В этой статье я расскажу, как работа с релизами локальной версии продукта оказалась для меня школой лидерства, какие навыки из тестирования пригодились в новой роли и чему пришлось учиться после перехода.

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

Двести миллионов лет динозавры удерживали вершину пищевой цепи. Они были совершенны для своего времени, пока резкая смена среды обитания и последовавший за ней пищевой дефицит не поставили точку в их истории. В схожей ситуации оказались и популярные таск-трекеры. Превратившись за два десятилетия из стройных и шустрых помощников в прожорливых Jiraзавров, они стали потреблять неприлично большие объёмы рабочего времени. В новой среде асинхронной и многопоточной разработки сам факт их выживания зависит от того, смогут ли они оставаться востребованными утилитами, или их место займут более совершенные системы, построенные на иной архитектуре.

Можно ли описать архитектуру на Python, а получить работающий каркас сервиса на Go, C++, Rust или TypeScript? Причём так, чтобы схема не становилась отдельной документацией, которую все забывают обновлять.

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

Привет! Меня зовут Дарья, я руковожу продуктом Naumen Project Ruler. Вместе с командой изучаю задачи пользователей и определяю, какие сценарии и возможности продукта нужно развивать, чтобы эти задачи решать.

На статус-митинге руководитель проекта оценил прогресс в 90%, все показатели в зеленой зоне. Команда движется отлично, все по плану. Через месяц все те же 90%. Показатели снова в норме, но почему процент не увеличился? Еще через месяц цифра по-прежнему не меняется. И вот, за две недели до дедлайна статус «краснеет», и выясняется, что до закрытия всех задач нужно не меньше квартала.

Знакомо? Что за магическое число — 90%, откуда оно берется и в какой момент отображает реальное состояние проекта? И в чем тут проблема: РП приукрасил статус, ошибка в планировании либо расчете прогресса? Попытаемся разобраться.

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

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

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

Первое подозрение было очевидным: слишком раздутые промпты. Мы искали не там.

Всем привет! Меня зовут Магомед, я инженер поддержки в команде Контента в Банки.ру. За 4 месяца я собрал на n8n несколько автоматизаций. Часть из них дежурит вместе со мной: утренний дайджест по состоянию сервисов, сторож аномалий после релизов и ИИ-агент, который знает наши сервисы, работает с Jira и умеет оценивать задачи. Другая часть работает на авторов контента: уведомляет о комментариях и просмотрах и проверяет, подходят ли к материалу прикреплённые виджеты.

В этой статье я не буду уходить в детали устройства воркфлоу: схем из n8n, промптов и разбора нод здесь не будет. Хочу показать, как конкретно я, инженер поддержки, применяю ИИ в ежедневной работе. Если захочется подробностей по какому-то из ботов, спрашивайте в комментариях, расскажу.

Дэкс Хорти из HumanLayer объясняет, почему “фабрика кода с выключенным светом”, где агенты пишут, ревьюят и тестируют без человека, пока не работает: по его мнению, при обучении модели почти не получают сигнала о поддерживаемости кода, а быстрого способа ее проверить пока нет. Его рецепт - вернуть ревью и сделать его дешевым планированием. Разбираю эссе и 272 комментария на HN и сравниваю с собственным конвейером на Claude Code и Codex: спека прозой, тесты вслепую, сверка второй моделью. Спойлер: 22 нарушения спеки при 2650 зеленых тестах, и разбор того, что эта цифра доказывает, а чего нет.

В моем приложении для управления финансами была кнопка «Показать Кубышу» Она раскладывала накопления по целям: сколько положить в подушку, сколько в отпуск, сколько в машину. Работала через LLM. У части людей из за белых списков вместо ответа она показывала «работает только с VPN»

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

AI‑Disrupt PDLC Сбера объединяет модель жизненного цикла, референсную архитектуру, уровни автономии AI‑агентов, модель зрелости, платформенные практики и governance. При этом многие его составляющие существовали до появления AI‑Disrupt.

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

Четыре месяца назад мы разрешили коллегам без инженерного бэкграунда выкатывать в прод приложения, которые им пишет ИИ-агент. После этого получили более 260 проектов от 150 человек, и весь этот код не читал ни один программист.

Дальше о том, как устроена наша песочница, что мы узнали за эти четыре месяца, где ошибались и что из этого получилось.

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

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

Привет, Хабр! Меня зовут Шамиль Зигантдинов, я директор по продуктам экосистемы ИТ-продуктов Лукоморье. Под катом расскажу про нашу систему работы с клиентскими запросами: что мы берем в дорожную карту продукта, что закрываем скриптами и настройками, а что отдаем партнерам в виде плагинов. И разберем, из чего складывается настоящая цена «фичи на месяц».

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

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

Меня как руководителя интересует не только качество отдельного теста. В какой‑то момент мне всё равно приходится отвечать на более практичный вопрос: могу ли я принимать решение о релизе, глядя на зелёный CI?

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

При вайб-кодинге без инженерного контура отладка съедает у разработчика больше времени, чем экономит генерация. 

От подхода «а давайте добавим немного ML» в 2023-м мы дошли до процесса, где работает не столько модель, сколько контур вокруг нее.

В этой статье делюсь нашим практическим опытом (набитыми шишками) и эволюцией подходов применения LLM (не только в разработке).