Кодинг не решён: разбор популярного мифа об ИИ

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

Основная часть расходов — это не код

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

Даже функциональные требования (то, что код должен делать) пока не решены. Здесь работает эффект Даннинга — Крюгера: чем меньше человек читает вывод, тем увереннее он в этом выводе.

Где ИИ действительно полезен

Есть четыре типа продуктов, где код не нужно читать:

1. Личное ПО. Разовая задача, автоматизация, самодельные патчи.
2. Прототип. Нужно показать, что технически и коммерчески возможно.
3. Одноразовая автоматизация. Бюджет есть только на проверку результата.
4. «Вооружённый» ИИ. Риск осознанно направили на цель, чтобы навредить.

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

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

Почему код для LLM труднее, чем текст

Код — это логика. Компьютеру всё равно, насколько вы уверены в своей правоте: если логика неверна, код не скомпилируется. Даже если синтаксис в порядке, ошибка всплывёт во время выполнения.

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

С обычным текстом проще: он связан с естественным языком, и там модель более-менее уверенно находит свой путь. С кодом та же машина, которая не может посчитать буквы R в слове «Raspberry» и предлагает дойти до автомойки пешком, выдаёт и логические ошибки.

Модели стохастичны: их ответ каждый раз немного разный, они не обязаны повторять прошлый результат. Чтобы приблизить их к логике, их оборачивают в обычный код — harness, — прогоняют тесты, добавляют приёмы вроде CoT. Но корневая проблема остаётся: модели плохо справляются с логикой и с объёмом. Чем длиннее вход и чем полнее занято контекстное окно, тем ниже точность.

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

ИИ нельзя сделать ответственным

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

Один из самых громких сторонников тезиса «кодинг решён» — Борис Черни из Anthropic, для которого Claude Code стал откровением. Проблемы при этом видно и со стороны:

• Запуск Claude Code возвращает меню помощи Bun
• Установщик CLI молча удаляет сам себя после установки
• Списывают оплату сверх тарифа и показывают ложные ошибки лимита

Напомним: Anthropic контролирует и модель, и harness, и промпт — утёкшие версии промптов лежат на GitHub, — и среду выполнения.

Код — побочный продукт, а ответственность — нет

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

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

Владение кодом держится на трёх опорах:

1. Знание. Вы понимаете, какую проблему решаете, как работает решение и какие у него ограничения.
2. Полномочия. Вам доверяют принимать решения, вы не бегаете за согласованием.
3. Ответственность. Если всё рухнуло, дежурите вы.

Уберите любую из трёх — владение разваливается. И неважно, каким способом код получен: отвечаете вы. Значит, вы должны его понимать.

Распространённые заблуждения

1. «Спецификацию можно написать целиком заранее.» Заранее описать софт осмысленно невозможно, кроме совсем тривиальных случаев.
2. «Я теперь пишу код намного быстрее и не помню, когда делал это руками.» Не путайте движение с прогрессом. Не измеряйте прогресс числом строк кода, PR или фич. Измеряйте уровень сервиса и удовлетворённость клиента.
3. «Я перестал писать код руками, теперь только читаю, а скоро и читать не буду.» Если опытный пользователь сам формулирует запрос и получает результат, какую ценность добавляете вы? Ищите не замену себе, а то, что вы создаёте поверх ИИ.
4. «Рычаг сместился к вкусу.» Вкус есть у всех, и рынок не ценит его так высоко, как хочется. ИИ снизил планку качества внешнего вида, но поднял планку того, за что платят.
5. «ИИ — это уравнитель, он делает творчество доступнее.» ИИ — множитель: он одинаково усиливает и сильных, и слабых. Разница в качестве даёт участие человека, итерации и глубина знаний.

Признаки передозировки ИИ

Автор даёт список, по которому можно себя проверить:

1. Вы совсем не терпите несогласия и нормального спора.
2. Доверяете ИИ-вендорам то, что ещё несколько лет назад показалось бы невозможным.
3. Идёте к ИИ при любой задаче, которая чуть-чуть требует думать.
4. Называете свою неосведомлённость и лень оптимизмом.
5. (этого пункта нет)
6. Вы перестали читать длинные тексты: книги, статьи, даже длинные письма.
7. Вы проводите больше времени с ИИ, чем с другими людьми, и позволяете ИИ прятать вас от живого общения.

И бонусный пункт: вы пролистываете. Заметили, что пункта 5 нет?

ИИ поднимает планку. Если ваш результат равен качеству ИИ или хуже — учитесь.

Экономика: почему SaaS продаёт SLA

Даже если бы код от LLM имел хорошие NFR и вы его понимали, остаётся экономика задачи.

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

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

Если вам нужно что-то уникальное, чего SaaS не даёт за разумные деньги, — собирайте сами, но считайте суммарную стоимость владения (TCO) и помните, что гарантий не будет. А если это ПО не ваш бизнес — купить SLA выгоднее.

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

Северное золото и настоящее золото

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

Инженеры отличаются от ИИ четырьмя вещами:

1. Ответственность. Поэтому они реже делают опасные ошибки. ИИ может незаметно переключиться на более слабую модель, не сказав об этом.
2. Разумность. ИИ прячет почти всю внутреннюю кухню: поработал несколько часов и вернулся со счётом. Та же модель, которая не может решить, идти пешком или ехать на автомойку, делает ошибки, которые трудно заметить и исправить.
3. Последовательность. Люди тоже ошибаются, но предсказуемо: научился — значит, знает. Нынешний ИИ заперт в своей контрольной точке обучения. Он может «учиться» через SKILL, AGENT и память, но пока это ненадёжно.
4. Дешевле. Стоимость генерации растёт, но всё равно заметно ниже инженера. Настоящая ценность инженера — решить правильную задачу так, чтобы решение можно было развивать, и взять ответственность, когда оно сломается. Общая стоимость владения ПО от ИИ не снизилась — слоп и страх остаться позади её только увеличили.

Что делать сейчас

• Руководителям. Слушайте своих инженеров. Если для них важно качество, это ваш пропуск через «SaaS-эпоху». Не требуйте впихивать ИИ во все возможные процессы.
• Разработчикам. Не жертвуйте своей долгосрочной ценностью ради краткосрочной скорости. Держите небольшой проект без ИИ, чтобы руки помнили ремесло, и не отдавайте облачным вендорам то, что не хотите потерять.
• Всем. Пользовательское приёмочное тестирование (UAT) прошло — это не значит «код достаточно хорош». Отправлять такое пользователям и перекладывать на них остальную проверку — значит сделать их подопытными крысами.

Автор не призывает менять чей-то инструментарий. Он просит одного: не ставить скорость выше качества в сервисах, за которые вы платите. Иначе эксперименты ставите не вы, а ваши пользователи.