День 2789. #Оффтоп #AI
Важно ли По-прежнему Качество Кода?
Автор оригинала: Марк Симан

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

Почему качество кода имеет значение
Выражение «писать код в стиле YOLO (You Only Look Once)» означает создание кода без оглядки на его качество — практика, которая, откровенно говоря, преобладала десятилетиями. И всё же компании-разработчики, позволяющие своим сотрудникам так работать, в итоге сталкиваются с проблемами. Они накапливают столько технического долга, что больше не могут своевременно реагировать на запросы бизнеса.

Важно уточнить: качество кода — это не то же самое, что качество ПО. Качество кода — это внутреннее свойство кодовой базы: то, как код структурирован, насколько он читаем и как легко его изменять.

До сих пор все это сводилось к вопросам человеческого восприятия и мышления. Именно этому посвящена книга «Код, который умещается в голове». Код писали люди. Людям приходилось его редактировать. А что, если ситуация изменится?

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

В реальности я не ожидаю, что LLM будут генерировать машинный код напрямую — хотя бы потому, что машинный код не обладает переносимостью. С другой стороны, нет оснований полагать, что в этом гипотетическом будущем LLM будут придерживаться языков, существующих сегодня. За исключением машинного кода, все языки программирования созданы для того, чтобы облегчить процесс написания кода людьми. Если люди перестанут смотреть на код, вполне вероятно появление новых языков, оптимизированных для того, чтобы LLM могли их воспринимать, генерировать и преобразовывать. Предположим, что появится один такой язык. Назовём его LLaMe.

Техдолг для LLM
Будет ли у LLM возникать техдолг? Непонятно. Возможно, нет. Тогда всё описанное далее теряет смысл: мы просто позволим LLM бесконечно генерировать код на LLaMe, не заботясь о последствиях, и это никогда не станет проблемой.

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

Следовательно, нужно исходить из того, что LLaMe будет допускать различные варианты структурирования кода. Некоторые из этих структур могут сложнее поддаваться изменениям, чем другие. Для «понимания» некоторых структур LLM может потребоваться больше ресурсов (токенов?). Хорошо структурированный код на LLaMe позволит LLM быстро и с минимальными затратами добавлять новые функции и исправлять ошибки. Улучшение же плохо структурированного кода на LLaMe потребует больше времени и ресурсов.

Могут ли LLM предотвратить появление техдолга?
Как выглядит плохой код, написанный LLM (назовем этот стиль LLaMe)? Мы даже не знаем, как выглядит «хороший» код LLaMe; нам неизвестно, какие паттерны и идиомы окажутся полезными, а каких стоит избегать. Мы, люди, накопили опыт за многие поколения. Мы кое-что знаем о том, что работает, а что нет. Однако весь этот опыт неразрывно связан с ограничениями человеческого мышления.

LLM не смогут учиться на нашем опыте. Все наши книги, доклады на конференциях, подкасты и посты в блогах посвящены человеческим проблемам. Вряд ли они помогут избежать техдолга в коде LLaMe. LLM придется учиться на собственном опыте.

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

Так что, возможно, техдолг в LLaMe будет проблемой в течение нескольких лет, но затем и она будет решена. LLM не будут писать код по принципу YOLO (бездумно и наобум), а станут следовать надлежащим практикам программирования LLaMe.

Итого
Качество кода важно для программистов-людей из-за когнитивных ограничений. Вряд ли LLM будут скованы теми же ограничениями, что и мы, но у них могут появиться свои собственные. Такие машинные ограничения могут привести к возникновению техдолга, замедляющего работу LLM при разработке и совершенствовании ПО.

Возможно, эта проблема так и не возникнет. Или же она появится на какое-то время, а затем будет решена. А может быть, и нет. Если это произойдет, мы можем столкнуться с проблемой, которую не в силах решить. Эти ограничения будут настолько выходить за рамки человеческого понимания, что у нас не будет шансов разобраться в неполадках. Как минимум, этот мысленный эксперимент наводит на мысль, что научить LLM создавать ПО совсем без участия человека будет гораздо сложнее, чем утверждают многие оптимисты в сфере ИИ.

Источник: https://blog.ploeh.dk/2026/07/23/does-code-quality-still-matter/