AI SDLC: сокровенные сведения о правилах разработки ПО с помощью ИИ

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

Код — не главное. ИИ всё напишет. Главное — ЧТО она напишет?! Каков ваш замысел?

Это меняет саму экономику разработки. Если раньше значительная часть времени уходила на ручное написание и проверку программного кода, то теперь всё больше работы можно передать агентам. Одновременно возникают новые ограничения: качество спецификаций, управление контекстом, согласование решений, архитектурный контроль и способность организации управлять большим количеством параллельно работающих агентов.

Что такое AI SDLC

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

Предыстория

Классический Software Development Life Cycle строится вокруг последовательности этапов, на которых люди анализируют потребность, формируют требования, проектируют систему, пишут код, тестируют его, разворачивают программное обеспечение и затем сопровождают его. Автоматизация отдельных операций существовала давно, однако ключевые интеллектуальные решения оставались за специалистами.

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

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

Расшифровка

AI SDLC — сокращение от Artificial Intelligence Software Development Life Cycle, то есть жизненный цикл разработки программного обеспечения с использованием искусственного интеллекта. Термином обозначают модели разработки, в которых ИИ используется системно на разных этапах создания и сопровождения ПО.

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

Суть

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

В AI SDLC меняется не только инструмент разработки — меняется распределение интеллектуального труда между человеком и машиной.

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

Простыми словами

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

Например, вместо задачи для разработчика:

Добавить в систему возможность согласования заявки руководителем.

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

Особенности и характерные черты

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

Это не автоматизация отдельных этапов, а новая модель разработки

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

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

Основные изменения можно представить следующим образом:

• человек задаёт намерение, цели и ограничения;
• ИИ-агент анализирует контекст и предлагает план действий;
• агенты выполняют реализацию и проверки;
• человек контролирует критические решения и принимает результат;
• спецификация сохраняет согласованное состояние системы и замысел продукта.

Петли требований, намерений и реализации

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

AI SDLC становится системой взаимосвязанных петель, а не однонаправленной последовательностью этапов.

Упрощённое сравнение можно представить так:

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

Особенно важным становится разделение на Intent Loop и Implementation Loop. В первой петле уточняется намерение — что именно должна делать система. Во второй агент превращает это намерение в работающий результат.

Петля	Основной вопрос	Типовая работа
Intent Loop	Что и зачем нужно создать?	Потребность, требования, спецификация, ограничения, согласование.
Implementation Loop	Как реализовать согласованный замысел?	План, код, тесты, исправления, сборка, развёртывание.
Обратная связь	Соответствует ли результат намерению?	Проверка, ревью, обнаружение расхождений и уточнение спецификации.

Именно поэтому ускорение Implementation Loop без ускорения Intent Loop не гарантирует такого же ускорения всего жизненного цикла. Если команда не успевает принимать решения, уточнять требования и согласовывать результат, производительность агентов упирается в человеческие ограничения процесса.

Спецификация как главный артефакт. Зарождение SDD

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

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

Отсюда возникает Spec-Driven Development (SDD) — разработка, управляемая спецификацией. Код перестаёт быть единственным главным артефактом. Спецификация фиксирует намерение, требования и ограничения, а код рассматривается как их реализация.

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

Context Engineering — управление контекстом

В AI SDLC недостаточно научиться писать хорошие промпты. Агенту требуется гораздо больше информации: требования, исходный код, архитектура, бизнес-правила, документация, результаты предыдущих запусков, ограничения безопасности и история решений. Поэтому на первый план выходит Context Engineering — системное управление контекстом, который получает агент.

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

• формирование контекста;
• актуализация и версионирование;
• фильтрация нерелевантной информации;
• контроль доступа;
• маршрутизация контекста между агентами;
• контроль объёма и стоимости контекста.

Harness важнее LLM

Качество AI SDLC определяется не только тем, какая языковая модель используется. В реальном проекте модель работает внутри harness — управляемой среды, которая предоставляет ей контекст, инструменты, права доступа, правила и механизмы проверки.

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

Поэтому в корпоративном AI SDLC важными становятся:

• контекст — что агент знает;
• инструменты — что агент может делать;
• разрешения — что ему позволено;
• проверки — как контролируется результат;
• наблюдаемость — кто и почему выполнил действие;
• governance — какие правила распространяются на агентов.

Мультиагентная разработка

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

Упрощённый сценарий может выглядеть так:

Product Agent
    ↓
Architecture Agent
    ↓
Coding Agent
    ↓
Testing Agent
    ↓
Security Agent
    ↓
Documentation Agent

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

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

Экономика токенов

У агентной разработки появляется собственная экономика. Каждый запрос к модели имеет стоимость, а сложная задача может потребовать десятков или сотен итераций: анализ контекста, планирование, генерация, запуск тестов, исправление ошибок и повторная проверка.

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

Для CIO постепенно становятся релевантными показатели, которые раньше практически не учитывались в управлении разработкой: стоимость агентного цикла, количество итераций, объём передаваемого контекста, стоимость проверки результата и доля задач, завершённых без вмешательства человека.

Проблемы и узкие места

Ускорение разработки с помощью ИИ не означает автоматического ускорения выпуска продукта. Наоборот, устранение одного ограничения быстро выявляет следующее. Поэтому AI SDLC необходимо рассматривать как систему с новыми узкими местами, а не только как способ увеличить производительность программистов.

Самое долгое теперь — совещания

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

Когда один участок процесса ускоряется в несколько раз, узким местом становится следующий этап цепочки.

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

Именно здесь возникает необходимость сокращать лишние согласования, формализовать критерии приёмки, автоматизировать проверки и переводить часть решений из совещаний в правила и спецификации.

Съест много токенов, если не уследить

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

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

Поэтому эффективный AI SDLC требует контроля не только качества ответа, но и стоимости достижения результата.

Инженерные и архитектурные решения остаются за человеком

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

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

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

Работы будет только больше: парадокс Джевонса

На первый взгляд рост производительности ИИ должен привести к сокращению объёма разработки. Однако здесь может проявиться парадокс Джевонса: повышение эффективности использования ресурса не обязательно уменьшает его суммарное потребление. Более дешёвая разработка делает экономически целесообразным создавать больше программных решений.

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

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

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

Для CIO это означает, что управление ИТ в эпоху AI SDLC может стать даже сложнее. Потребуется контролировать не только портфель приложений и команды разработчиков, но и портфель агентных систем, контекстов, спецификаций и автоматизированных процессов. Чем дешевле становится создание ПО, тем важнее становится архитектура всего цифрового ландшафта.