Быть Linux Торвальдсом

Пост antirez за июль 2026 года на https://antirez.com/news/171, адаптированный из расшифровки его видео на YouTube. В заголовке написано "Linux Torvalds" вместо Linus - это собственная оговорка автора, перекочевавшая из устной речи.

Написание ядра не было чем-то редким

Вводный тезис намеренно сбивает пафос. Когда Торвальдс писал первое ядро Linux, он читал исходники Minix, понимал архитектуру компьютеров и определённо был блестящим программистом, однако написать минимально рабочее ядро Unix для 386 - на старте под одну архитектуру - было по силам многим. antirez оценивает это примерно как одного на тысячу или десять тысяч: далеко не большинство программистов, но всё же немало. В доказательство он приводит ленту Hacker News за последние несколько лет, полную ядер на C, микроядер с нуля, ядер на Rust, компактных вертикальных Unix-систем для Raspberry Pi и операционных систем для ESP32. Большинство авторов сделали бы это хуже Торвальдса. Но сам по себе этот подвиг всё равно не объясняет, почему Торвальдс такой один.

Он перестал писать код

Редким оказалось то, что произошло дальше. На очень раннем этапе истории Linux Торвальдс почти полностью перестал писать код, чтобы руководить проектом: стать координатором и тем единственным умом, который чётко удерживает в фокусе цели проекта. antirez отмечает, что большинство maintainer'ов известных open-source проектов так не делают, и причисляет к ним самого себя на протяжении долгого времени.

При этом он подчёркивает, что и противоположный подход не был ошибкой. Всё зависит от природы самого программного обеспечения. Ядро, которое стремится поддерживать множество устройств, платформ и подсистем, а также постоянно адаптироваться к новому железу и новым требованиям софта, неизбежно перерастает возможности одного исполнителя. Redis мог оставаться компактным и самодостаточным, поэтому antirez мог не выпускать код из рук - мысль, которая звучит иначе в свете разрастания возможностей, описанного в redis-cost-of-ambition. Другой его пример - D. Richard Hipp, недавно приславший ему pull request в linenoise: Hipp тоже стремился к стабильности, минимализму и производительности, сохранял кодовую базу SQLite очень небольшой и продолжал писать код очень долго. Небольшие устойчивые проекты это позволяют. Linux - нет.

Что же тогда делает Торвальдс вместо этого? Вовсе не построчный review каждого патча. Он глубоко погружается в конкретную реализацию, только когда нужно разобраться в происходящем, и изредка сам писал или переписывал подсистемы с нуля - antirez вспоминает стек USB много лет назад и виртуальную файловую систему, где перерабатывалась структура inode'ов и кэш inode. Он написал Git. Но в основном он общается с maintainer'ами подсистем и решает, стоит ли вообще браться за ту или иную функциональность или двигаться в выбранном направлении. Выражаясь языком Брукса из The Mythical Man-Month, он удерживает концепции дизайна и сохраняет их целостность через диалог со всеми, кто находится ниже него в иерархии, причём сразу по двум осям: как именно реализовано решение и какого качества код, а отдельно - чего проект хочет и чего не хочет от планировщика, модульной системы, поддержки железа или интеграции Rust. Именно такое сочетание - блестящий программист, maintainer, дизайнер и человек, способный сохранять целостность структуры огромного проекта в общении с множеством людей, - antirez и называет настоящим гением.

Перенос роли

Поворот во второй половине текста заключается в том, что программирование с LLM сажает вас ровно на то же место. Вы не проверяете каждую строчку; вы удерживаете идеи и задаёте направление. По мнению antirez, в таком виде эта работа проще, чем у Торвальдса, по крайней мере пока не запущено много параллельных агентов: меньше участников для координации, и вместо большой команды, движущейся с человеческой скоростью, перед вами эквивалент одного-трёх помощников (по одному на каждую активную ветку), мгновенно дающих обратную связь. Меньше переключения контекста и никакого трения из-за человеческих характеров. (Случай с параллельными агентами - как раз то место, где всё перестаёт быть простым; этот тезис log-distributed-llms доказывает на уровне теорем о невозможности.)

Исходя из этого, он отмежёвывается от термина vibe coding как описания того, чем является автоматическое программирование. Он не относится к нему пренебрежительно: для людей без технических навыков, желающих создавать собственные инструменты, это действительно путь к демократизации разработки, и он им только рад. Но суть не в этом. В руках опытного программиста, дизайнера или архитектора автоматическое программирование означает принятие роли Торвальдса, тогда как агенты выступают в роли maintainer'ов подсистем. А это требует понимания того, за какие реализации браться, а за какие нет, и умения формулировать архитектурные ориентиры, которые хороший программист продумывает заранее. Это навык, которому нужно учиться, - тот же переход, который Торвальдс совершил от самостоятельной реализации всего подряд к дирижированию. Заключительный вывод носит полемический характер: это ответ тем, кто утверждает, будто LLM делают программирование простым для каждого.

Это тот же тезис, что и в control-the-ideas-not-the-code, только подкреплённый биографией, а не инструкцией. Он также полемизирует с cult-of-vibe-coding, но с другой стороны: Брэм Коэн упрекает отказ читать сгенерированный код в догматизме, тогда как antirez утверждает, что отказ от вычитывания каждой строчки - это именно то, как руководство крупным проектом выглядело всегда. Расхождение здесь уже, чем кажется: оба требуют, чтобы кто-то удерживал архитектурный замысел, и спорят лишь о том, какую долю созданного артефакта этот человек должен прочесть, чтобы продолжать его удерживать. Преемственность идей Брукса, лежащая в основе всей этой дискуссии, прослеживается в no-silver-bullet-llms.