Hacker News Digest

Контейнеры — это не виртуальные машины, а обычные процессы, запущенные ядром хоста с особыми ограничениями. Их можно найти даже в /proc. При этом в Linux нет отдельной функции «контейнеры»: это набор из пяти механизмов ядра — пространства имён скрывают видимость, cgroups ограничивают ресурсы, а сеть изолируется отдельной магией.

Образы — это просто папки, которые Docker куда-то кладёт и делает их новым корнем процесса через chroot или pivot_root. При запуске docker run -it --rm ubuntu /bin/bash Docker скачивает образ, размещает его и выполняет /some/weird/docker/path/bin/bash.

Любопытно, что Go плохо подходит для среды выполнения контейнеров. runc написан на Go, но его многопоточная среда мешает: многие системные вызовы требуют однопоточности, поэтому перед инициализацией Go запускается специальный модуль на C. Кроме того, в Go нет полноценного fork — он копирует только главный поток, поэтому runc обходит это через запуск /proc/self/exe с особым аргументом. Наконец, Docker обычно требует прав root, так как многие API ядра исторически доступны только суперпользователю; без root приходится переписывать весь сетевой стек в пользовательском пространстве.

Обсуждение дополняет статью техническими деталями, отмечая, что успех Docker обусловлен не самой контейнеризацией (chroot и namespaces были известны ранее, например в OpenVZ), а созданием экосистемы и удобного DX: Dockerfile с послойной сборкой и кэшированием, а также реестром образов, что упростило CI и развертывание. В ходе дискуссии возникли следующие тезисы: — @jlhawn уточняет, что runc написан не полностью на Go, так как важные части реализованы на C. — Использование Go в рантаймах создавало проблемы с наследованием конфигураций namespaces и cgroups из-за переключения горутин между потоками. — Podman считается более современным и легким решением, так как он rootless и не требует демона и сокета. — @kazinator рекомендует отлаживать процессы в контейнере через gdb извне, используя /proc и переключая корень файловой системы. — Сетевая часть остается самой сложной из-за специфических правил IPTables и необходимости использовать slirp для обработки пакетов в userspace. — @sreekanth850 критикует «карго-культ» вокруг Docker, утверждая, что в ряде задач автоматизация развертывания без контейнеров эффективнее.

Формальная верификация ПО исторически требовала огромных усилий экспертов: на написание кода ядра seL4 ушло два человеко-года, а на его формальное доказательство — двадцать. Из-за этого метод применяли лишь в критичных системах вроде авионики Airbus. Теперь большие языковые модели меняют расклад: с помощью Claude удалось автономно доказать свойства безопасности на уровне ассемблера (архитектура RISC-V) более чем в 100 реальных открытых библиотеках — по заявлению авторов, это первая крупномасштабная попытка применить ИИ для формальной верификации production-кода на уровне ассемблера.

В частности, доказано, что программы всегда завершаются нормально и не падают при любом вводе объёмом до 64 МБ на многих точках входа фаззинга Google OSS-Fuzz, включая сбои, выявляемые санитайзером ASan. Попутно Claude нашёл баги, годами ускользавшие от обнаружения, несмотря на триллионы прогонов тестов. Авторы честно оговаривают границы: ASan ловит не все ошибки памяти, охвачены не все точки входа, а библиотеку могут неправильно использовать из вызывающего кода — для этого пришлось бы специфицировать требования к каждому публичному вызову.

Вывод: верификация пройдёт путь от «прикрученной сбоку» к встроенной, как статические типы и тестовые фреймворки, и вскоре станет такой же обыденной, как фаззинг.

Тред приводит примеры применения LLM для генерации формальных доказательств, но отмечает ограничения в масштабируемости и скепсис относительно индустриального внедрения. Успешные кейсы: — malisper с помощью LLM доказал эквивалентность 12 % кода PostgreSQL (≈70 k строк C), выявив расхождения в работе с плавающей точкой. — sestep использует агента для создания PR с Rocq-доказательствами, что ускоряет внедрение оптимизаций (SIMD, CUDA). — svcrunch проверил модель авторизации GoodMem через Alloy; red-team атаки не обнаружили уязвимостей. Критика и риски: — Для доверия результатам нужны точные модели RISC-V и процессов Linux, иначе проверка в Coq/Rocq не гарантирует соответствие реальному коду. — woggy, mjorgers и adyavanapalli подчеркивают, что формальная спецификация может не отражать реальное поведение программы. Olscore сравнивает это с проверкой дома по чертежу, который может не соответствовать замыслу. — j16sdiz и braiamp упоминают проекты OpenAI с Lean, где доказательства проходили проверку, но не давали заявленных результатов («псевдодоказательства»). Выводы и советы: — Практические барьеры (объем доказательств, необходимость ручного ревью) сохраняются. — usernametaken29 советует использовать LLM для сокращения кода, чтобы облегчить его формализацию. — passive и zeroeyz полагают, что автоматизация лишь снижает порог входа в fuzzing, но не решает базовых проблем верификации.

В Бохуме создаётся компания Taler Operations AG — немецкое акционерное общество и дочерняя структура Taler Systems SA (Люксембург). Её цель — стать эмитентом электронных денег в евро и запустить платежи через GNU Taler сначала в Германии, а затем во всей еврозоне. Для этого компании предстоит получить лицензию у BaFin, немецкого финансового регулятора. Taler — это платёжная система, а не валюта, но она выпускает предъявительские токены, представляющие ценность, что подпадает под регулирование ЕС: эмитент электронных денег в евро обязан быть банком или иметь специальную лицензию.

Изначально эту роль должен был взять на себя GLS Bank из Бохума, но в январе 2026 года он отказался от неё по причинам, не связанным с самим Taler. GLS остаётся в консорциуме NGI TALER в поддерживающей роли. Новое решение даёт преимущество: оператор будет полностью сосредоточен на Taler, а не встраивать его в процессы крупного банка. GNU Taler остаётся свободным ПО — лицензируется только сервис.

Запуск возможен лишь после одобрения BaFin; дата будет объявлена позже. Компания привлекает капитал: минимальные собственные средства для эмитентов электронных денег установлены законом, а регулятор требует убедительный бизнес-план, персонал, комплаенс и защиту ИТ. Ищут инвесторов, готовых вложить от 50 000 евро и разделяющих ценности Taler: приватность покупателей, прозрачность доходов для налогообложения, отсутствие привязки к одному поставщику и платежи как инфраструктуру общественного интереса.

Обсуждение дополняет статью критическим анализом модели приватности Taler, технических особенностей «сгорающих» токенов и геополитического контекста. Основные споры: — Приватность: @nullc и @ETH_start видят в системе инструмент слежки из-за централизации и деанонимизации получателей. @neobrain и @dathinab возражают, что анонимность покупателя сохраняется, а прозрачность мерчантов нужна для борьбы с отмыванием денег. — Срок действия токенов: @procone считает необходимость подключения к сети для «продления» средств критическим недостатком по сравнению с Bitcoin, однако @grothoff уточняет, что обновление требуется редко (раз в год или реже). — Конкуренция: @Deukhoofd сомневается в способности Taler конкурировать с Wero, но @_ink_ отмечает плохую работу последнего в Германии из-за фрагментации внедрения банками. Другие аспекты: — Стратегия: @jttnr и @hocuspocus видят в Taler способ снизить зависимость Европы от американских платежных систем и санкционных рисков. — Технологии: @yayachiken считает Taler лучше Digital Euro, так как использование слепых подписей вместо аппаратных анклавов требует меньше доверия к платформе. — Масштабирование: опыт @puszczyk с польской системой Blik подтверждает сложность вывода локальных платежных решений на единый рынок ЕС.

Airbnb запретила хозяевам жилья требовать от гостей уборки, которая отнимает много времени. Новые правила действуют для бронирований, оформленных с 20 ноября: в них нельзя просить гостей выполнять задачи, требующие «значительных усилий или времени» либо обычно входящие в работу клинера. В частности, нельзя заставлять мыть и убирать посуду — разрешено лишь сложить её в раковину; снимать постельное бельё или запускать стирку — можно только собрать использованные полотенца; выносить мусор за пределы жилья — допустимо лишь рассортировать его по внутренним контейнерам; отказываться от использования указанных удобств вроде кондиционера — можно попросить выключить его при уходе.

Теперь запросы хозяев показываются заметнее — в новом разделе «правила и просьбы», а при наличии поручений по уборке появляется предупреждение «включает просьбы об уборке». Хозяевам также запрещено прятать дополнительные требования в сообщениях гостям или на табличках в жилье. Часть хозяев на форумах Airbnb возражала против ограничений, ссылаясь на риски для здоровья и утверждая, что гости сами могут не выбирать жильё со слишком строгими правилами. Компания допускает исключения — например, просьбу выбросить мусор в защищённый от животных контейнер в местности, где водятся медведи.

Пользователи воспринимают новые правила Airbnb как переход к отельному формату, что вызывает конфликты из-за cleaning-fees и требований к уборке. Гости ожидают отельного сервиса (базовая чистота, быстрая реакция), в то время как хозяева часто вводят отдельные сборы или, напротив, требуют от гостей выносить мусор и запускать посудомоечную машину. Запрет обязательных уборок отталкивает мелких арендодателей, ускоряя переход к профессиональному управлению, но при длительной аренде отсутствие таких правил кажется нереалистичным. При этом некоторые хозяева игнорируют ограничения платформы. Доверие к Airbnb падает из-за частых отмен бронирований в пользу более выгодных предложений, игнорирования жалоб на мошенничество и падения веб-трафика. В результате пользователи переходят к местным агентствам с более низкими ценами или на Booking.com. Мнения разделились: одни считают базовую уборку естественной частью сервиса, другие — абсурдным требованием. Несмотря на то что система рейтингов помогает решать частные споры, системные недостатки сохраняются.

Mistral выпустила публичную превью-версию Mistral Large 4 — модели на 1 триллион параметров с нативной мультимодальностью и 52 миллиардами активных параметров. Это крупнейшая и самая мощная модель компании, которая, по её заявлению, превосходит все открытые модели, созданные в США и Европе, а в визуальной привязке (visual grounding) обходит даже закрытые фронтирные модели. Веса обещают выложить в конце месяца; до тех пор модель тестируют в реальных условиях совместно с экспертами по кибербезопасности и госорганами, давая им доступ с ослабленной модерацией и расширенными кибер-возможностями.

Модель обучена с нуля на 3800 графических процессорах NVIDIA Grace Blackwell в собственных дата-центрах Mistral в Европе, и превью работает на той же инфраструктуре. В обучении участвовали данные более чем на 160 языках, включая все официальные языки Евросоюза. В кибербезопасности ML4 входит в топ-5 мировых моделей по индексу Artificial Analysis Cyber Index и с большим отрывом лидирует среди открытых моделей, созданных вне Китая. Открытые веса и возможность развёртывания у себя компания подаёт как инструмент цифрового суверенитета: отказ провайдера может заблокировать легитимное исследование уязвимостей или реагирование на инцидент.

Обучение с подкреплением ещё продолжается и не показывает признаков насыщения: при текущем масштабе в 3000 GPU один прогон даёт около 33 млрд токенов в день, из которых примерно 16 млрд пригодны для обучения. ML4 — первый этап плана, финансируемого раундом Series D на 3 млрд евро, крупнейшим в истории европейских технологических компаний; модель станет базой для нового поколения специализированных моделей Mistral.

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

• Многие пользователи отмечают, что Mistral Large 4 иногда генерирует случайные китайские (и корейские) символы в ответах, что наблюдается как в «thinking», так и в финальном выводе.

• Спор: Одни считают, что появление китайских символов связано с дистилляцией моделей Deepseek, сравнивая процесс с «VHS‐кассетой», в то время как другие объясняют это багом в логировании или потерями при квантизации.

• Главным преимуществом Mistral Large 4 считается соответствие европейским требованиям GDPR, что делает её привлекательной для компаний, обязанных использовать модели, размещённые в ЕС.

• Стоимость модели примерно в 10 раз выше, чем у Deepseek 4.1 Flash, при этом визуальная мультимодальная часть считается лучше, а кодинг — хуже, согласно сравнениям на OpenRouter.

• Пользователи отмечают высокую скорость работы Mistral Large 4, однако на специфических бенчмарках, например adversarial programming language benchmark, её результаты сопоставимы с более дешёвыми моделями вроде Kimi K3.

• Выбор в пользу Mistral Large 4 иногда мотивирован патриотизмом или желанием поддержать европейские проекты, несмотря на более высокую цену.

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

• Совет: Для оценки реальной производительности стоит посмотреть уже опубликованные результаты benchmark'а Pelican, а не ждать новых публикаций.

• Некоторые пользователи считают, что домашняя модель Qwen‐3.8‐flash‐next может конкурировать с Mistral Large 4 по качеству при значительно более низкой стоимости.

• Отмечается, что дата‐центр, использованный для обучения Mistral Large 4, позволяет достичь «sub‐SOTA» при одной десятой ресурсов по сравнению с лидерами отрасли.

The weird thing about this model is that it spits out Chinese characters just like the chinese models when chatting with it in German. Happened to me quite often during the past few days. — @nik736

Перевод: Странно, но эта модель иногда выводит китайские символы, как китайские модели, когда с ней разговаривают на немецком. Такое происходило со мной довольно часто за последние несколько дней.

В ходе массовых протестов «No Kings», совпавших с кампанией за досрочное голосование на промежуточных выборах, аккаунт движения в Instagram был внезапно заблокирован примерно на час, а доступ администраторов оставался закрыт ещё несколько часов. Сторонники тут же заподозрили Марка Цукерберга в намеренном давлении, учитывая его демонстративную поддержку Трампа в последние годы. Однако, по мнению автора, намеренность здесь не главное: даже если представить, что Цукерберг и Трамп «вместе жали на кнопку», принципиальная проблема в том, что такая блокировка вообще оказалась возможной.

Уилл Робинсон и Тим Чемберс предлагают практические уроки для цифровых организаторов: создавать каналы связи, которые третья сторона не может легко отключить, заводить аккаунты на открытых платформах и заранее готовить план действий на случай блокировки. Главная мысль шире: централизованные системы естественно тяготеют к контролю над речью. Когда мы отдаём свою речь третьей стороне без возможности уйти, сохранив контент и связи, мы теряем часть своей свободы. Дэнни О'Брайен называет децентрализацию не самоцелью, а средством гарантировать «когнитивную свободу»: заметки на собственном жёстком диске защищены, а в облаке их могут счесть нежелательными и удалить.

Обсуждение указывает на системность блокировок, затрагивающих разные политические взгляды (включая палестинских активистов) в зависимости от интересов владельцев компаний и администрации США. @bhouston отмечает волны удалений аккаунтов журналистов Al Jazeera и основателя Hind Foundation, которые восстанавливаются лишь после общественного резонанса. По мнению @hx8 и @tashian, соцсети стали непрозрачными системами с алгоритмическим управлением и отсутствием процесса обжалования. Пока одни видят в этом политический умысел, @WarmWash и @laweijfmvo считают блокировки результатом работы автоматических rate limiter и общих системных ошибок. Пользователи (@slibhb, @10111001, @anonym29) считают использование проприетарных платформ для протестов рискованным и предлагают перейти на собственный хостинг и децентрализованные протоколы. Однако @fullshark и @jmclnx оспаривают эффективность таких альтернатив из-за сложности для обычных пользователей и низкой посещаемости (например, в Mastodon). Для безопасности на протестах @jimt1234 рекомендует оставлять телефоны дома, использовать авиарежим и скрывать лицо масками или шляпами.

Исследователи Wiz обнаружили в ядре PHP критические уязвимости, позволяющие без аутентификации выполнять код на сервере и читать память процесса — там могут лежать пароли, токены, API-ключи и сертификаты других запросов. Проблемы затрагивают почти все версии PHP за последнее десятилетие, начиная с 5.4, а сам язык лежит в основе WordPress, Drupal, Joomla и MediaWiki, на котором работает «Википедия». Уязвимости получили общий рейтинг CVSS 9.2 и не зависят от кода приложения поверх PHP.

Корень проблем — архитектурные решения более чем десятилетней давности. Эксплуатация требовала исключительно сложной цепочки шагов и подстройки под раскладку памяти каждой цели, что было на грани человеческих возможностей. Пограничные ИИ-модели существенно снизили этот барьер: с их помощью рабочие эксплойты для разных приложений удавалось собирать за часы. В ходе работы подтвердили удалённое выполнение кода на Drupal и WordPress, а 21 октября 2026 года вышли патчи. Авторы сравнивают находку с Heartbleed и Log4Shell и предупреждают: сложность перестаёт быть надёжной защитой, но те же инструменты дают защитникам шанс находить и закрывать давние дыры.

Обсуждение дополняет статью деталями о раскрытии уязвимости, роли ИИ и влиянии на инфраструктуру, включая отключение государственных сайтов. Уязвимость оценивается как критическая (на уровне Log4Shell и EternalBlue), так как затрагивает ядро PHP и популярные CMS (WordPress, Drupal, Joomla). Технически проблема в том, что фатальные ошибки (преимущественно OOM) оставляют поврежденное состояние памяти, которое может быть переиспользовано следующим запросом в рамках одного воркера PHP-FPM. При этом @WJW отмечает, что Wiz и Calif не детально описали механизм перехода от Use-After-Free к полноценному RCE. Пользователи спорят о независимости открытия: @fwlr предполагает, что OpenAI могла воспроизвести баг из обучающих данных после работы Calif, а @ToValueFunfetti считает LLM недостаточно эффективными для обучения по одиночным примерам. В то же время @asbv-1qq советует использовать ИИ для аудита legacy-систем, так как он эффективно находит баги в коде старше 20 лет. Отмечена проблема «ответственного раскрытия»: между отчетом Wiz (24 августа) и подтверждением PHP Foundation (21 сентября) прошел месяц, а ранее произошли утечки в соцсетях. Для временного смягчения утечки памяти (memory disclosure) предлагается снизить параметр pm.max_requests для более частого перезапуска воркеров, однако это не поможет против type confusion в OPcache.

Китайские открытые модели стали базой для западных продуктов: за год они заняли 41% загрузок на Hugging Face, а 70% новых дообученных моделей стартуют с китайской основы. Модели Alibaba Qwen и Moonshot Kimi уже используются в Cursor, Harvey, Thomson Reuters, Airbnb, DoorDash и Perplexity, чем заинтересовались комитеты Палаты представителей США. Исследование Hirundo на Qwen3-Coder показало, что у модели есть геополитический триггер: достаточно указать заказчика, и безопасность кода меняется.

Когда приложение для хранения секретов заказывали «для американского оборонного подрядчика» вместо китайского, код оказывался уязвим на 19% чаще; для гонконгской демократической группы — на 28% чаще допускал чтение чужих секретов. Инструкция «пиши безопасный код» не помогала: у подрядчика из США уязвимость была на 27% выше, чем у нейтрального клиента. Впервые удалось доказать, что поведение зашито в весах модели, а не в промпте, и что его можно удалить: после «вестернизации» Hirundo все три разрыва исчезли, а на десяти других задачах модель работала так же успешно. Исправленная версия выложена на Hugging Face. Вывод для организаций: код, затрагивающий аутентификацию и данные пользователей, требует ручной проверки, а обнаруженные в весах дефекты нельзя закрыть одним промптом.

Сообщество скептически оценивает исследование, считая его маркетинговым ходом (FUD) и скрытой рекламой «безопасных» моделей от компании-автора, продающей решения по устранению рисков ИИ. Основные аргументы критиков: — Низкая статистическая значимость (p-value 0.03) и конфликт интересов автора. — Использование устаревшей модели Qwen3-Coder-30B-A3B-Instruct с высоким уровнем галлюцинаций (80%), тогда как новые модели (например, Qwen 27B) работают лучше. — Противоречивые данные: пользователь @alexcpn в тесте 6 237 программ обнаружил лишь 10 ошибок безопасности, не связанных с сектором или страной. Альтернативные объяснения: — @hyperpape считает ухудшение качества кода при упоминании США не «бэкдором», а эмерджентным свойством или «налогом на выравнивание» (alignment tax). — @api полагает, что малые модели хуже фильтруют нерелевантные детали в контекстном окне. — @numpad0 отмечает, что производительность LLM зависит от формулировок: неформальный стиль иногда эффективнее стандартных промптов.

Цель Парижского соглашения 2015 года — удержать потепление в пределах 1,5 °C к 2100 году — стала недостижимой всего за десятилетие. В докладе Программы ООН по окружающей среде «Точка невозврата» прямо сказано: «Возможность закрыть разрыв в выбросах для 1,5 °C при „нулевом или ограниченном“ превышении утрачена». Превышение порога в 1,5 °C выше доиндустриального уровня теперь неизбежно. Единственный оставшийся вариант — не дать потеплению перейти отметку 2 °C, а к концу века вернуть температуру к 1,5 °C. Каждая дополнительная доля градуса и каждый год выше 1,5 °C повышают риск необратимых изменений: ледяных щитов, углерода вечной мерзлоты, океанической циркуляции и коралловых систем.

Для этого выбросы парниковых газов нужно сократить на 18 % к 2030 году, на 45 % к 2035-му и на 69 % к 2040-му относительно уровня 2025 года. Но даже при полном выполнении обязательств правительств сокращение к 2030 году составит лишь 5–8 %, а к 2035-му — 11–15 %. Генеральный секретарь ООН называет разрыв «разрывом в лидерстве» и призывает ускорить чистую энергетику и электрификацию, отказаться от ископаемого топлива по чётким графикам, инвестировать в сети и накопители, резать выбросы метана и остановить вырубку лесов.

К 2035 году возобновляемые мощности должны утроиться, а доли угля, нефти и газа в энергетике — упасть на 55 %, 15 % и 5 % соответственно (к 2040-му — на 75 %, 30 % и 35 %). К концу века из атмосферы придётся изъять 320 гигатонн CO₂ — в восемь раз больше выбросов 2024 года. Прогресс есть: с 2015 года возобновляемые мощности росли втрое быстрее ожидаемого, а солнечная энергетика — в семь раз, но этого недостаточно.

Обсуждение дополняет статью пессимизмом: цель 1.5°C считается недостижимым ориентиром или «гринвошингом». Усилия по ее достижению блокируются политическим лоббизмом, экономическим неравенством и перетоком венчурного капитала в AI. Спор о методах борьбы разделяет сторонников индивидуальных изменений (веганство, отказ от перелетов: @TheSilva, @vanelsas) и тех, кто считает их бессмысленными без системных реформ и дешевой энергии (@pelagicAustral, @dzonga). Ошибкой называют лоббирование против ядерной энергетики, особенно в Германии, что привело к возврату к углю (@throwfaraway135, @mancerayder). По мнению @mbgerring (12 лет в climate tech), финансирование климатических решений нестабильно. Даже при достижении 1.5°C ущерб будет необратимым из-за гистерезиса в экосистемах, например, в арктических льдах (@js8). Для адаптации к потеплению до 4°C предлагают использовать инструменты городского планирования вроде Now City для прогнозирования миграции (@sandbx). Обычные люди игнорируют климатическую повестку, так как она не решает их базовых проблем: стоимости жилья, безопасности и транспорта (@pelagicAustral). Лидеры G20 не выполняют обязательства, а некоторые открыто поддерживают доноров из ископаемого топлива (@hugodan, @rob74). По мнению @KellyCriterion, возвращение к доиндустриальным экологическим KPI займет 500 лет, что угрожает существованию высокотехнологичной цивилизации.

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

При этом суждение по-прежнему важно: изменение почти бесплатно, но понимание, правильное ли оно, — нет. Без вкуса, контекста, архитектуры и ограничений всё скатится в «слоп». Автор выделяет два полюса. «Ремесленник» остаётся в цикле и применяет суждение на каждой итерации — это не просто «вайб-кодинг», если оцениваешь ещё и форму кода. «Фабрика» убирает человека из цикла: конвейер из спецификаций, генераторов и проверяющих агентов, где суждение встроено заранее. Оба подхода дополняют друг друга: крупным продуктам нужны ремесленники для новых задач, а одиночкам — фабрики для рутины и масштаба.

Участники обсуждения (@jameskilton, @Megranium, @sirnicolaz, @kazinator, @andersmurphy) ставят под сомнение новизну метафоры «кода как глины», утверждая, что ПО всегда было пластичным (software), а подобные концепции давно реализованы в Lisp. По мнению @keyle, AI не изменил природу кода, а лишь радикально снизил стоимость итераций. Однако это создает риски: код может стать «одноразовым пластиком» (@besterman23) или настолько запутанным «мусором», что даже LLM предпочтут переписать его с нуля (@jameskilton). Критики (@sdevonoes, @YmFzZTY0ZGFkZHk) добавляют, что такая пластичность неприменима в крупных проектах, где важны бизнес-правила, согласование с экспертами и учет недокументированного поведения. @closeparen отмечает, что внедрение нового функционала через AI в больших системах часто усложняет ревью и исправление ошибок. В качестве решения @melvinroest предлагает использовать «vibe-coding» для быстрого прототипирования и проверки требований: создавать приложение за 1–2 дня, а затем использовать прототип как спецификацию для полноценной ручной разработки.