Human in the Loop — не кнопка «спросить человека на всякий случай»
Когда говорят о безопасной автоматизации, часто предлагают простое решение: пусть система перед каждым действием запрашивает подтверждение.
Звучит разумно. На практике такая схема быстро превращает человека в кнопку «ОК».
Если агент останавливается на каждом шаге, человек перестаёт разбираться в деталях и начинает подтверждать всё подряд. Автоматизация не экономит время, а лишь перекладывает на оператора поток однотипных уведомлений. Формально контроль есть. Фактически его нет.
Human in the Loop нужен не везде. Он нужен там, где цена ошибки оправдывает остановку процесса.
Человек должен оставаться в цепочке, если действие:
— трудно или невозможно отменить;
— меняет production или влияет на большое число пользователей;
— открывает, передаёт или удаляет персональные и конфиденциальные данные;
— создаёт финансовые обязательства или проводит платёж;
— может иметь юридические последствия;
— выполняется в условиях высокой неопределённости;
— выходит за заранее согласованные лимиты и правила.
Например, агент может самостоятельно подготовить миграцию, проверить её на тестовой среде и собрать план отката. Но запуск миграции в production требует подтверждения.
Он может классифицировать документы и подготовить список на удаление. Но необратимое удаление должно пройти через человека.
Он может сформировать платёжное поручение. Но отправка денег, особенно новому получателю или сверх установленного лимита, требует отдельного решения.
Контрольные точки стоит выбирать не по количеству действий, а по риску. Для этого достаточно оценить три вещи:
1. Последствия ошибки. Что произойдёт, если система ошиблась?
2. Обратимость. Можно ли быстро и полностью отменить действие?
3. Неопределённость. Насколько агент уверен, что правильно понял ситуацию?
Чем выше возможный ущерб, ниже обратимость и больше неопределённость, тем раньше должен подключаться человек.
При этом само подтверждение должно быть содержательным. Не «Разрешить продолжить?», а:
— что именно будет сделано;
— какие объекты и пользователи будут затронуты;
— почему система предлагает это действие;
— какие риски она обнаружила;
— можно ли откатить результат;
— что произойдёт, если ничего не делать.
Хороший Human in the Loop не заставляет человека контролировать каждый шаг. Он даёт автоматизации работать самостоятельно в безопасных границах и возвращает управление человеку перед действительно рискованным решением.
Иначе получается худший вариант: машина ничего не решает, а человек подтверждает всё, не успевая ничего проверить.
Когда говорят о безопасной автоматизации, часто предлагают простое решение: пусть система перед каждым действием запрашивает подтверждение.
Звучит разумно. На практике такая схема быстро превращает человека в кнопку «ОК».
Если агент останавливается на каждом шаге, человек перестаёт разбираться в деталях и начинает подтверждать всё подряд. Автоматизация не экономит время, а лишь перекладывает на оператора поток однотипных уведомлений. Формально контроль есть. Фактически его нет.
Human in the Loop нужен не везде. Он нужен там, где цена ошибки оправдывает остановку процесса.
Человек должен оставаться в цепочке, если действие:
— трудно или невозможно отменить;
— меняет production или влияет на большое число пользователей;
— открывает, передаёт или удаляет персональные и конфиденциальные данные;
— создаёт финансовые обязательства или проводит платёж;
— может иметь юридические последствия;
— выполняется в условиях высокой неопределённости;
— выходит за заранее согласованные лимиты и правила.
Например, агент может самостоятельно подготовить миграцию, проверить её на тестовой среде и собрать план отката. Но запуск миграции в production требует подтверждения.
Он может классифицировать документы и подготовить список на удаление. Но необратимое удаление должно пройти через человека.
Он может сформировать платёжное поручение. Но отправка денег, особенно новому получателю или сверх установленного лимита, требует отдельного решения.
Контрольные точки стоит выбирать не по количеству действий, а по риску. Для этого достаточно оценить три вещи:
1. Последствия ошибки. Что произойдёт, если система ошиблась?
2. Обратимость. Можно ли быстро и полностью отменить действие?
3. Неопределённость. Насколько агент уверен, что правильно понял ситуацию?
Чем выше возможный ущерб, ниже обратимость и больше неопределённость, тем раньше должен подключаться человек.
При этом само подтверждение должно быть содержательным. Не «Разрешить продолжить?», а:
— что именно будет сделано;
— какие объекты и пользователи будут затронуты;
— почему система предлагает это действие;
— какие риски она обнаружила;
— можно ли откатить результат;
— что произойдёт, если ничего не делать.
Хороший Human in the Loop не заставляет человека контролировать каждый шаг. Он даёт автоматизации работать самостоятельно в безопасных границах и возвращает управление человеку перед действительно рискованным решением.
Иначе получается худший вариант: машина ничего не решает, а человек подтверждает всё, не успевая ничего проверить.
❤1
AI превращает разработчика в маленького тимлида
Представьте разработчика, у которого одновременно работают три AI-агента.
Один пишет тесты.
Второй рефакторит старый модуль.
Третий обновляет документацию.
А что в это время делает сам разработчик?
Он ставит задачи, объясняет контекст, распределяет работу, проверяет результат, объединяет изменения и решает, что можно выпускать.
Звучит знакомо?
Это практически должностная инструкция тимлида.
Раньше типичный цикл выглядел так:
написал код → отладил → закоммитил.
Теперь всё чаще иначе:
декомпозировал задачу → выбрал исполнителя → дал инструкции → проверил → собрал результат.
Кода руками разработчик пишет меньше. Но ответственности у него меньше не становится. Наоборот: теперь ошибка может появиться сразу в трёх параллельных ветках, и во всех случаях отвечать за неё будет человек.
Поэтому навыки, которые раньше считались преимущественно лидерскими, становятся обычными инженерными навыками:
— декомпозиция;
— системное мышление;
— архитектура;
— постановка задач;
— критическая оценка результата;
— коммуникация;
— ответственность за итог.
И здесь, на мой взгляд, главный сдвиг:
делегирование становится инженерным навыком.
Недостаточно уметь написать хороший код. Нужно уметь объяснить задачу так, чтобы её правильно выполнил другой исполнитель. Даже если этот исполнитель не человек.
При этом меняется и роль тимлида. Он руководит уже не только людьми. Он проектирует систему, в которой люди и агенты работают параллельно, не мешают друг другу и выдают предсказуемый результат.
Возможно, AI не сделает каждого разработчика в десять раз быстрее.
Но он уже делает каждого разработчика немного тимлидом.
Представьте разработчика, у которого одновременно работают три AI-агента.
Один пишет тесты.
Второй рефакторит старый модуль.
Третий обновляет документацию.
А что в это время делает сам разработчик?
Он ставит задачи, объясняет контекст, распределяет работу, проверяет результат, объединяет изменения и решает, что можно выпускать.
Звучит знакомо?
Это практически должностная инструкция тимлида.
Раньше типичный цикл выглядел так:
написал код → отладил → закоммитил.
Теперь всё чаще иначе:
декомпозировал задачу → выбрал исполнителя → дал инструкции → проверил → собрал результат.
Кода руками разработчик пишет меньше. Но ответственности у него меньше не становится. Наоборот: теперь ошибка может появиться сразу в трёх параллельных ветках, и во всех случаях отвечать за неё будет человек.
Поэтому навыки, которые раньше считались преимущественно лидерскими, становятся обычными инженерными навыками:
— декомпозиция;
— системное мышление;
— архитектура;
— постановка задач;
— критическая оценка результата;
— коммуникация;
— ответственность за итог.
И здесь, на мой взгляд, главный сдвиг:
делегирование становится инженерным навыком.
Недостаточно уметь написать хороший код. Нужно уметь объяснить задачу так, чтобы её правильно выполнил другой исполнитель. Даже если этот исполнитель не человек.
При этом меняется и роль тимлида. Он руководит уже не только людьми. Он проектирует систему, в которой люди и агенты работают параллельно, не мешают друг другу и выдают предсказуемый результат.
Возможно, AI не сделает каждого разработчика в десять раз быстрее.
Но он уже делает каждого разработчика немного тимлидом.
❤3
Промптинг заканчивается. Начинается инженерия спецификаций
Последние полтора года нас учили правильно разговаривать с AI:
«Дайте модели роль».
«Добавьте больше деталей».
«Сформулируйте хороший промпт».
Но чем сложнее становятся AI-агенты, тем меньше результат зависит от магии формулировок.
Проблема чаще всего не в промпте. Агенту просто не хватает контекста.
Сегодня Claude, Codex и другие агенты уже не отвечают на один изолированный вопрос. Они читают репозиторий, открывают файлы, меняют код, запускают тесты и создают pull request.
То есть работают не внутри промпта, а внутри проекта.
И здесь быстро выясняется неприятная вещь: если команда не умеет описывать задачу, ограничения, архитектуру и критерии готовности, никакая модель это не исправит.
Плохая постановка задачи остаётся плохой постановкой задачи. Просто теперь она быстрее превращается в плохой код.
Поэтому на первый план выходит не Prompt Engineering, а Context Engineering. Или, точнее, инженерия спецификаций.
Агенту нужны:
- понятный README;
- правила проекта;
- архитектурные ограничения;
- ADR и Decision Log;
- описание API и бизнес-логики;
- соглашения по именованию;
- Definition of Ready и Definition of Done;
- проверяемые критерии приёмки;
- примеры правильного и неправильного поведения.
Раньше документация помогала разработчикам быстрее разобраться в проекте. Теперь она становится ещё и интерфейсом между командой и AI-агентами.
Причём хороший контекст полезнее длинного промпта. Если архитектурные решения нигде не записаны, агент начнёт их угадывать. Если критерии готовности размыты, он сам решит, когда задача закончена. Если бизнес-правила существуют только в голове у разработчика, модель о них не узнает.
Можно сколько угодно улучшать формулировку запроса. Но нельзя промптом компенсировать отсутствие спецификации.
Поэтому самый полезный AI-инструмент следующего года может оказаться не новой моделью.
А хорошей документацией.
Кажется, мы постепенно переходим от умения «правильно попросить» к умению точно описать, что нужно построить, в каких границах и как проверить результат.
От Prompt Engineering к Context Engineering.
И это уже не навык общения с моделью. Это обычная инженерия, которую мы слишком долго откладывали.
Последние полтора года нас учили правильно разговаривать с AI:
«Дайте модели роль».
«Добавьте больше деталей».
«Сформулируйте хороший промпт».
Но чем сложнее становятся AI-агенты, тем меньше результат зависит от магии формулировок.
Проблема чаще всего не в промпте. Агенту просто не хватает контекста.
Сегодня Claude, Codex и другие агенты уже не отвечают на один изолированный вопрос. Они читают репозиторий, открывают файлы, меняют код, запускают тесты и создают pull request.
То есть работают не внутри промпта, а внутри проекта.
И здесь быстро выясняется неприятная вещь: если команда не умеет описывать задачу, ограничения, архитектуру и критерии готовности, никакая модель это не исправит.
Плохая постановка задачи остаётся плохой постановкой задачи. Просто теперь она быстрее превращается в плохой код.
Поэтому на первый план выходит не Prompt Engineering, а Context Engineering. Или, точнее, инженерия спецификаций.
Агенту нужны:
- понятный README;
- правила проекта;
- архитектурные ограничения;
- ADR и Decision Log;
- описание API и бизнес-логики;
- соглашения по именованию;
- Definition of Ready и Definition of Done;
- проверяемые критерии приёмки;
- примеры правильного и неправильного поведения.
Раньше документация помогала разработчикам быстрее разобраться в проекте. Теперь она становится ещё и интерфейсом между командой и AI-агентами.
Причём хороший контекст полезнее длинного промпта. Если архитектурные решения нигде не записаны, агент начнёт их угадывать. Если критерии готовности размыты, он сам решит, когда задача закончена. Если бизнес-правила существуют только в голове у разработчика, модель о них не узнает.
Можно сколько угодно улучшать формулировку запроса. Но нельзя промптом компенсировать отсутствие спецификации.
Поэтому самый полезный AI-инструмент следующего года может оказаться не новой моделью.
А хорошей документацией.
Кажется, мы постепенно переходим от умения «правильно попросить» к умению точно описать, что нужно построить, в каких границах и как проверить результат.
От Prompt Engineering к Context Engineering.
И это уже не навык общения с моделью. Это обычная инженерия, которую мы слишком долго откладывали.
❤1