Что усилить при внедрении агентной разработки
Допустимая автономность определяется проверяемостью результата.
Это аналитическая выжимка из стрима «Как писать код с AI-агентами?». Ссылка открывает содержательную часть после предэфирной беседы. Шесть направлений ниже опираются на высказывания участников стрима, а конкретные чек-листы и способ проверки на пилотах — авторская систематизация, а не дословные рекомендации спикеров.
Шесть усилений
1. Проверка готовности кодовой базы к работе с ИИ
Оценивать не только зрелость команды и процесса, но и техническую способность агента выполнить работу:
- найти нужную часть системы по карте модулей, сервисов и терминов;
- понять внутренние и внешние границы, зависимости и межсервисные процессы;
- воспроизвести нужный контур локально или в безопасной тестовой среде;
- самостоятельно замкнуть цикл обратной связи (
feedback loop) через тесты, статический анализ (lint), проверку типов (type-check), контрактные или сквозные проверки (end-to-end); - получить машинно проверяемый сигнал о нарушении архитектуры.
Это превращает вопрос «есть ли AGENTS.md?» в проверку реальной исполнимости процесса агентом.
Связь с источником: карта системы, контракты и возможность сквозной проверки — с 1:11:04.
2. Проверяемость определяет допустимую автономность
Для каждого процесса-кандидата задавать вопрос:
Как без экспертного чтения всего результата отличить хорошее выполнение от плохого?
Если автоматического или дешёвого проверочного сигнала нет, агент готовит черновик, исследование или предложение. Если есть тест, схема, инвариант, контрольный набор данных или воспроизводимый расчёт, агент может вести процесс до следующей контрольной точки с человеком.
Связь с источником: проверяемые артефакты и передача результата человеку — с 56:43.
3. Архитектура как исполняемые ограничения
Текстовые журналы архитектурных решений (ADR), схемы C4 и правила полезны, но для критичных границ нужен хотя бы один исполняемый механизм:
- тесты зависимостей или архитектурные тесты;
- проверка OpenAPI, AsyncAPI или других схем;
- контрактные тесты;
- запрет циклических или неразрешённых зависимостей;
- мутационное тестирование критичной бизнес-логики.
Цель — сделать архитектуру не только подсказкой агенту, но и автоматически проверяемым ограничением.
Связь с источником: контракты и OpenAPI — с 1:10:34, архитектурные тесты как исполняемое представление архитектуры — с 1:29:08, мутационное тестирование — с 31:19.
4. Проверочные наборы для промптов и инструкций
Относиться к промпту или инструкции как к недетерминированной программе. Практический набор проверочных примеров может содержать:
- реальные или обезличенные задачи;
- ожидаемое условие вызова (
trigger): должна ли инструкция примениться; - обязательные ограничения результата;
- критерии успешного и неуспешного выполнения (
pass/fail); - модель и её версию;
- несколько повторных прогонов;
- журнал ухудшений после изменения промпта, модели или контекста.
Проверять нужно не только тело инструкции, но и её описание: ложный вызов или пропущенный вызов ломает процесс раньше исполнения инструкции.
Связь с источником: как понять, что промпт хороший, и зачем проверять инструкции на наборе данных — с 1:42:54.
5. Наблюдаемость агентского процесса
Для пилотной выборки задач сохранять структурированный след:
- входную задачу и спецификацию;
- модель и конфигурацию;
- использованные инструменты;
- длительность и стоимость;
- человеческие вмешательства;
- результаты автоматических проверок;
- возвраты на доработку;
- итоговый инженерный или бизнес-результат.
Для пилота не обязательно сразу строить общее хранилище данных (data lake). Достаточно небольшой сопоставимой выборки задач, чтобы улучшать контекст, промпты и инструкции по наблюдаемым данным, а не по впечатлению.
Связь с источником: журналы работы агентов как данные для анализа эффективности — с 53:37.
6. Контракт передачи и совместимость инструментов
Стандартизировать не конкретного агента, а командный протокол:
- структуру контекста и спецификации;
- интерфейс инструкции;
- обязательные проверки;
- формат отчёта и передачи результата (
handoff); - контрольные точки человека;
- требования к журналу выполнения.
Передача результата должна понижать размерность: решение, изменения, доказательства, риски и следующая контрольная точка вместо нескольких экранов сгенерированного текста. Протокол желательно проверять минимум с двумя используемыми в команде агентскими клиентами, не пытаясь навязать всем один интерфейс.
Связь с источником: совместимость внутренних инструментов с разными агентами — с 55:20, понижение размерности при передаче результата — с 56:43.
Что не переносить буквально
Ниже — авторские ограничения, а не пересказ позиции всех участников стрима.
- Не собирать без разбора все чаты и встречи в общее хранилище данных: сохранять единый источник истины (
SSOT), происхождение данных, права доступа и маршрутизацию каждого типа контекста. - Не делать долю кода, созданного ИИ, основной метрикой: это вспомогательная телеметрия, а не доказательство эффекта.
- Не строить автономную многоагентную фабрику до доказательства одного воспроизводимого процесса.
- Не превращать эти пункты в масштабную программу до повторного подтверждения на реальных задачах; сначала проверить один воспроизводимый процесс.
Ближайшая проверка
Проверить эти шесть направлений и набор проверочных задач на двух ближайших пилотах. После второго повторения решить, какие пункты становятся постоянными правилами командного процесса.
Источник и граница интерпретации
Основной источник — стрим «Как писать код с AI-агентами?», Константин Доронин, 20 августа 2026 года. В разговоре участвовали Андрей Бреслав, Валерий Ковальский и Максим Ключников. Содержательная часть начинается с 00:09:33; предэфирная беседа исключена из рабочего транскрипта.
Из стрима взяты шесть направлений усиления. Состав конкретных чек-листов, структура наблюдаемого журнала и проверка на двух пилотах — авторская систематизация, а не дословная рекомендация участников.
Отдельно в стриме сформулирован принцип для детерминированных шагов: если этап можно сделать обычной программой, его не следует перекладывать на нейросеть — фрагмент с 1:47:46.