Всем привет, на связи снова Саша Сергеев, CTO в Профи.ру. И сегодня поговорим кое о чём серьёзном.
Последнее время слышу про новый вид долга — когнитивный. Это когда код пишется быстрее, чем люди успевают его понять и взять под контроль. В статье обсудим этот феномен: расскажу, есть ли когнитивный долг у нас в команде и что собираемся делать с ним дальше.
Что такое когнитивный долг
С техническим долгом всё более-менее понятно. Команда осознанно идёт на упрощение: где-то разрешили себе костыль, где-то пожертвовали красотой архитектуры ради скорости, где-то сознательно обошли свои же стандарты с надеждой, что потом поправите. Все понимают, что сделали задачу не идеально, а ещё также понимают, что это надо будет когда-то чинить. Но это будет завтра.
А вот когнитивный долг уже про другое — не про качество кода, а про то, понимает ли хоть кто-нибудь, что в нём написано. Автор статьи, на которую я выше сослался, привела пример: участники её курса после 7–8 недель перестали понимать, как вносить минимальные правки в код, потому что всё ломалось. Сначала подумали, что дело в техдолге. Начали разбираться и поняли: просто писали код так быстро, что перестали понимать, как работает система as a whole. А когда не видишь картинку целиком, очень сложно работать фрагментарно.
Сейчас, когда ИИ-агенты становятся лучше и лучше с каждым днём, в системе часто могут появляться куски, поведение которых команда не может объяснить. Код написан, он крутится в проде, бизнес на нём зарабатывает, но, если спросить, что там внутри происходит и почему именно так, — ответить не могут.
Справедливости ради, нужно сказать, что раньше такое тоже случалось и без ИИ. Классический пример — низкий bus factor: один человек владел большим куском логики, потом внезапно уволился, и на команду сваливался работающий, но непонятный код. И пока всё ок — всё ок. Как только что-то ломается, команда впервые понимает, что ничего не понимает.
Откуда берётся этот долг
Опишу типичную картину. Разработчик берёт ИИ-агента и просит его сделать такую-то фичу. Фича не ограничивается одной функцией — там несколько файлов, несколько слоёв логики, интеграции, тесты и так далее.
Но разработчик перегружен: или ему не хватает опыта, или просто хочется быстрее закрыть задачу. Он убеждается, что всё нажимается, форма отправляется, то есть фича внешне работает. Но что именно внутри сгенерированного кода происходит, он до конца не понимает.
Важный нюанс. Тут нельзя проводить параллель с тем, как делали раньше: вставили с Хабра или Stack Overflow пару строчек хука или утилиту. Это нормальная рабочая практика, так как чаще всего копируется небольшой фрагмент, который разработчик хотя бы по диагонали читает и задачу которого понимает.
С ИИ ситуация другая. Модель генерирует не один хелпер, а целый кусок бизнес-логики. И разработчик, особенно не очень опытный, может даже не осознать, что он не понимает этот код по-настоящему. В этом кроется опасное заблуждение.
Добавим сюда давление на скорость. Руководство ожидает, что с ИИ всё станет быстрее. Появляется риск, что попытка осмыслить код и провести ревью начнёт восприниматься как тормоз для бизнеса. В итоге когнитивный долг накапливается незаметно, маленькими порциями, в каждой фиче.
К чему ведёт когнитивный долг: сеньоры стали особенно важны
На фоне появления когнитивного долга стоимость сильных разработчиков резко увеличивается. Если развитие пойдёт по текущей траектории, то сеньор всё меньше будет писать код руками и всё больше будет принимать технические решения и управлять потоком кода, который за него генерируют ассистенты и агенты.
По сути, сеньор превращается в человека, который принимает десятки решений в день: что переписать, что не трогать, какие подходы уместны, какие ведут к катастрофе через полгода, где когнитивный долг допустим (потому что риск низкий), а где нет.
Если у сеньора раньше была возможность выдохнуть на рутинной части, то теперь так не получится.
Когда значительную часть кода пишет ИИ, эта зона отдыха растворяется. Остаётся только тяжёлая часть: проектирование, архитектура, ревью, принятие компромиссов. Не все к этому готовы, и не все хотят так работать.
Другой вариант — если код продолжат писать люди, но с опорой на ИИ-ассистентов. Тогда к сеньору просто будет прилетать больше кода на ревью. Скорость генерации вырастет, а вот время на вдумчивый разбор — нет.
И так и так риск когнитивного долга будет увеличиваться, но без конкретных цифр. Так как посчитать его пока что не получится, всё работает на ощущениях.
Кто виноват и что делать?
Хорошая новость: никто не виноват. Плохая: делать с этим что-то всё равно надо.
Как делают другие — не знаю, пока что об этом говорят мало. Так что расскажу про наш подход в Профи.ру.
Наши команды не живут в реальности, где код пишут только агенты. В наш прод попадает только то, что тщательно отсмотрели и проверили люди. Но это не означает, что проблемы когнитивного долга нас не касаются. Наоборот, мы сознательно закладываем на его решение ресурсы.
Во‑первых, у нас уже есть карта рисков по доменам системы. Мы про это подробно писали в прошлой статье: весь продукт разделён на логические домены, у каждого свой цвет на интерактивной карте.
«Зелёные домены» — некритичные: даже если там что-то пойдёт не так, команда в своём темпе и без паники всё поднимет. «Красные» — обратная история: чаты, аутентификация, базы данных. Здесь ошибаться нельзя, поэтому команда идёт чинить код максимально оперативно. Эту карту мы раскрашиваем вместе на специальных встречах, где обсуждаем риски и договорённости.
Когнитивный долг мы тоже теперь вписываем в эту картину. Где‑то мы честно признаёмся сами себе, что долг есть, но это некритично: ущерб ограничен. А где‑то, если зона ближе к «красной», сознательно выделяем людей и время, чтобы разобраться, как всё устроено, и вернуть контроль над кодом.
Во‑вторых, мы много экспериментируем с тем, как ИИ помогает в разработке. Сейчас активно используем его в нескольких задачах, таких как:
генерация «рыбы» кода, которую потом доводят до ума разработчики;
автоматические проверки стиля и простых паттернов;
помощь в рефакторинге и работе с легаси — там, где у человека часто не хватает терпения делать одно и то же вручную.
При этом мы не хотим привязываться к конкретной модели, которая сейчас в тренде. Стараемся строить процессы так, чтобы завтра можно было заменить одну модель другой, а общий контур остался тем же. Если модель станет лучше, то проверки и написание кода станут качественнее, но сама идея процесса не меняется.
Важная оговорка: мы не перекладываем ответственность за код на ИИ. Любой разработчик у нас отвечает за каждую строчку, независимо от того, написал он её сам, взял из интернета или сгенерировал через агента.
В‑третьих, мы смотрим в сторону того, как ИИ может не только писать код, но и помогать контролировать качество и сложность. Полноценного агента-ревьюера, который бы на равных заменял опытного сеньора, я пока не видел.
Модели умеют находить локальные проблемы: очевидные баги, нарушения стиля, потенциальные уязвимости. Но увидеть, что задача решена концептуально не тем способом, по-прежнему им не под силу. Это зона ответственности человека.
Пока что когнитивный долг — это зона большой неопределённости. Но нас это не пугает, ведь мы никогда не снижаем уровень контроля над кодом, даже если ищем пути для ускорения и автоматизации через ИИ.
А вы что думаете? Если есть что добавить, поправить или спросить, приглашаю в комментарии.
