Глава 1: Первый промпт + план проверки

Пролог: Parts Unlimited, 2014#

Помните Bill Palmer из “The Phoenix Project”?

2014 год. Bill — вице‑президент по ИТ‑эксплуатации в Parts Unlimited, компании на грани катастрофы. Деплои занимают много времени и ломаются слишком часто. Каждый инцидент — это ночи без сна, ручной триаж логов, координация команд через почту и телефонные звонки.

Bill тушит пожары вручную. Каждый день — новый кризис.

2026 год. Познакомьтесь с Lance Bishop.

Lance — руководитель программы Phoenix Project (руководитель поставки) в компании, похожей на Parts Unlimited. Те же проблемы: Phoenix Project “не успевает”, деплои ломаются, инциденты повторяются, инфраструктура разрослась, а команда небольшая.

Но есть одно отличие: у Lance есть ИИ-агенты — как «ускоритель поставки» и как способ сделать качество воспроизводимым.

Не вместо знаний. Вместе со знаниями.

Сцена из “The Phoenix Project” (2014)#

Глава 3-4 книги: “Почему каждый деплой — это катастрофа?”

Steve Masters, CEO, вызывает Bill Palmer в кабинет. Вопрос простой, но убийственный: “Почему Phoenix Project постоянно задерживается? Почему каждый деплой ломается?”

Bill понимает: нужны данные. Но где их взять?

Следующие дни Bill и его команда собирают информацию вручную:

• Wes Davis роется в Excel-таблицах с историей деплоев (смешанные форматы, нет стандарта)
• Patty McKee собирает цепочки писем с отчётами по инцидентам (много писем, часть контекста теряется)
• Bill сам ищет паттерны в Jira-тикетах (шум, слабая разметка, трудно фильтровать)

Результат анализа (ручная работа команды):

• Пайплайн деплоя: много ручных шагов (часть описаний устарела)
• Доля отказов: высокая (точные цифры неясны)
• Время деплоя и отката: долго и непредсказуемо
• Топ причин падений: качественно (“вроде бы миграции”), без строгой статистики

Bill показывает результаты Steve. CEO спрашивает: “Это точно? Можешь доказать?”

Bill честно отвечает: “Это лучшее, что мы можем собрать вручную. Точность… 70%.”

Ключевые проблемы подхода 2014:

• Время: дни ручной работы на анализ ограниченного периода
• Точность: “примерно”, потому что ручной сбор = ошибки человека
• Воспроизводимость: нет (каждый раз собирать заново)
• Паттерны: качественно (“миграции БД, вроде бы”), не количественно

Та же задача в 2026: как Lance решает с ИИ-агентами#

Контекст: CEO Parts Unlimited (2026) задаёт тот же вопрос: “Почему деплои ломаются?”

Подход Lance Bishop (2026):

Lance начинает диалог с агентом и формулирует промпт:

Роль: ты — агент для анализа деплоев.

Задача: проанализируй последние <N> деплоев по логам CI/CD.

Для каждого деплоя извлеки:
- Дата/время
- Статус: `success`/`failed`
- Длительность
- Шаг падения: `failed_step`, если `status = failed`

Формат ответа: JSON-массив + таблица статистики (основные причины падений без “ложной точности”)

Ограничения:
- Работай только с указанными файлами/артефактами; не делай сетевых запросов и не изменяй данные.
- Не включай секреты/PII и сырые логи в ответ; используй короткие цитаты и маскирование.

УСЛОВИЯ ОСТАНОВКИ:
- Если логи недоступны — остановись и сообщи
- Если формат логов неясен — задай вопрос
- НЕ додумывай отсутствующие данные

Расположение логов: ./ci-cd-logs/deployments/*.log

Время выполнения:

• Агент генерирует парсер: быстро
• Парсинг деплоев: быстро
• Верификация (выборочная проверка): быстро
• Итого: заметно быстрее, чем ручной сбор

Результат:

{
  "total_deployments": "<VALUE>",
  "success_rate": "<VALUE>",
  "failed_rate": "<VALUE>",
  "top_failures": [
    {"step": "database_migration", "count": "<N>", "percentage": "<VALUE>"},
    {"step": "config_validation", "count": "<N>", "percentage": "<VALUE>"},
    {"step": "service_timeout", "count": "<N>", "percentage": "<VALUE>"}
  ]
}

Richard (инженер из команды) проверяет результат (выборочная проверка: 3 случайных деплоя вручную) → корректно

Показывает CEO. CEO спрашивает: “Это точно?”

Lance отвечает: “План проверки прилагается. На выборке проверили — совпало. Хочешь повысить уверенность — вот список ID для дополнительной выборочной проверки.”

Сравнение: 2014 и 2026

Что изменилось:

• Скорость: заметно быстрее (дни ручной работы → быстрый прогон с проверкой)
• Точность: выше (план проверки обязателен)
• Воспроизводимость: промпт можно переиспользовать для следующих 50 деплоев
• Проверяемость: план проверки делает результат доверенным

Что НЕ изменилось:

• Ответственность на человеке: Lance обеспечивает проверяемость результата (не доверяет слепо)
• Нужен опыт Senior+: понимание пайплайна деплоя, что такое миграции БД, какие метрики важны
• Доверяй, но проверяй: агент помогает, но человек контролирует качество

В этой главе вы научитесь:

• формулировать первый промпт так, чтобы результат был проверяем
• верифицировать результаты агента (план проверки)
• не доверять слепо, но получать пользу быстро

Кто вы (и почему это важно)#

Эта книга для Senior/Staff/Principal+ инженеров, которые:

• управляли командами или принимали архитектурные решения
• работали с продакшеном (деплои, инциденты, дежурства)
• понимают, что “быстро” без контроля качества = “переделывать в пятницу вечером”

Вам не нужно объяснять, что такое CI/CD, SLO, или код-ревью. Вы это знаете.

Вам нужно научиться применять этот опыт к работе с агентами.

Быстрый старт: первый промпт#

Цель#

Быстро получить структурированные данные из логов деплоя и проверить их корректность.

Помните сцену из пролога? Bill Palmer собирал данные о деплоях днями, с условной точностью. Сейчас вы сделаете ту же задачу быстро и с проверяемым результатом.

Ваша задача (2026)#

Контекст: Пайплайн деплоя ломается каждую неделю.
Вице-президент по инженерии (VP Engineering) спрашивает: “Почему деплои падают?”
Задача: Найти топ-3 причины падений.

Вход#

• Логи деплоя (логи CI/CD)
• Любой ИИ-агент: агент (с доступом к файлам/командам) или чат‑режим

Промпт (готовый к копированию)#

Роль: ты — агент для анализа деплоев.

Контекст:
- У нас есть логи последних 10 деплоев в формате CI/CD
- Деплои часто падают, но паттерн неясен

Ограничения:
- Анализируй данные в режиме read-only: без изменений файлов/окружения и без сетевых вызовов.
- Не публикуй сырые логи; маскируй секреты/PII и цитируй только релевантные строки.

Задача:
1) Проанализируй логи и для каждого деплоя извлеки:
   - Дата/время
   - Статус: `success`/`failed`
   - Длительность
   - Шаг падения (если `status = failed`)
   
2) Выведи результат в формате JSON-массив, отсортированный по дате (сначала новые)

3) Посчитай статистику:
   - Сколько успешных/неудачных деплоев
   - Топ-3 причины падений по полю `failed_step` с процентами

Формат ответа:
- JSON с данными деплоев
- Таблица статистики

УСЛОВИЯ ОСТАНОВКИ:
- Если логи недоступны или путь не указан — остановись и сообщи об этом
- Если формат логов неясен — задай уточняющий вопрос
- НЕ додумывай отсутствующие данные

Расположение логов: ./deployment-logs/*.log

Что делает агент:

Агент не просто “думает над ответом”. Он сам выполняет команды:

1. Читает файлы логов (как cat deployment-logs/*.log)
2. Парсит данные (генерирует и выполняет Python/bash скрипт)
3. Выдаёт результат: JSON + таблица

Bill в 2014 делал то же самое вручную: открывал Excel, искал через grep, писал однострочные команды на bash. Агент использует те же инструменты, но автономно.

Шаги#

1. Скопируй промпт в чат
2. Укажи путь к логам (замени ./deployment-logs/*.log на реальный путь)
3. Запусти агента — он сгенерирует скрипт или код для парсинга
4. Проверь код — проверь, что агент не делает опасных операций (запись, удаление, сетевые вызовы)
5. Запусти скрипт — получи JSON с данными
6. Проверь результат (см. ниже “План проверки”)

Пример результата#

Агент выполнил парсинг логов (написал и запустил Python скрипт) и выдал:

[
  {
    "date": "2026-01-15",
    "status": "failed",
    "duration": "<DURATION>",
    "failed_step": "database_migration"
  },
  {
    "date": "2026-01-14",
    "status": "success",
    "duration": "<DURATION>"
  },
  {
    "date": "2026-01-13",
    "status": "failed",
    "duration": "<DURATION>",
    "failed_step": "config_validation"
  }
]

Статистика:

План проверки#

Вопрос: как проверить, что агент не соврал?

Метод 1: Выборочная проверка

• Выбери 2-3 деплоя из результата
• Открой оригинальные логи вручную
• Проверь: дата, статус, failed_step совпадают?
• Если выборка сходится → агент, вероятно, работает корректно

Метод 2: Граничные случаи

• Проверь первый и последний деплой (по дате)
• Проверь самый длинный и самый короткий (по duration)
• Эти кейсы часто выявляют ошибки парсинга

Метод 3: Проверка здравого смысла

• Агент говорит “50% database_migration”
• Посчитай вручную: в 10 деплоях должно быть 5 падений на database_migration
• Совпадает? → ОК

Красные флаги (когда НЕ доверять):

• Агент выдал ровно 50%/50% (слишком “красиво”)
• Все даты одинаковые или последовательные (1, 2, 3, 4…)
• Failed steps не похожи на реальные (например, “step_1”, “step_2”)
• Статистика не сходится (сумма процентов ≠ 100%)

Проверка результата (чеклист)#

• JSON валиден (не сломан синтаксис)
• Все обязательные поля присутствуют (date, status, duration)
• Даты в правильном порядке (сначала новые)
• Выборочная проверка: 2-3 деплоя совпадают с оригинальными логами
• Статистика сходится (сумма процентов = 100%)
• Код агента безопасен (нет операций записи/удаления/сетевых вызовов)

Ожидаемый результат#

Артефакт: JSON с данными деплоев + таблица статистики

Время:

• Агент: быстро (вместо часов вручную)
• Верификация: быстро

Польза:

• Быстро: структурированные данные без “дней ручной работы”
• Проверяемо: вы знаете, как верифицировать результат
• Воспроизводимо: промпт можно переиспользовать для следующих 10 деплоев

Теория: что мы только что сделали?#

Концепция 1: Промпт как контракт#

Вы уже работали с контрактами: контракты API, функциональные требования, критерии приёмки.

Промпт — это контракт между вами и агентом:

• Роль: кто агент (аналитик, разработчик, ревьюер)
• Контекст: что агент знает (логи, формат, ограничения)
• Задача: что агент должен сделать (шаги, формат ответа)
• Условия остановки: когда агент должен остановиться и спросить

Почему это важно:

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

Агент не понимает неявный контекст. Ему нужен явный контракт.

В 2014 Bill Palmer из Parts Unlimited собирал данные о деплоях каждый раз заново: дни поиска по Excel-таблицам, цепочкам писем, Jira‑тикетам — без воспроизводимого процесса. Следующий раз — снова дни. Промпт делает процесс явным: один раз написал контракт → запускаешь когда нужно → получаешь результат быстро.

История из практики:

На проекте VIKI мы попросили агента “проанализировать ответы API и найти проблемы”. Агент выдал:

• “200 OK — всё хорошо”
• “500 Internal Server Error — есть проблема”

Очевидно? Нет. Проблема была в задержке: p95 выше допустимого, но агент не знал, что задержка — это тоже “проблема”.

Фикс: добавили в промпт явный критерий: “p95‑задержка выше порога считается проблемой”.

Вывод: Агент не “думает”. Агент выполняет контракт. Если контракт неполный — результат непредсказуем.

Концепция 2: Доверяй, но проверяй#

Вы управляли командами. Вы знаете принцип “доверяй, но проверяй”:

• Доверяй junior’у задачу
• Но проверяй pull request перед мержем

С агентами — то же самое.

Почему:

Агенты ошибаются по-другому, чем люди — и по-другому, чем ручной сбор данных.

В 2014 Bill Palmer потратил дни команды на ручной сбор данных о деплоях. Показал CEO: “падений много, вроде бы из-за миграций”. CEO спросил: “Это точно?” Bill честно ответил: “Это лучшее, что мы можем собрать вручную. Точность… 70%.” Проблема: ошибки человека, смешанные форматы, качественные выводы.

В 2026 агент выдаёт данные быстро. Но у агента другие проблемы:

• Люди: забывают, устают, недопонимают
• Агенты: галлюцинируют, игнорируют контекст, додумывают

План проверки делает результат проверяемым: выборочная проверка 2-3 случаев → 100% совпадение с оригинальными логами.

Типичные режимы ошибок агентов:

1. Галлюцинации — агент выдумывает несуществующие данные
2. Контекстные ошибки — агент игнорирует важные детали из промпта
3. Логические ошибки — агент делает некорректные выводы
4. Ошибки формата — агент выдаёт JSON с синтаксическими ошибками

Как снижать риск:

• Выборочная проверка: проверяй 10-20% результата вручную
• Граничные случаи: проверяй первый/последний, min/max
• Проверка здравого смысла: проверяй, что статистика сходится
• Автоматизация: пиши скрипты для проверки (модульные тесты для результатов агента)

Компромисс:

Верификация занимает время, но:

• Без верификации: риск принять некорректные данные → неправильные решения
• С верификацией: уверенность в результате → можно использовать для решений, влияющих на продакшен

Когда верификация не нужна:

• Тривиальные задачи (переименовать переменную, добавить комментарий)
• Решения с низкими ставками (черновик документации, брейншторм)

Когда верификация обязательна:

• Данные продакшена (логи, метрики, конфиги)
• Бизнес-решения (анализ рисков, оценка затрат)
• Безопасность (модель угроз, контроль доступа)

Концепция 3: Условия остановки#

Вы работали с circuit breakers в микросервисах: если сервис падает → остановись и не делай повторных попыток.

Условия остановки для агентов — то же самое:

Агент должен знать, когда остановиться и спросить человека.

Примеры условий остановки:

• Логи недоступны → остановись и спроси где логи
• Формат неясен → покажи пример лога и спроси как парсить
• Данных недостаточно → перечисли какие данные нужны

В 2014 Bill Palmer додумывал отсутствующие данные: не все логи деплоя были доступны, поэтому вывод “миграции БД, вроде бы” — качественный, без строгой статистики. У него не было опции “остановись и спроси” — нужно было показать CEO хоть что-то.

В 2026 агент может (и должен) остановиться: если логов нет → “СТОП: логи недоступны по пути X, где искать?” Вместо галлюцинаций — явный вопрос.

Примеры условий остановки:

• “Если логи недоступны — остановись и сообщи об этом”
• “Если формат логов неясен — задай уточняющий вопрос”
• “НЕ додумывай отсутствующие данные”

Почему это важно:

Без условий остановки агент будет додумывать и галлюцинировать.

История из практики:

На проекте ASIMOV агент анализировал логи деплоя. Один лог был повреждён. Агент додумал данные:

• Date: “2026-01-01” (первое января, потому что “начало года”)
• Status: “success” (потому что “оптимистичный вариант”)

Мы приняли эти данные и сделали неправильный вывод: “деплой 1 января прошёл успешно”.

На самом деле: деплоя 1 января не было. Файл был corrupted.

Фикс: добавили условие остановки: “Если лог повреждён или нечитаем — остановись и сообщи об этом”.

Вывод: Агент не должен додумывать. Если данных нет — агент должен остановиться и спросить.

Практика: SOP для первого промпта#

В 2014 Bill Palmer анализировал деплои без процесса: каждый раз заново собирал Excel-таблицы, цепочки писем, Jira-тикеты — часы/дни команды. Следующий раз — снова часы/дни.

В 2026 SOP делает процесс воспроизводимым: один раз написал процедуру → каждый раз быстрый прогон. Разница: заметная по времени и по воспроизводимости.

Назначение#

Воспроизводимый процесс написания и проверки промпта для типовой задачи (анализ логов, парсинг данных, генерация отчётов).

Входы (входные артефакты)#

• Задача (например, “найти топ-3 причины падений деплоя”)
• Источник данных (логи, метрики, конфиги)
• Формат ответа: JSON, таблица, текст

Процедура#

Шаг 1: Определи роль агента#

Что делать:

• Опиши роль агента в одном предложении: “ты — агент для анализа деплоев”
• Роль задаёт контекст: агент-аналитик ведёт себя иначе, чем агент-разработчик

Почему этот шаг: Роль помогает агенту “понять”, какой стиль ответа от него ожидается.

Контрольная точка 1: проверь роль

Чеклист:

• Роль описана в одном предложении
• Роль соответствует задаче (анализ → аналитик, код → разработчик)

Сценарий сбоя: На проекте MORPHEUS мы не указали роль. Агент был “универсальным”. Результат: вместо анализа логов агент предложил “написать модульные тесты”. Не то, что нужно.

Шаг 2: Добавь контекст#

Что делать:

• Опиши, что агент знает: формат данных, ограничения, предположения
• Контекст помогает агенту не делать лишних предположений

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

Контрольная точка 2: проверь контекст

Чеклист:

• Описан формат данных: JSON, простой текст, CSV
• Указаны ограничения (только чтение, без сетевых вызовов)
• Явные предположения (например, “логи в хронологическом порядке”)

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

Шаг 3: Формулируй задачу пошагово#

Что делать:

• Разбей задачу на 3-7 шагов
• Каждый шаг — конкретное действие: “извлеки дату”, “посчитай статистику”

Почему этот шаг: Пошаговая задача снижает вероятность ошибки: агент знает, что делать на каждом шаге.

Контрольная точка 3: проверь задачу

Чеклист:

• Задача разбита на 3-7 шагов
• Каждый шаг — конкретное действие (не абстракция)
• Формат ответа указан явно: JSON, таблица

Сценарий сбоя: На проекте SEVER мы сказали “проанализируй логи”. Агент выдал текстовое описание: “Деплои падают из-за миграций”. Не структурированные данные, не проверяемо.

Шаг 4: Добавь условия остановки#

Что делать:

• Перечисли ситуации, когда агент должен остановиться и спросить
• Явные условия остановки: “если логи недоступны”, “если формат неясен”

Почему этот шаг: Условия остановки предотвращают галлюцинации и додумывания.

Контрольная точка 4: проверь условия остановки

Чеклист:

• Есть минимум 2-3 условия остановки
• Условия остановки покрывают типичные проблемы (нет данных, неясный формат)
• Явный запрет на додумывание: “НЕ додумывай отсутствующие данные”

УСЛОВИЕ ОСТАНОВКИ: Если задача слишком сложная для одного промпта (например, требует много шагов) — остановись и разбей на несколько промптов.

Шаг 5: Запусти агента и проверь результат#

Что делать:

• Запусти агента
• Примени план проверки (выборочная проверка, граничные случаи, проверка здравого смысла)

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

Контрольная точка 5: верификация завершена

Чеклист:

• Выборочная проверка: 2-3 кейса совпадают с оригиналом
• Граничные случаи проверены (первый/последний, min/max)
• Проверка здравого смысла: статистика сходится

Сценарий сбоя: На проекте ZAPAD мы пропустили верификацию. Агент выдал данные с ошибкой парсинга: “duration: ” интерпретировал неверно. Мы приняли эти данные → неправильные выводы о производительности.

Выходы (артефакты)#

• Промпт (готовый к переиспользованию)
• Результат: JSON, таблица
• Отчёт о верификации (что проверено, какие кейсы прошли)

Доказательства#

Как доказать, что SOP выполнен правильно:

• Промпт содержит все элементы: роль, контекст, задачу, условия остановки
• Результат прошёл верификацию (выборочная проверка, граничные случаи, проверка здравого смысла)
• Артефакт воспроизводим: другой инженер может запустить промпт и получить аналогичный результат

Параллельный трек: эволюция от 2014 к 2026#

Как это было в 2014 — Bill Palmer, без агентов#

Сцена из книги (Главы 3-4 “The Phoenix Project”):

Ситуация: Steve Masters, CEO, вызывает Bill Palmer в кабинет: “Почему Phoenix Project постоянно задерживается? Почему каждый деплой ломается? Мне нужны данные для заседания совета директоров очень скоро.”

Действия (что делал Bill вручную):

• День 1: Wes Davis роется в Excel-таблицах (80+ строк деплоев, смешанные форматы, неполные данные)
• Patty McKee собирает цепочки писем с отчётами по инцидентам (много писем за период, ручной анализ)
• День 2: Bill Palmer ищет паттерны в Jira-тикетах (150+ тикетов, половина без тегов)
• День 2 (вечер): Вся команда сводит данные в одну таблицу, пытается найти паттерны

Затраты времени: дни ручной работы команды

Последствия:

• Результат неточный: много предположений, неполные данные
• CEO не может принять уверенное решение на заседании совета директоров
• Команда раздражена: “скучная работа в Excel” вместо решения проблем
• Паттерны качественные: “миграции БД, вроде бы” — без количественных данных

Почему так долго/дорого:

• Первопричина 1: Ручной сбор данных из разных источников: Excel, почта, Jira — нет единого источника истины
• Первопричина 2: ошибки человека при ручном подсчёте (ошибки копирования‑вставки, пропущенные строки)
• Первопричина 3: нет воспроизводимого процесса — каждый раз собирать заново, непоследовательные методы

Размышление Bill Palmer:

“Это лучшее, что мы можем собрать вручную за пару дней. Точность… условная. Я знаю, это не идеально, но у нас нет времени делать идеально — нужно тушить пожары. Steve просит данные очень скоро, а мы уже потратили дни команды на этот анализ.”

Результат Bill (конец книги “The Phoenix Project”, после трансформации):

• Автоматизированный сбор данных: логи деплоя → дашборд CI/CD
• Время: дни ручной работы → существенно быстрее (автоматизация)
• Точность: “примерно” → заметно лучше (автоматизированный парсинг, меньше ошибок человека)
• Бизнес: Phoenix Project запущен, бизнес-эффект стал ощутимым

Что у Bill получилось: через автоматизацию и процессы он радикально ускорил сбор фактов и сделал его повторяемым.

Как это стало в 2026 (Lance Bishop, с агентами)#

Та же проблема (с агентами):

Ситуация: CEO Parts Unlimited (2026) задаёт тот же вопрос: “Почему деплои ломаются? Мне нужны данные для заседания совета директоров завтра.”

Действия (что делает Lance с агентом):

• Lance открывает диалог с агентом, пишет промпт:

  Роль: агент для анализа деплоев.
  Задача: проанализируй последние <N> деплоев по логам CI/CD.
  Формат: JSON + таблица статистики (основные причины падений без “ложной точности”)
  УСЛОВИЯ ОСТАНОВКИ: если логи недоступны — остановись и сообщи
  Расположение: ./ci-cd-logs/deployments/*.log
  

• Агент генерирует парсер + парсит деплои
• План проверки: выборочная проверка → совпадение на выборке

Затраты времени: заметно меньше, чем ручной сбор

Последствия:

• Результат проверяемый (автоматизация + план проверки)
• CEO получает данные быстро → уверенное решение на заседании совета директоров
• Команда сфокусирована: меньше рутины → больше стратегической работы
• Паттерны становятся формализуемыми без “выдуманных процентов”

Почему так быстро/дёшево:

• Агент закрывает первопричину 1: автоматически парсит все источники (логи CI/CD, API Jira) — единый пайплайн
• Агент закрывает первопричину 2: меньше ошибок человека (агент не устаёт, не пропускает данные, единообразный парсинг)
• Агент закрывает первопричину 3: промпт = воспроизводимый процесс (запускаем когда нужно, результат сопоставим)

Размышление Lance:

“Bill Palmer в 2014 потратил дни команды и получил условную точность. Я потратил меньше времени с агентом и получил проверяемый результат.

Это не магия. Это автоматизация Билла в 2014 + «слой интеллекта» в 2026:

• Bill научил нас автоматизировать рутину (скрипты, дашборды)
• Агенты добавляют «интеллект» (парсинг неструктурированных данных, распознавание паттернов, адаптивность)

Я стою на плечах Bill Palmer. Агенты — это мультипликатор к его достижениям, не замена.”

Эффект мультипликатора: как агенты усиливают улучшения Phoenix Project#

Главная мысль:

Агенты не “заменяют” то, что сделал Bill Palmer. Они усиливают эффект:

• Bill добился радикального ускорения через автоматизацию
• Lance добивается радикального ускорения через агентов
• Агент добавляет скорость и «слой интеллекта» (адаптивность к новым форматам)

Что агенты добавляют к автоматизации Bill Palmer в 2014:

1. Интеллект: агент понимает неструктурированные данные (логи, письма) без жёсткой схемы
2. Адаптивность: новый формат логов? обновить промпт (быстро) или переписать скрипт (дольше)
3. Интерфейс на естественном языке: промпт вместо кода — доступно любому инженеру, не только DevOps
4. Верификация встроена: план проверки явно в промпте, не “забыли проверить”

Эволюция, а не революция#

Ключевая разница:

• В 2014: Bill Palmer — герой, который вручную собирает данные (героизм) → автоматизация через скрипты
• В 2026: Lance Bishop — оркестратор, который пишет промпт и верифицирует результаты (системно и осмысленно)

Не замена, а усиление:

Параллели с управлением людьми:

Bill Palmer (2014) управлял командой людей:

• Давал задачу: “Wes, собери данные о деплоях из Excel”
• Проверял результаты: “Это точно? Проверь ещё раз”
• Корректировал: “Добавь анализ по времени суток”
• Время: дни на координацию

Lance Bishop (2026) оркеструет агента:

• Даёт задачу (промпт): “Проанализируй деплои, формат JSON, условия остановки”
• Проверяет результаты: выборка 3 кейса → 100% совпадение
• Корректирует (итерация): “Добавь разрез по времени суток” (обновили промпт, перезапустили)
• Время: быстро суммарно

Ключевой навык переносится:

• Умение формулировать чёткие задачи (бриф → промпт)
• Умение ставить критерии качества: критерии готовности (Definition of Done, DoD) → план проверки
• Умение проверять результаты (ревью → доказательства через выборочную проверку)

Bill Palmer делал это с людьми. Lance делает это с агентами.

Принципы те же. Исполнение — обычно в разы быстрее (оценка порядка величины; зависит от качества входных данных и дисциплины верификации).

Сравнение: путь Bill и путь с агентами#

Трансформация Bill Palmer (2014, “The Phoenix Project”):

Хронология:

• Месяц 0: кризис (деплои ломаются, Phoenix Project задерживается)
• Месяц 3: первые улучшения (автоматизированный мониторинг, базовые скрипты)
• Месяц 6: крупные улучшения (пайплайн CI/CD, автоматизация деплоев)
• Месяц 12: успех: Phoenix Project запущен, бизнес-эффект виден

Ключевые вехи:

• Время анализа: дни → быстрее (автоматизированные скрипты)
• Успешность деплоев: 40% → 85% — CI/CD + тестирование
• MTTR: часы → меньше (runbooks + координация)

Инвестиции:

• длительная трансформация
• 3-5 инженеров на полный день под автоматизацию
• существенные вложения (инструменты, обучение, изменение процессов)

Результаты:

• Phoenix Project запущен в срок → бизнес-эффект
• Позиция на рынке восстановилась (реакция рынка позитивная)
• Конкурентное преимущество (частота деплоев: несколько раз в неделю → несколько раз в день)

Путь инженера (2026, с агентами):

Хронология:

• Неделя 0: тот же кризис (деплои ломаются, CEO требует данные)
• День 1: первый промпт (анализ становится быстрым)
• Неделя 2: системные промпты (несколько анализов автоматизировано)
• Месяц 3: ИИ‑усиленный CI/CD (агенты + автоматизация в духе Bill Palmer, 2014)

Ключевые вехи:

• Время анализа: дни → быстро (агенты поверх автоматизации)
• Успешность деплоев: 40% → 90% (агенты раньше обнаруживают проблемы)
• MTTR: часы → заметно меньше (триаж с помощью агента, см. главу 6)

Инвестиции:

• первый промпт сделан быстро
• вложения в обучение команды работе с агентами
• общие вложения: время и внимание, без “магических чисел”

Результаты:

• Тот же анализ сразу: День 1 → быстрее решения → инкрементальная ценность
• Phoenix Project запущен быстрее (агенты по всему циклу)
• Конкурентное преимущество: частота деплоев растёт кратно (агенты оркестрируют автоматизацию)

Мультипликатор агентов для инвестиций Билла:

• Время до ценности: быстро по сравнению с месяцами организационных изменений
• Вложения: заметно ниже за счёт меньшей доли ручной работы и инфраструктурных изменений
• ROI (окупаемость инвестиций): считать по вашему контексту (см. шаблон в Приложении A)

Типовые ошибки#

Ошибка 1: Промпт без условий остановки#

Симптом: Агент додумывает отсутствующие данные или галлюцинирует.

Пример: Промпт: “Проанализируй последние 10 деплоев и найди паттерны.”
Результат: Агент выдаёт 10 деплоев, но один из них — выдуманный (дата не существует, статус “success” без оснований).

Почему так происходит: Агент оптимизирован на “выполнить задачу”, а не на “остановиться и спросить”. Без явных условий остановки он будет додумывать.

Последствия: Вы принимаете некорректные данные → неправильные решения.

Как избежать: Всегда добавляйте условия остановки:

• “Если логи недоступны — остановись и сообщи об этом”
• “Если формат логов неясен — задай уточняющий вопрос”
• “НЕ додумывай отсутствующие данные”

Неправильно:

Роль: ты — агент для анализа деплоев.
Задача: проанализируй последние 10 деплоев и найди паттерны.

Правильно:

Роль: ты — агент для анализа деплоев.
Задача: проанализируй последние 10 деплоев и найди паттерны.

УСЛОВИЯ ОСТАНОВКИ:
- Если логи недоступны — остановись и сообщи об этом
- Если формат логов неясен — задай уточняющий вопрос
- НЕ додумывай отсутствующие данные

Ошибка 2: Верификация пропущена#

Симптом: Вы доверяете результату агента без проверки.

Пример: Агент выдал статистику: “database_migration: 50%, config_validation: 30%, timeout: 20%”. Вы приняли эти данные и сделали презентацию для VP. На презентации выяснилось: агент ошибся, config_validation на самом деле 40%.

Почему так происходит: Агенты выглядят убедительно. Они выдают структурированные данные, таблицы, проценты. Легко поверить, что “агент не ошибается”.

Последствия:

• Неправильные решения (инвестируем в фикс database_migration, а проблема в config_validation)
• Потеря доверия (вы “тот человек, который принёс неправильные данные”)

Как избежать: Всегда применяйте план проверки:

• Выборочная проверка: 2-3 кейса вручную
• Граничные случаи: первый/последний, min/max
• Проверка здравого смысла: статистика сходится

Bill Palmer в 2014 показал CEO данные с точностью ~70% — «лучшее, что мы можем собрать вручную». В 2026 с планом проверки вы отвечаете: «Проверено выборочной проверкой на 3 случаях — совпадение с оригинальными логами».

Неправильно: Агент выдал результат → вы используете его без проверки.

Правильно: Агент выдал результат → вы проверяете 2-3 кейса вручную → вы используете результат.

Ошибка 3: Задача слишком абстрактная#

Симптом: Агент выдаёт текстовое описание вместо структурированных данных.

Пример: Промпт: “Проанализируй логи деплоя.”
Результат: “Деплои падают из-за миграций базы данных. Рекомендую улучшить процесс миграций.”

Это не помогает: нет данных, нет статистики, не проверяемо.

Почему так происходит: Задача слишком абстрактная. Агент не знает, что конкретно вы хотите: JSON, таблицу, список, текст?

Последствия: Вы получаете общие слова вместо конкретных данных.

Как избежать: Формулируйте задачу пошагово и указывайте формат ответа:

• “Извлеки дату, статус, длительность”
• “Выведи результат в формате JSON”
• “Посчитай статистику: топ-3 причины падений с процентами”

Неправильно:

Роль: ты — агент для анализа деплоев.
Задача: проанализируй логи деплоя.

Правильно:

Роль: ты — агент для анализа деплоев.
Задача:
1) Проанализируй логи и для каждого деплоя извлеки:
   - Дата/время
   - Статус: `success`/`failed`
   - Длительность
2) Выведи результат в формате JSON-массив
3) Посчитай статистику: топ-3 причины падений с процентами

Бизнес-эффект: что изменилось после первых итераций#

Экономия времени#

Анализ деплоев (основная задача):

• До: дни ручной работы команды
• После: быстрый прогон с верификацией
• Снижение: в разы (за счёт автоматизации и повторяемого шаблона)
• Ценность: экономия упущенной выгоды на каждый анализ

Цикл принятия решений:

• До: несколько дней (сбор данных + анализ + ревью)
• После: быстро (агент + ревью + презентация CEO)
• Снижение: в разы (быстрее цикл «сбор → анализ → решение»)
• Ценность: быстрее реакция на проблемы, конкурентное преимущество

Итоговая экономия времени: ощутимое снижение ручной рутины на повторяемых анализах

Улучшение качества#

Точность данных:

• До: “примерно” (ручной сбор, ошибки человека, неполные данные)
• После: заметно выше — автоматизированный парсинг + план проверки (выборочная проверка)
• Эффект: CEO может принимать более уверенные решения на заседании совета директоров

Воспроизводимость:

• До: 0% (каждый раз собирать заново, непоследовательные методы, нет документации)
• После: 100% (промпт задокументирован, SOP воспроизводим, любой инженер может запустить)
• Эффект: знание не теряется при уходе людей, процесс становится устойчивее

Покрытие:

• До: последние 10 деплоев (ограничено ручной работой, смещённая выборка)
• После: последние 50 деплоев (агент не устаёт, обрабатывает весь массив)
• Эффект: выше статистическая уверенность, проще ловить редкие паттерны

Организационный эффект#

Скорость принятия решений:

• Раньше: “Давайте соберём данные за пару дней, потом встреча” → встреча откладывается
• Теперь: “У меня есть данные за последние 50 деплоев” → решение принимается сразу
• Пример: решение по приоритетам фичи Phoenix Project за 1 день вместо 1 недели

Мораль команды:

• Раньше: команда делала “скучную работу в Excel” днями; росли раздражение и риск выгорания
• Теперь: быстрый агент + больше времени на стратегические задачи (архитектура, оптимизация)
• Наблюдение: нагрузка стала более устойчивой (первая польза)

Масштабируемость:

• До: Bus factor = 1 — Bill Palmer единственный, кто может собрать эти данные
• После: Bus factor = 2 (промпт задокументирован, Wes/Patty могут запустить анализ)
• Значение: если Bill уйдёт в отпуск, кто-то другой может запустить анализ

Экономическая модель (под ваш контекст)#

Если вы хотите посчитать эффект, не подставляйте “универсальные цифры из книги”. Посчитайте по вашей модели:

• база: сколько ручной рутины и координации уходит на сбор фактов
• цель: что делегируется агенту, где обязательна проверка, где условия остановки
• стоимость: время внедрения + поддержка шаблонов/проверок
• ценность: сэкономленное инженерное время + снижение рисков + ускорение решений

Шаблон для расчёта — в Приложении A.

Сравнение с Phoenix Project#

Bill Palmer (2014, финальное состояние, после автоматизации):

• Вложения: процессные изменения + инструменты автоматизации
• Результаты: Phoenix Project запущен, бизнес-эффект стал ощутимым
• Время до ценности: заметная задержка (организационные изменения)

Lance Bishop (2026 с агентами):

• Вложения: настройка промпта и проверки
• Результаты: та же задача решается быстрее и воспроизводимее, решения принимаются увереннее
• Время до ценности: быстро, потому что не требует больших инфраструктурных изменений

Мультипликатор агентов для времени до ценности: Bill Palmer потратил месяцы организационных изменений чтобы добиться автоматизации. Lance получает инкрементальную ценность быстро (первый промпт).

Ключевое отличие:

• Автоматизация Bill (2014): требовала инфраструктурных изменений, обучения команды, месяцы
• Подход с агентами (2026): промпт + верификация = немедленная ценность, без инфраструктурных изменений

Организационная трансформация началась#

После первых итераций с первым промптом:

Понимание в команде:

• Команда видела: агент может делать полезную работу (не игрушка)
• Команда видела: план проверки критичен («доверяй, но проверяй»)
• Команда видела: промпт = воспроизводимый процесс (любой инженер может использовать)

Основание для масштабирования:

• Шаблон промпта готов: роль + контекст + задача + формат + условия остановки
• Шаблон верификации готов: выборочная проверка + граничные случаи + проверка здравого смысла
• Команда обучена: Wes, Patty, Bill могут создавать новые промпты

Рост доверия:

• CEO видел: проверяемые данные → доверяет результатам агента
• Совет директоров видел: быстрые решения (быстро по сравнению с днями) → конкурентное преимущество
• Команда видела: меньше скучной рутины → больше инженерной ёмкости

Следующая волна:

• Определили: 5 дополнительных задач анализа (паттерны инцидентов, дрейф конфигурации, узкие места производительности)
• Потенциал: дополнительная экономия и высвобождение ёмкости на соседних задачах анализа
• План: несколько итераций на промпт, затем масштабирование по мере готовности

Сравнение: агенты и альтернативы#

Альтернатива 1: нанять аналитика данных

• Стоимость: найм и онбординг (время и деньги)
• Время до ценности: заметная задержка
• Риски: ошибки человека остаются; аналитик может уволиться

Альтернатива 2: купить аналитический инструмент

• Стоимость: лицензии + интеграции + поддержка
• Время до ценности: заметная задержка
• Риски: может потребоваться кастомный код для форматов данных Parts Unlimited

Альтернатива 3: агенты

• Стоимость: время на промпт, верификацию и поддержание шаблонов
• Внедрение: быстро, если есть доступ к данным и понятный процесс
• Сопровождение: регулярные обновления при изменениях форматов/процессов
• Риски: снижены через план проверки

Преимущество агентов (при корректных ограничениях и верификации):

• быстрее путь к первому циклу ценности (делегирование → проверка → повторяемость)
• Воспроизводимо: промпт воспроизводим при тех же входных данных и правилах; инструмент и форматы логов всё равно могут требовать обновлений

Накопительный эффект (Глава 1 → Глава 2 → Глава 3 → … → Глава 10)#

Важнее “накопительных цифр” — накопительный эффект:

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

Глава 1 = первый шаг к масштабируемой ценности.

Подготовка к следующей главе#

Что сделать сразу (сегодня):

1. Выберите одну задачу анализа в вашей команде (что занимает 2+ часов вручную, регулярно повторяется)
2. Напишите первый промпт для этой задачи (используйте шаблон: роль, контекст, задача, формат, условия остановки)
3. Составьте план проверки (2-3 кейса, сравните с ручным результатом)

Что подготовить к следующей главе (Глава 2):

• Первый промпт готов и верифицирован → в Главе 2 добавим ограничения: что агент НЕ должен делать
• План проверки работает → в Главе 2 добавим условия остановки (когда агент должен остановиться)
• Команда видела результат → в Главе 2 масштабируем практику: SOP для диалога

Ожидаемый накопительный эффект после Главы 2:

• Глава 1: автоматизация анализа (меньше рутины, больше предсказуемости)
• Глава 2: безопасность (ограничения, меньше рисков)
• Итого: накопительный эффект закрепляется по мере прохождения глав

Резюме#

Что мы сделали#

• Написали первый промпт как контракт (роль, контекст, задача, условия остановки)
• Получили структурированные данные из логов быстро (вместо часов вручную)
• Научились верифицировать результаты агента (выборочная проверка, граничные случаи, проверка здравого смысла)

Артефакты#

• Промпт: готовый к переиспользованию шаблон для анализа логов
• План проверки: методы проверки результатов агента
• SOP: воспроизводимый процесс написания и проверки промпта

Ключевые принципы#

1. Промпт как контракт: явная роль, контекст, задача, условия остановки
2. Доверяй, но проверяй: выборочная проверка обязательна
3. Условия остановки: агент должен знать, когда остановиться и спросить

Критерии приёмки главы#

Вы успешно освоили материал, если можете:

• Написать промпт по шаблону (роль, контекст, задача, формат ответа, условия остановки)
• Проверить результат агента на 2–3 кейсах (включая хотя бы один граничный случай)
• Явно описать, что агент делает при недостатке данных (останавливается и задаёт уточняющие вопросы)

Следующие шаги#

В Главе 2 вы научитесь:

• создавать системный промпт роли (как агент должен себя вести)
• добавлять ограничения (что агент НЕ должен делать)
• строить SOP диалога (как агент должен уточнять требования)

Завязка: Вы умеете получать пользу от агента быстро. Но как контролировать, что агент делает и что он НЕ должен делать? Об этом — в следующей главе.

От одного промпта к системе за 10 глав. Вы прошли первый шаг.