software on demand
Apr. 19th, 2026 10:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoЯ тут заставил LLM написать мне кусок кода, который, с большой вероятностью, был написан много раз до этого. Я догадывался, что могу пойти и найти, но это ж целое дело - лицензия, интерфейсы, документация.
Так что написать ещё раз было проще. Реально проще. NIH (not invented here) синдром, традиционно считается плохим; в большинстве случаев, "написать своё" - плохая идея, особенно, если это не новая уникальная задача или не странная комбинация требований.
Но всё меняется... Код становится дешёвым, и думать о том, "писать или нет" нужно не с точки зрения "сколько нужно потратить на написание", а с точки зрения, что лучше, ещё одна зависимость, или локальное сопровождение.
По мере того, как написание кода будет становиться всё лучше и дешевле (а оно будет, open-модели уже пишут терпимо, и будет ещё лучше, поскольку SOTA показывают куда идти), очевидно, что баланс между NIH и "ещё одной зависимостью" будет становиться всё более с перекосом в сторону NIH. Причин, помимо "дешёво и просто" много. Во-первых любая фича за ваш каприз. Во-вторых, минус огромная головная боль с сопровождением зависимостей. Security становится лучше (аргумент: сейчас модно искать 0-day с помощью LLM'ок, когда это станет не только модно, но и полезно, аудит локального кода будет рутинной процедурой, и локальность кода упрощает проблему), меньше возни с трекингом изменений.
Возможно, мы дойдём до этапа, когда наличие зависимостей в проекте будет восприниматься как "сложно" и "есть глубокие причины". Концепция библиотек станет возвращаться в (условные) 90ые, когда библиотек было мало и были глубокие причины иметь каждю эту so'шку на своей машине, а не в сырцах в коде.
А следующий этап - software on demand, то есть "под задачу". Сейчас оно звучит ещё странно и vibe'ово, но если посмотреть, что делают LLM при исследовании проблемы - они же пишут сниппеты на питоне для анализа. То же самое можно и с более крупным софтом. В ответ на запрос пользователя (допустим, в рамках фантастики ближнего полёта) "хочу синкать батареи у панелей синкать с батарей у машины, так, чтобы панельки побольше работали" будет написан софт, который именно это и делает. С конкретными моделями машины и панели (будет новая машина - "поправь, чтобы и с Jomdong работало"), без какой-либо далёкой перспективы, но будет.
И вот очень интересный момент будет, когда количество начнёт переходить в качество (или его отсутствие). Одна софтинка да, две да, но если у нас взаимодействие software on demand, которое общается с software on demand, которое что-то делает с данными из другого software on demand, вот тут вот что-то интересное уже начинает проклёвываться.
Точно ли `import json`, или можно просто дописать парсинг json'а на месте? А runtime нам нужен? А операционная система?
А что, если железо будет таким простым и таким специфичным (больше не надо legacy и совместимость), что софт под него проще писать с нуля каждый раз?
... А что, если и железо?
Так что написать ещё раз было проще. Реально проще. NIH (not invented here) синдром, традиционно считается плохим; в большинстве случаев, "написать своё" - плохая идея, особенно, если это не новая уникальная задача или не странная комбинация требований.
Но всё меняется... Код становится дешёвым, и думать о том, "писать или нет" нужно не с точки зрения "сколько нужно потратить на написание", а с точки зрения, что лучше, ещё одна зависимость, или локальное сопровождение.
По мере того, как написание кода будет становиться всё лучше и дешевле (а оно будет, open-модели уже пишут терпимо, и будет ещё лучше, поскольку SOTA показывают куда идти), очевидно, что баланс между NIH и "ещё одной зависимостью" будет становиться всё более с перекосом в сторону NIH. Причин, помимо "дешёво и просто" много. Во-первых любая фича за ваш каприз. Во-вторых, минус огромная головная боль с сопровождением зависимостей. Security становится лучше (аргумент: сейчас модно искать 0-day с помощью LLM'ок, когда это станет не только модно, но и полезно, аудит локального кода будет рутинной процедурой, и локальность кода упрощает проблему), меньше возни с трекингом изменений.
Возможно, мы дойдём до этапа, когда наличие зависимостей в проекте будет восприниматься как "сложно" и "есть глубокие причины". Концепция библиотек станет возвращаться в (условные) 90ые, когда библиотек было мало и были глубокие причины иметь каждю эту so'шку на своей машине, а не в сырцах в коде.
А следующий этап - software on demand, то есть "под задачу". Сейчас оно звучит ещё странно и vibe'ово, но если посмотреть, что делают LLM при исследовании проблемы - они же пишут сниппеты на питоне для анализа. То же самое можно и с более крупным софтом. В ответ на запрос пользователя (допустим, в рамках фантастики ближнего полёта) "хочу синкать батареи у панелей синкать с батарей у машины, так, чтобы панельки побольше работали" будет написан софт, который именно это и делает. С конкретными моделями машины и панели (будет новая машина - "поправь, чтобы и с Jomdong работало"), без какой-либо далёкой перспективы, но будет.
И вот очень интересный момент будет, когда количество начнёт переходить в качество (или его отсутствие). Одна софтинка да, две да, но если у нас взаимодействие software on demand, которое общается с software on demand, которое что-то делает с данными из другого software on demand, вот тут вот что-то интересное уже начинает проклёвываться.
Точно ли `import json`, или можно просто дописать парсинг json'а на месте? А runtime нам нужен? А операционная система?
А что, если железо будет таким простым и таким специфичным (больше не надо legacy и совместимость), что софт под него проще писать с нуля каждый раз?
... А что, если и железо?
no subject
Date: 2026-04-19 09:01 pm (UTC)no subject
Date: 2026-04-20 01:10 pm (UTC)no subject
Date: 2026-04-20 07:35 am (UTC)Да, с одной стороны, у нас ещё нет достаточно опыта; но похоже, что абстракция сегодня что-то не особо нужна кому-то. С другой стороны, это ж, может быть, движение в сторону биологизации софтвера и хардвера? Хз. Но в биологии есть гены.
no subject
Date: 2026-04-20 01:17 pm (UTC)Потом пошли компиляторы. Сначала компиляторы использовали инструкции (какие есть), пошли нарекания, споры про неточную семантику, и т.д. и т.п.. Всей истории я не знаю, но точно знаю, чем всё закончилось. Инструкции процессора интересны только системным программистам (раннего этапа загрузки и в маленьких сниппетах ассемблерного кода в ядре), и создателям компиляторов. И "интринзики" для особых ценителей производительности.
Все остальные полностью всё отдали на откуп компиляторам, которые и есть основной потребитель инструкций.
Может быть, через какое-то время, у этих инструкций появится ещё один потребитель (LLM, которой надо просто, однозначно и с хорошей документацией), и код действительно будет писаться LLM. Prompt to binary, или, может быть, какую-то llm-friendly VM (что более вероятно, потому что под неё легче тренировать LLM'ки).
А вот "железо под LLM" - это уже фантастика среднего полёта. Я даже не могу уверенно предсказывать, каким оно будет. FFPGA всюду? LLM2Chip и микро-партии? Прямая печать на вафлях? Но там же едкая химия...
no subject
Date: 2026-04-20 12:59 pm (UTC)no subject
Date: 2026-04-20 01:22 pm (UTC)Допустим, всё печатается как попало, но всё печатается LLM'ками, так что паттерны одинаковые и легко обнаружимые (как в коде). LLM подхватывает стиль и доделывает/переделывает под конкретное изделие.
Доводя до абсурда: у нас в углу комнаты кондиционер, который сделан по форме стен, с учётом колонны и балки, и когда мне потребовалось добавить туда фильтр против нового класса (чего-то чего мы пока не знаем но что уже есть в воздухе в изобилии), робот открыл крышку, 3D сканировал внутренности, пошёл по ссылкам на QR-кодах почитать specs и предыдущие requirements, уточнил как этот фильтр должен применяться (по существующей мед литературе), задал несколько странных вопросов пользователю (можно ли подключить проточную воду?), допечатал, вставил, запустил, посмотрел, что не работает, поправил, допечатал, обновил документацию (qr-коды), всё, фильтр готов.
Я не знаю как он работает, подозреваю, что не совсем хорошо, я могу попросить второй робот проверить. Он почитает доки, возьмёт образцы воздуха, подтвердит, что работает. На том и успокоимся.
А есть там стандартные детали, или все лопасти по форме стенки сделаны, чтобы облетать вокруг колонны по гиперболической кривой, это и не важно.
no subject
Date: 2026-04-20 06:10 pm (UTC)