Повышение эффективности ИИ продолжит улучшать базовые показатели командной работы.

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

Это изменение легче всего ошибочно принять за «нормальную боль после повышения эффективности». Реальная проблема более конкретна: базовый план мощности команды по умолчанию был переписан, но разделение задач, пороговые значения качества и распределение ответственности остались в старой версии.

После ускорения основных задач точка очереди будет перенесена в процесс принятия решений.

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

• Остается ли граница спроса неизменной после нескольких раундов изменений?
• Конфликтуют ли неявные предположения сгенерированного кода с ограничениями существующей сети. — Если одновременно модифицируются несколько модулей, кто несет ответственность за конечное поведение?

Эти три типа проблем невозможно решить, продолжая ускоряться. Они требуют консенсуса между ролями, контекстной преемственности и единого понимания цены неудачи. Из-за этого время, сэкономленное в первой половине, часто съедается откатом или двумя раундами доработок во второй половине.

После увеличения давления подачи первое, что дает сбой, — это старое определение завершения.

Раньше готовое обычно определялось как «доступная функция + пройденные тесты + завершенная документация». По мере ускорения развития ИИ это определение станет слишком расплывчатым. Коммит, который выглядит завершенным, может просто «запуститься», не ответив на ключевые вопросы:

• Наблюдается ли путь отказа
• Можно ли откатить исключения во время оттенков серого
• Можно ли сохранить автоматически созданную деталь при следующем изменении

Если определение выполненного не будет повышено, у команды возникнет иллюзия темпа: более высокий уровень видимого завершения и более низкий процент истинного завершения. Наиболее типичным явлением на этом этапе является то, что стендап-данные очень хорошие, но в ночь релиза возникает много проблем.

Механизм проверки необходимо расширить от проверки кода до проверки гипотез

Чистого анализа кода на данном этапе недостаточно. Сгенерированный код часто грамматически правилен и структурно завершен, а проблемы часто скрыты в предположениях. Например, стратегия повтора по умолчанию, тайм-аут по умолчанию и путь перехода на более раннюю версию кажутся разумными, но при их включении в текущую систему они могут просто попасть в слабое место.

Эффективный обзор должен четко указать, «от каких предпосылок зависит это изменение». Чем четче предпосылка, тем стабильнее будет последующая совместная отладка. В реальной реализации запись трех типов информации позволяет существенно сократить объем переработок:

1. Ключевые предположения (от каких внешних условий это зависит)
2. Сигнал о несостоятельности (какое явление свидетельствует о несостоятельности гипотезы)
3. Действие отката (кто будет обрабатывать сигнал и через какое время после его появления)

Это делается не для увеличения нагрузки на процесс, а для того, чтобы превратить неявные суждения, изначально скрытые в записях чата, в явные ограничения, с которыми можно заранее сотрудничать.

Повышение эффективности ИИ не приведет к автоматическому снижению давления, оно изменит распределение давления

Судя по инженерным результатам, напряжение не исчезло, а перекочевало из «выходной скорости» в «качество сходимости». Тот, кто сможет быстрее обнаружить неверные предположения, свести межмодульные различия и стабилизировать пути сбоя, сможет поддерживать стабильную поставку в новом ритме.

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