Код работает. Но команда не понимает почему
PR принят. Тесты зелёные. Решение уже в проде.
Но через месяц появляется новое требование — и выясняется, что никто не хочет трогать этот код.
Не потому, что он плохо написан. Просто команда не может уверенно ответить:
— почему выбрали именно это решение;
— какие предположения в него заложены;
— где проходят его границы;
— что сломается при изменении требований.
AI заметно ускорил путь от задачи до работающего кода. Но вместе с этим появился новый вид долга — долг понимания, или comprehension debt.
Это не совсем обычный технический долг.
Технический долг обычно заметен: дублирование, сложные зависимости, отсутствие тестов, устаревшие библиотеки. А здесь код может выглядеть вполне прилично.
Проблема в другом: команда формально владеет решением, но фактически не понимает его достаточно хорошо, чтобы безопасно развивать.
Особенно опасна фраза:
Проверка результата не равна пониманию решения.
Как тимлиду не допустить накопления такого долга?
На ревью обсуждать не только код, но и решение:
1. Почему выбран этот подход?
2. Какие альтернативы рассматривались?
3. На каких предположениях всё держится?
4. Где решение перестанет работать?
5. Сможет ли автор объяснить его без ссылки на чат с AI?
Не каждый PR должен превращаться в архитектурный трактат. Но чем выше цена ошибки, тем важнее зафиксировать ход мысли: в описании PR, ADR, комментарии к тесту или короткой схеме.
AI может генерировать код быстрее, чем команда успевает строить его ментальную модель. Поэтому новая задача тимлида — следить не только за скоростью разработки и качеством кода, но и за тем, остаётся ли понимание внутри команды.
Потому что код, который никто не понимает, — это уже не ускорение.
Это отложенный инцидент.
PR принят. Тесты зелёные. Решение уже в проде.
Но через месяц появляется новое требование — и выясняется, что никто не хочет трогать этот код.
Не потому, что он плохо написан. Просто команда не может уверенно ответить:
— почему выбрали именно это решение;
— какие предположения в него заложены;
— где проходят его границы;
— что сломается при изменении требований.
AI заметно ускорил путь от задачи до работающего кода. Но вместе с этим появился новый вид долга — долг понимания, или comprehension debt.
Это не совсем обычный технический долг.
Технический долг обычно заметен: дублирование, сложные зависимости, отсутствие тестов, устаревшие библиотеки. А здесь код может выглядеть вполне прилично.
Проблема в другом: команда формально владеет решением, но фактически не понимает его достаточно хорошо, чтобы безопасно развивать.
Особенно опасна фраза:
«Это AI предложил, мы проверили — работает».
Проверка результата не равна пониманию решения.
Как тимлиду не допустить накопления такого долга?
На ревью обсуждать не только код, но и решение:
1. Почему выбран этот подход?
2. Какие альтернативы рассматривались?
3. На каких предположениях всё держится?
4. Где решение перестанет работать?
5. Сможет ли автор объяснить его без ссылки на чат с AI?
Не каждый PR должен превращаться в архитектурный трактат. Но чем выше цена ошибки, тем важнее зафиксировать ход мысли: в описании PR, ADR, комментарии к тесту или короткой схеме.
AI может генерировать код быстрее, чем команда успевает строить его ментальную модель. Поэтому новая задача тимлида — следить не только за скоростью разработки и качеством кода, но и за тем, остаётся ли понимание внутри команды.
Потому что код, который никто не понимает, — это уже не ускорение.
Это отложенный инцидент.
👍2❤1
Долг понимания: новый вид технического долга
Код компилируется.
Тесты проходят.
PR смержен.
Фича работает.
Формально всё хорошо. Но через несколько месяцев выясняется, что никто в команде толком не понимает, почему решение устроено именно так.
С AI попасть в эту ситуацию стало проще.
Разработчик ставит задачу агенту. Агент исследует кодовую базу, предлагает реализацию, пишет тесты и исправляет ошибки. Результат выглядит убедительно, поэтому хочется проверить только внешнее поведение:
Работает?
Работает.
Значит, можно принимать.
Проблема проявится позже, когда изменятся требования. Тогда окажется, что команда не знает:
— какие предположения заложены в решение;
— почему выбран именно этот подход;
— какие альтернативы были отброшены;
— где находятся скрытые ограничения;
— что сломается при следующем изменении.
Я бы назвал это долгом понимания.
Обычный технический долг часто появляется как осознанный компромисс: сейчас делаем проще, потом переделаем.
С долгом понимания хуже. Команда может даже не знать, что компромисс существует. Код уже стал частью системы, а объяснение осталось где-то в истории диалога с агентом.
Особенно опасно принимать таким образом сложную бизнес-логику, инфраструктурный код, concurrency, безопасность, нетривиальные оптимизации и архитектурные изменения.
Поэтому правила «тесты зелёные» уже недостаточно.
Перед merge я бы добавил ещё одну проверку:
Могу ли я объяснить это решение другому инженеру без открытия истории диалога с AI?
Почему код устроен именно так? На каких предположениях он держится? Где его границы? Что придётся пересмотреть при изменении требований?
Если ответов нет, код может быть рабочим. Но ownership над ним у команды ещё не появился.
AI делает создание кода дешевле. Значит, понимание этого кода становится дороже и ценнее.
Код компилируется.
Тесты проходят.
PR смержен.
Фича работает.
Формально всё хорошо. Но через несколько месяцев выясняется, что никто в команде толком не понимает, почему решение устроено именно так.
С AI попасть в эту ситуацию стало проще.
Разработчик ставит задачу агенту. Агент исследует кодовую базу, предлагает реализацию, пишет тесты и исправляет ошибки. Результат выглядит убедительно, поэтому хочется проверить только внешнее поведение:
Работает?
Работает.
Значит, можно принимать.
Проблема проявится позже, когда изменятся требования. Тогда окажется, что команда не знает:
— какие предположения заложены в решение;
— почему выбран именно этот подход;
— какие альтернативы были отброшены;
— где находятся скрытые ограничения;
— что сломается при следующем изменении.
Я бы назвал это долгом понимания.
Обычный технический долг часто появляется как осознанный компромисс: сейчас делаем проще, потом переделаем.
С долгом понимания хуже. Команда может даже не знать, что компромисс существует. Код уже стал частью системы, а объяснение осталось где-то в истории диалога с агентом.
Особенно опасно принимать таким образом сложную бизнес-логику, инфраструктурный код, concurrency, безопасность, нетривиальные оптимизации и архитектурные изменения.
Поэтому правила «тесты зелёные» уже недостаточно.
Перед merge я бы добавил ещё одну проверку:
Могу ли я объяснить это решение другому инженеру без открытия истории диалога с AI?
Почему код устроен именно так? На каких предположениях он держится? Где его границы? Что придётся пересмотреть при изменении требований?
Если ответов нет, код может быть рабочим. Но ownership над ним у команды ещё не появился.
AI делает создание кода дешевле. Значит, понимание этого кода становится дороже и ценнее.
👍2
«Возьми ownership» — одна из самых бесполезных фраз менеджера.
Её удобно произносить.
Разработчик принёс проблему?
Возьми ownership.
Задача зависла?
Нужно больше ownership.
Никто не принимает решение?
Ну вы поняли.
Проблема в том, что ответственность за результат нельзя выдать человеку одной фразой. Для неё нужны как минимум четыре условия.
1. Понятная зона ответственности
За что конкретно отвечает человек?
За сервис?
За отдельную фичу?
За техническую реализацию?
За delivery целиком?
«Отвечай за всё» обычно означает, что границы ответственности не определены вообще.
2. Полномочия
Если разработчик отвечает за сервис, но любое изменение требует согласования трёх руководителей, такой ownership носит скорее декоративный характер.
Ответственность без права принимать решения создаёт не автономию, а удобного виноватого.
3. Контекст
Чтобы принимать решения, человек должен понимать:
— зачем существует продукт;
— какие ограничения есть у бизнеса;
— какие риски допустимы;
— что сейчас важнее всего.
Нельзя требовать продуктового мышления и одновременно передавать человеку только номер задачи в Jira.
4. Понятный ожидаемый результат
Ownership — это не «разберись как-нибудь».
Должно быть ясно, что считается хорошим результатом, какие ограничения нужно учитывать и где заканчивается зона самостоятельности.
Например, фраза «ты отвечаешь за сервис» сама по себе почти ничего не означает.
Нормальный ownership предполагает, что человек может:
— принимать большинство технических решений;
— определять необходимые улучшения;
— обсуждать SLA;
— поднимать риски;
— инициировать работу с техдолгом.
При этом он понимает, какие изменения можно делать самостоятельно, а какие требуют обсуждения с командой или архитекторами.
Мне кажется, зрелость команды хорошо видна именно здесь.
Не по количеству раз, когда руководитель произнёс слово ownership.
А по количеству решений, которые люди способны принимать самостоятельно — в понятных границах и с достаточным контекстом.
Её удобно произносить.
Разработчик принёс проблему?
Возьми ownership.
Задача зависла?
Нужно больше ownership.
Никто не принимает решение?
Ну вы поняли.
Проблема в том, что ответственность за результат нельзя выдать человеку одной фразой. Для неё нужны как минимум четыре условия.
1. Понятная зона ответственности
За что конкретно отвечает человек?
За сервис?
За отдельную фичу?
За техническую реализацию?
За delivery целиком?
«Отвечай за всё» обычно означает, что границы ответственности не определены вообще.
2. Полномочия
Если разработчик отвечает за сервис, но любое изменение требует согласования трёх руководителей, такой ownership носит скорее декоративный характер.
Ответственность без права принимать решения создаёт не автономию, а удобного виноватого.
3. Контекст
Чтобы принимать решения, человек должен понимать:
— зачем существует продукт;
— какие ограничения есть у бизнеса;
— какие риски допустимы;
— что сейчас важнее всего.
Нельзя требовать продуктового мышления и одновременно передавать человеку только номер задачи в Jira.
4. Понятный ожидаемый результат
Ownership — это не «разберись как-нибудь».
Должно быть ясно, что считается хорошим результатом, какие ограничения нужно учитывать и где заканчивается зона самостоятельности.
Например, фраза «ты отвечаешь за сервис» сама по себе почти ничего не означает.
Нормальный ownership предполагает, что человек может:
— принимать большинство технических решений;
— определять необходимые улучшения;
— обсуждать SLA;
— поднимать риски;
— инициировать работу с техдолгом.
При этом он понимает, какие изменения можно делать самостоятельно, а какие требуют обсуждения с командой или архитекторами.
Мне кажется, зрелость команды хорошо видна именно здесь.
Не по количеству раз, когда руководитель произнёс слово ownership.
А по количеству решений, которые люди способны принимать самостоятельно — в понятных границах и с достаточным контекстом.
❤1