Ускоряем разработку ПО с помощью AI
За 3 месяца выстраиваем AI SDLC на пилотной команде: встраиваем AI-агентов в процесс разработки, измеряем, как изменились скорость и качество, и готовим процесс к переносу на остальные команды.
AI ускоряет написание кода. Но не обязательно ускоряет разработку
Разработчики уже пишут код в Cursor и Claude Code и решают отдельные задачи быстрее. Но работа команды в целом ускоряется намного меньше.
Каждый использует свои инструменты, промпты и подходы. Удачные приёмы знает один человек, и до других команд они не доходят.
Код пишется быстрее, а постановка задач, ревью, тестирование, исправления, согласования и выкладка занимают всё больше времени.
Требования живут в Jira, знания — в Confluence и головах разработчиков, архитектурные правила — в истории code review. Агент до этих знаний не дотягивается.
Кода и PR становится больше. Но непонятно, быстрее ли задачи доходят до релиза, больше ли команда выпускает и не стало ли больше переделок.
Чтобы AI ускорил всю команду, мало ускорить написание кода. Нужно перестроить весь путь задачи: от требования до production.
Четыре уровня. Большинство команд стоит на первом
Путь всегда начинается с личных инструментов разработчика. На следующем шаге команды обычно застревают. Чтобы перейти с первого уровня на третий, нужно менять то, как в компании ставят и принимают задачи. Более мощный агент этого не заменит.
На диагностике мы определяем, где вы сейчас, и какой переход даст эффект в этом году. Прыгать через уровень бесполезно.
Разработчики берут Cursor, Claude Code и другие инструменты под код, тесты и разовые задачи. Быстрее работает отдельный человек.
Агент получает задачу с контекстом и сам делает большую часть изменения. Разработчик ставит задачу и принимает результат, а руками пишет меньше кода.
Спеки, специализированные агенты и quality gates собраны в один процесс от требования до production. Человек проверяет работу в контрольных точках. Ускоряется весь путь задачи до релиза.
Команды работают на общей инфраструктуре: общие знания, правила, агенты, проверки и метрики. Новая команда сразу работает по готовому процессу.
AI Harness — среда, в которой команда и агенты работают вместе
Спецификация становится главным документом задачи: агенты пишут код по спеке, люди ставят рамки и принимают результат. Агент сдаёт работу агенту-проверяющему. Если проверка не прошла три раза подряд, задачу забирает человек.
Типовые задачи проверяются автоматически. Там, где ошибка дорого стоит, код смотрит человек.
Критерии приёмки привязаны к тестам, поэтому агент не додумывает требования сам.
Архитектурная карта, контракты, журнал решений — версионируются в git рядом с кодом.
Инструкции агентам под ваш стек и кодовую базу. Человек проверяет изменения, которые могут задеть другие части системы.
Пять шагов: от диагностики до передачи процесса вашей команде
Наш агент сканирует репозитории, архитектор разбирает архитектуру и процессы. Смотрим, где ставятся задачи: в Jira, от которой нельзя отказаться, или в markdown-спеках прямо в репозитории.
Фиксируем стартовые метрики, чтобы через три месяца сравнить результат с цифрами.
Правила, база знаний, спецификации и quality gates под ваш стек.
Сам Harness собирается за несколько дней. Остальное время уходит на договорённости о ролях: кто в команде отвечает за Harness дальше.
Пилотная команда проводит две-три реальные задачи из своего бэклога через весь цикл: спека, код от агента, проверка, выкладка. После воркшопа команда работает только по новому процессу.
Чтобы команда не боялась пробовать, на время пилота отключаем KPI по дефектам. Если скорость и падает, то меньше чем на неделю.
Архитектор доступен в чате. По git видно, где работал агент, а где человек исправлял код руками. Каждый такой случай разбираем и меняем по нему правила Harness. Раз в неделю команда привязывает дефекты к спекам.
Если продолжать править код руками, ошибка повторится в следующей задаче. Исправлять нужно правила и проверки, из-за которых она появилась.
Через три месяца сравниваем со стартовым замером DORA-метрики и AI-метрики: какую долю решений принимают агенты и как эти решения влияют на качество.
Следующую команду запускают уже ваши люди: 1–3 сотрудника, которых мы готовим с первого дня как внутреннюю команду Harness. Новая команда начинает с готового Harness.
Всё живёт в вашем репозитории как часть кодовой базы и работает после нашего ухода.
Как выглядит зрелый процесс на практике
Клиенты анонимизированы по условиям соглашений. Ниже — как устроен процесс, который мы выстроили в реальных командах.
Команда уже уверенно работала с агентами на отдельных задачах и перешла на цепочку агентов, которые сами передают задачу друг другу: Planner создаёт ветку, MR и обновляет спеки, Coder пишет код, Reviewer проверяет код и CI.
человеком
человеком
Единый LLM-шлюз: все запросы к провайдерам идут через него и логируются, ключи изолированы, у команд есть бюджеты токенов, модель выбирается по требованиям безопасности и цене. Чувствительные задачи решает модель на серверах компании.
Смена модели не требует переделки кода агентов.
Команда из восьми человек ведёт несколько продуктов одновременно на общем корпоративном harness. Проверки качества выполняют агенты: одна модель пишет код, другая его проверяет. Правило «автор не ревьюит свой код» действует и для агентов.
Пять принципов работы
Готового решения из коробки у нас нет. Агентов и правила команда собирает под свой стек и кодовую базу вместе с нами. То, что команда сделала сама, она потом и поддерживает.
База знаний, журнал решений, промпт-шаблоны и регламенты живут в вашем репозитории как часть кодовой базы и работают после нашего ухода.
Задачи, которые затрагивают один модуль, проходят автоматические проверки. Задачи, которые задевают другие команды, агент сам отправляет на архитектурное ревью.
Главное изменение для разработчика: он правит инструкции агентам, а код получается из них. Исправлять код руками после агента — как править бинарник после компилятора.
Команда из шести человек после внедрения делает ту же работу составом два-три: тестирование и часть инженерных задач забирают агенты. А подразделения, которым разработчиков не выделили бы, получают сотрудника, который делает для них инструменты с агентами на готовом 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 в командах разработки. Компетенции закрывают весь цикл: архитектура, инженерные процессы, организационные изменения и коммерческий результат.
Ведёт внедрение от диагностики до результата и отвечает за то, чтобы новый процесс прижился в команде. 20 лет меняет то, как работают команды, сейчас операционный директор ScrumTrek. С 2023 года занимается AI в управлении: сооснователь Кактус.AI, соавтор методики Oper8, с которой 50+ компаний перестраивали процессы. Знает, где люди сопротивляются изменениям и что с этим делать.
Начнём с разговора о вашей команде
На первом созвоне разбираем, как сейчас устроена постановка задач и разработка, где AI уже используется, и что можно измерить. После созвона будет понятно, какой Harness собирать и с какой команды начать.