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.
И это уже не навык общения с моделью. Это обычная инженерия, которую мы слишком долго откладывали.
❤2
Definition of Ready для AI-агента
Мы давно усвоили: плохо поставленная задача плохо заканчивается.
Но затем открываем чат с AI-агентом и пишем:
Сделай фичу.А через час удивляемся, почему он изменил не тот модуль, нарушил архитектуру и написал тесты, которые ничего не проверяют.
Проблема не всегда в агенте. Иногда он просто слишком буквально выполнил слишком расплывчатое задание.
Поэтому AI-агенту нужен свой Definition of Ready.
До запуска он должен понимать:
— какую проблему решает;
— где можно менять код;
— куда заходить нельзя;
— какие есть архитектурные ограничения;
— какой стиль принят в проекте;
— какие тесты должны пройти;
— что считается готовым результатом;
— как именно человек будет проверять его работу.
Сравните два задания.
Плохое:
Сделай регистрацию.
Готовое к работе:
Добавь регистрацию через этот API.
Следуй этому ADR.
Меняй только модуль Auth.
Схему базы не трогай.
Вот примеры похожего кода.
Вот обязательные тесты.
Задача готова, когда выполняются эти сценарии.Во втором случае агенту не приходится угадывать ваши намерения. Он может заниматься реализацией.
DoR придумали не для бюрократии и не только для разработчиков. Он нужен любому исполнителю, от которого ждут предсказуемого результата.
Даже если исполнитель кремниевый.
Мы давно усвоили: плохо поставленная задача плохо заканчивается.
Но затем открываем чат с AI-агентом и пишем:
Сделай фичу.А через час удивляемся, почему он изменил не тот модуль, нарушил архитектуру и написал тесты, которые ничего не проверяют.
Проблема не всегда в агенте. Иногда он просто слишком буквально выполнил слишком расплывчатое задание.
Поэтому AI-агенту нужен свой Definition of Ready.
До запуска он должен понимать:
— какую проблему решает;
— где можно менять код;
— куда заходить нельзя;
— какие есть архитектурные ограничения;
— какой стиль принят в проекте;
— какие тесты должны пройти;
— что считается готовым результатом;
— как именно человек будет проверять его работу.
Сравните два задания.
Плохое:
Сделай регистрацию.
Готовое к работе:
Добавь регистрацию через этот API.
Следуй этому ADR.
Меняй только модуль Auth.
Схему базы не трогай.
Вот примеры похожего кода.
Вот обязательные тесты.
Задача готова, когда выполняются эти сценарии.Во втором случае агенту не приходится угадывать ваши намерения. Он может заниматься реализацией.
DoR придумали не для бюрократии и не только для разработчиков. Он нужен любому исполнителю, от которого ждут предсказуемого результата.
Даже если исполнитель кремниевый.
❤1👍1🔥1
AI ускоряет не разработку. Он ускоряет вашу систему
За последнюю неделю я прочитал около двадцати материалов про AI в разработке: исследования DORA и Microsoft, статьи Atlassian и Habr, обсуждения на Hacker News.
Удивительно, насколько часто они приходят к одной и той же мысли.
Ещё год назад все сравнивали модели:
Claude.
GPT.
Gemini.
Cursor.
Кто лучше пишет код. Кто точнее понимает контекст. Кто быстрее закрывает задачу.
Сегодня вопрос «умеет ли AI писать код?» уже не так интересен.
Фокус сместился на другое:
что произойдёт с инженерной командой, когда код перестанет быть главным ограничением?
И здесь ответы разных исследований сходятся.
AI усиливает существующую систему работы.
Если задачи хорошо описаны, архитектурные решения зафиксированы, тесты надёжны, а ревью не занимает неделю — команда действительно ускоряется.
Если требования меняются по дороге, знания живут в головах, а каждый PR проходит археологическую экспертизу — AI просто быстрее создаёт следующую порцию незавершённой работы.
Формально кода становится больше.
Фактически очередь перед ревью, тестированием и приёмкой растёт ещё быстрее.
Вот что мне особенно запомнилось:
— DORA рассматривает AI не как замену инженерным практикам, а как усилитель уже существующих возможностей команды.
— Microsoft делает акцент не только на инструментах, но и на роли руководителей, устройстве работы и организационных изменениях.
— Atlassian пишет о смещении узкого места: генерация кода ускоряется, поэтому ограничением становятся контекст, согласования, ревью и проверка результата.
— В обсуждениях практиков на Hacker News спор всё чаще идёт не о том, какая модель умнее, а о том, как встроить её в процесс и не потерять качество.
Кажется, эпоха главного вопроса:
«Какую модель выбрать?»
постепенно заканчивается.
Начинается эпоха вопросов:
«Как поставить задачи так, чтобы AI не угадывал требования?»
«Кто и как будет проверять результат?»
«Где теперь появится очередь?»
«Какие части процесса придётся перестроить?»
Выбор модели всё ещё важен. Но разница между двумя моделями может оказаться менее значимой, чем разница между командами, в одной из которых есть понятный инженерный процесс, а в другой — только лицензия на новый инструмент.
Что почитать:
— DORA: State of AI-assisted Software Development 2025
— Microsoft Work Trend Index 2026
— Atlassian: The bottleneck keeps shifting
— Atlassian: How AI is Changing Developer Workflows
А у вашей команды после внедрения AI где сместилось узкое место: постановка задач, контекст, ревью, тестирование или приёмка?
За последнюю неделю я прочитал около двадцати материалов про AI в разработке: исследования DORA и Microsoft, статьи Atlassian и Habr, обсуждения на Hacker News.
Удивительно, насколько часто они приходят к одной и той же мысли.
Ещё год назад все сравнивали модели:
Claude.
GPT.
Gemini.
Cursor.
Кто лучше пишет код. Кто точнее понимает контекст. Кто быстрее закрывает задачу.
Сегодня вопрос «умеет ли AI писать код?» уже не так интересен.
Фокус сместился на другое:
что произойдёт с инженерной командой, когда код перестанет быть главным ограничением?
И здесь ответы разных исследований сходятся.
AI усиливает существующую систему работы.
Если задачи хорошо описаны, архитектурные решения зафиксированы, тесты надёжны, а ревью не занимает неделю — команда действительно ускоряется.
Если требования меняются по дороге, знания живут в головах, а каждый PR проходит археологическую экспертизу — AI просто быстрее создаёт следующую порцию незавершённой работы.
Формально кода становится больше.
Фактически очередь перед ревью, тестированием и приёмкой растёт ещё быстрее.
Вот что мне особенно запомнилось:
— DORA рассматривает AI не как замену инженерным практикам, а как усилитель уже существующих возможностей команды.
— Microsoft делает акцент не только на инструментах, но и на роли руководителей, устройстве работы и организационных изменениях.
— Atlassian пишет о смещении узкого места: генерация кода ускоряется, поэтому ограничением становятся контекст, согласования, ревью и проверка результата.
— В обсуждениях практиков на Hacker News спор всё чаще идёт не о том, какая модель умнее, а о том, как встроить её в процесс и не потерять качество.
Кажется, эпоха главного вопроса:
«Какую модель выбрать?»
постепенно заканчивается.
Начинается эпоха вопросов:
«Как поставить задачи так, чтобы AI не угадывал требования?»
«Кто и как будет проверять результат?»
«Где теперь появится очередь?»
«Какие части процесса придётся перестроить?»
Выбор модели всё ещё важен. Но разница между двумя моделями может оказаться менее значимой, чем разница между командами, в одной из которых есть понятный инженерный процесс, а в другой — только лицензия на новый инструмент.
Что почитать:
— DORA: State of AI-assisted Software Development 2025
— Microsoft Work Trend Index 2026
— Atlassian: The bottleneck keeps shifting
— Atlassian: How AI is Changing Developer Workflows
А у вашей команды после внедрения AI где сместилось узкое место: постановка задач, контекст, ревью, тестирование или приёмка?
👍1
Кто вырастит senior-разработчиков, если AI заберёт junior-задачи
Раньше путь junior-разработчика выглядел довольно предсказуемо.
Поправить небольшой баг.
Добавить поле в API.
Написать простой тест.
Разобраться, почему задача работает локально, но падает в CI.
Сами по себе эти задачи не делали человека senior. Но именно на них разработчик учился читать чужой код, ходить по стеку вызовов, замечать архитектурные ограничения и восстанавливаться после собственных ошибок.
Теперь значительную часть такой работы можно отдать AI.
Junior получает готовый фрагмент кода, запускает тесты, немного правит результат и отправляет PR. Формально задача выполнена быстрее.
Но есть проблема: скорость выполнения задачи и скорость обучения — не одно и то же.
Можно получить правильный ответ, не поняв:
— почему решение устроено именно так;
— какие варианты были отброшены;
— где оно сломается на реальных данных;
— почему тесты зелёные, но уверенности всё равно нет;
— как найти ошибку, если AI уверенно предложил не тот путь.
Раньше обучение частично происходило автоматически — просто потому, что без понимания задачу было сложно закончить.
С AI этот механизм перестаёт работать. Можно закрывать задачи и почти не накапливать инженерный опыт.
Значит, выращивание разработчиков придётся проектировать отдельно.
Не запрещать AI. Это примерно как запретить IDE, чтобы люди лучше запоминали синтаксис.
Но и не считать закрытые тикеты доказательством развития.
Нужны другие практики:
— просить объяснить решение и его ограничения;
— разбирать не только итоговый код, но и ход рассуждений;
— давать задачи на диагностику, а не только на генерацию;
— обсуждать альтернативы на ревью;
— постепенно увеличивать область ответственности;
— оставлять человеку право ошибиться и самостоятельно найти причину.
Возможно, главной задачей senior-разработчика скоро станет не написание сложного кода, а создание среды, в которой junior не превращается в оператора кнопки «сгенерировать».
AI забирает рутину. Но вместе с рутиной он может случайно забрать и практику.
И тогда вопрос уже не в том, сможет ли junior быстрее закрывать задачи.
Кто и как будет выращивать следующего senior, если путь от проблемы к решению он больше не проходит сам?
Раньше путь junior-разработчика выглядел довольно предсказуемо.
Поправить небольшой баг.
Добавить поле в API.
Написать простой тест.
Разобраться, почему задача работает локально, но падает в CI.
Сами по себе эти задачи не делали человека senior. Но именно на них разработчик учился читать чужой код, ходить по стеку вызовов, замечать архитектурные ограничения и восстанавливаться после собственных ошибок.
Теперь значительную часть такой работы можно отдать AI.
Junior получает готовый фрагмент кода, запускает тесты, немного правит результат и отправляет PR. Формально задача выполнена быстрее.
Но есть проблема: скорость выполнения задачи и скорость обучения — не одно и то же.
Можно получить правильный ответ, не поняв:
— почему решение устроено именно так;
— какие варианты были отброшены;
— где оно сломается на реальных данных;
— почему тесты зелёные, но уверенности всё равно нет;
— как найти ошибку, если AI уверенно предложил не тот путь.
Раньше обучение частично происходило автоматически — просто потому, что без понимания задачу было сложно закончить.
С AI этот механизм перестаёт работать. Можно закрывать задачи и почти не накапливать инженерный опыт.
Значит, выращивание разработчиков придётся проектировать отдельно.
Не запрещать AI. Это примерно как запретить IDE, чтобы люди лучше запоминали синтаксис.
Но и не считать закрытые тикеты доказательством развития.
Нужны другие практики:
— просить объяснить решение и его ограничения;
— разбирать не только итоговый код, но и ход рассуждений;
— давать задачи на диагностику, а не только на генерацию;
— обсуждать альтернативы на ревью;
— постепенно увеличивать область ответственности;
— оставлять человеку право ошибиться и самостоятельно найти причину.
Возможно, главной задачей senior-разработчика скоро станет не написание сложного кода, а создание среды, в которой junior не превращается в оператора кнопки «сгенерировать».
AI забирает рутину. Но вместе с рутиной он может случайно забрать и практику.
И тогда вопрос уже не в том, сможет ли junior быстрее закрывать задачи.
Кто и как будет выращивать следующего senior, если путь от проблемы к решению он больше не проходит сам?
❤2
Почему AI не уменьшает ответственность тимлида
AI может написать код, подготовить тесты, собрать документацию, найти подозрительное место в PR и предложить решение.
Кажется, что чем больше работы забирают инструменты, тем меньше остаётся руководителю.
На практике — наоборот.
AI снимает часть рутины. Но он не решает, какую задачу действительно нужно делать первой. Не определяет, какой технический долг допустим сейчас. Не отвечает за то, что команда быстро и качественно решает не ту проблему.
У тимлида по-прежнему остаются:
— приоритеты;
— архитектурные решения;
— развитие команды;
— качество процесса;
— инженерная культура;
— ответственность за результат.
Можно делегировать AI подготовку решения. Нельзя делегировать ему понимание контекста и последствий.
Если агент создал PR за десять минут, кто-то всё равно должен проверить, соответствует ли он требованиям, не ломает ли архитектуру и не создаёт ли новый риск. Скорость генерации кода не отменяет инженерного контроля. Она лишь быстрее доставляет решения к точке, где этот контроль необходим.
Более того, автономные инструменты увеличивают масштаб каждого управленческого решения.
Плохой приоритет теперь можно реализовать быстрее. Слабое архитектурное решение — распространить шире. Неясное требование — превратить в работающий, протестированный и совершенно ненужный код.
AI делает команду производительнее не сам по себе. Он усиливает систему, в которую встроен.
Поэтому чем больше автономии получают инструменты, тем важнее качество решений тимлида. Его работа постепенно смещается от контроля выполнения к проектированию среды: правил, ограничений, обратной связи и границ ответственности.
AI уменьшает объём ручной работы.
Но не уменьшает ответственность за то, зачем, как и с каким результатом эта работа выполняется.
AI может написать код, подготовить тесты, собрать документацию, найти подозрительное место в PR и предложить решение.
Кажется, что чем больше работы забирают инструменты, тем меньше остаётся руководителю.
На практике — наоборот.
AI снимает часть рутины. Но он не решает, какую задачу действительно нужно делать первой. Не определяет, какой технический долг допустим сейчас. Не отвечает за то, что команда быстро и качественно решает не ту проблему.
У тимлида по-прежнему остаются:
— приоритеты;
— архитектурные решения;
— развитие команды;
— качество процесса;
— инженерная культура;
— ответственность за результат.
Можно делегировать AI подготовку решения. Нельзя делегировать ему понимание контекста и последствий.
Если агент создал PR за десять минут, кто-то всё равно должен проверить, соответствует ли он требованиям, не ломает ли архитектуру и не создаёт ли новый риск. Скорость генерации кода не отменяет инженерного контроля. Она лишь быстрее доставляет решения к точке, где этот контроль необходим.
Более того, автономные инструменты увеличивают масштаб каждого управленческого решения.
Плохой приоритет теперь можно реализовать быстрее. Слабое архитектурное решение — распространить шире. Неясное требование — превратить в работающий, протестированный и совершенно ненужный код.
AI делает команду производительнее не сам по себе. Он усиливает систему, в которую встроен.
Поэтому чем больше автономии получают инструменты, тем важнее качество решений тимлида. Его работа постепенно смещается от контроля выполнения к проектированию среды: правил, ограничений, обратной связи и границ ответственности.
AI уменьшает объём ручной работы.
Но не уменьшает ответственность за то, зачем, как и с каким результатом эта работа выполняется.
👍2❤1
Как измерять продуктивность AI в разработке
Не строками кода.
Не количеством коммитов.
И точно не количеством промптов.
Все эти цифры показывают активность, но ничего не говорят о том, стала ли команда быстрее доставлять рабочие изменения.
Я бы смотрел на другие метрики:
— Review Time — сколько времени уходит на проверку AI-кода. Если код генерируется за минуту, а ревью занимает два часа, ускорения не произошло.
— Revert Rate — как часто изменения приходится откатывать. Быстро написанный код, который ломает прод, — это не продуктивность.
— Lead Time — сколько проходит от постановки задачи до доставки результата пользователю.
— Throughput — сколько завершённых изменений команда действительно выпускает за период, а не сколько начинает.
— Change Failure Rate — какая доля изменений приводит к инцидентам, откатам или срочным исправлениям.
— Количество ручных исправлений — сколько работы остаётся разработчику после генерации: переписать логику, добавить проверки, исправить архитектуру.
— Процент принятого AI-кода — какая часть предложений доходит до итогового изменения без существенной переработки.
Но важное ограничение: эти метрики нельзя превращать в рейтинг разработчиков или соревнование между командами.
Иначе AI начнут использовать не там, где он полезен, а там, где проще улучшить цифру.
Главный вопрос не в том, сколько кода написал AI.
Главный вопрос — помог ли он быстрее доставить качественное изменение без роста риска и скрытой ручной работы.
Не строками кода.
Не количеством коммитов.
И точно не количеством промптов.
Все эти цифры показывают активность, но ничего не говорят о том, стала ли команда быстрее доставлять рабочие изменения.
Я бы смотрел на другие метрики:
— Review Time — сколько времени уходит на проверку AI-кода. Если код генерируется за минуту, а ревью занимает два часа, ускорения не произошло.
— Revert Rate — как часто изменения приходится откатывать. Быстро написанный код, который ломает прод, — это не продуктивность.
— Lead Time — сколько проходит от постановки задачи до доставки результата пользователю.
— Throughput — сколько завершённых изменений команда действительно выпускает за период, а не сколько начинает.
— Change Failure Rate — какая доля изменений приводит к инцидентам, откатам или срочным исправлениям.
— Количество ручных исправлений — сколько работы остаётся разработчику после генерации: переписать логику, добавить проверки, исправить архитектуру.
— Процент принятого AI-кода — какая часть предложений доходит до итогового изменения без существенной переработки.
Но важное ограничение: эти метрики нельзя превращать в рейтинг разработчиков или соревнование между командами.
Иначе AI начнут использовать не там, где он полезен, а там, где проще улучшить цифру.
Главный вопрос не в том, сколько кода написал AI.
Главный вопрос — помог ли он быстрее доставить качественное изменение без роста риска и скрытой ручной работы.
❤2✍1👍1🔥1