Habr: Agentes de IA transformam delivery, e equipes precisam reconstruir todo o ciclo de desenvolvimento

На Habr вышел разбор того, почему с приходом ai-агентов инженерные команды упираются уже не в скорость написания кода, а в стоимость проверки и передачи контекста. Автор ссылается на DORA 2025, где AI на работе используют 90% технологических специалистов, а более 80% связывают его с ростом продуктивности. Но чем быстрее создаются код, ADR и документация, тем сильнее растет нагрузка на ревью и контроль стабильности.

Поэтому смотреть на AI предлагается не как на очередной инструмент внутри старого процесса, а как на повод пересобрать весь цикл поставки изменений. В статье разделяют три режима работы. Первый — ai-assisted development, когда модель помогает быстрее собирать требования, писать черновики ADR, тест-кейсы или документацию, но сам процесс остается прежним.

Второй — agentic delivery, где агент уже читает репозиторий, готовит изменения, гоняет проверки и открывает PR, а человек подключается на эскалациях. Как пример такого сдвига автор упоминает вывод GitHub Copilot coding agent в general availability. Третий режим — ai-native sdlc: здесь LLM перестает быть «чатом сбоку» и становится интерфейсом к рабочему контуру, через который команда двигает задачу от идеи до релиза.

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

Поэтому командам нужен внешний, машиночитаемый контекст, доступный и людям, и агентам: цели, ограничения, риски, критерии готовности, ADR, API-контракты, security-правила, команды локальной проверки и заметки по rollout. Если критическое знание продолжает жить в чатах, созвонах и памяти отдельных разработчиков, агент просто работает по неполной картине. Отсюда вытекает и новый фокус на harness — среде исполнения агентов.

Речь уже не о большом системном промпте, а о наборе правил и ограничений, встроенных в процесс. В репозитории должны появляться явные инструкции для агентов, команды сборки и тестов, критерии готовности, архитектурные и безопасностные ограничения. Повторяемые сценарии предлагается оформлять как skills, playbooks и repo rules, а не объяснять заново в каждом чате.

Причем ограничения должны быть не только текстовыми: система должна уметь останавливать рискованные действия, запрещать merge без подтверждений и переводить спорные шаги на человека. Отдельно автор разбирает слой контроля. В ревью должен приходить не просто diff, а evidence pack: что именно поменялось, какие сценарии покрыты, какие проверки прогнаны, какие риски остались и как откатить изменение.

Поверх этого нужны quality gates — лимиты на размер изменений, обязательные validate-команды, проверка архитектурных ограничений и синхронное обновление документации. Еще один слой — evals для повторяющихся задач. Они позволяют явно зафиксировать ожидаемое поведение агента и проверять, остается ли workflow стабильным после очередных изменений, а не скатывается ли процесс в дорогой вариант vibe coding с потоком шумных PR.

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

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

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