Чистый код в эпоху coding-агентов

Короткая публикация на yanist.com с одной главной мыслью: при работе с coding-агентами чистый код не теряет важности, а становится только нужнее. Аргумент строится на том, что контекстные окна LLM - это машинный эквивалент когнитивной нагрузки человека, поэтому те же принципы организации, которые помогают человеку ориентироваться в кодовой базе, помогают и агенту. Неаккуратный код вынуждает агента читать больше файлов, чем необходимо, сжигать место в контексте на нерелевантный код и тратить токены на ориентацию вместо генерации результата.

Подача опирается на разделение из книги Роберта Мартина "Чистая архитектура" (Clean Architecture) между ценностью кода (делает ли он то, что нужно) и его структурой (организован ли он так, чтобы его можно было изменить позже). Ценность заметить легко: возможность либо работает, либо нет. Структуру заметить труднее, а издержки от неё накапливаются: каждый плохо организованный модуль делает добавление следующей возможности чуть сложнее, а каждая заплатка поверх неаккуратной абстракции немного повышает вероятность багов. Мартин приводил этот аргумент для команд разработчиков; публикация переносит его на разработку с помощью агентов, отмечая, что агенты страдают от тех же структурных издержек, только выраженных в засорении контекста, а не в путанице у программиста.

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

Это конструктивное дополнение к нескольким другим материалам вики. В cult-of-vibe-coding доказывается, что код нужно читать самому (цикл аудита, обсуждения и исполнения Коэна). В no-silver-bullet-llms утверждается, что узкое место - это проектирование и спецификация, а не скорость генерации кода. В building-syntaqlite-ai зафиксировано, что происходит, когда проектирование перекладывают на агента и теряют ментальную модель. Этот пост мягче: он не выступает против использования агентов, а лишь говорит о том, что архитектурные решения по-прежнему остаются за человеком. Агент генерирует код; вы поддерживаете архитектуру. Такое разделение труда работает только в том случае, если архитектура достаточно чиста, чтобы агент мог эффективно в ней ориентироваться.

Статья "The Peril of Laziness Lost" Брайана Кантрилла объясняет глубинную причину, по которой агенты по умолчанию создают беспорядок: работа ничего им не стоит, поэтому у них нет стимула к упрощению. Именно "добродетельная лень", вызванная ограничениями человеческого времени, порождает чистый код, за поддержание которого выступает этот пост. refactoring-that-never-happens приходит к тому же выводу со стороны рефакторинга: агенты никогда не теряются в запутанном коде, поэтому чистка, которая сохраняет его понятным для навигации, перестаёт происходить, если человек не заставит это сделать.

Материал поверхностный: он излагает аргумент без доказательств или разбора практических примеров. Но основное наблюдение (контекстные окна ограничены -> структура определяет, сколько полезной работы поместится в один контекст) верно и связывает традицию "чистого кода" с миром LLM-агентов так, как оригинальные работы Мартина и Фаулера, очевидно, не могли.

benchmarking-opus-5-slopcodebench подкрепляет цифрами компромисс, который предполагается в этом посте: на всех контрольных точках SlopCodeBench сложность у каждой модели росла, а модель с наименьшей средней сложностью достигла этого, написав примерно в пять раз больше функций, чем остальные.

Один из опубликованных архитектурных паттернов, который явно продвигает себя на этой предпосылке, - porto-sap: текущий README проекта начинается с утверждения, что подход "один класс с единственной обязанностью на файл" делает кодовую базу более удобной для Copilot. По сути, это тот же аргумент из статьи, только превращённый в соглашение о структуре папок.