От легаси до Greenfield Один агентный SDLC — два очень разных пути

Сегодня я рад впервые выступить на баркемпе и рад, что мы организуем баркемп именно по этой теме. Поэтому хочу поговорить про тему, которую вы видите на экране, — от легаси до Greenfield. И здесь сразу проговорю, что расскажу наш путь: как мы к этому пришли, как у нас это работает, и в целом покажу прямо на слайдах, прямо на практике, что абсолютно любой проект можно перевести на агентскую разработку. Суть только в том, что этот путь будет абсолютно разным. Где-то это будет легко, где-то сложно, но абсолютно любой проект, абсолютно любое легаси можно перевести на агентскую разработку.

Путь, который мы прошли

Давайте расскажу про путь, который мы прошли. Этапы, которые, я уверен, есть в каждой компании. Все начинали свой путь, абсолютно все, кто здесь присутствует, с бесплатных инструментов, с чатиков DeepSeek, с чатиков того же ChatGPT и подобного. И простой процесс вайб-кодинга, который был у всех.

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

Переход на корпоративные подписки

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

И с этим нужно было что-то делать. Поэтому мы перешли на корпоративные подписки — Claude, Cursor, Codex, но основную часть у нас занимает наш GitWay, и всю инфру мы строим на OpenCode. И в целом теперь эта система позволила получить управляемый процесс, предсказуемый процесс в плане бюджетирования и инструментарий, который позволяет мерить качество, пользу и вообще в целом использование внутри компании.

Классический SDLC и агентский SDLC

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

Все помнят классический SDLC. До моего выступления мне задавали вопрос, что такое SDLC. Если говорить кратко, не вдаваться в подробности, это процесс создания программ от начала до конца. Всё, надеюсь, я ответил на вопрос. Именно поэтому все помнят классический SDLC из 2015, из 2020 года, когда на каждом участке создания продукта стоял человек. И скорость разработки заключалась в том, насколько быстро контекст передаётся между ролями и насколько масштабно и быстро мы можем расширить команду, которая у нас есть.

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

Что такое агентский SDLC? Это процесс, когда главная фишка — в передаче контекста. У нас каждый этап стандартного SDLC закрывается агентами.

От промпт-инжиниринга к контекст-инжинирингу

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

Как устроен процесс SDLC изнутри

Если говорить про то, как у нас устроен процесс SDLC изнутри, то есть контекст. Подробнее разберу на следующих слайдах, но в целом контекст мы пережили несколько итераций. Мы работали с различными тулзами, поднимали отдельную базу, в которой хранили контекст, использовали различные тулзы, которыми пестрит Instagram, запрещённый в Российской Федерации, и другие соцсети.

И в какой-то момент мы просто пришли к банальному, что доступно каждому, — к хранению контекста непосредственно в репозиториях. Мы работаем по формату Spec. То есть, я думаю, все понимают, что такое SuperPowers, все знают методологию по формированию спецификаций. И до начала реализации мы всегда формируем спеку. То есть у нас в репозиториях хранятся спецификации, мы всё это храним. И если говорить про процесс, то тут стоит проговорить важную особенность.

Весь процесс должен покрываться агентами

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

В целом, если смотреть на базовый компонент, то AGENTS.md — это инструмент и выходная информация для любого агента разработки, любого агента полного цикла: как работать с проектом, как себя вести. Для этого у нас в том числе есть базовая MCP-шка. Кстати, вопрос, который сегодня очень популярен. Я надеюсь, все понимают, что такое MCP-шка. Если нет — расскажу после выступления.

В общем, если смотреть на базовые спеки: ARCHITECTURE.md — здесь сразу же агентам рисуются архитектуры, формируются и фиксируются потоки, и в целом техническое описание процесса. PROJECT.md — это бизнес-контекст, это ограничения, это скоуп, по которому мы работаем. DATABASE.md — это модель данных, которая сразу же фиксируется и дорабатывается итеративно в рамках разработки через агентов. Ну и различные ADR-ки, сервисы интеграции.

Знания находятся внутри репозитория

Главная фишка, которая получается из этого набора, — это то, что теперь знания про проект, про разработку, про технологии находятся непосредственно внутри репозитория.

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

Кто управляет контекстом

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

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

Дежурные агенты

Хочу рассказать про дежурные агенты, как мы их называем в нашей компании, которые внедряются абсолютно на всех проектах до момента, когда разработка перешла на агентский режим. Агент ревью — я думаю, здесь не стоит что-то дополнительно пояснять. Все понимают, как что запускать, как это делать на локальных клаудах, как внедрять в CI/CD.

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

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

Что это даёт

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

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

Агентский SDLC — это про рост сотрудников

Я считаю, что агентский SDLC — это про рост сотрудников, рост непосредственно в архитектурную сторону. И смотрите, я тот человек, который писал абсолютно все мейнстримные штуки на всех мейнстримных языках. И хочу сказать, что сейчас все инженеры, кто переходит в агентский режим, становятся более широкими. Потому что больше нет жёсткой привязки к стекам. Нужно понимать только базовые инженерные навыки, и специалисты выступают непосредственно оркестраторами.

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

Проекты на берегу: от легаси до Greenfield

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

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

Чек-лист готовности

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

• Тесты. Любой проект, который реализуется и в который внедряется агентская разработка с помощью ИИшки, должен быть обвязан тестами. И это гарантия безопасности, гарантия стабильности, и в целом SDLC агентской разработки построен, в частности, на TDD-методологии, которая как раз строится через спецификации.
• Модульность. Насколько проект существует с изолированными доменами, насколько можно говорить про выделение отдельных участков, которые имеют только собственную ответственность и контекст.
• Контекст. Это моё любимое. Я постоянно про это говорю. Говорю на каждом созвоне в рамках компании, говорю на дадтолках, которые вот буквально вчера несколько тем разгоняли, связанных с контекстом. Насколько архитектура и информация по проекту не лежит в головах сотрудников? То есть насколько она перенесена на бумагу, насколько её можно было оцифровать. Насколько контекст проекта лежит в репозитории либо в любой базе знаний, которую можно оформить.
• Автоматизация. Насколько автоматизирована сборка, насколько автоматизирована выкладка приложения. Насколько доступна воспроизводимая среда для запуска агентов — опять же, для тестирования.
• Стандарты кода. Насколько код соответствует стандартам? Есть ли у него чёткий codestyle, проходит ли он ряд линтеров? И вот здесь мои улыбки, которые могут сейчас возникнуть, — вроде бы какая-то банальщина. Но любой агент, если внедрять ему чёткие стандарты, будет повторять стилистику, будет повторять архитектурные решения, те, которые есть сейчас в поле. То есть если засунуть строчку контекста проекта в агент, то он будет попусту, без стандарта, без чётко заданных требований, повторять то, как это написано.

Светофор готовности

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

Кейс: десятилетний легаси

Что касается легаси, хочу рассказать про кейс, который был у нас в компании. Для меня он был особенно ярким. Представьте десятилетний легаси, который не документирован. Я думаю, все сталкивались с такими проектами. У которого есть команда, которая 10 лет его пишет. Команда, понятно, обновляется, и остаётся буквально три человека — держателей контекста. То есть это три бутылочных горлышка, которые знают, что вот это вот не трогай, вот сюда не тыкай, а вот здесь я потрачу неделю на то, чтобы какие-то базовые вещи, которые все понимают, например, какую-нибудь кнопку на новый объект стащить, потрачу неделю на это.

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

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

Движение по изолированным доменам

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

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

Монорепа и результат

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

И что мы имели раньше? Раньше мы имели буквально 2–3 носителя знаний, которые обладали информацией по проекту. Сейчас мы имеем чёткий контекст, который пишет сам агент. 70% кода на этом проекте реализуется через агента. Если раньше были ситуации, когда нам приходилось увеличивать команду либо, шутки ради, стоять, чтобы уместиться в спринты, сейчас мы перешли к режиму, что полностью реализуем спринты, которые формируем практически в середине проекта, и быстрее клиенты приходят и просят задать ещё. То есть у нас клиенты не успевают генерировать бизнес-задачи за период, который мы тратим на разработку на этом проекте.

Грабли, на которые мы наступали

И стоит проговорить про грабли, на которые мы наступали и с которыми столкнулись.

• Первая грабля. Скормим агенту весь монолит, и всё будет хорошо. Нет, не будет хорошо. Если монолиту засунуть кучу кода, то чем больше контекста, с которым он будет работать, тем хуже он начнёт писать. Многие говорят о том, что вот появились новые модели, в них входит миллион токенов, контекст так много увеличился. Бессмысленно. Каким бы контекстное окно ни было большим, у любой модели, которую вы используете для разработки, оно всё равно будет всё рушить. Поэтому не нужно сразу кормить весь монолит, надеясь на то, что всё будет хорошо.
• Вторая грабля. Агент учится у вашего кода, я уже проговаривал: если код написан плохо, если никаких стандартов кода не выдвигается, агент начинает повторять паттерны, которые из раза в раз те или иные разработчики повторяют на проекте. И здесь стоит сказать про то, что как раз эта грабля стабилизировала нас на создании нашей MCP-шки со стандартами кода, со стандартами агентов. У нас в целом мы фокусировали template bridge, я думаю, каждый слышал этот плагинчик, который активно используется. И в его проекты, в технологии, засунули агентов, засунули требования к коду и активно дёргаем ремиум-агентами. Опять проект подцепляем, и за счёт этого у нас теперь качество кода, которое выходит на выходе, всегда предсказуемо хорошее.

Ну, размытые контракты и длинные знания мы уже проговорили.

Обратная ситуация: проект с нуля в агентском режиме

Теперь давайте поговорим про ситуацию, когда у нас абсолютно обратная история. Давайте поговорим про обратную ситуацию, когда проект с нуля сразу же реализуется в агентском режиме.

У нас внутри была утилита, внутренний продукт, который использовался 1С-аналитиками. Он назывался «Аналитик Крякер» в первой своей версии. И это была внутренняя система работы с документами. Там был цикл работы непосредственно аналитиков по скоупу, который принят в СОУ-4. Мы с помощью полного цикла формирования документов закрывали.

В какой-то момент мы увидели, что стоит этот проект развивать. Увидели его масштабность и перевели в проект, который называется ArtiRub. ArtiRub — это продукт, который полностью родился в агентском режиме. Представьте, у вас есть архитектура, которая сразу же построена под агента. Сейчас я её отдельно покажу. У вас сразу же есть контекст проекта с первого коммита. У вас продукт полностью может рефакториться, тяжёлые задачки выполняться буквально за считанные часы вместо месяцев и лет.

Архитектура под агентский режим

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

Упираясь в контекст, я хочу проговорить про контекст. Ядро чистое, ядро, которое содержит чисто базовую логику продукта, и оно не дописывается, оно переходит от версии к версии, но здесь не нужно ничего менять. Прелесть этой архитектуры как раз в этих двух объектах, которые вы видите на экране. Это Extension SDK и расширения.

В целом, Extension SDK и сама архитектура ArtiRub построены таким образом, что у нас есть реестр плагинов, реестр расширений, которые мы можем активно подключать и менять полностью, дорабатывать системы. То есть вся доработка продукта происходит не за счёт переписывания всего сервиса, а за счёт написания конкретного расширения.

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

Что это даёт

И что это главное даёт? Это даёт огромный буст разработки, предсказуемый качественный результат, который сразу покрыт тестами — за счёт написания вот такого рода расширений, за счёт такой архитектуры. Задачи, которые вы видите на экране, — многие, я думаю, эти задачи проходили, и у кого-то даже волосы выпадали, особенно при миграции. Такая архитектура позволяет быстро, предсказуемо делать большие задачи, на которые раньше требовалось не один месяц разработки.

Что уместить в забор

Что уместить в забор? Смотрите, я до этого показывал чек-лист, поэтому по чек-листу можно быстро пропустить свой проект. И в целом хочется проговорить, что этот чек-лист, который родился у нас итеративным путём, на практике, мы потом увидели у компании Factory AI. У них есть framework, можете ознакомиться, — Agent Readiness, который показывает 8 слоёв репозитория и демонстрирует готовность к агентской разработке. То есть мы совпали в наших мнениях, в нашей практике с этой компанией, и считаю, что этот чек-лист в целом подойдёт абсолютно всем.

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