У AI нет мудрости — и у вас её не будет

Показательные цитаты, которые Alexandru Nedelcu слышал от коллег и из индустриальных дискуссий в последний месяц: «Я не писал код с 2025 года», «Код-ревью мертвы», «Люди больше не читают код». Индустрия действительно меняется, однако люди и организации, попавшие в ловушку и переставшие читать и писать код, делают это на свой страх и риск — таков центральный тезис его новой колонки.

Поддерживаемость невозможно измерить

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

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

И при этом мы знаем как факт: чтобы заметить плохой код, нужно время. Месяцы, годы. Опытные инженеры благодаря натренированному чутью распознают code smells и принимают меры задолго до того, как плохие эффекты станут наблюдаемыми.

Эксперты не следуют правилам — они их создают

Чутьё профессионалов построено на поту и слезах: многочасовой дебаг и починка продакшен-инцидентов, клятвы себе больше никогда не повторять прошлых ошибок. Такую интуицию нельзя упаковать в список жёстких правил — потому что всё зависит от контекста. Эксперты несовместимы с теми же правилами и рецептами, которые делают новичков продуктивнее. Эксперты не следуют правилам — они создают правила.

И вот здесь начинается проблема.

Почему AI не обучается поддерживаемости

• AI не обучают тому, что означает «поддерживаемый код». Любое reinforcement learning требует reward-сигнала, который можно измерить немедленно, — а не через месяцы или годы.
• AI учится правилам из правил, написанных для новичков.
• AI выхватывает паттерны из кода, встречающегося «в дикой природе», — и будем честны: большинство такого кода довольно плох.
• Fitness-функцию для поддерживаемого кода определить нельзя — по крайней мере, мы не знаем как. Иначе она давно была бы встроена в линтеры.

Провал на «упрощении» кода

Замечали, насколько ужасно AI «упрощает» код? Даже SOTA-модели. Он не умеет нормально определять функции: вместо прояснения он дробит большие функции на более мелкие, которые на деле нигде не переиспользуются. Извлекать меньшую функцию из большей — плохой выбор, если для понимания большей теперь нужно читать ещё и реализацию извлечённой. Определять переиспользуемые и проясняющие функции — искусство, требующее мастерства. Большинство разработчиков, всё ещё оставаясь «продвинутыми новичками» (advanced beginners) в терминах модели Дрейфуса, не умеют определять хорошие, проясняющие, переиспользуемые функции. AI сейчас — тоже.

Путь к мастерству перекрыт

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

Такие люди никогда не достигнут мастерства. Они больше не принимают решений, больше не несут ответственность за ошибки в коде — и, значит, не учатся на них. Теперь ошибки делает AI. AI не учится на этих ошибках, и люди, доверившие ему кодирование, тоже.

Брр.

Инструмент, а не революция

Без недопониманий: LLM — отличный инструмент. Автор — никакой не луддит: он встроил AI в собственную ежедневную работу и учит коллег тому, чему научился сам. С удовольствием поручает моделям всю скучную, высасывающую душу работу и радуется выигрышу в эффективности. Но в конце дня это просто инструмент, и, как у всякой революции, его свет тоже померкнет. По мнению автора, уже меркнет: в tech-новостах сейчас, честно говоря, довольно скучно.

Люди в целом ужасно умеют делать прогнозы, и будущее удивит нас всех. Но один прогноз автор всё же берётся сделать:

В будущем мы увидим всё больше компаний, гордо рекламирующих политику «NO-AI» как конкурентное преимущество. И они будут правы.

«Кодинг не решён»

Возражение «автоматизированные конвейеры всегда эффективнее» не учитывает специфику софтверной индустрии: мы всегда занимались автоматизацией в масштабе, всё, чем мы занимаемся, — это автоматизация, и LLM — далеко не единственное её средство. В зависимости от контекста это может оказаться даже отвлечением от главного.

«Кодинг не решён» — ни в каком осмысленном смысле. Да, можно поручить LLM построить компилятор C/C++. А можно просто склонировать GCC или LLVM — и получить компилятор лучше, к тому же бесплатно. И, возможно, есть куда более полезные способы потратить время и ресурсы, чем заново изобретать одни и те же CRUD-приложения: человеческие потребности и желания бесконечны, новых целей хватает.

Суть

• Поддерживаемость и хорошая архитектура не измеряются, поэтому не могут стать reward-сигналом для обучения моделей.
• Интуиция эксперта — контекстна, её нельзя свести к правилам, по которым учатся модели.
• Делегировав AI не только письмо, но и чтение кода, разработчик лишает себя пути к мастерству.
• Софтверная индустрия и так вся состоит из автоматизации — LLM не отменяет ответственности за результат.

Если люди и компании не начнут относиться к использованию AI ответственно, последствия не заставят себя ждать.