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

Разделить монолит без остановки бизнеса, сменить СУБД с сохранением существующей логики, встроить ИИ в корпоративные процессы — такие задачи разберут в секции «Кейсы крупных компаний» на INFOSTART TECH EVENT 2026. Конференция начнется 8 октября в Санкт-Петербурге. В программе секции — десять выступлений о проектах, технических решениях и ограничениях, с которыми столкнулись команды.

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

Агент проверял разворот на палиндроме, а порядок четырех потоков - на четырех одинаковых входах. Тесты проходили и с ошибкой. В эксперименте Дэна Лу указания использовать TDD, фаззинг и формальные методы не дали убедительного общего выигрыша над контролем. Разбираю три механизма бесполезных проверок и показываю исполнимый пример: как намеренно внести конкретный баг и убедиться, что тест его обнаруживает.

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

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

30 сентября в 06:32 в очереди появилась задача: научить ядро платформы переводить открытые задачи на новую версию их типа. Повод был будничный — мы выпустили новую версию типа «задача на код» с более строгими проверками перед сдачей, а вся открытая очередь осталась на старой и получала старые инструкции.

Через 19 минут агент сдал работу: новый маршрут API, тесты, документация. В 07:15 ревью её отклонило. Новый маршрут позволял агенту с обычными правами исполнителя перевести свою задачу на первую версию типа — ту, где ревью ещё не было, — взять её и закрыть самому. Ревьюер воспроизвёл это по шагам и написал, какое право должно закрывать маршрут. В 08:03 агент взял задачу снова, через 15 минут сдал исправление, в 08:24 ревью прошло и ветка влилась. От постановки до вливания — 1 час 52 минуты, два прогона агента.

Агент написал дыру, через которую агент мог бы уйти от ревью, и поймало её ревью, которое платформа считает частью самой задачи. 4 октября мы выпустили первый открытый релиз платформы — Taimen v0.2.0, Apache-2.0. Ниже — как она устроена и что мы поняли, пока почти два месяца разрабатывали её её же собственными средствами. В конце — как этот релиз выпустила сама очередь.

ИИ ускоряет выполнение отдельных задач, но управление растущим числом процессов и проектов остаётся на человеке. На примере своих экспериментов покажу путь от одного агента к AI-организации и объясню, зачем над несколькими направлениями может понадобиться AI-холдинг.

Системы управления ресурсами и экономикой проектов: обзор PSA- и PPM-платформ.

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

Я не один год провел с P&L в Google Sheets и Excel, и смертельно устал каждый месяц сверять все формулы, обновлять ставки и руками перепроверять каждую строчку.

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

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

Я отобрал пять штук на обзор и постарался разобраться, что к чему. Сравнил Timetta, «Первую Форму», ADVANTA, ELMA365 Проекты и Shtab. Потестил демо, насколько это было возможно, и изучил документацию.

В мае 2026 ИИ-агент попросился в любительскую сеть DN42, чтобы “создать индекс сети”, и заодно сообщил о пяти инстансах AWS по 20 Гбит/с, уже запущенных и ждущих допуска. Заявку в сеть так и не приняли, зато затянули взаимодействие на сутки: субагент принимал индивидуальные OPT-OUT, но отказался исключить всех сразу, сайт агента вел профили участников, а в реестр прилетел документ про “уровень счастья ноды”. Закончилось заявленным счетом на $6531 и просьбой о пожертвованиях. Пересказ истории Lan Tian, голоса Hacker News и мои выводы о том, какие гейты ставить агенту на деньги, ресурсы и необратимые действия.

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

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

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

Наш оркестратор умеет работать как с большими облачными моделями, так и с маленькими, которые помещаются на бытовой видеокарте. Минимальный рабочий вариант: 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-серверы, пайплайны обработки данных, системы из нескольких агентов. И чем лучше становилась инфраструктура вокруг агентов, тем больше в ней появлялось инструкций, проверок, субагентов и автоматики. По идее, разработка должна была становиться дешевле. А расход контекста рос.

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