Coding не решён: почему LLM не заменят программистов
Coding Is Not Solved – Alex Ewerlöf Notes
Alex Ewerlöf утверждает, что LLM не способны заменить программистов в ответственных проектах, так как не несут ответственности за ошибки. Он выделяет три области, где можно не читать код: личные проекты, прототипы и кибератаки. В остальных сферах — медицине, финансах, авиации — необходима подотчётность, недоступная ИИ. Автор предупреждает об «AI-передозировке» и призывает не жертвовать качеством ради скорости.
AI не может нести ответственность. Он не может понести никаких последствий. Худшее, что вы можете сделать с AI, — это отключить его от питания.
- efficax
Чтение кода не означает, что ты понимаешь код. Один урок, который мне дал опыт в разработке ПО: я никогда не понимал код. Ты думаешь, что он работает определённым образом, пока не выяснишь, что это не так.
Что LLM делают возможным — это чтобы я сказал: выясни все способы, которыми эта штука работает. Проанализируй разные способы, которыми мы можем запускать это ПО, собери фаззер, собери property-тесты и запусти это ПО во всех возможных сценариях. Логируй полные трейсы. Логируй все выходные данные. А теперь проанализируй каждый сценарий на баги. Вручную ты этого не сделаешь.
Если мы настроены серьёзно, если мы направим на это ресурсы и выделим время (а мы могли бы сделать это, просто сказав: это займёт вдвое меньше времени, чем раньше!), ПО, созданное LLM в здравоохранении, финансах, автомобилестроении, оборонке, энергетике, авиации, производстве, можно сделать БОЛЕЕ надёжным и лучшим с помощью LLM... ни разу не прочитав ни единой строки кода. LLM, кстати, очень хороши в логике.
В общем, всё это читается как написанное тем, кто на самом деле не использует LLM для создания ПО или не пробовал их уже давно. Я чувствовал то же самое в 2025 году. Я написал сотни тысяч строк сложного кода. Вы, человек, читающий это, вероятно, взаимодействовали с ПО, которое я написал. Какое-то время вы бы взаимодействовали с ним каждый раз, когда совершали транзакцию по дебетовой карте в США, например. Я понимаю код и забочусь о качестве, и именно поэтому я полностью за LLM в коде.
- askonomm
Я обнаружил, что ИИ позволяет ленивым и некомпетентным разработчикам быть ещё ленивее и ещё некомпетентнее. Это, в свою очередь, приводит к тому, что качество продукта страдает сильнее и быстрее. Из-за sheer объёма кода, который сейчас выкатывается, код-ревью — вещь, которая раньше хоть как-то мешала ленивым и некомпетентным разработчикам выкатывать ужасный код, — фактически мертва, поскольку ни один человек уже реально не может просматривать такие объёмы кода. Некоторые компании внедрили ИИ для ревью кода, что, ну... у вас ИИ пишет код, ИИ ревьюит код... надеюсь, вы видите всю глупость этого, если ожидаете хоть каких-то детерминированных результатов.
Время покажет, адаптируется ли потребитель к более низкому качеству продуктов, позволяя компаниям оправдывать существование ленивых и некомпетентных разработчиков, или потребитель даст отпор, вынуждая компании повышать качество своих разработчиков.
Примечание: я использую ИИ каждый день, и с ним вполне возможно создавать высококачественное ПО, если только ты не ленив и не некомпетентен.
- temp00345
Я читаю такие статьи более-менее каждый день.
Эта статья была бы на 100% верной, если бы вышла год назад, на 75% верной 9 месяцев назад, на 50% верной 3 месяца назад, а сейчас она, вероятно, верна на 25%, если не меньше.
Я прекрасно понимаю, откуда это идёт. Я тоже с трудом принимаю, что мой 30+ летний опыт программирования быстро становится устаревшим. Я теряю из-за этого сон, это тяжело.
Но просто возьмите и дайте последним моделям (Opus 5.5 / Astra 6 на сегодня) ещё один шанс.
Посмотрите, на что они способны, и прочитайте код, который они выдают.
Любая проблемная область, низкоуровневый C++ или высокоуровневый Typescript, или Clojure, или странная комбинация всего этого...
Не стесняйтесь, дайте им большую задачу, пусть построят целое приложение, UI и всё остальное...
А теперь сравните результат с Opus 4 или gpt-5 годичной давности — когда они не могли собрать даже одну функцию без того, чтобы она не была странной и багованной.
Вот именно в этом моя проблема: не в том, что модели уже очень хороши, а в том, как быстро они стали такими хорошими.
Так что если программирование ещё не решено, это случится очень скоро.
- thesumofall
Я думаю, автор недооценивает, насколько скучным и простым являются 90% корпоративного ПО. Та часть, которая не управляет самолётами и электростанциями. Очень многое из него происходит из ночных поделок, плохо управляемых субподрядчиков и требований, которые изначально низкого качества (потому что написаны людьми с совсем другой основной работой). И знаете что? Большая часть этого работает 24/7 без сбоев. LLM просто дают нам больше такого. И, может быть, это даже лучше.
- brainless
Я программирую около 30 лет (включая школьные годы). Профессионально — 18 лет.
Может кто-нибудь сказать мне, почему у нас 40 или более языков программирования, из которых около 10 популярных? Плюс примерно 20 фреймворков в каждом из них. И добавьте ещё 200 популярных библиотек для каждого языка? Эта матрица не имеет смысла, пока не осознаешь — это предпочтения до самого низа.
Большинство из нас, инженеров, построили собственную ментальную модель программирования. Мы все правы. Но пользователям плевать. LLM здесь, чтобы производить код всё ближе и ближе к железу, по мере необходимости. Они могут сидеть и строить граф из каждой спецификации, использовать AST, который они разработают, и запускать его на CPU, если придётся. Они это сделают. Никакие наши обсуждения это не остановят.
Программирование будет переизобретено. Я не думаю, что текущие способы написания ПО вообще будут иметь значение.
- hibikir
> Ты также не можешь нести ответственность за то, что не контролируешь. Это понимание — ключ к рассуждению о поведении системы и её исправлению, когда ИИ неизбежно даёт сбой.
Это не очень хорошая посылка. По всему праву вы найдёте людей, которых сделали ответственными за то, что они не контролируют и чем они вроде бы владеют. Спустите собаку, которая навредит ребёнку, или просто держите её в среде, откуда она может сбежать, и посмотрите, что произойдёт.
Существуют непредсказуемые ситуации, в которых человека могут не привлечь к ответственности, поскольку проблема может возникнуть далеко за пределами разумных указаний.
Так что, конечно, вас могут привлечь к ответственности за то, что делает ИИ, который вы якобы не совсем контролируете, или за написанный ИИ код, который вы поставляете. Относитесь к этому как к выпуску стаи волков или продаже небезопасной игрушки, которая может покалечить детей. Прецедентов повсюду полно.
- thefilmore
От авторов «программирование решено»: сегодня коллега, пытавшийся запустить Claude Code, столкнулся с проблемой, когда вместо этого показывается меню помощи Bun [1]. Ранее Claude Code несколько раз удалял сам себя, когда я его использовал. [2]
- hakunin
Те, кто утверждает, что ПО, сгенерированное LLM, достаточно хорошее:
Не писали код целую вечность
Не могут заметить, если их код, образно говоря, имеет 6 пальцев!
Имеют низкую планку того, что выглядит хорошо
Не заботятся о качестве или NFR
С трудом понимают S-кривую
Есть исключения вроде antirez, но я думаю, это справедливо для многих громких оптимистов.
- lordnacho
Мои мысли по этому поводу:
- Программирование в малом решено. У меня есть текущее состояние, я хочу его изменить, и я знаю, как хочу его изменить. Например, у меня по какой-то причине есть блокирующий TCP-обработчик, и я хочу сделать его асинхронным. Я могу либо возиться с ним, либо просто позволить LLM внести изменения за меня.
- Программирование в широком смысле никогда не решено. Нужно суждение, чтобы решить, что ты хочешь сделать. Что бы ты ни строил, придётся принимать решения (Для кого/чего это?) и эти решения меняются со временем. LLM могут принять некоторые решения по умолчанию за тебя, и если тебя они устраивают, ты получаешь дефолт (отлично для POC). Однако ты можешь даже не осознавать, что именно оно решило сделать за тебя. На каком-то масштабе ты будешь тратить много времени на пересмотр этих решений. Но что у нас есть сейчас — так это то, что трение при изменении решений стало намного ниже. Теперь можно тестировать много вещей, которые раньше отнимали очень много времени.
- Тезис о том, что LLM вероятностны, не так важен, как его раздувают. Если я прошу джуна написать что-то, я тоже не знаю, что он сделает. Чёрт, ты можешь быть уверен, что способен решить задачу, но сам не знаешь, как будет выглядеть решение. Может оказаться, что библиотека, которую ты собирался использовать, в итоге не подходит. Ты не знаешь, что используешь в конечном счёте, но знаешь, что что-то решит проблему. У задачи может быть больше одного решения, и не всегда важно, какое именно ты найдёшь.
- Я ВСЁ ЕЩЁ т […]
- josephmtummon
Читая статью, я определённо соглашался с автором, но также ловил себя на согласии с контраргументами в комментариях.
Что лично мне кажется противоречивым в практике ИИ-программирования, так это то, что я полностью согласен: ИИ невероятно впечатляет в выполнении даже сложных задач, и я как минимум могу сказать, что он намного-намного лучше меня пишет код.
Моя проблема с ним в том, что он каждый раз даёт «ленивый» вариант, не требующий такого же уровня мышления. Я понимаю, что это полностью на мне как на разработчике, и простое решение — убедиться, что я не торопясь учусь и понимаю, что именно производит LLM. Я пытаюсь так делать и настроил отдельные навыки, чтобы убедиться, что я строю своё понимание по ходу дела.
Тем не менее, если я сегодня сяду и реализую что-то без использования LLM, это займёт у меня намного больше времени, но как только я втягиваюсь, я нахожу состояние потока, которого никогда не получу от чтения вывода LLM туда-сюда. А когда я заканчиваю, даже если моё решение не идеально, я узнал гораздо больше, и мой собственный контекст проблемы гораздо лучше, и обычно после этого я могу сделать ревью с LLM. Обычно это оставляет меня с лучшей реализацией и, что важнее, с той, за которую я могу стоять.
Я думаю, что для нового разработчика вроде меня (~2 года опыта), поскольку я не накопил годы и годы опыта решения задач, если я не выделю время в своём дне, чтобы отложить ИИ-инструменты и улучшить свои навыки решения задач, я […]