День 2712. #Оффтоп #AI
Почему Важно Качество Кода, Созданного ИИ Агентом?
Автор оригинала: Steve “Ardalis” Smith

Один из разработчиков, с которым я недавно общался, задал вопрос, который я слышу всё чаще: «Раз уж мы можем создавать код так быстро, имеет ли качество кода такое уж большое значение? Предположим, код соответствует требованиям, подтверждён реальным пользовательским тестированием, тогда какая разница, как он выглядит? Мы просто находимся на другом уровне абстракции. Когда появились языки программирования второго и третьего поколений, вас волновало, какой ассемблерный код они выдают — лишь бы он делал то, что нужно? Поддерживаемость — кем? Какая разница, если ИИ-боты могут переписывать целые блоки кода за минуты? Зачем архитектура? Она для того, чтобы облегчить работу людям. Наблюдаемость — кем? ИИ-боты могут обрабатывать логи почти мгновенно. Тестируемость? ИИ может писать модульные и интеграционные тесты.»

Если всё это соблюдено, имеет ли значение сам код?

Думаю, ответ по-прежнему «да», но по причинам, которые не были очевидны два года назад.

Аналогия с ассемблером
Нас не волнует ассемблерный код, генерируемый компилятором, потому что компиляторы, JIT и компоновщики детерминированы. Если доказано, что фрагмент кода работает правильно, мы уверены, что он будет продолжать работать правильно при каждом запуске. Мы десятилетиями доверяли этим инструментам. Но даже в них есть ошибки. Особенно это касается оптимизирующих компиляторов. Поэтому аналогия не совсем «компиляторы идеальны, LLMs — нет».

Фактическое различие заключается в детерминизме. Ошибка компилятора воспроизводима. Вы можете создать минимальный тестовый пример, отправить отчёт, и в следующем релизе это будет исправлено. Доверие к компиляторам зарабатывалось десятилетиями именно потому, что детерминизм позволял систематически сокращать количество ошибок.

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

Добавьте достаточное количество защитных механизмов — структурированные выходные данные, этапы проверки, детерминированную постобработку — и вы сможете значительно уменьшить разброс. Но вы никогда не получите гарантию уровня компилятора от языковой модели. Это просто другой класс инструментов с другой моделью доверия.

Больше не будет бесплатных обедов
Есть вторая, все более практичная причина: ИИ стоит денег, а плохой код требует больше использовать ИИ. Компиляторы не взимают плату за минуту использования. Вас не беспокоит, что создание класса из 50 000 строк кода приведет к большим затратам. А ИИ-агенты платные. Каждый токен, который агент считывает для понимания вашей кодовой базы, стоит денег. И чем запутаннее кодовая база, тем больше токенов ей нужно потратить.

Два года работы над проектом с поддержкой ИИ без структуры — код, добавляемый «на лету» для каждого частного случая, дублирование повсюду, отсутствие связности — и ИИ будет невероятно сложно вносить какие-либо изменения. Ему понадобятся огромные размеры контекста, чтобы просто понять, что происходит. За это вы заплатите токенами и временем. Архитектура «Большого комка грязи» - такая же проблема для LLM, как и для людей.

Люди, отвергающие принципы качества кода как «для людей» (которые не нужны для агентов), вернутся к ним. Потому что затраты на поддержку станут непомерно высокими.

Несколько примеров:
1. Используйте промежуточное ПО для сквозных задач, вместо того чтобы копировать логирование, аутентификацию, блоки try-catch и т.д. в каждую конечную точку или сервис. Это позволяет сохранить фактическую бизнес-логику в этих конечных точках, обработчиках и сервисах более чистой и понятной для людей. Но это не единственная причина. Каждое дублирование этой логики — это дополнительный контекст, который агент должен прочитать, понять и поддерживать в согласованном состоянии. Вы платите за каждый токен.

2. Организуйте систему в инкапсулированные модули с чёткими границами. Не потому, что людям проще ориентироваться (хотя это так), а потому, что хорошо ограниченный модуль позволяет агенту сосредоточиться на небольшом, согласованном фрагменте кодовой базы. Контекст меньше - стоимость ниже.

3. Принципы SOLID, DRY, разделение ответственности — всё это было сформулировано как способы сделать код более понятным и изменяемым для людей. Эти же свойства делают код дешевле и надёжнее для понимания и изменения ИИ-агентами.

Аргумент о том, что «архитектура предназначена только для людей», предполагает, что ИИ-агенты могут идеально обрабатывать сколь угодно большие контексты и действовать на их основе без затрат или ошибок. Это не верно сегодня, и вряд ли будет верно в будущем.

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

Так что аналогия с ассемблером привлекательна. Но результаты компиляции в ассемблер бесплатны, детерминированы и проверены. Код, написанный агентом, не обладает ни одним из этих качеств. Т.е. хорошо структурированная кодовая база — это способ предотвратить съедание ИИ-агентами всего вашего бюджета.

Источник: https://ardalis.com/why-care-about-agent-authored-code-quality/