13 октября 2026 года Линус Торвальдс ответил в рабочей переписке разработчику, который хотел ограничить ИИ в работе над ядром Linux. Ответ был довольно резким и саркастическим: Торвальдс предложил оппоненту отказаться не только от ИИ, но и от компиляторов.
Свою позицию по ИИ Торвальдс подробно объяснил ещё в мае на конференции Open Source Summit North America.
«Вот новое правило лично для вас»
Спор начался в обсуждении патча: один из разработчиков предложил, чтобы описания коммитов люди писали сами, без ИИ. Довод такой: ИИ сильно ускоряет работу, и сам Торвальдс рассказывал, что с ИИ сделал за пару месяцев то, на что ушли бы годы. И если автор коммита понимает код, написанный ИИ — то описание коммита отнимет у него совсем немного времени. В этом случае будет проще отсеивать патчи от тех, кто бездумно пересылает ответы модели.
«Всё дело в ваших заморочках», — ответил Торвальдс и ехидно предложил собственное правило:
Вот новое правило лично для вас: не используйте компиляторы ни в одном своём патче для ядра.
И продолжил: пусть автор пишет код на ассемблере и этим докажет своё понимание того, что делает машина. А сообщение к коммиту пусть набирает без текстового редактора.
Мы не будем вводить дурацкие правила вроде «нельзя использовать инструменты для X».
Есть вещи важнее инструментов:
Я ожидаю, что люди стараются изо всех сил и понимают, что делают. Но это понимание очень мало зависит от того, какими инструментами они пользуются.
О тех, кто сторонится ИИ, Торвальдс высказался отдельно:
Люди, которых я уважаю и считаю умными, — не те, кто шарахается от новых и интересных инструментов.
«ИИ не изменяет программирование»
По мнению Торвальдса, ИИ — следующий шаг в цепочке инструментов, которая началась с машинного кода и продолжилась ассемблером и компиляторами. Торвальдса явно раздражает подсчёт строк, написанных ИИ:
ИИ — отличный новый инструмент, но это всего лишь инструмент. И когда я вижу, как люди говорят: «Эй, 99% нашего кода написано ИИ» — я злюсь. Потому что я могу почти гарантированно утверждать: 100% их кода написано компиляторами. Но они почему‑то никогда об этом не говорят.
На Open Source Summit Торвальдс сравнил продуктивность ИИ и компиляторов:
ИИ повысит вашу продуктивность в 10 раз. А я утверждаю, что компиляторы повысили продуктивность в тысячу раз. Так что ИИ — это здорово, но ИИ не изменяет собственно программирование. Возможно, он изменяет другие области, не поймите меня неправильно. Но я программист, и меня это не волнует.
Разработчик должен знать свой проект, и никуда ему от этого не деться:
Люди, которые понимают, что делают и которые разбираются в системах, смогут правильно формулировать запросы для инструментов и получать хороший код. А тот, кто не понимает сложности систем, тоже будет писать промпты и создавать процессы — но эти процессы будут давать сбои. Поэтому, я думаю, вам всё‑таки нужно понимать, как всё работает.
«Оказалось, я ошибался»
Я люблю эти инструменты. Я нахожу их очень полезными и интересными. Но они точно создают болевые точки.
За два последних релиза в ядре стало примерно на 20% больше коммитов. Сначала Торвальдс решил, что компании торопятся протолкнуть код в релиз 7.0. «Оказалось, что я ошибался», — говорит Торвальдс. Дополнительные коммиты — заслуга ИИ‑инструментов: за последние полгода они заметно улучшились, и написать патч для ядра стало проще. Разработка ускорилась почти по всем направлениям.
Разработчики ядра Linux пока справляются с потоком: в каждом релизе участвует больше тысячи человек. Похожий кризис роста Торвальдс уже проходил:
Около 2000 года мне пришлось изменить то, как я работаю, потому что я перестал справляться с проектом, пока Linux рос.
«Они действительно выгорают»
В анонсе 7.1-rc4 Торвальдс написал, что из‑за ИИ‑отчётов рассылка об уязвимостях стала «почти полностью неуправляемой». Баг, найденный с помощью ИИ, «по сути стоит считать публичным», говорит Торвальдс: этот баг, скорее всего, уже нашли и другие. Значит, чинить такой баг можно открыто, но выкладывать готовый код для атаки через него (эксплойт) всё равно не стоит.
Часть исследователей, по словам Торвальдса, «хочет получить всю славу за баг и опубликовать его ещё до того, как поговорит с пострадавшими». Компании охотно платят за поиск багов с помощью ИИ, но патчи к найденному присылают редко.
У Linux есть ресурсы, чтобы разбирать такие находки. У тысяч других проектов их нет:
Есть проекты, которые не входят в ядро Linux — личные проекты какого‑то одного разработчика. Человек работает над проектом десять лет или дольше, и у него есть всего один, от силы три человека, которые занимаются исправлением ошибок и выпуском патчей. И вот они действительно выгорают.
Выгорание усиливают отчёты «на бегу» (drive‑by): человек находит баг с помощью ИИ, сообщает о нём — и пропадает.
Когда вы просите предоставить дополнительную информацию, оказывается, что человек просто сделал такой drive‑by и даже не отвечает на ваш вопрос. Вот это и есть настоящая проблема с выгоранием.
Искать баги с помощью ИИ может кто угодно, а разбираться с находками приходится мейнтейнерам. Мейнтейнеры будут постоянно в роли догоняющих, и Торвальдс думает, что этого не избежать.
«Мы пользуемся ИИ‑инструментами»
Мейнтейнеры ядра Linux активно пользуются ИИ‑инструментами, но все правки проверяют и сопровождают живые люди. Многие ведущие разработчики ядра запускают модели локально.
Не стоит целиком зависеть от больших компаний, которые однажды решат: о, нам тоже надо зарабатывать.
Главная трудность, по словам Торвальдса, социальная:
Конфликт не в том, что ИИ плохой. Конфликт в том, что появляются социальные барьеры и болевые точки.
И тем не менее:
Вообще‑то я смотрю на всё это очень позитивно.
«Учиться работать в новых условиях»
Валентин Исипчук, наставник на курсе «Вайб‑кодинг на Claude Code» в Хекслете и практикующий разработчик (Java, Kotlin, Golang, JavaScript/TypeScript):
Мы входим в новый этап разработки, и не всем от этого комфортно. И то, что это отметил даже Линус Торвальдс, известный консерватор, — самое большое тому подтверждение. Поэтому вместо запретов нужно учиться работать в новых условиях: искать способы автоматизировать проверки и ревью, снижать нагрузку на мейнтейнеров.
Источники
Комментарии (189)
edogs
04.11.2026 15:56На самом деле контроль за разработкой давно утерян. Даже те, кто писал на асме, уже с трудом понимали что там происходит в железе, но имели представление. Потом пошли компиляторы, оптимизаторы кода, преобразователи, синтаксический сахар и т.д.. Потом прогеры стали подключать сторонние либы написанные кем попало. Внутри команды - джунский код никто от и до не проверяет уже давно. Гуру программирования на голубом глазу признают что понятия не имеют как писать алгоритмы, т.к. забыли уже и синтаксис не очень помнят. Вон код для боинга индусы писали за копейки.
То есть по большому счету ситуация с приходом ИИшницы не изменилась качественно.
Как раньше человек полагался на непонятно чей код (чужие либы, джуны, компилятор, виртуальная машина) и не вникал в чужой код глубоко (основные тесты прогоняются, работает и все), так и сейчас полагается на непонятно чей код.
Хочешь контролировать всё от и до? Асма даже недостаточно будет, т.к. надо знать физическую архитектуру процессра и всех его связей с периферией и саму периферию. Реально это? Нет. Так что расслабляемся и понимаем, что ИИ ситуацию принципиально не меняет, оно просто подсвечивает те проблемы которые существуют уже давно и существование которых всех устраивало.
balamutang
04.11.2026 15:56Чепуха, компилятор это не черный ящик. Те кто пишет ответственный код не использует левые либы.
А ии это как раз черный ящик. И проблема в том что генерить этот ящик может тонны слопа, который некому ревьювить, нет столько людей.
GreyPoint
04.11.2026 15:56Я согласен
ИИ, алгоритмически, это вероятностная математическая система, а значит всегда есть вероятность получить мину замедленного действия в код. Для снижения вероятности ошибки в коде, необходимо использовать рой ИИ агентов где одни пишут, другие проверяют третьи перепроверяют, но даже так это не проконтролировать на 100%. Вполне допускаю, что через какое-то время такой косяк в инфраструктурном коде где нибудь в cloudflare положит половину интернета.
Страшно не то что код не заработает, страшно, что он заработает и заработает как нам покажется идеально
AbuMohammed
04.11.2026 15:56Давно известно, что если что то заработало с первого запуска, то жди невероятно ..пы.
edogs
04.11.2026 15:56Чепуха, компилятор это не черный ящик.
Увы, компилятор давно уже не тупой переводчик А в Б. Нет гарантии, что Ваша программа которая компилировалась одним и тем же компилятором, но разных версий и/или в разном окружении и/или с разными настройками - будет во всех случаях корректно работать и работать вообще.
Те кто пишет ответственный код не использует левые либы.
Увы, сторонние либы используют абсолютно все. А они обновляются, в них появляются новые баги, фиксятся старые, а некоторые баги висят годами.
Ну а про ответственный код, знаете, все говорят что они пишут ответственный код, а потом оказывается что боинги падают т.к. отдали код индусам на аутсорс, с бинанса крадут миллиарды, а дыра в пхп внезапно затрагивает изрядную часть интернета. Можно еще вспомнить ошибки в коде в космической области, когда там знак перепутали или систему мер не ту выдали. Давайте не обманывать сами себя про некий абсолютно ответственный код в вакууме.проблема в том что генерить этот ящик может тонны слопа, который некому ревьювить, нет столько людей.
Проблема с недостатком людей для ревью началась намного раньше нейрослопа. С нейрослопом она просто стала достаточно заметной, чтобы на нее обратили внимание.
Навяло:
- Ты всего лишь машина, только имитация жизни. Робот напишет код? Робот отревьюит его до самых железных кодов, чтобы точно знать, что код без ошибок, не полагаясь на третьих лиц?
- А ты?
Wesha
04.11.2026 15:56Нет гарантии, что Ваша программа которая компилировалась одним и тем же компилятором, но разных версий и/или в разном окружении и/или с разными настройками - будет во всех случаях корректно работать и работать вообще.
Вообще-то есть.
Робот отревьюит его до самых железных кодов, чтобы точно знать, что код без ошибок, не полагаясь на третьих лиц?
- А ты?Вообще-то да. Если заплатите соответствующую сумму, конечно.
ivpetrov386
04.11.2026 15:56Както лихо вы за всех отвечате, что они используют сторонние либы. Полно кода, который их не использует. Всякие марсоходы, там из стороннего наеврное чтото типа misra, но и это не левое.
General_Failure
04.11.2026 15:56"Полно кода" и "марсоходы". Как там, в 2100-м? А вот у нас в 2026-м Марс пока только разведывается несколькими марсоходами.
nidalee
04.11.2026 15:56Сколько людей пишут код для марсоходов и прочих ядерных подлодок? 1% разработчиков на планете наберется? Или все же подавляющее большинство джсоны перекладывает обильно удобряя либами?
RTFM13
04.11.2026 15:56ну смотря что считать сторонними. условный stdlib.h это сторонняя?
randomsimplenumber
04.11.2026 15:56Контроллируется незнакомыми людьми с неизвестными мотивами. И внезапно https://habr.com/ru/companies/pt/articles/277383/
UFO_01
04.11.2026 15:56Что за крайности, либо пиши через ИИ, либо на машкодах. Есть ДОСТАТОЧНЫЙ уровень контроля, который варьируется в зависимости от ситуации. Если вы этого не понимаете, это ваша проблема.
будет во всех случаях корректно работать и работать вообще.
Будет, в ответственных сферах используются только сертифицированные под требования компиляторы фиксированной версии. См. первый абзац.
Увы, сторонние либы используют абсолютно все.
А в ответственных сферах их использование запрещено. Аналогично, см. первый абзац.
что боинги падают т.к. отдали код индусам на аутсорс
Боинги падают потому что великоумные инженеры читали данные только с одного датчика, а при срабатывании намертво блокировали управление. Манагеры фальсифицировали данные испытаний, не внесли информацию о системе в руководство и затыкали рты ОТК. Наверное это индусы виноваты. Если бы использовали ИИ вместо индусов, разницы бы было ноль. Ну ещё и великолепный демедж контроль, потому что везде пишут что это индусы виноваты, а не сам боинг и его руководство.
- Робот напишет код? Робот отревьюит его до самых железных кодов, чтобы точно знать, что код без ошибок, не полагаясь на третьих лиц?
- А ты?
Если надо - да. За соответствующий чек.
K0styan
04.11.2026 15:56С учётом того, что микрокод процессора может инструкции переставлять, если сочтёт, что так конвейеры и шины лучше загрузит, то даже написание в машинных кодах, не говоря о языке ассемблера, уже не гарантирует понимания того, что в железке происходит.
mckeenly15
04.11.2026 15:56На самом деле контроль за разработкой давно утерян... Внутри сторонних либ джунский код... Гуру программирования на голубом глазу признают что понятия не имеют как писать алгоритмы, т.к. забыли уже и синтаксис не очень помнят... Вон код для боинга индусы писали за копейки.
Громкое утверждение и голословные доводы. Просто берем и пишем что придет в голову, подтверждения не нужны, главное чтобы звучало эффектнее)
edogs
04.11.2026 15:56Это можно в полной мере сказать как раз о Вашем утверждении. Вы даже пары минут не уделили чтобы хоть что-то проверить, но сразу катаете опровержение, да еще такое откровенно желтушно-байтовое из серии "требуй от оппонента пруфы на каждый чих, займи все его время":)
Но не проблема, рзовая акция "погуглим за вас" буквально за пару минут в паре примеров покрывающая все Ваши отквоченные претензии.
Про потерю контроля: https://habr.com/ru/articles/423889/?ysclid=mw2pkotz8013700158
Про гуру: https://habr.com/ru/articles/323188/?ysclid=mw2ovw63ix146715548
Про некорректные либы: https://habr.com/ru/articles/251751/?ysclid=mw2o6yyj4g708797416
Про боинг: https://habr.com/en/articles/458224/comments/?ysclid=mw2pinu1jc293638544Wesha
04.11.2026 15:56Да я вижу уже, что Вы
ysclidот урла ручками отрезать не способны — и Вы нам тут о контроле талдычите?
Trab_l13
04.11.2026 15:56Так его! /s
qyix7z
04.11.2026 15:56«И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется» ©
Wesha
04.11.2026 15:56
«Техника‑молодёжи», 1981, № 12, c.58
habrolog
04.11.2026 15:56Вот ей-богу, создатели алгоритма сжатия djvu будут гореть в аду.
Преимущества шакального сжатия продержались выгодными лет 5, ну максимум (максимум!) 10, пока дисковое пространство еще было дорогое (напомню, что придумали его не в 1988, как может казаться, и даже не в 1993, а аж в 1998!) А невосполнимого ущерба создано — на десятки лет в будущее. Десятки тысяч, если не сотни, единиц печатной продукции и даже рукописных манускриптов... надо просто-напросто сканить заново.
RTFM13
04.11.2026 15:56Парсинг всех этих емейлов и урлов неблагодарное занятие. Если это не домашняя поделка для себя а прод серьёзный, то по хорошему надо садиться и читать стандарт на пару сотен страниц (только в той части которая тебя касается). А потом садиться и еще неделю изучать сложившуюся практику и решать на сколько ты готов отступить от стандарта чтобы случайно не порезать условный гугл.
Можно библиотечную функцию использовать, но если с ней что-то не так (а с ней точно что-то не так) то надо будет всё равно делать всё что выше + разбираться как работает библиотечная функция.
Или просто написать запрос иишке. Она кстати умеет сама сходить стандарт почитать, библиотечную функцию отревьюить и т.п. И всё это занимает от минуты до получаса вместо от недели до месяца. Хотя конкретно веб там по большей части из коробки в неплохом качестве.
Wesha
04.11.2026 15:56Какой к чёрту парсинг? До знака вопроса — путь к документу, после — параметры запроса. Путь не где-то, а на Хабре; здесь параметры — чисто от рекламных интеграций, всё работает и без них. Какие ещё тут стандарты нужны???
randomsimplenumber
04.11.2026 15:56Старики рассказывали про старинные CMS, где путь к документу всегда /index.php.
NeoCode2
04.11.2026 15:56Ну компиляторы все-таки детерминированы. Один и тот же исходник порождает один и тот же бинарник. В случае с ИИ детерминированности нет, там по определению присутствует элемент случайности и на один и тот же промпт может выдаться совершенно разное.
А вот куча сторонних библиотек, скачивающихся из инета автоматически, как сейчас современные программисты любят - это да, тот еще элемент случайности, хотя вроде и без ИИ.
Dhwtj
04.11.2026 15:56Не только детерминированы. Качество их результата доказано на ревью, тестах и эксплуатации.
LLM этого просто быстро работающий по шаблонам эксперт общих знаний и отладчик, плохо погруженный в контекст, не понимающий приоритетов и ограничений конкретного проекта. И потому его результаты без гарантий
KohINoor
04.11.2026 15:56И что-то я не припомню случая, чтобы компилятору можно было сказать "что-то мне не нравится, что у тебя вышло, давай заново" и это как-то повлияло бы на результат.
randomsimplenumber
04.11.2026 15:56Компилятор: сыплет warningов.
Программист: да что ты понимашь, железяка. Я художник, умвр.
RTFM13
04.11.2026 15:56На самом деле всё наоборот.
Компилятор (а тем более линковщик) имеют право собрать по разному. Функции местами переставить и т.п. Там в многопотоке может в разном порядке собраться. Не говоря про кучу вкомпиленных таймстэмпов и путей. Чтобы этого гарантировано не было - там отдельные неслабые заморочки. Ими сравнительно недавно озаботились.
А вот нейронка это чистая дискретная математика. Чтобы ответы различались имеет два параметра температуру и стартовое значение для рандомизатора. Если это стартовое значение выставить фиксированным то ответы будут под копирку (по идее температуру тоже, но это не точно). Это используется для всякой отладки и бенчмарков, где воспроизводимость нужна.
ToxaBes
04.11.2026 15:56(по идее температуру тоже, но это не точно)
Только при условии что температура в обоих вызовах будет равна нулю.
Лихо вы вероятностные числовые сита записали в чистую дискретную математику.
RTFM13
04.11.2026 15:56Лихо вы вероятностные числовые сита записали в чистую дискретную математику.
Это вы лихо заменили веса вероятностями. Между ними разница как раз в детерминированности.
БЯМ это модель и модель математическая буквально. А в основе всё равно дискретная математика. По крайней мере в текущем варианте.
А компилятор часто это открытая система. Те же таймстэмпы от NTP зависят, а тот от всего что угодно - я кофе пролил, коммент на 3 секунды позже отправил, очереди на маршрутезаторах сдвинулись в отоге на пару байт и в австралии у кого-то сборка изменилась. А еще он от GPS зависит, а тот от чего угодно - от фазы луны от вспышек на солнце, от планет соседних, да и крупный астероид младший бит может перещелкнуть. Хотя наверное тут уже квантовая неопределенность больше погрешностей вносит. Т.е. вообще непредсказуемая хрень.
при условии что температура в обоих вызовах будет равна нулю.
да, конечно, это и имелось в виду.
asdadn
04.11.2026 15:56да, конечно, это и имелось в виду.
А какой смысл рассматривать этот частный случай? Никто не использует LLM с нулевой температурой. В таком случае и с компиляторами можно рассматривать только случай с последовательной однопоточной компиляцией.
RTFM13
04.11.2026 15:56В бинарнике обычно есть поле время компиляции. На этом детерминизм заканчивается.
RTFM13
04.11.2026 15:56Из компиляторов рандомизацию специально убирали для воспроизводимости. А в ЛЛМ её наоборот добавили (для невоспроизводимости).
cpud47
04.11.2026 15:56БЯМ это модель и модель математическая буквально. А в основе всё равно дискретная математика. По крайней мере в текущем варианте.
Да, только статистическая. А статистика максимально далека от дискретной математики. Впрочем, это лишь вопрос терминов
BugM
04.11.2026 15:56А статистика максимально далека от дискретной математики. Впрочем, это лишь вопрос терминов
Не-не-не. Это принципиальное отличие.
Статистика это про методологию, доверительные интервалы и честный учет всего неизвестного.
Правильно работать со статистиской мало кто умеет. Оно вообще не очевидно.
cpud47
04.11.2026 15:56Ну, как область знаний ллм как и мл живут где-то рядом со статистикой. Где там проводить границы не сильно принципиально.
P.S. Но в определённом смысле мл есть раздел статистики. В статистике далеко не обязательны доверительные интервалы и многое прочее. А вот определения, задачи и теоремы у статистики и серьёзного мл во многом пересекаются.
RTFM13
04.11.2026 15:56Если из БЯМ убрать рандомизацию она не перестаёт быть БЯМ. Рандомизация туда внесена принудительно специально размазать ответы чтобы она всем не отвечала одно и тоже. Это опция для гуманитариев по сути.
Более того, для локальных квантованных моделей рекомендуется выкручивать температуру пониже или в ноль. Она от этого не портится.
cpud47
04.11.2026 15:56Не совсем. Там без рандомизации качество ответов падает по некоторым причинам. Поэтому она принципиальна.
RTFM13
04.11.2026 15:56в кодинге я не заметил падения. наоборот, на квантованной модели меньше ошибок в вызове функций.
опять же, воспроизводимая рандомизация на основе Г(П)СЧ - это почти оксюморон.
cpud47
04.11.2026 15:56Не сразу понял что имелось ввиду. БЯМ является стат моделью не потому, что есть температура. Дело в том, что любой мл в принципе основан на статистике и теорвере. Впрочем не сильно вижу смысла спорить о терминах.
ToxaBes
04.11.2026 15:56Это опция для гуманитариев по сути.
Похоже, что гуманитарий здесь один.
Более того, для локальных квантованных моделей рекомендуется выкручивать температуру пониже или в ноль. Она от этого не портится.
Жадное декодирование (температура 0) может приводить к зацикливанию текста, бесконечным повторам и общему ухудшению качества. Тот же Qwen рекомендуют для своих моделей температуру от 0.6 до 1.0.
Зачем вы пишете бред, который опровергается первым запросом в гугле?
RTFM13
04.11.2026 15:56Жадное декодирование (температура 0) может приводить к зацикливанию текста, бесконечным повторам и общему ухудшению качества. Тот же Qwen рекомендуют для своих моделей температуру от 0.6 до 1.0.
В текущем контексте этоне важно. Если рандомизация основана на алгоритмическом ГПСЧ она всё равно детерминирована.
LinkToOS
04.11.2026 15:56Жадное декодирование (температура 0) может приводить к зацикливанию текста, бесконечным повторам и общему ухудшению качества. Тот же Qwen рекомендуют для своих моделей температуру от 0.6 до 1.0.
Зачем вы пишете бред, который опровергается первым запросом в гугле?Гугл так отвечает:
Обзор от ИИ
Для локальных квантованных моделей (особенно в форматах GGUF, EXL2, AWQ низкой битности, например, 4-бит или 3-бит) действительно рекомендуется снижать температуру или выставлять её в 0, если вам нужна точность, логика или работа по четким инструкциям (программирование, анализ текста, извлечение данных).
Почему квантованные модели «не любят» высокую температуру?
1. Искажение распределения вероятностей (Деградация весов): При сильном квантовании (сжатии модели) «расстояние» между правильными и ошибочными токенами (словами) в предсказаниях модели сокращается. Логические связи становятся более хрупкими.
ToxaBes
04.11.2026 15:56Это вы лихо заменили веса вероятностями. Между ними разница как раз в детерминированности.
Изучайте параметр температура и ее значения, которые требуют современные модели для нормальной работы.
cpud47
04.11.2026 15:56При фиксированном сиде и фиксированной температуре ответы будут одинаковыми, даже если температура не нуль. Разве нет?
BugM
04.11.2026 15:56Нет. Температура это буквально random(). Выбери не самое подходящее продолжение фразы, а следующее вот с такой вероятностью.
И это делает конечный результат лучше, как не странно. Самое вероятное продолжение может быть неверным и нужен механизм перебора остальных.
RTFM13
04.11.2026 15:56нет, не буквально. используется псевдослучайный (алгоритчический) генератор. который в свою очередь может инициализироваться уже случайным seed.
Но если seed задать явно, то ГСЧ выдаст одну и ту же последовательность.
В компиляторах кстати seed тоже добавили именно для воспроизводимости.
BugM
04.11.2026 15:56Ок, упрощенно а не буквально. LLM много раз прогоняет текст через рандомизатор и каждый следующий результат зависит от предыдущего. Практически можно считать что это не seed, а именно граница рандома.
Разница видна только тем кто модели обучает. Там уже важно.
RTFM13
04.11.2026 15:56Рандомизация ЛЛМ является принудительной надстройкой, а не неотъемлемым свойством архитектуры. Выкрутите температуру в ноль, скорее всего в вопросах програмирования станет только лучше.
BugM
04.11.2026 15:56Хуже. Антропики шарят в программировании. И там не 0. Тоже нужны разные варианты и перебор.
cpud47
04.11.2026 15:56Не, температура это просто параметр распределения. Рандом вызывается на каждый токен.
RTFM13
04.11.2026 15:56По идее да, но там тьма нюансов в реализации из-за которых на практике может перещелкнуться 1 бит и дальше оно может покатиться как снежный ком.
Типа "эффекта бабочки".
cpud47
04.11.2026 15:56Компилятор (а тем более линковщик) имеют право собрать по разному. Функции местами переставить и т.п. Там в многопотоке может в разном порядке собраться. Не говоря про кучу вкомпиленных таймстэмпов и путей. Чтобы этого гарантировано не было - там отдельные неслабые заморочки. Ими сравнительно недавно озаботились.
Вроде большинство промышленных компиляторов однопоточны. А в однопоточном компиляторе довольно естественно получается воспроизводимость со модулю дебагинфо/метаинформации. Можно конечно рандомизированные алгоритмы использовать, но их вроде никто кроме rustc особо не использует.
BugM
04.11.2026 15:56Попробуйте собрать С++ проект побольше в один поток. Хромиум это отличный пример. Там не то что чаю попить можно, а выспаться успеешь.
cpud47
04.11.2026 15:56Ну так каждый вызов cc однопоточен. Просто вызываем паралельно несколько компиляций для разных файлов. Или уже добавили внутреннюю многопоточность в clang/gcc?
Wesha
04.11.2026 15:56Попробуйте собрать С++ проект побольше в один поток.
«Оу, мсье — тонкий извращенец!» ©
Wesha
04.11.2026 15:56Функции местами переставить и т.п.
Я Вам сейчас страшную тайну открою, но от перестановки мест слагаемых сумма не меняется. Проверено столетиями.
RTFM13
04.11.2026 15:56О, с разморозкой. Вы к нам из какого столетия?
От перестановки слагаемых контрольная сумма как раз таки меняется.
Ну и при операциях с FP обычная арифметическая сумма тоже легко меняется от перестановки слагаемых. Это как раз наиболее трудноустранимая причина недетерминированности ЛЛМок и много чего еще.
Wesha
04.11.2026 15:56Ну да, ну да, программа
int a() { ...код... } int b() { ...код... } int main { a(); b(); }работает совершенно не так, как
int b() { ...код... } int a() { ...код... } int main { a(); b(); }, охотно верю!
cpud47
04.11.2026 15:56У них может быть разный перф (вроде в среднем +-10%). Плюс есть ещё всякие ctors которые могут менять порядок выполнения кода в зависимости от порядка линковки. Поэтому меняется всё же.
trinxery
04.11.2026 15:56Очевидно, что в "функции местами переставить" имелось ввиду поменять их порядок выполнения.
glebliutsko
04.11.2026 15:56имеют право собрать по разному
Имеет, но запуск одной и той же версии компилятора на одних, с одними и теми же флагами и на тех же исходниках дает одинаковый результат. На этом все воспроизводимые сборки построены. В том же debian, например, если не ошибаюсь, все пакеты воспроизводимы. Так где же тут рандом?
Чтобы ответы различались имеет два параметра температуру и стартовое значение для рандомизатора
Вот только математика с плавающий запятой на GPU не детерминирована (по крайне мере без дополнительных ухищрений). Так что даже температура равная 0 не гарантирует точно такой же ответ.
Тут просто другой вопрос, а на сколько LLM нужна такая же детерминирована как компилятору? Компилятор то мы постоянно запускаем, а LLM один раз сгенерировала исходники, их проверили (проверили же? :) ) и закомитили.
RTFM13
04.11.2026 15:56Имеет, но запуск одной и той же версии компилятора на одних, с одними и теми же флагами и на тех же исходниках дает одинаковый результат. На этом все воспроизводимые сборки построены.
нет, изучите вопрос. там немного сложнее.
В целом - да, стремятся к воспроизводимости. Но это потребовало ряда доработок.
glebliutsko
04.11.2026 15:56Там же все эти доработки сводятся к тому, что бы билд система на вход компилятору подавала статичные данные без всякях timestamp и прочей фигни.
Вся "недетерминированность" возникает от того, что система сборки подаёт на вход компилятора не статичные данные (временные метки, флаги сборки, абсолютные пути к исходникам). Сам компилятор как компилировал детерминировано, так и продолжает.
asdadn
04.11.2026 15:56Именно детерминированность мне представляется не настолько значимой. Куда важнее наличие гарантий. Компилятор должен выдавать аутпут с той же самой логикой, что и инпут(в рамках defined behaviour, разумеется). Если он этого не делает, значит, в нём есть баг, требующий исправления. Да, контроля за низкоуровневыми аспектами нет, но в том и суть высокоуровневых ЯП - абстрагироваться от части низкоуровневых деталей, гарантировав контроль над остальной логикой.
Тем временем, LLM вообще не может дать никаких гарантий.
i86com
04.11.2026 15:56Один и тот же исходник порождает один и тот же бинарник.
В разных версиях компилятора - разный.
Ну компиляторы все-таки детерминированы.
Ну вот опять это неверное использование термина. Детерминированность за пределами головы программиста не имеет никакого значения.
"Computers make very fast, very accurate mistakes."
А внутри головы программиста она уже давно не складывается - софт ушёл настолько далеко от простых алгоритмов, что мозгу homo sapiens не удастся удержать всё в контексте. Да, даже воображаемому "супер-умнику в подвале, который пишет код ядра большой системы и всё помнит наизусть", который точно-точно где-то существует. Не говоря уже про реальных людей, у которых помимо программирования есть семья, жизнь и заботы.
Почему вы это пишете? Потому что, да, когда в первый раз используешь ИИ для написания программы, то не знаешь, чего ожидать в результате. Оно вообще скомпилится? Оно заработает? А если будет ошибка - то где и почему?
Но использование ИИ - это тоже навык. Нужно понимание того, как работает ИИшка и что у неё в данный момент есть в контексте, чтобы знать, на каких задачах и в каких местах она будет "искать чёрную кошку в тёмной комнате, где её нет". И что характерно, таки "найдёт" - просто сгаллюцинирует её.
Как и понимание, почему ИИ может за пару секунд прочитать портянку лога и верно ответить на вопрос по ней, а вот буквы r в слове strawberry без специальной обвязки затрудняется подсчитать.
Это сродни пониманию, какую либу можно тянуть в продакшен, а какую - пока рано. Или какая часть проекта заслуживает доверия, а какая была написана коллегами давно, во время аврала и лучше туда вообще не соваться. Тот же рандом. Неустранимый, но контролируемый.
Wesha
04.11.2026 15:56Но использование ИИ - это тоже навык.
Вы, я так понимаю, навык наработали? Мастер-класс покажете, или отмазку придумать попросите?
i86com
04.11.2026 15:56Я пишу только о том, с чем работал и разбирался. С генерацией комиксов по многоэтажным промптам таки не работал. Можете считать это отмазкой.
acsent1
04.11.2026 15:56Не совсем, но в мире линукса решили что нужно избавляться от этой недетерминированности и двигаются в сторону Reproducible Builds.
tatapstar
04.11.2026 15:56Зачем ИИ-разрабу быть детерминированным? Ему в отличие от компилятора код написать нужно единожды. Детерминированность нужна только для ИИ-компилятора, интерпретатора, чем никто ещë не пользуется
SokilOff
04.11.2026 15:56С учётом дикого количества багов и уязвимостей, которые сейчас регулярно находятся и фиксятся благодаря ИИ в продуктах крупнейших софтовых фирм, "кожано-костяной слоп" (написанный и сеньорами, и гуру, и прочими небожителями кода) оказался на практике ничуть не качественнее и не надёжнее "нейрослопа".
Пора уже смириться, что таких в чётко детерминированных задачах, как программирование, машина в результате окажется сильнее, и "пластмассовый мир победит". Шахматисты уже поняли, что бессмысленно бороться с AlphaGo Zero и Stockfish, и стадия принятия у них наступила. У программистов же пока нечто среднее между гневом и торгом.
Dhwtj
04.11.2026 15:56таких в чётко детерминированных задачах, как программирование
Шито? Лол
Щютка дня
Даже не близко. Особенно в обследовании и проектирования
Детерминировано там только: компилятор и тесты на стенде.
kabas
04.11.2026 15:56+100 очень хорошее сравнение с шахматами. Да, игра умерла, как таковая и то, что сейчас - смешно. Говорю как бывший фанат и игрок. Я вот сам сейчас навайбкодил плагин к deepseek harness для конвертации некоторых специальных файлов pdf в xlsx. Штатные средства ОС не справлялись по опредеденным причинам. Очень удобно, все работает. Заняло 30 минут. Это будущее, которое уже наступает. И да, вспомним количество багов в софте, написанном людьми... Или это типа "правильные" баги :) ??
Flux
04.11.2026 15:56+100 очень хорошее сравнение с шахматами
Шахматы это буквально конечный автомат с конечным числом состояний по ребрам которого можно двигаться, какое еще хорошее сравнение?
LinkToOS
04.11.2026 15:56С учётом дикого количества багов и уязвимостей, которые сейчас регулярно находятся и фиксятся благодаря ИИ в продуктах крупнейших софтовых фирм, “кожано-костяной слоп” (написанный и сеньорами, и гуру, и прочими небожителями кода) оказался на практике ничуть не качественнее и не надёжнее “нейрослопа”.
Смотреть надо на реальную эксплуатацию, а не на цифры найденных уязвимостей, 99% из которых лишь чисто формально являются “уязвимостями”.
Шахматисты уже поняли, что бессмысленно бороться с AlphaGo Zero и Stockfish, и стадия принятия у них наступила
А экскаватор сильнее любого дзюдоиста.
Шахматисты никуда не исчезли. И шахматы, как вид спорта, так и остались соревнованием между людьми.Пора уже смириться, что таких в чётко детерминированных задачах, как программирование, машина в результате окажется сильнее
Такую машину нужно еще создать. Для того чтобы “машина оказалась сильнее программистов”, самим программистам нужно еще изрядно потрудиться, чтобы создать систему которая окажется “сильнее” их. Если у них вообще получится повысить “интеллект” программы до такого уровня. Пока что не получилось.
Тут как бы парадокс - чтобы создать программу которая будет умнее программистов, программистам сначала самим нужно стать достаточно умными.BugM
04.11.2026 15:56Смотреть надо на реальную эксплуатацию, а не на цифры найденных уязвимостей, 99% из которых лишь чисто формально являются “уязвимостями”.
Уже пора признать что LLM нашли реально много настоящих уязвимостей. Вал CVE неспроста.
Поток неуязвимостей с которым мейнтенерам проектов надо что-то делать от этого не исчез и проблема есть.
killnet
04.11.2026 15:56LLM спрятан за спиной мейнтенера. Я не удивлюсь если LLM находит 1 уязвимость, создавая при этом n+1. Ответственность у мейнтейнера теперь не только за себя, но и за LLM.
Wesha
04.11.2026 15:56
Fedorkov
04.11.2026 15:56Смартфоны потребляют меньше человеческого мозга и уделывают Магнуса Карлсена.
thelittlewitch1
04.11.2026 15:56Формулировка, конечно, отличная, очень вхарактерно для Джо Рогана. Обыграть телефон в шахматы. Чет мне думается какой-нибудь популярный chess.com всё "в облаке", а не на устройстве, считает. Но конкретика подкаст-бро не интересна, только возможность нарезать на вертикальные клипы +- минутной длины.
vdudouyt
04.11.2026 15:56Есть по крайней мере одна очень простая и в то же время очень серьезная причина, почему переход к ИИ - это не как переход с асма к ЯВУ в свое время: компилятор это детерменированная штука, а ИИшница - нет.
RTFM13
04.11.2026 15:56Всё наоборот. Выше расписал подробнее.
ToxaBes
04.11.2026 15:56Называя ИИ детерминированной штукой вы просто расписываетесь в том, что ничего не понимаете ни в ИИ, ни в машинном обучении. Прекращайте.
RTFM13
04.11.2026 15:56Есть что возразить по сути? Или только умного строить?
Спросил ради хохмы у двух иишек. Дали противоположный ответ, но в пояснениях написали практически одно и тоже. Просто одна сделала уклон на архитектуру, а другая на фактическое поведение.
Алгоритмически являются детерминированными. Отличия в изначальных весах и версиях софта выносим за скобки. Это де факто разные системы. как разные версии компилятора.
Основные причины недетерминированности являются искусственными (T, seed, Top-P/Top-K). есть еще мелкие нюансы типа недетерминированных FP операций, порядка загрузки MoE моделей и т.п. Тут история в чем-то похожа на недетерминируемость компилятора. Всякая многопоточность, оптимизация и т.п. Но практически всё сводится к округлению (или начальному состоянию). Недетерминизм FP кстати старая боль, по этому в серьёзных вычислениях его использование - моветон (хотябы в той же бухгалтерии). Но когда вычислений много приходится идти на компромис.
Квен сказал, что если взять квантованную плотную модель и поотключать всю рандомизацию и запустить на синглтрэде, то "вероятность побитового детерминизма высокая". Для сравнения, у компилятора по умолчанию она нулевая из-за таймстемпов. Т.е. хэш бинарника не сойдётся условно никогда. А у модели может.
Wesha
04.11.2026 15:56Для сравнения, у компилятора по умолчанию она нулевая из-за таймстемпов.
Ну расскажите нам, как таймстемпы влияют на генерацию последовательности ассемблерных команд.
RTFM13
04.11.2026 15:56генерацию последовательности ассемблерных команд
вы точно понимаете смысл слов которые пишете?
если вы про генерацию исполняемого файла, то вот так например влияют:
printf("Date: %s, time: %s\n", __DATE__, __TIME__);на ассемблере (или при чем тут ассемблер вообще?) суть примерно таже, но на память не напишу, давно я не брал в руки шашек, но уверен каждая первая иишка справится.
Wesha
04.11.2026 15:56Потому что компилятор, ВНЕЗАПНО, превращает текст буковками в ассемблерные команды.
И ассемблерные команды в Вашем примере, ВНЕЗАПНО, будут сгенерированы одни и те же. Меняться будут строковые данные.
salnicoff
04.11.2026 15:56LLM не думает она тупо копирует. А копирует как раз тот самый код, написанный джуном с использованием левых библиотек и без понимания работы железа.
Politura
04.11.2026 15:56Гуру программирования на голубом глазу признают что понятия не имеют как писать алгоритмы, т.к. забыли уже и синтаксис не очень помнят.
Можете привести подтверждения своим словам? Из того, что я вижу - приходится намного больше ревьюить кода и бывает, что больше понимать всякий свежий синтаксис, который LLM-ки подсовывают, чтоб принять решение - надавать по рукам и заставить переделать, или наоборот самому подобным пользоваться.
cpud47
04.11.2026 15:56На самом деле, качественное изменение в том, что мы перешли с модели снепшотов(декларативной) к модели диффов(императивной). Раньше был исходный код и этот код люди непосредственно читают и правят — он источник истины. И в общем-то не важно это код на каком-нибудь ЯП, или на условном асме. Теперь же исходный код является артефактом генерации, люди не трогают его напрямую. Вместо этого источником истины является серия промптов на изменение "исходников".
Можно конечно считать спеки новым источником истины. Но здесь два момента. Первый, промпты никуда не делись, пусть и стали содержать меньше информации. Второй заключается в том, что спеки не предсказуемы(у них нет семантики), в отличии от ЯП: если по спеке генериться кривой код, мы не можем сказать, что это "баг" в ЛЛМ — мы всегда вынуждены считать это багом в спеке.
Подход с дифами уже встречался в индустрии. Его использовали в бд, где любая правка кода делается через миграцию (ручную или автоматизированную). Их использовали девопсы, где любое изменение делается через команду на мутацию. И там и там этот подход связан со множеством сложностей. В бд многие перенесли логику на уровень приложения (что само по себе не прям идеально). В девопсе многие пересели на кубер с агро, то есть по сути эмулируют декларативный подход поверх императивной внутренней модели (не сказать что очень успешно, но как есть).
Поэтому качественное различие всё же есть. И как по мне, в негативную сторону.
Получится ли сделать декларативный и при этом предсказуемый подход к программированию через ллм — вот в чём вопрос.
P.S. можно было бы ещё добавить про абстрагирование и институт репутации. Но это вторично, по сравнению с обозначенной проблемой.
powerman
04.11.2026 15:56На самом деле контроль за разработкой давно утерян.
Он утерян только теми, кого это устраивает. Остальные пока ещё в состоянии разобраться в причинах неожиданного поведения кода, при необходимости раскапывая вниз через все слои до железа включительно. И, к слову, с такого рода сложной отладкой и объяснением происходящего ИИ может сильно помочь.
Контроль - это не понимание 100% времени всего происходящего на всех уровнях (такого почти ни у кого не было даже во времена перфокарт), а возможность разобраться, когда это действительно необходимо.
ИИ быстро пишет код - это ещё не утеря контроля. Утеря происходит в тот момент, когда вы решаете написанный им код не ревьювить, либо аппрувить после ревью то, что не поняли. По большому счёту это примерно то же самое, как лет 5 назад нанять в команду из 5 разработчиков ещё 25 миддлов и пустить их закрывать таски, мержить и выкатывать в прод без какого-либо контроля и ревью, просто дать им почитать существующие доки и довериться, что они будут делать хорошо, а плохо - не будут. :-)
ulisma
04.11.2026 15:56Утеря происходит в тот момент, когда вы решаете написанный им код не ревьювить, либо аппрувить после ревью то, что не поняли.
А здесь уже включается психология. Если на тебя падают задачи как из рога изобилия, бесконечные оры менеджмента, что надо все быстрее и чего ты там копаешься, то какое ревью? Здесь гораздо выгоднее просто апрувнуть и забыть. А потом, если что, поправить опять же таким способом. Но с точки зрения рабочего процесса ты чист и пофигу на качество.
Поэтому IMHO все меньше людей будут заниматься нормальным ревью. Человек сейчас поставлен в такие условия, где ревью в принципе не нужно. Это вот большая проблема применения иишки.
RedBrick
04.11.2026 15:56На самом деле контроль за разработкой давно утерян.
Мне это напомнило предложение одного моего знакомого вообще отменить экзамены при получении водительских прав, дескать всё равно кому надо просто их покупают, а если отменить, то хотя бы коррупции будет меньше. Но мне кажется, что утеря некоторой части контроля, это повод терять его дальше и дальше – где-то есть та грань, после перехода которой всё начнет ломаться фатально и совсем уж в непредсказуемых местах.
engine9
04.11.2026 15:56ИИ очаровал и околдовал Линуса.
LinkToOS
04.11.2026 15:56Линус просто нашел очередной повод для троллинга. Что он там реально думает об ИИ, это еще вопрос.
Выложил бы он видео, как он создает и отлаживает программы с помощью ИИ. Или стрим запустил. Было бы интересно на это посмотреть.BugM
04.11.2026 15:56Но зачем? Отлаживать через ИИ прямо удобно. Он и логи посмотрит и флеймграф распарсит и распределенную систему промониторит по всем хостам и мелочи проверит и даже в системы коллег сходит и проверит что там как на самом деле. Ушла рутина которая жрала кучу времени и бесила.
Все этим занимаются. Это даже не столько эффективно (пофиг пусть менеджеры думают про эффективность) сколько приятно. Не надо делать всю обязательную рутину которую сложно автоматизировать скриптами. Надо делать только интересные штуки.
nidalee
04.11.2026 15:56Я вижу немного иначе: напротив, Линус осадил человека, который хотел потроллить и начать кому-то что-то запрещать:
13 октября 2026 года Линус Торвальдс ответил в рабочей переписке разработчику, который хотел ограничить ИИ в работе над ядром Linux.
Совсем маленький попенсорс понятно, почему запрещает - у них беклог из сотен PR, работу работать там давно никто не хочет, особенно бесплатно (сам там был), поэтому тупо запрещают. А если в ядре Linux поставить запрет на ИИ, значит все эти находки ИИшные пойдут вместо ядра на биржу эксплоитов. Кто от этого выиграет - не совсем ясно. Это в убогой никому не нужной альтернативе фотошопу можно нос морщить и воротить, а людям работу работать надо... Сколько там CVE-шек на девятку было в октябре?
LinkToOS
04.11.2026 15:56А если в ядре Linux поставить запрет на ИИ
Речь шла вовсе не о запрете использования ИИ, а всего-лишь о пометке “Assisted-by”. Эту пометку нужно было ставить если использовались любые средства автоматизации при создании кода, а не только ИИ.
Разработчик, которому отвечал Линус, настаивал чтобы правило с пометкой оставили. Линус ему возразил по существу - в такой пометке нет никакого практического смысла, потому что большинство разработчиков пометку ставить отказываются, и нет способа надежно проверить использовалась ли автоматизация или нет. Так что в результате все остается на совести разработчиков (а ее у них нет). Кроме того, есть другие барьеры чтобы задерживать некачественный код.
Про “ассемблер” было сказано Линусом, чтобы указать разработчику на то что все по сути используют какую-то автоматизацию, уже давно. Только ассемблер является чистым программированием без автоматизации (хотя даже это условно, потому что смещения вычисляются автоматически). По этой логике все должны ставить пометку “Assisted-by”.
JBFW
04.11.2026 15:56Что ж, ещё ничто не существовало вечно.
Постепенно все это будет усложняться до тех пор, пока не превратится в "черный ящик", поддерживать который будут не админы с программистами, а жрецы (те, кто следует заданным ритуалам) и колдуны (те, кто ритуалам не следует, получая интересные эффекты).
А там, глядишь, появится что-то новое, достаточно простое и понятное - и вытеснит...
MaxakCh
04.11.2026 15:56Ну бубен то уже больше 20 лет используется)) Ничего не меняется, только стучать в него быстрее приходится
art3012
04.11.2026 15:56Результат работы ассемблеров и компиляторов детерминирован, в отличие от нейросетей. Линус, очевидно, устал.
shiru8bit
04.11.2026 15:56Так и результат работы конечного кода, сгененерированного нейросетями, после компиляции детерминирован. А человеческий исходный код в процессе создания примерно также недетерменирован, как разные генерации исходного кода для одной задачи.
pilot114
04.11.2026 15:56Линус-то может и устал, но, очевидно, сравнивает нейросети и компиляторы в вопросе эффективности (кстати, не в пользу нейросетей, если вы внимательно причитали статью). Он не сравнивает их с вопросе надёжности.
Мериться детерминизмом нужно в контексте написания исходных кодов, т.е. сравнивать детерминированность преобразования "требования => исходный код". И тут, упс, уже не так всё однозначно.
asdadn
04.11.2026 15:56Мериться детерминизмом нужно в контексте написания исходных кодов, т.е. сравнивать детерминированность преобразования “требования => исходный код”.
Это зависит от того, рассматриваем мы с перспективы менеджера или с перспективы программиста. Обычно когда происходит холивар на тему "может ли LLM заменить программиста", то одни люди интерпретируют этот вопрос как "может ли LLM сделать ненужными навыки программиста", а другие "может ли LLM заменить программиста как исполнителя требований бизнеса". Ответ на первый вопрос - нет, по крайней мере в некоторых кейсах точно не может(из-за неопределённости естественных языков), тогда как второй вопрос пока остаётся открытым. Тем не менее, до недавних пор консенсус состоял в том, что нужно пытаться свести все источники недетерминированности к человеческому фактору(а его минимизировать), но это уже чисто юридический и философский вопрос.
Wesha
04.11.2026 15:56"может ли LLM заменить программиста как исполнителя требований бизнеса".
Может. Но есть нюанс...
tenzink
04.11.2026 15:56Тем не менее, до недавних пор консенсус состоял в том, что нужно пытаться свести все источники недетерминированности к человеческому фактору(а его минимизировать)
И где и когда был такой консенсус?
yurix4
04.11.2026 15:56Результат работы ассемблеров и компиляторов детерминирован, в отличие от нейросетей.
Вроде бы более-менее детерминированный... в пределах одной версии, без изменения флагов компиляции. Но разные флаги генерируют разный код. И уж тем более разные версии компиляторов.
Посмотрите столько статей написано от PVS Studio например. Где-то код, который на первый взгляд кажется правильным, работает нормально, а где-то сбоит. Скомпилировал дебаг-версию - работает, собираешь релиз - ломается. Во многом конечно из-за undefined behavior, но не всегда. Если бы один и тот же код соответствовал всегда одному и тому же бинарнику, то не выходили бы новые версии компиляторов без выхода нового стандарта языка. Да и вообще немало UB на уровне железа. Простейший пример - переполнение знакового. И как уже тут упомянули - разные поколения процессоров обращаются с потоком команд по-разному из-за различий в архитектуре.
Да и не просто так пользуются популярностью такие инструменту как Godbolt, чтобы понять что сгенерирует компилятор определенной версии. И ведь реально код отличается! Но мы же не разбираем asm-вывод компиляторов для вообще всего, ведь это было бы слишком много. Читают asm только там где в этом есть реальная необходимость.
И как раз именно Линус на себе эти проблемы и чувствует. Linux работает на самых разных архитектурах и собирается разными компиляторами. И не переписывают прям все ядро под новые версии. Тем более еще и rust в ядро завезли, компилятор которого меняется активнее чем компиляторы C. Потому в данном вопросе детерминированность не является определяющей, ведь по сути ее и так нет.
То что при том же запросе (и ненулевой температуре) ИИшка даст другой код - это не проблема. Присылают на ревью именно конкретный патч, а не промпт к ИИшке. И этот патч проверяют люди (или - в том числе и люди). И Линус - последний в этой цепи проверок.
Даже если ИИ - стохастический попугай, выдающий дежавю, он может быть полезен так как большинство приемов в программировании совсем не уникально и уже применялось.
Думаю, не стоит сравнивать Linux и продукты где слоп идет в прод практически без ревью. В таких продуктах вероятно и раньше применялся подход "херак-херак -- и в продакшн".
Filipp42
04.11.2026 15:56Я уверен, что сейчас наступает золотое время для Lean 4. Именно благодаря ИИ мы можем рассчитывать на код, в котором почти гарантированно нет багов.
В коде на Lean мы можем прописывать любые спецификации поведения программы, и доказывать их (если не упрёмся в теорему гробовой крышки (она же теорема Райса))
Раньше была проблема, что доказать корректность кода было архи-муторно. Это нужно было делать очень долго вручную. Причём доказательство нужно было переписывать при любом изменении кода.
Теперь доказательство может писать ИИ! И не только доказательство!
Часто разработчики не применяют самые сложные и агрессивные оптимизации потому, что боятся: их код будет содержать баги.Но с Lean достаточно написать спецификацию, и оптимизировать можно как угодно! У нас всё равно будут доказательства корректности кода.
Уже и статья есть по этому поводу:
https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-than-rust/
alan008
04.11.2026 15:56Ох уж эти сказки, ох уж эти сказочники! (с)
Из того, что действительно напрашивается - некий мета язык, на основе которого можно писать спецификации, которые потом гарантированно и детерминированно перекладываются с помощью ИИ либо в конкретный язык высокого уровня (С++ и т.п.) либо сразу в байт-код некой вирт. машины.
Dhwtj
04.11.2026 15:56некий мета язык, на основе которого можно писать спецификации
Rust отлично подойдёт)
Его спецификации это типы и сигнатуры функций (сигнатуры Rust дают отличные гарантии что функция делает и что не делает так что не надо смотреть реализацию)
nin-jin
04.11.2026 15:56Там в сигнатуре прям так и написано мол "кушает не более гигабайта памяти" и "данные берет только с example.org и ни откуда больше"?
Dhwtj
04.11.2026 15:56Ты не поверишь!©
данные берет только с example.org и ни откуда больше"
use url::Url; pub struct ExampleOrgData { // Приватное поле: снаружи напрямую не создать inner: String, } impl ExampleOrgData { // Публичный конструктор проверяет домен pub fn from_source(data: String, source_url: &Url) -> Result<Self, SourceError> { match source_url.domain() { Some("example.org") => Ok(Self { inner: data }), _ => Err(SourceError::InvalidOrigin(source_url.to_string())), } } // Безопасный доступ только для чтения pub fn as_str(&self) -> &str { &self.inner } } #[derive(Debug)] pub enum SourceError { InvalidOrigin(String), }кушает не более гигабайта памяти
Rust обычно использует плоские структуры с известным объемом памяти на элемент. Это в ООП всё сложно.
nin-jin
04.11.2026 15:56Какое отношение ваш валидатор имеет к сигнатурам функций, которые его не используют для запросов?
Какое отношение ваше "обычно", которое даже в сигнатуре не представлено, имеет к гарантиям компилятора?
Что такое сигнатура функции можете уточнить у препода по информатике, если в вашей школе эту тему ещё не проходили.
daniillnull
04.11.2026 15:56Нет, Rust ужасно подойдет. Спасибо его синтасису.
Зато он хорошо подойдет как раз как таргет для генерации кода, ибо чем строже язык, тем ниже вероятность получить слопных ошибок на ровном месте...
thelittlewitch1
04.11.2026 15:56"ИИ" и "детерминированно"
немногосовсем не пересекающиеся понятия, не?
misha_erementchouk
04.11.2026 15:56Как спецификацию-то правильно записать? В известном глуповатом меме спецификация отождествляется с кодом, что само по себе не неправильно, только такой код редко пишется. Большинство кода (и багов) пишется в императивной парадигме, которая в немалом числе случаев является пересвистыванием спецификации.
В свою очередь попытки решить проблему описания точной спецификации нередки. В перемешку первые ассоциации: Prolog, SysML, Alloy, TLA+, Dafny (?).
А есть еще и контекстуальные ошибки, которые существуют внутри конкретных сред и контекстов исполнения. Например, стандартный комментарий к программам, которые пишутся при обучении - не используйте такой-то и такой-то метод на практике. Т.е., с одной стороны, программа доказуемо соответствует "спецификации", а, с другой, на практике получим, скажем, уязвимость.
Непонятно, почему именно Lean будет хорош для решения таких задач.
mbait
04.11.2026 15:56Я просил ИИ, стоит ли нам в проекте переписать критически важные модули на Idris. ИИ ответил, что возможно был бы толк, будь у него столько же тренировочных данных для Idris, сколько было для C++. Подозреваю, что с Lean та же проблема: все как-то резко забыли, что ИИ это всё ещё очень сложный предсказатель следующего слова в цепочке, и успех говнокодинга в большей степени обусловлен мириадам открытых проектов на популярных языках.
Filipp42
04.11.2026 15:56Строго говоря, Lean гораздо популярнее, чем Idris. Причём на него, насколько я знаю, специально учат современные модели. Потому что Lean уже стал очень популярен как средство для формализации математики.
Мне Gemini 3.1 Pro писала большой код на Lean без харнес который компилировался с первого раза.
Может быть, время Lean настанет позже, но я надеюсь, что когда-нибудь Lean станет хорошим выбором для повседневного использования. По крайней мере, я хочу в это верить.
А можете рассказать про ваш проект? Idris там скорее всего вообще не подойдёт. Для него действительно очень мало данных. На счёт Lean я не знаю. Может быть, пока на нём не получится написать большой проект чисто из-за отсутствия библиотек. Но библиотеки пишут!
DmitryR1974
04.11.2026 15:56В том, что ИИ - это инструмент, и инструмент хороший - Торвальдс прав. Чего он не понимает - что у любого инструмента есть ограниченная область применения и правила применения. Поэтому он похож на человека, который предлагает каждому засунуть себе в задницу отвёртку, а несогласных обвиняет в том, что они против отвёрток.
ulisma
04.11.2026 15:56Так это же известный манипулятивный прием. Делается обобщение из другой области, логически утверждения не связаны.
Типа ты не выпил на корпоративе, значит ты ненавидишь коллег. Не кодишь с иишкой - ты против прогресса. Не отрезал себе палец - не патриот и т. п.
gpaw
04.11.2026 15:56в чем-то он прав, где-то и нет. представьте, вы закодили проект. всё выложили для себя - психологически. и - вы его тянете десяток лет, два. это дикое выгорание. как и - то, что идет к этому проекту сайдом. психологически - видение Торвальдса - логично. но по факту… нам нужно новое ядро. посмотрим на Huawei с их подходом с двухкомпонентным решением - с их ArkTS. подумаем про разделение дата-блока и блока приложений, при разделение (может посмотрим на jails FreeBSD)?
P.S. ну и давайте писать новые языки, под современные реалии, в самом деле. я вот пишу, вы тоже можете.
3e961d8a3beb0590404708b0
04.11.2026 15:56ну и давайте писать новые языки, под современные реалии, в самом деле. я вот пишу, вы тоже можете.
Напишите язык на котором хочеться писать самому, несмотря на наличие ЛЛМ)
gpaw
04.11.2026 15:56и пишу потихоньку :) пару лет как на самом деле. почему нет-то? ЛЛМ - не враг, дообучать на локальных моделях можно. или LLVM? так мой IR вполне транслируется…
на самом деле это крутая жвачка для ума. проектирование, когда отталкиваешься от 30 лет опыта программирования, вот “как бы я решил это”. смотришь на решения проброса пейлоада ошибок - следующий шаг за Келли, ориентируюясь на его IO-интерфейсный подход к асинку… ну там круто же, что можно покопать?
Astroscope
04.11.2026 15:56По мнению Торвальдса, ИИ — следующий шаг в цепочке инструментов, которая началась с машинного кода и продолжилась ассемблером и компиляторами.
Рискую набраться минусов, но я с Торвальдсом в этом согласен примерно полностью. Сейчас мы на очередном этапе эволюции отношения человека с его задачами, и компьютера, который эти задачи решает. И действительно, мы начинали с механических тумблеров, прошли через машинный код к ассемблеру, местами задержавшись на нем достаточно долго (изредка по сегодня включительно), шагнули к компиляторам и наплодили их огромное количество, и наконец пришли к сегодняшней парадигме "запрос обычными словами - ответ строками кода". Кто раньше не понимал, как оно работает, не поймет и сегодня. Кто уже понимает или пока только осваивает - тот ничего не теряет от использования более эффективных инструментов, а наоборот извлекает из них пользу, часто очень заметную, понимая и принимая их ограничения. Мне очень хочется по-стариковки поворчать про то, как мы в наше время писали на ассемблере, а то и в машкодах, но это глупо по форме и ошибочно по сути. Что толку от того, что ты застрял в ассемблере, можешь сделать невероятно крутые штуки (это совсем не факт, я вот не могу, но для красного словца допустим), если вся индустрия ушла вперед, вычислительное мощности выросли где в разы, а где на порядки, и твой честно выстраданный код просто не имеет смысла? Главное тут понимать ограничения инструментов, которыми пользуешься, но я вроде уже писал об этом парой фраз ранее.
Flux
04.11.2026 15:56То есть С++ для старика это харам и искушение для неверных, а beamsearch поверх предсказателя следующего токена - омн-ном-ном, какой полезный инструмент!
Совсем кукуха поехала у бедняги.
black_warlock_iv
04.11.2026 15:56Ладно C++. Как насчёт разработки через списки рассылки? Почему-то инструменты чтобы это сделать нормально его не устраивают.
3e961d8a3beb0590404708b0
04.11.2026 15:56Рассылками удобно работать из emacs, всё в текстовом виде - не нужно запускать браузер.
На какие инструменты предлагаете заменить?black_warlock_iv
04.11.2026 15:56На что угодно, лишь бы можно было просто зарегиться и делать мёржреквесты.
feelamee
04.11.2026 15:56списки рассылки это фильтр для людей, которым “лишь бы […] зарегитьсяи делать мёржреквесты”
Flux
04.11.2026 15:56Ага, ведь у ядра так много квалифицированных мейнтейнеров что от новых кандидатов приходится анально огораживаться.
И все эти мейнтейнеры черпают из кода ядра эликсир вечной молодости, делая приток молодых разработчиков просто не нужным.
zgwerby
04.11.2026 15:56В смысле "кукуха"?
Кто Линуса ужинает - то его и танцует. Судя по всему - его очень хорошо отужинали за маркетинговый бюджет (a-la "реклама со звёздами в прайм-тайм") и сейчас он ну очень активно, в канве полученной методички, отрабатывает "бесплатные" подписки, оплату конференций и прямые вливания "на поддержание штанов".
Дед неплохо устроился светить лицом, а ты про "кукуха". С кукушкой у него все в порядке, купоны стрижёт только в путь.
mishkin79
04.11.2026 15:56Моя старая работа по дизайну (лет 18 назад) фотореалистично отрендеренная Гроком (вся геометрия и детали сохранены). Было лень всё это текстурировать, пересобирать и отшлифовывать. А тут бац и аишечка случилась). Может программистам тоже с другой стороны на проблему посмотреть надо?)
asdadn
04.11.2026 15:56Не знаю, мне лень придумывать дизайн. Аишечка всё равно сделает лучше чем кожаный. /s
nin-jin
04.11.2026 15:56Тут, главное, не задаваться вопросом, как кожанные со своим багажом будут попадать внутрь без каких-либо дверей.
Wesha
04.11.2026 15:56Там ещё вопрос, чем они будут дышать, когда туда попадут (с учётом наличия отсутствия форточек на окнах, и каких бы то ни было вентиляционных отверстий на корпусе).
zgwerby
04.11.2026 15:56В полу дырки, естественно. А чтобы залезть - нужно заезжать на эстакаду и полезать червячком через люк в днище
Практичность - ничто, дизаен - всё.
Заодно узнали, что ещё один несостоявшийся Артемий сидит на хабреrandomsimplenumber
04.11.2026 15:56Все в чем я не разбираюсь оно делает идеально (ц). Хотя стопэ, это же чей то дизайн, ИИ его просто отрендерило? Так дизайн ради дизайна и без ИИ давно уже практикуется. Ничего качественно нового - плохого.
k4ir05
04.11.2026 15:56А вас там стойка в левом окне на первой картинке не смущает? На других картинках то её нет. А левое сиденье на последней? А мигрирующий руль?
Может программистам тоже с другой стороны на проблему посмотреть надо?)
Нам в коде таких косяков не надо. На картинках они терпимы, но в коде могут привести к печальным последствиям.
vadimr
04.11.2026 15:56Linux потихоньку разваливается под собственной сложностью. Новую систему явно уже не Торвальдс писать будет. Что старичку остаётся?
Dhwtj
04.11.2026 15:56У Линукс странные (для десктопа) отсутствия гарантии выделения памяти по calloc и злобный oom killer, который убивает даже пользовательские приложения (ужас ужас!).
Может быть, в следующем поколении продумать этот момент? Винда тут приняла более рациональные решения для десктопа
Для следующего поколения десктопной ОС я бы хотел видеть выбираемый контракт: приложение может запросить строгий commit и получить ошибку в точке выделения, а инфраструктурные задачи сохраняют overcommit
BugM
04.11.2026 15:56Линус стал типичным средненьким С-level менеджером. Ему подчиненные пишут разумное предложение, а он отрицает и не хочет его принималь и утверждать. Он очарован LLM.
Любой текст написанный LLM должен быть помечен что он от LLM. Особенно если это текст предназначенный для чтения человеком. Тикет, комментарий, письмо и так далее. Мини правки человеком LLM авторство не отменяют. А вот причесывание человеческого текста через LLM можно не помечать. Все вроде научились что такое причесывание надо еще раз вычитывать и убирать воду, повторы и прочий мусор.
nidalee
04.11.2026 15:56А вот причесывание человеческого текста через LLM можно не помечать.
А как вы будете отличать? Вот я скажу, что только правил - как вы проверите? Или как сейчас будут бесконечные срачи за em-dash и прочие "я чувствую это ИИ, мамой клянусь!"?
mishkin79
04.11.2026 15:56Вот рендер геометрии в браше.
Вот рендер от сеточки с сохранением геометрии (грёбанные заклёпки которые грок постоянно лепит на нос что бы ему не говорили о технологии изготовления этого самолёта и минусы в карму которые к карме не имеют вообще отношения). Сделано за минуту, текстурирование и шейдеры с выставлением света съели бы час минимум. Сеточки - инструмент. Можно проверить идею, или развернуть мысль углубив её за минуты.
У вас минута ушла чтобы не разобравшись влепить минус. Такое...настоящее нейрохрючево )
Wesha
04.11.2026 15:56Мой намётанный инженерный глаз терзают смутные сомненья™, что при текущей посадке двигателей и длине винтов последние будут своими концами рубить фюзеляж...
astroduck
04.11.2026 15:56Странно слышать подобное от того, кто сам еще недавно запрещал ИИ в разработке. Тем более странно предъявлять аргументы уровня сравнения пальца с жопой. Потому что компилятор выполняет детерминированное преобразование одного представления кода в другое, а ИИ выполняет не детерминированное преобразование. Правильную работу компилятора можно гарантировать при условии исправления всех багов, что трудно, но технически достижимо. Правильную работу ИИ в принципе невозможно гарантировать, он может выдавать правильный результат в 999 случаев из 1000, но в одном случае из 1000 может выдать такое, от чего волосы встанут дыбом. Это не значит что ИИ нужно запретить (напротив, это очень интересный и потенциально великолепный инструмент), но его аргументы в его защиту крайне слабы.
zgwerby
04.11.2026 15:56"Пссс, Линус, хочешь раз в месяц получать по тысчонке-другой баксов, не облагаемых налогом и разных материальных и нематериальных бенефитов сверху? Тебе для этого нужно будет всего лишь светить лицом, давать интервью (вот методичка на 900 страниц, но она простая) и раз в месяц выкатывать 'А это сделал робопоп, не скажу сколько промтов, не скажу как, не скажу, сколько сжёг токенов, не скажу с которой попытки и сколько допиливалось человеком, но это все на 100% сделала робоболталка, покупайте Х в подписке МегаУльтраТотал, всего за 399.99$1' в паблик. Медиа мы обеспечим".
1не является публичной офертой
ulisma
04.11.2026 15:56Я люблю эти инструменты. Я нахожу их очень полезными и интересными. Но они точно создают болевые точки.
Мне кажется, что многие неправильно истолковали его слова. Он же по сути сказал, что иишка - это интересный инструмент, который можно где-то использовать. Но он не даст такой прирост производительности в написании кода, как те же компиляторы. А также этот инструмент может создать много проблем при неправильном использовании.
Другими словами, инструмент есть и его можно где-то применять, почему нет? Но в то же время, это не панацея, надо делать проверки и не надо ожидать революции. Так что все ок, вроде. В целом, обычная философия, ничего особенного.
diderevyagin
04.11.2026 15:56Неважно кто кому что говорит - важно кто кому платит.
Кто платит Линусу - тот и музыку заказывает.
Полезный ли ИИ инструмент ? Полезный !
Стоит ли использовать ? Вполне !
Можно ли ему доверять ? Нет. и дело даже не в том, что модель работы LLM такая, что этому доверять попросту нельзя. Моя работа - я за нее отвечаю.
не дошли LLM по уровню прогнозируемости результата до уровня компилятора.
так что посыл тут простой - средний менеджер Линус отрабатывает свое содержание.
net_racoon
04.11.2026 15:56Я же правильно понимаю, что те к кому он этот бред пишет работают за бесплатно? В таком случае, почему они его в /dev/null не пошлют?
ksbes
04.11.2026 15:56У - уважение. В безденежных сообществах главный мотиватор - это авторитет. И за него бъются и нередко - очень ожесточённо.
DarthVictor
04.11.2026 15:56You were the chosen one! It was said that you would destroy the vibecode, not join them! Bring balance to the Engeneering, not leave it in darkness!
usiqwerty
04.11.2026 15:56Люди, которых я уважаю и считаю умными, — не те, кто шарахается от новых и интересных инструментов.
Я люблю эти инструменты. Я нахожу их очень полезными и интересными.
Ох уж эти интересные инструменты
ideological
Возможно что его мнение не релевантно, не так давно он заявил о себе «Я больше не программист»
zgwerby
Все куда как проще и прозаичнее: Линуса (как узнаваемое, популярное и авторитетное в определенных кругах лицо) взяли на содержание с рекламными целями, дав методичку и отсыпав "бесплатных" токенов. Умно. Безжалостно эффективно. Деньги не пахнут. Джорданы рекламируют газировки и дезодоранты, Линус рекламирует модели.
Интереснее даже не это, впрочем, интереснее другое. После прорыва пузыря, когда зафиксируют прибыли и свалят, а подписки взлетят на порядок-два по стоимости - что конкретно он будет делать: сидеть с мордой кирпичом уже не особо прокатит
beeruser
И когда ентот ваш пузырь лопнет? :)
Локальные модели никто не отменял. Через несколько лет победят дефицит памяти и можно будет доступный ПК нафаршировать сотнями ГБ.
DrGluck07
Вот на этом невысказанном предположении...
Wesha
Ну то есть первый китайский звоночек в конце той недели Вы не услышали?
Baronello
Американцы массово проголосовавшие против датацентров под которые уже законтрактованы чипы и чипы уже заложены, и планово уже должны вводиться в работу это тоже неинтересно.
ksbes
А кто их голос слушает и слышит? Не риторический вопрос. Действительно интересно - “отрабатывет” демократия в этом вопросе или нет?
panzerfaust
Мне кажется, 3-4.11 произошла хорошая демонстрация того, что vox populi со счетов сбрасывать не стоит. И есть ощущение, что вольница около-ИИ-бизнеса, которому можно всё с которого всё как с гуся вода, тоже двинулась к своему завершению.
panzerfaust
Не подскажете, дефицит будут побеждать до или после удешевления недвижимости? У меня там где-то рядом запись на получение безусловного базового дохода. Не хочу, чтобы накладка получилась.
nidalee
Со дня на день вот уже второй год, наверное.
inbuckswetrust
Большие пузыри долго надуваются но лопаются всегда :)
ksbes
Долг США растёт уже почти 60 лет как …
dunmaksim
И когда ентот ваш пузырь лопнет? :)
Скоро, брат, скоро...
allishappy
Стоило только Линусу похвалить нейронки, и вот он у же не такой уж и программист. Да и код у него всегда не очень был. Да и вообще не такой уж и сложный проект он ментейнит
CrashLogger
Он уже много лет не пишет код. Сейчас он просто менеджер. И как любой менеджер, он любит ИИ. Ведь ИИ позволяет избавиться от этих назойливых людишек, которым вечно что-то не нравится.