Качество кода всё ещё имеет значение?

Когда агент за несколько минут делает задачу, на которую раньше уходил день, возникает соблазн пересмотреть привычные правила разработки. Зачем тратить время на структуру кода, понятные названия и разделение ответственности? Всё работает. А когда понадобится что-то изменить, можно снова попросить агента.

В этом рассуждении есть логика. Мы привыкли писать код так, чтобы его мог понять человек. Разбиваем систему на модули, уменьшаем связанность, выбираем названия, по которым через полгода можно вспомнить, что здесь происходит.

Но если всё больше кода пишут агенты, для кого мы продолжаем стараться?

Я пока не вижу причин отказываться от качества кода. Хотя допускаю, что со временем мы будем иначе понимать, что такое хороший код.

Человеку всё ещё нужно проверять код

Сегодня человек по-прежнему ставит задачу, принимает решения, проверяет изменения и отвечает за результат. Даже если разработчик не написал ни одной строки, ему нужно разобраться, можно ли всё это релизить.

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

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

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

Для меня качество кода становится заметно при следующем изменении. Насколько легко добавить новое поведение, проверить его и убедиться, что существующее продолжает работать?

Что изменится, если код будут читать только агенты

Сложнее представить, что будет, если человек вообще перестанет читать код.

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

У современных агентов тоже есть ограничения. Чтобы изменить поведение системы, агенту нужно выяснить, где находится нужная логика, от чего она зависит и какие условия нельзя нарушать. Если эти сведения разбросаны по проекту, их сначала придётся найти и связать между собой.

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

Технический долг и рефакторинг

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

Можно, конечно, поручить агенту рефакторинг. Но ему всё равно придётся разобраться, какое поведение нужно сохранить. Если документация устарела, тесты покрывают только основной сценарий, а исключения спрятаны в условиях, сначала нужно восстановить правила системы. Быстро переписать код и выяснить, как он должен работать, совсем разные задачи.

Во сколько обойдётся следующее изменение

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

Мне ближе практический критерий: оправдана ли сложность и можем ли мы уверенно менять этот код?

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

Какие требования к коду будут у будущих систем, я не знаю. Возможно, они научатся справляться со сложностью способами, к которым мы сейчас не привыкли.

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

Поводом для размышлений стала статья Does code quality still matter?.