Код научился писать себя. Теперь разработке нужно научиться фиксировать решения

Релиз, который застрял после готового кода

Представьте: утром команда отдаёт задачу coding-агенту, а к обеду получает работающий diff с тестами. Кажется, релиз должен случиться завтра. Но затем выясняется, что критерии приёмки неполны, решение расходится со старой спецификацией, security-review будет только в четверг, а никто уже не помнит, почему ограничение появилось два года назад.

Код готов. Работа — нет. Именно с этого парадокса начинается опубликованный Anthropic AI-Native SDLC Playbook. Когда Build сокращается с недель до часов, старый процесс не ускоряется целиком. Он просто начинает быстрее упираться в Plan, Test, Deploy и Maintain — этапы, которые всё ещё живут в человеческом темпе.

Anthropic разворачивает конвейер в петлю

Обычный SDLC похож на эстафету. Идея переходит к product manager, требования — к архитектору, дизайн — к разработчику, код — к QA и release-команде. Каждая роль получает документ, тикет или ссылку и пытается восстановить замысел предыдущей.

Anthropic предлагает перестать воспринимать Plan, Design, Build, Test, Deploy и Maintain как шесть изолированных комнат. В AI-native SDLC это одна петля: принятый результат этапа запускает следующий, а production-инцидент возвращается в начало уже как новый intent.

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

• Plan: исходная проблема превращается в понятный человеку и агенту intent.
• Design: intent становится требованиями и технической спецификацией с учётом правил компании.
• Build: агент создаёт план, код, тесты и сопутствующую документацию.
• Test: проверки и evals выполняются постоянно, а не только на границе этапа.
• Deploy: автоматические слои review проверяют стандартные риски, а человек рассматривает критические решения.
• Maintain: агенты отслеживают эксплуатационные сигналы, диагностируют проблему и возвращают её в новый цикл.

У каждого решения должна остаться память

В модели Anthropic каждый этап заканчивается сохранённым артефактом, который может прочитать следующий агент и проверить человек: intent, spec, plan, diff с тестами, pull request с результатами review или запись об инциденте. История изменений одновременно становится audit trail: видно, кто сформулировал запрос, что создал агент и кто подтвердил результат.

Это важнее выбора формата файла. Компания может хранить intent в Git, Jira или другой системе, если определён источник истины и объекты связаны между собой. Проблема начинается, когда задача существует отдельно от решения, спецификация — отдельно от реализации, а причина изменения остаётся только в переписке.

Мы называем это «Контекст → Генерация → Контекст»

За два месяца до публикации playbook Anthropic основатель Laplace Александр Некрашенко описал ту же проблему со стороны инженерной команды. Когда агент генерирует тысячу строк за час, понимание системы больше не возникает автоматически в процессе ручного написания кода. Команда может получить работающий результат, но потерять знание о том, почему система устроена именно так.

Предложенная формула нового цикла — «Контекст → Генерация → Контекст». На входе команда собирает задачу, ограничения, архитектуру и правила для агента. На выходе возвращает в рабочие системы причины решений, связи с задачами, описание изменений и новое знание о продукте. Следующая итерация начинается с этого сохранённого контекста, а не с повторного исследования кода.

Anthropic формализует этот принцип на уровне всего SDLC. Intent, spec, plan, diff, результаты review и запись об инциденте становятся последовательными носителями контекста. Форматы отличаются, но задача одна: не позволить пониманию исчезнуть между генерацией, проверкой и следующей итерацией.

Laplace работает этажом выше кода

Coding-агент видит репозиторий. Но причина, по которой ему вообще понадобилось менять код, почти всегда живёт где-то ещё. Клиент пожаловался в одном месте, product manager создал задачу в другом, требования обновили в Confluence, архитектурное исключение обсудили на встрече, а прошлую реализацию можно понять только по GitHub.

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

• Jira даёт задачи, статусы, комментарии, участников и историю работы.
• Confluence хранит требования, решения, регламенты и проектную документацию.
• GitHub связывает требования с issues, pull request, diff и файлами реализации.
• Документы workspace дополняют процесс спецификациями, таблицами, презентациями и другими материалами.
• Context Audit показывает неполные задачи, пробелы документации, слабые связи и незавершённые решения.
• Цифровые сотрудники собирают, проверяют и передают контекст для конкретной роли процесса.

Laplace не заменяет среду программирования, CI/CD или coding-агента. Его роль — сделать корпоративный контекст доступным управляемой цифровой команде и сократить потери информации на переходах между людьми, агентами и системами.

Понедельник. Запрос ещё не стал задачей

Новый цикл начинается не с промпта «напиши фичу». В понедельник нужно поймать intent: чья это проблема, какой результат нужен, какие системы затронуты, где проходят границы и что пока неизвестно. В модели Anthropic этот черновик проверяет product owner, и только после этого он становится основанием для дизайна.

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

• Найти первоначальный запрос и затронутых пользователей.
• Сопоставить задачу с актуальными требованиями и прошлыми решениями.
• Выявить отсутствующие критерии приёмки, ограничения и владельцев.
• Подготовить структурированный brief для product owner и engineering.
• Оставить утверждение требований ответственному человеку.

Среда. Код уже готов, понимание ещё нужно проверить

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

Laplace может подготовить входной контекст для такой сессии: связанные требования, решения, задачи, pull request и релевантные документы. После реализации цифровой сотрудник может сопоставить diff с исходной постановкой, проверить наличие связей и выделить вопросы для review. Фактическое выполнение тестов и изменение кода остаётся задачей coding-агента и инженерного toolchain.

Пятница. Релиз заканчивается новой памятью, а не кнопкой Deploy

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

В текущем Laplace действия зависят от доступных агенту инструментов и прав workspace. Предложения по изменениям могут оставаться черновиками до явного подтверждения. Цифровой release-координатор может собрать задачи, изменения, документацию и открытые вопросы в единый пакет для решения о выпуске, но само решение остаётся за ответственными людьми.

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

Где красивая схема сталкивается с реальностью

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

• Laplace уже соединяет рабочие источники и позволяет создавать специализированных цифровых сотрудников.
• Context Audit уже помогает находить контекстный долг по доступным данным.
• Автоматизации Laplace запускают одного настроенного агента по расписанию через доступные ему инструменты.
• Произвольная событийная оркестрация всех шести стадий SDLC пока не реализована.
• Единый Knowledge Graph и Process Discovery Agent находятся в развитии и не являются доступными функциями продукта.

Поэтому разумный сценарий внедрения — использовать Laplace рядом с coding-агентами: сначала наладить контекст и отдельные роли на самых болезненных handoff, измерить эффект, а затем постепенно связывать проверенные этапы.

Что можно изменить уже в понедельник

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

• 1. Выберите один handoff: идея → постановка, спецификация → разработка, pull request → релиз или инцидент → новая задача.
• 2. Измерьте baseline: время ожидания, число возвратов, пропущенные требования и ручной поиск информации.
• 3. Определите источник истины и связи между Jira, Confluence, GitHub и дополнительными документами.
• 4. Проведите Context Audit и устраните критические пробелы.
• 5. Создайте одну цифровую роль с ограниченными инструментами и проверяемым результатом.
• 6. Определите точку человеческого подтверждения и ответственность за решение.
• 7. Сравните длительность, полноту и качество нового процесса с baseline.
• 8. Автоматизируйте следующий переход только после устойчивого результата.

Частые вопросы об AI-native SDLC

Что такое AI-native SDLC?

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

Чем AI-native SDLC отличается от AI-кодинга?

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

Заменяет ли Laplace Claude Code?

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

Может ли Laplace автоматизировать весь SDLC?

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

С какого этапа SDLC лучше начать?

Начните с перехода, где команда регулярно теряет время или контекст и может измерить результат: подготовка постановки, сбор контекста перед разработкой, проверка соответствия реализации требованиям или подготовка release-пакета.