Инженерный менеджмент после того, как код подешевел

Автор — уже три года директор по инженерии — признаётся, что долго считал отставшими тех, кто повторяет «старые правила»: директор не должен писать код, хорошая работа требует времени, ограждай команду от бизнеса, добивайся консенсуса перед решением. Но после внедрения LLM в его организации стоимость производства кода упала, и он начал проверять каждое правило на прочность. Вывод оказался неожиданным: примерно половина правил держалась на предпосылках, которые сломались, а другая половина — на предпосылках, которые устояли и теперь значат даже больше.

Что мы действительно знаем

Подешевело производство правдоподобного кода — и назад цена не вернётся. Всё остальное, настаивает автор, либо не доказано, либо ложно. Что ИИ радикально ускорил разработку — не доказано. Что код-ревью, документация и онбординг устарели — неверно. Что тем же роадмапом можно управлять вдвое меньшим штатом — ставка, а не факт. Строить практики на узком утверждении разумно; строить на широких — значит играть чужими карьерами и называть это выводом.

Сортировать, а не жечь

Главная мысль: каждую управленческую практику нужно проверять по тому, на чём она держится. Опирается на стоимость написания кода — на пересмотр, потому что эта стоимость сдвинулась. Опирается на то, как люди координируются, строят доверие и проверяют корректность, — ничего не изменилось, каким бы архаичным ни казался ритуал. Возраст практики и её обоснованность — независимые переменные, а многие сортируют «по ощущению».

Метрики вроде velocity и числа закрытых тикетов всегда были слабыми приближениями, но терпимыми, пока труд по написанию кода был дефицитен. Теперь дешевле всего накрутить их объёмом — а объёма как раз в избытке.

Верификация становится узким местом

Механическую проверку (типы, тесты, контракты, линтеры) агенты гоняют быстрее любого ревьюера. Но быстро это потому, что кто-то заранее записал, что значит «правильно». Семантическая проверка — соответствует ли код нужной бизнес-политике и регуляторным рискам — живёт в головах людей, и ИИ, проверяющий ИИ, делит с генератором слепые пятна. Дешёвая проверка провоцирует больше генерации, а значит и больше проверки; растёт доля системных ошибок вместо глупых. Самое медленное в верификации — не проверка, а ответственность: подпись под результатом не сжимается, потому что это принятие риска, а не обработка информации.

Нерешённые проблемы

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

Пересматривая тезисы, автор оставляет их живыми, но с оговорками: директору код писать не обязательно, но нужен контакт с инструментами, чтобы не обмануться ни хайпом, ни отрицанием; ограждать команду от бизнеса опасно — без контекста ИИ выдаёт складную и неверную работу масштабно; консенсус нужен лишь для необратимых решений.

В пределе, доводит автор мысль, оргструктура перестаёт фиксировать, кто производит, и начинает фиксировать, кто подписывает. Такие компании будут выглядеть маленькими и почти пустыми: короткий список имён, привязанных к длинному списку решений.

Источник: Hacker News