За 3 месяца выстраиваем AI SDLC на пилотной команде: внедряем AI-агентов в процесс разработки, измеряем влияние на скорость и качество и готовим систему к масштабированию на всю инженерную команду.
Разработчики уже используют Cursor, Claude Code и др., и могут выполнять отдельные задачи значительно быстрее. Но производительность всей инженерной системы часто меняется гораздо меньше.
Каждый использует свои инструменты, промпты и подходы. Лучшие практики зависят от отдельных людей и плохо масштабируются между командами.
Код создаётся быстрее, но больше времени уходит на постановку задач, review, тестирование, исправления, согласования и deployment.
Требования живут в Jira, знания — в Confluence и головах разработчиков, архитектурные правила — в истории code review. AI не может стабильно использовать этот контекст.
Количество сгенерированного кода и PR растёт, но непонятно, сократились ли lead time и time-to-market, вырос ли throughput и не увеличился ли rework.
Чтобы AI влиял на производительность всей команды, недостаточно ускорить написание кода. Нужно перестроить весь путь изменения — от требования до production.
Путь всегда начинается с личных инструментов разработчика. Дальше нужен не более мощный агент, а другой процесс, и именно здесь команды застревают: между уровнями 01 и 03 лежит не апгрейд тулинга, а смена того, как в компании ставят и принимают задачи.
На диагностике мы определяем, где вы сейчас, и какой переход даст эффект в этом году. Прыгать через уровень бесполезно.
Разработчики берут Cursor, Claude Code и другие инструменты под код, тесты и разовые задачи. Быстрее становится конкретный человек.
Агент получает задачу с контекстом и сам делает существенную часть изменения. Разработчик ставит задачу и принимает результат. Ручной работы в реализации становится меньше.
Спеки, специализированные агенты и quality gates собраны в один процесс от требования до production. Человек стоит в контрольных точках, а не в каждом шаге. Ускоряется цикл целиком, а не набор кода.
Команды работают на общей инфраструктуре: единые знания, правила, агенты, gates, метрики. Новая команда наследует готовый процесс, а не собирает свой с нуля.
Спецификация становится главным артефактом: агенты пишут код по спеке, люди ставят рамки и принимают результат. Агент сдаёт работу проверяющему агенту; три неудачные пересдачи — и задача уходит человеку.
Автоматический цикл для типовых задач, ревью человека там, где цена ошибки высокая.
Acceptance criteria, привязанные к тестам: агент не достраивает предположения молча.
Архитектурная карта, контракты, журнал решений — версионируются в git рядом с кодом.
Инструкции агентам под ваш стек и вашу кодовую базу, blast radius вместо тотального контроля.
Наш агент сканирует репозитории, архитектор смотрит на архитектуру и процессы. Разбираемся, как устроена постановка задач: Jira, которую не сдвинуть, или спеки в markdown прямо в репозитории.
Фиксируем стартовые метрики, чтобы через три месяца сравнивать с ними, а не с ощущениями.
Правила, база знаний, спецификации и quality gates под ваш стек. Спека становится главным артефактом: агенты пишут код по спеке, люди ставят рамки и принимают результат.
Сам Harness собирается за несколько дней. Остальное время уходит на договорённости о ролях: кто в команде отвечает за Harness дальше.
Пилотная команда протаскивает две-три реальные задачи из своего бэклога через весь цикл: спека, генерация, валидация, выкладка. После воркшопа команда работает только по новому процессу.
Возражения снимаем заранее: на время пилота убираем KPI по дефектам. Производительность если и проседает, то меньше чем на неделю.
Архитектор доступен в чате. По git видно, где работал агент, а где человек полез править руками — такие случаи разбираем и превращаем в правки Harness. Раз в неделю команда привязывает дефекты к спекам.
Ручные исправления — это продолжать есть кактус. Чинить нужно систему, которая породила дефект.
Через три месяца — ревью: DORA-метрики плюс AI-метрики (доля решений, которые принимают агенты, и импакт этих решений) против стартового замера.
Следующую команду запускают уже ваши люди: 1–3 сотрудника, которых мы готовим с первого дня как внутреннюю AI Harness Team. Новая команда наследует готовый Harness, а не строит с нуля.
Всё живёт в вашем репозитории как часть кодовой базы и работает после нашего ухода.
Клиенты анонимизированы по условиям соглашений. Ниже — устройство процесса, которое мы выстраивали на реальных командах.
Команда, прошедшая устойчивый уровень задачных агентов, перешла на цепочку агентов с автоматическими handoffs: Planner создаёт ветку, MR и обновляет спеки, Coder пишет код, Reviewer ревьюит и проверяет CI.
Единый LLM-шлюз: проксирование к провайдерам, логирование запросов, изоляция реквизитов, бюджетирование токенов, роутинг по безопасности и цене. On-prem модель закрывает чувствительные задачи.
Смена модели не требует переделки кода агентов.
Команда из восьми человек ведёт несколько продуктов одновременно на общем корпоративном harness. Quality gates переведены на агентов: одна модель пишет, другая ревьюит, правило «разработчик ≠ ревьюер» соблюдается и для агентов.
Мы не привозим коробку. Агенты и правила собираются под ваш стек и вашу кодовую базу с нашим сопровождением — свои решения приживаются, чужие нет.
База знаний, журнал решений, промпт-шаблоны и регламенты живут в вашем репозитории как часть кодовой базы и работают после нашего ухода.
Задачи с малым радиусом поражения идут через автоматический цикл. Задачи, задевающие другие команды, агент сам отправляет на архитектурное ревью.
Главный сдвиг — в головах: править не код, а инструкции агентам, которые пишут код. Исправлять код руками после агента — как править бинарник после компилятора.
Команда из шести человек после внедрения делает ту же работу составом два-три: тестирование и часть инженерных задач забирают агенты. Плюс подразделения, которым никогда не досталось бы разработчиков, получают вайб-кодера на готовом Harness.
Полную автономию агентов за квартал не строим: цель пилота — устойчивый процесс на одной команде и люди, способные его масштабировать.
Перестройка архитектурного ландшафта и решения о составе команд остаются на вашей стороне. Мы даём механизм и цифры, на которых такие решения можно принимать.
Более 15 лет повышает эффективность организаций через Agile-подход, цифровую трансформацию и развитие продуктового мышления. Работал с Microsoft, Альфа-Банком и Яндексом. Автор книги «Lean Data Science». С 2023 года консультирует компании по применению GenAI. Выпускник МФТИ с красным дипломом.
Программист и CTO с более чем 18-летним опытом в коммерческой разработке: путь от разработчика до тимлида, CTO и VP of Engineering. С 2014 года — в образовании и консалтинге: готовит инженеров, нужных IT-индустрии. Сооснователь образовательной платформы Хекслет, обладатель премии Highload++ за вклад в IT-образование.
AI-консультант и технический руководитель с 15+ годами опыта в разработке ПО, архитектуре и управлении инженерными организациями — от самостоятельного создания сложных систем до ролей CTO и CDO. Строил AI-решения для крупных корпоративных клиентов, масштабировал AI-направление до команды в 60 специалистов. Опыт в agentic AI: агенты для бизнес-процессов и внедрения AI-native SDLC в командах разработки. Компетенции закрывают весь цикл: архитектура, инженерные процессы, организационные изменения и коммерческий результат.
На первом созвоне разбираем, как сейчас устроена постановка задач и разработка, где AI уже используется, и что реально измерить. По итогам — понятная картина: какой Harness собирать и с какой команды начинать.
Свяжемся в течение одного рабочего дня. Если удобнее сразу написать — hello@praxor.ru.