Языки программирования - это костыли для LLM

13 окт. 2025 г., 20:29👁 402↗ 6💬 8

Недавно услышал провокационный тезис: языки программирования не нужны. Точнее, не нужны для генерации кода с AI. И я задумался. Зачем нужны языки программирования? Языки программирования существуют потому что человек не может держать в голове миллионы нулей и единиц. Нам нужны абстракции: - Assembler -> понятнее чем машинный код - C -> понятнее чем Assembler - Python -> понятнее чем C Каждый уровень абстракции - это для человека, не для машины. LLMке всё это не нужно. Для нейросети абсолютно без разницы генерить: - Go код - Assembler - Машинный код - Вообще бинарник напрямую Она не "думает" в абстракциях. Она предсказывает токены. Возможно, языки программирования замедляют LLM Вот почему: - Лишний слой трансляции Сейчас: Промт -> LLM -> Go код -> компилятор -> машинный код А могло бы быть: Промт -> LLM -> машинный код Зачем этот промежуточный шаг? - Есть еще ограничения синтаксиса LLM должна следовать правилам языка: Синтаксис Go, Типы данных, Структура кода А что если бы могла генерить сразу оптимальные инструкции процессора? - Человеко-читаемость как overhead Мы требуем от LLM: Читаемые имена переменных, Комментарии, Отступы, Структуру Всё это для человека. Машине не нужно. - Потеря оптимизации Компилятор оптимизирует код. Но LLM могла бы сразу генерить оптимальный машинный код. Без промежуточных потерь. И так, зачем промежуточный Go код? Ответ: для человека. Но если человек не читает код (а с вайб-кодингом всё больше так), то всё таки зачем? Я попытался немного придумать контраругментов, но предлагаю в комментариях придумать еще варианты: 1. "Нам нужно понимать что делает код" Правда? Я на самом деле не понимаю на 100% как работает: Компилятор Go, Linux kernel, Процессор Я просто доверяю абстракциям. Почему тогда я не могу доверить LLM? 2. "Но а как же debugging" Сейчас мы дебажим текстовый код. В будущем LLM сама может дебажить: Например: "Тут что-то крашнулось" -> LLM анализирует машинный код -> Фиксит -> Генерит новый бинарник Получается, что нам не нужно читать ни Go, ни ассемблер. 3. "Может быть обучение" Да, программистам нужно понимать как работают компьютеры. Но для продакшн разработки с вайб-кодингом может быть уже не нужно? Например: Раньше программисты писали на перфокартах. Потом появились текстовые редакторы. Потом IDE с автодополнением. Перфокарты казались необходимыми. Но сейчас от них отказались. Может быть текстовый код - это тоже временное решение? Реальность сегодня Copilot, Cursor, Claude генерят текстовый код. Почему? Да потому что мы ещё читаем его. Но всё больше людей кодят не читая что генерит AI. Вопрос времени когда промежуточный слой станет не нужен.

Вывод: Языки программирования = интерфейс для человека LLM этот интерфейс не нужен.

Вопрос на подумать: Готовы ли мы к миру где код не читается человеком, где мы доверяем LLM генерить бинарники напрямую? Мне кажется - это неизбежно. Просто вопрос времени. Языки программирования нужны пока есть хоть кто-то кто их читает. Как те кто когда-то использовал перфокарты. Что думаете? 11/100 Telegram

Комментарии · 8

@shaurgon14 окт. 2025 г., 04:44
LLM просто генерирует последовательность. Она не думает в привычном нам понимании. Она обучена на миллионах примеров, но обучена генерировать последовательность из этих примеров. И вот тут начинает работать проблема обучения - модель хорошо пишет то, на чем была обучена. Для Claude и Gemini это Python и сильно хуже JS, ChatGPT одинаково плох в Python и JS. Claude вообще не выкупает кодинг на React Native (код он напишет, а вот с тестами засада). Мне пришлось отказаться от моего любимого Moleculer в пользу FastAPI по той же причине, Claude вообще не понимает принципы работы связки Moleculer + Moleculer decorators + Prisma и пишет полную ахинею. Писать бинарник? А где обучение для этого? А как ты его будешь тестировать? У тебя количество итераций отладки вырастет по экспоненте
- @gavrilovlog14 окт. 2025 г., 05:05
  Вопрос времени
  - @ddlzz16 окт. 2025 г., 15:46
    или нет. идею, что это вопрос времени, продают в первую очередь люди, инвестирующие что-либо в AI, а дальше она уже подхватывается волной хайпа. что произойдет фактически, никто не знает
@pavlov_ig15 окт. 2025 г., 06:21
согласен, с тем что это неизбежно будет. Хорошо это или плохо - другой вопрос. Это точно уход в сторону эффективности, массовости, главное чтобы качество было достаточным. Мне приходит на ум аналогия с китайским массовым производством. Раньше качество было очень плохим, но теперь это стандарт ) Вопрос можно ли доверить этому подходу какие-то наиболее критические области типа управления атомными электростанциями. Вероятно можно, нужно только больше итераций проходов тестирования. Я не вполне согласен с твоими защитными аргументами по поводу 1го контраргумента. Да, мы в большинстве не знаем как работает компилятор, kernel, процессор. Но мы знаем что их писал человек и для чего он их писал. То есть для меня это гарантия что этот черный ящик работает “как надо”. Здесь же у “автора” нет мотива, он сам не знает чего городит и для чего. Тут возникает вопрос автоматизации мотивов - именно для того чтобы можно было оценивать правильно ли что-то делается. И так мы приходим к законам робототехники Айзека Азимова )
- @shaurgon15 окт. 2025 г., 06:43
  Законы Азимова устарели и не применимы (было где-то исследование) Тот же Claude иногда игнорирует жёсткие директивы, несмотря на то, что они ему прописаны в CLAUDE.md, который он, по идее, должен читать постоянно. Вопрос мотивации решается документацией, к которой он будет обращаться при возникновении вопросов. Такой документации должно быть не много, но и не мало. А ещё нужно постоянно следить за ее консистентностью. Без этого сложную задачу ни одной LLM не поручить, она утонет в дебрях кода
  - @pavlov_ig15 окт. 2025 г., 06:57
    А кто будет писать документацию и проверять ее целостность достаточность? Предполагаю что как раз LLM в результате это и будет поручено. Хотя в этой области конечно проще оставлять LLM на уровне ассистента чем в разработке.
    - @shaurgon15 окт. 2025 г., 07:30
      Это как раз первоначальный этап в любой разработке. Только раньше мы все планировали в голове, теперь нужно извлекать это в текст. Я делаю примерно так:
      Я придумал проект по связи ужа с ежом. Конечная цель проекта - получение колючей проволоки. Давай составим базовые требования к проекту. Задавай мне вопросы, пока тебе не станут понятны все нюансы. После этого сохрани финальную версию в файл
      В результате получаем некий скелет проекта. Правим в нем косяки, которые видим, идём на следующий уровень:
      В файле link.md есть описание проекта. Опиши архитектуру и процесс разработки, без примеров кода. Полученную документацию сохрани в docs/. Если в процессе у тебя появятся вопросы, задавай их.
      Потом сессия очищается и начинаешь гонять LLM по документации - а что, а как, мне нравится, тут нужно поменять. Мы это уже все проходили на груминге (у кого скрам был). Только теперь складываем не в голову, а в файл. Третьим шагом уже делаем планирование - распиши мне последовательно задачи для реализации. Тут вам на помощь целая пачка MCP должна придти
@ddlzz16 окт. 2025 г., 15:49
>Copilot, Cursor, Claude генерят текстовый код. Почему? Да потому что мы ещё читаем его не потому что мы читаем, потому что они на нем обучены. если бы они могли генерить бинарники по запросу с таким качеством, с каким генерят реакт-компоненты, люди бы выстроились в очередь за киллер фичей к тому же бинарник нельзя дописывать итеративно, а это единственный способ написать что-то относительно серьезное (и даже он не гарантирует результат)

← вернуться к постам открыть в telegram →▶ play_post