В чём реальная проблема ЛЛМ

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

Т.е., по моему опыту, лажа начинается уже до 5к сток кода.

А ты не сравнивал производительность исполняемого кода, созданного нейронной сетью и написанного грамотным инженером? Избыточность строк исходного кода относительно ручного написания ПО имеется?

А была такая красивая сказка, что всех программистов уволят…

А теперь.. всё равно работать надо…

Я последний раз занимался оптимизацией кода по производительности в универе, т.е. очень давно.

Современные реалии моей работы в том, что самые ресурсоемкие части системы выполняют асики (или плисы - не суть важно, что именно) которые работают в программно-аппаратном комплексе за кучу бабок штука.

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

Т.е. на самом деле, программный код - это дешевое говно по определению. Оно так задумано глобально сапиенсом, концептуально. И, соответственно, у ЛЛМ просто нет экономической целесообразности. Смысл софтовой индустрии - в воспроизводстве говна. А ЛЛМ слишком некреативны для этого.

Интересно, ты лично пробовал в таком режиме работать с LLM?

Проблема в том, что всё равно вся эта системы будет работать как оверпрайснутый Джун, потому что всё равно всё надо будет объяснять на естественном языке.

По моему опыту ЛЛМ лучше всего справляются с утилитами и гуишными тулзами строк на 3тыс кода, но не сильно больше.

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

Буквально из твоих слов следует, что для LLM задачу надо делить на подзадачи до 3 тыс.кода, поручать им эти части, а самому «руководить и направлять».

Буквально из твоих слов следует, что для LLM задачу надо делить на подзадачи до 3 тыс.кода, поручать им эти части, а самому «руководить и направлять».

Проблема в том, что не все задачи можно так поделить. Будет какая-то суперсистема, типа обработчика ошибок, которая должна охватить всё, знать всё о проекте.

Но, когда можно, то, да.

Будет какая-то суперсистема, типа обработчика ошибок, которая должна охватить всё, знать всё о проекте.

Для неё придётся отдельную документацию составить, которая будет подсовываться в LLM. LLM ведь не работает с кодом реализации всех API.

Я последний раз занимался оптимизацией кода по производительности в универе, т.е. очень давно.

Мой бывший работодатель тоже так думал лет 20. А потом упёрлись в производительность топовых десктопов, и пришлось учиться оптимизировать.

Проблема в том, что не все задачи можно так поделить. Будет какая-то суперсистема, типа обработчика ошибок, которая должна охватить всё, знать всё о проекте.

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

потому что тебе очень дорого всё разжёвывать

Очевидно же, что язык программирования гораздо лучше приспособлен для описания проблемы компу, чем язык естественный. Поэтому объём описания на естественном языке всегда будет больше. Это ещё в 60-х годах поняли и перестали делать ЯП устроенные как речь.

тоже так думал лет 20. А потом упёрлись в производительность топовых десктопов

Т.е. целых 20 лет удавалось не тратить время на всякую херню, а решать более общие задачи. Это же замечательно.

Потому что в обработчике-то можно, но если это что-то большее, чем обработчик, то не выйдет. Например, чтобы переконфигурировать систему из самолёта в подводную лодку, надо знать, чем каждая часть в данный момент занимается, все ли модули выполнены по стандарту MIL-STD-810G, допустимо ли потерять модули, которые не выполнены, как организованы взаимодействия между модулями - по воздуху, по проводу, по радиоканалу и т.д. и т.п.

надо запускать их под агентом

Агенты нужны чтобы ИИ решал задачу проактивно. Проблему полноты описания задачи это никак не решает.

Для неё придётся отдельную документацию составить,

Ну, удачи. В производственном аду, когда система постоянно меняется, иметь чёткую документацию.

Вроде бы да. Но проблема в том, что как только будет готов первый вариант системы, и он даже будет работать. Но для второго этапа ты запаришься объяснять ЛЛМ, как его дальше менять осмысленно.

Я согласен, что ЛЛМ - это очень крутая тулза, но в основном для «бутстрапинга» кода и экспериментальной проверки всяких гипотез о реальных технических компонентах ПО. Для устойчивой гарантии качества всё равно нужны все те же дорогущие сапиенсы.

Большой вопрос, подходят ли ЯП для LLM в качестве решения задачи. Возможно, для написания ПО ИИшечкой нужно создать новый язык.

Не думаю, что здесь можно найти золотую середину. ЯП с более простой структурой бесполезны, если нужно писать весь мир с нуля без батареек и чтобы теоретически в будущем это кто-то мог поддерживать без доступа к ЛЛМ. ЯП, на которых дохрена кода в опенсорс (типа JS) плохи, потому что для них куча библиотек, фреймворков, версий, и неизбежно будет больше галлюцинаций.

Ну мы работаем на таких дешманских нодах, что ни в какие пределы мы ещё годами не упремся.

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

Так и тут - с чего вы взяли, будто ЯП будет пользоваться большинство программистов, а не полтора человека на всю планету (как нынче обстоит дело с программированием на ассемблере)? А всё остальное будет писать ИИ-шечка.

Ну покажи мне контору, которая создала бы продукт уровня файрфокса на ЛЛМ с ассемблером в качестве ЯП.

фундаментальная теоретическая проблема

«Преждевременная оптимизация — корень всех зол.» // Дональд-наш-Кнут © (wikiquote.org).

система, которая слишком много галлюцинирует

Это следствие неустойчивости модели к изменчивому контексту. Теоретически лечится избыточностью обучающих данных и строгим отделением их от проверочной выборки.

Да. И это вообще самый сложный аспект биг даты, о котором надо говорить со школьной скамьи.

Проблема в том, что не все задачи можно так поделить. Будет какая-то суперсистема, типа обработчика ошибок, которая должна охватить всё, знать всё о проекте.

Очень абстрактный пример без конкретики, но он уже попахивает говнодизайном. Если напишешь конкретнее, можно попробовать разобрать. Но всяких «суперсистем» в проекте обычно не должно быть.

Кстати, исключения а ля плюсы/Ада были как раз придуманы ради дизайна «я не знаю, каким ошибкам приведет падение меня как отдельного модуля». Но макаки типа тех, кто Ариан в 90х уронил, не поняли, как пользоваться этим механизмом.

Почему сразу с ассемблером в качестве ЯП? Надо произвести исследования, нельзя ли повысить эффективность программировалия ЛЛМ, если не ограничиваться существующими ЯП.

Очень абстрактный пример без конкретики, но он уже попахивает говнодизайном.

Дык, процентов 80 современного ПО - это говнодизайн.

Это не решает основной проблемы: кто-то из сапиенсов должен проверить код. Чем более высокоуровневый ЯП, тем проще это сделать.

Что за ошибки ЛЛМ отвечать будет промпт-инженер, а не разраб ЛЛМ, надеюсь, объяснять не надо.

Но макаки типа тех, кто Ариан в 90х уронил, не поняли, как пользоваться этим механизмом.

Всё они прекрасно понимали, просто обработка исключений занимает дополнительные вычислительные ресурсы, поэтому, они просто не стали нагружать тамошний дохленький компьютер дополнительной обёрткой в try-catch именно того кода, который и сбойнул. А не стали оборачивать, ибо предполагали, что эти переменные никогда не уйдут в минус из-за физических особенностей Ариан-4. Ага, на Ариан-5, который не имел этих физических особенностей.

Это не решает основной проблемы: кто-то из сапиенсов должен проверить код.

Ровно то же самое говорили про Алгол-60, компилятор которого на первых порах генерировал эталонную ахинею, которая работала дай бог через раз.

В производственном аду, когда система постоянно меняется, иметь чёткую документацию.

Документацию тоже LLM-ка может генерить отдельной задачей. Или даже другая LLM. Но я не пробовал так работать.

Это и есть «не уметь в исключения».

Не, я считаю, это неверное «повторное использование кода» прежде всего. Во вторую очередь - излишняя оптимизация по принципу «хотели как лучше, а получилось как всегда»

Есть одна большая проблема в этой аналогии. Компилятор алгола купил один раз, и используешь, он не будет просить денег, чтобы отрефакторить код для следующего коммита. А с ЛЛМ нужно платить фактически за вычислительный ресурс за каждый токен, каждый раз. На любой чих.

А с ЛЛМ нужно платить фактически за вычислительный ресурс за каждый токен, каждый раз. На любой чих.

Используйте локальную ЛЛМ.

Т.е. фактически, мы платим не за какие-то квантово-механические ноухау, а тупо за ресурс барыг-монополистов.

Используйте локальную ЛЛМ.

Это будет говно на палке. Если бы можно было универсальную ЛЛМ сделать на коленке, ОпенАИ с антропиками даже не взлетели бы.

Слушай ну натрави ты соннет на лорчик, раз сам не вдупляешь. Уже сколько раз и я и остальные писали что в 2026 рулят скиллы и зерошотные техники. Галюны после 3-4 промтов это банальное следствие мат модели, пруфов уже хоть жопой ешь.

В целом с рутинными задачами самые последние БЯМы справляются окей. Написать тест, небольшой класс или ф-цию, исправить опечатки, найти что-то по смыслу. С дизайном я бы не стал доверять.

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

Человек всё ещё нужен конечно и вряд ли когда-либо будет не нужен, он должен ревьювить говнокод и останавливать агента когда у него начинает сносить крышу.

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

Так нормально делай - нормально будет

Им всем начинает сносить крышу с ростом контекста, потому что БЯМ не может отличить ошибки, неправильные утверждения и т.п. своём контексте. Даже было исследование недавно.

Поэтому при нормальном workflow задачи атомарны и на каждую берётся чистый контекст.

Это всё круто, типа, тестируй через ИИ’шку. А только не делают коммерцоиды вещи тестируемыми. Например, мне, чтобы ИИ’шка смогла тестировать мой код, надо получить доступ к кишкам ноды, чтобы поставить туда проприетарный бинарь, настроить его запуск в системд, т.е. в итоге мне проще у себя хостить rest api сервис и говорить ИИ’шке, чтобы она его дёргала…

Дальше возникают проблемы. Как дать доступ этой ИИ’шке в корпоративную сетку?

Это будет говно на палке.

Увы, но какую-то работу выполнять она способна.

Это потому, что они бесплатные. Сперва, для завлекалочки, вам подсовывают более мощную модель, а потом, когда вы втягиваетесь, всё более ограниченную. Используй локальные LLM, Люк!