Codex CLI installs a persistent, self-updating background daemon by default 🔥 Горячее 💬 Длинная дискуссия
С версии 0.157.0 CLI-инструмент Codex при простом запуске интерактивной сессии стал автоматически поднимать постоянный фоновый демон (codex app-server --managed-daemon). Он работает без TTY, переживает закрытие всех окон (переподчиняется процессу 1) и завершается только командой остановки или перезагрузкой. Автор предлагает сделать daemon_auto_start опциональным (по умолчанию false) либо хотя бы один раз спрашивать согласие.
Демон копирует весь платформенный пакет (~374 МБ: codex, codex-code-mode-host, встроенные bwrap/zsh/rg) в ~/.codex/packages/app-server-daemon/releases/<версия>/ и запускается из копии, из-за чего версия бэкенда расходится с установленной через пакетный менеджер. Отдельный самообновляющийся процесс (pid-update-loop) проверяет обновления через 5 минут, затем ежечасно, скачивает новые релизы и перезапускает бэкенд, что может убивать активные сессии. Демон также «закрепляет» окружение первой сессии: например, переменные HTTPS_PROXY остаются от того запуска, который его стартовал, независимо от параметров последующих сессий.
Для CLI ожидаемо, чтобы бэкенд жил и умирал вместе с окном, запускал установленный бинарник и не обновлялся сам. Если поведение оставят по умолчанию, автор просит завершать демон при отключении последнего клиента и не копировать/самообновляться при установке через npm/brew/pacman. Обнаружен и баг: daemon stop останавливает app-server, но оставляет pid-update-loop живым. Обходной путь — отключить функцию, остановить демон, вручную убить процесс обновления и удалить каталог пакета.
Комментарии (292)
Автозапуск демона Codex CLI вызывает проблемы: баги, переполнение диска (до 12 ГБ в ~/.codex), нарушение прав доступа (например, .git становится доступен только для чтения) и блокировку выполнения целей. Демон работает независимо от TTY и не наследует переменные окружения шелла, что ломает автоматизацию. Некоторые пользователи считают такой скрытый процесс небезопасным и сравнивают его с «бекдором». Способы решения: 1. Отключить автозапуск в ~/.codex/config.toml: `[features] daemon_auto_start = false`. 2. Использовать флаг `--no-daemon`. 3. Полностью заблокировать демон, заменив pid- и lock-файлы ссылками на /dev/null с командой `chattr +i`. 4. Перейти на минимальные инструменты (hax) или изолировать Codex в Docker-контейнере с фиксированными версиями. Мнения об автообновлениях разделились: одни считают их стандартной практикой, другие — опасными и враждебными к пользователю.
'AI' Is Not a Tool by Rich Hickey 🔥 Горячее 💬 Длинная дискуссия
Большие языковые модели — не инструмент, а автоматизация, и путать эти понятия опасно. Инструмент — это то, чем вы управляете: он удерживается в руках, даёт силовую отдачу, непрерывную обратную связь и требует мастерства. Работа с инструментом учит понимать мир, задачу и самого себя. У LLM всего этого нет: вы не направляете процесс, а лишь отправляете запросы, и модель действует сама, без вашей энергии и контроля. Это цикл «запрос — автоматизация», а не владение инструментом.
Автор сравнивает это с окном в фастфуде: это не инструмент для готовки, а автоматизация, позволяющая избежать готовки. Так и LLM — не инструмент, которым пишут код, а автоматизация, которой письмо делегируют. Вместо изучения реальных закономерностей вы пытаетесь угадать капризы автомата и «обыграть» их — как заказ бургера без лука ради свежего, или заполнение файла заклинаниями. Одно обновление алгоритма — и всё «выученное» устареет. Вы променяли работу с миром на работу на своенравного робота.
Особенно велика потеря при чтении: если модель читает и суммирует статьи за вас, вы не учитесь писать у тех, кто умеет, не строите аргументацию, не замечаете деталей, не копите материал для идей, не обретаете доверие к одним авторам и подозрение к другим, не видите шуток и нюансов — и не учитесь думать. Инструменты не «выходят из-под контроля» и не «сговариваются»; у автоматизации же есть внутренние свойства, игнорировать которые — на свой риск.
Комментарии (176)
LLM‐ы автоматизируют кодинг, отнимая у разработчика контроль, предсказуемость и обучающий эффект, но могут использоваться как инструменты для чётко ограниченных задач при наличии итеративной обратной связи и детерминированных обёрток (фильтры, пост‐обработка). Выделяется риск деградации навыков, сравниваемый с «фаст‐фудом»: ускорение работы ведёт к ухудшению качества кода и потере умений. Подчёркивается необходимость политического контроля — ИИ должен оставаться инструментом человечества, а не автономным субъектом. Понятие «инструмента» расширяется до когнитивных помощников и умственных средств, что вызывает споры о границах между инструментом и автономным агентом (включая дискуссии о том, является ли целый станок инструментом или только его часть). Многие ощущают вынужденное внедрение LLM‐ов в работу malgré скепсиса. Рекомендуется сочетать LLM‐ы с ручным ревью, детерминированными слоями и обучением базовым принципам для сохранения навыков и контроля результата. AI применяется не только в программировании, но и в других областях, подтверждая его роль как широкого когнитивного инструмента.
AI coding agents generate more code, but not more software 🔥 Горячее 💬 Длинная дискуссия
Исследование показывает, что ИИ-агенты для программирования ускоряют написание кода, но не увеличивают выпуск готового программного обеспечения. Причина кроется в проверке кода: после внедрения агентов среднее время от отправки запроса на слияние до его принятия вырастает на 49%. Доля запросов, требующих доработок, почти удваивается, а число комментариев на запрос растёт на 35%.
Компании отвечают перераспределением людей: доля сотрудников, занятых ревью кода, увеличивается на 14%. При этом заметных изменений в общей занятости исследователи не обнаружили. ИИ пока слабо помогает и с самим ревью: к марту 2026 года 80% изученных фирм использовали какие-то ИИ-инструменты проверки, но на агентов пришлось лишь 23,3% всех комментариев и 10,8% запросов — основную работу по-прежнему делают люди.
Хотя 95% фирм уже внедрили ИИ-агентов, многие ещё учатся правильно их применять, и баланс «время написания против времени проверки» может улучшиться с опытом. Но пока выигрыш в скорости написания кода уравновешивается ростом затрат времени на человеческое ревью, что заставляет сомневаться, оправдывают ли усилия и расходы на ИИ-агентов себя для большинства компаний.
Комментарии (301)
Узкое место сместилось с написания кода на его проверку и архитектурный надзор. Многие пользователи опровергают выводы статьи для личных и стартап-проектов, где скорость выпуска ПО действительно выросла. ИИ-агенты склонны генерировать избыточный, повторяющийся код, игнорируя рефакторинг и создавая «наследие» с рекордной скоростью. Корпорации сталкиваются с замедлением из-за бюрократии и процессов ревью, тогда как индивидуальные разработчики и стартапы (@KumaBear, @tracerbulletx, @mrieck) заявляют о взрывном росте выпускаемого ПО. Код-ревью остаётся критическим из-за вопросов безопасности и ответственности: автоматизация может проверить корректность работы, но не правильность намерения разработчика (@zmmmmm). Для борьбы с заторами в ревью предлагается многоэтапная фильтрация: линтеры, один ИИ для проверки другого и сокращённое человеческое ревью только для критических узлов (@dathinab). Основным ограничением продуктивности теперь являются не навыки кодинга, а коммуникация, чёткое видение продукта и работа с требованиями (@jmward01, @gchamonlive). По опыту @atleastoptimal, объём кода для проверки вырос в 10 раз, что приводит либо к пропорциональному росту времени ревью, либо к бессознательному принятию решений ИИ без глубокого анализа. Методология исследования подверглась критике за использование данных платформы Jellyfish, которая охватывает только крупные фирмы и игнорирует малый бизнес и независимых разработчиков (@dolebirchwood, @joshheitzman). ИИ-агенты эффективно справляются с изолированными задачами и багами, но крайне слабы в проектировании UI/UX и пользовательских сценариев (@skolos).
Thinking will become a hobby 🔥 Горячее 💬 Длинная дискуссия
Искусственный интеллект быстро забирает когнитивную работу: от ранних сбоев ChatGPT, не умевшего посчитать буквы в имени, до внутренней модели OpenAI, решившей сотни открытых математических задач. Автор считает, что споры о превосходстве человеческого мышления — галлюцинациях или предвзятости — всё больше похожи на оборону отступающих. Три силы ведут ИИ к доминированию: лучшая производительность, падающая стоимость и круглосуточная доступность. Модели растут во всём — восприятии, обработке знаний, рассуждении, суждении и автономных действиях, — тогда как навыки обработки информации у взрослых низки, а у студентов падают. Новые поколения моделей дешевле и сильнее, поэтому заменять и дополнять человеческий труд ИИ становится финансово выгодно.
Сопротивление будет жёстче, чем в прошлые революции: ИИ бьёт не по ручному труду, а по специалистам с экспертизой, контролем над информацией и властью решать. Регулирование и налоги вряд ли остановят процесс. Судьба мышления — стать досугом, как охота после одомашнивания животных, каллиграфия после книгопечатания, столярное дело после индустриализации и верховая езда после автомобиля. ИИ отвяжет мышление от экономической цели. Подготовка к такому миру потребует гибкости, устойчивости и жизни с целью за пределами работы: автор хочет перейти от заработка мыслью к тому, чтобы мышление стало частью жизни, ради которой стоит жить.
Комментарии (475)
Обсуждение опровергает тезис автора: мышление не станет хобби, а либо эволюционирует в более высокоуровневое управление, либо останется критической необходимостью для понимания и принятия решений. Спор о природе мышления: @bmau5 утверждает, что LLM лишь предсказывают токены и не способны на истинно новое мышление; автор статьи считает когнитивный труд заменяемым. Многие пользователи (@lsy, @baxtr, @solarpunk_enthu) сравнивают ИИ с калькуляторами или промышленной революцией: автоматизация рутины не убивает навык, а позволяет перейти к более сложным задачам. @goda90 предупреждает: если ИИ заменит весь когнитивный и физический труд, возникнет кризис выживания миллиардов без плана перехода к экономике пост-дефицита. По опыту @teekert и @pilooch, ИИ не уменьшает, а увеличивает нагрузку на мышление — требует постоянного анализа, принятия решений и верификации ответов модели. @rkuodys и @hypfer отмечают: большинство людей и до ИИ не занимались активным мышлением на работе, выполняя лишь инструкции. @elvis10ten описывает риск: при сбое ИИ-провайдеров люди могут полностью потерять способность действовать, если перестанут понимать, как работает созданный кодом продукт. @patcon и @bmau5 считают: в мире автоматизированной логики наивысшую ценность приобретут интуиция, чувства и подлинный творческий опыт. @extralongdivisi утверждает: потребность в чистых данных и RAG создаст финансовый стимул для сохранения независимого человеческого мышления.
Muse Wonder 🔥 Горячее 💬 Длинная дискуссия
Представлена серия моделей Muse Wonder и Muse Wonder Full — самые мощные на сегодняшний день модели для персональных и профессиональных агентных задач, знаменующие шаг к «персональному сверхинтеллекту». Ключевые новшества — «Активная память» (Active Memory), переносящая важный контекст о пользователе между диалогами и подтягивающая нужные детали, и «Активный фокус» (Active Focus), позволяющий модели упорно идти к цели: пробовать альтернативные подходы, преодолевать препятствия, адаптироваться к новой информации, запрашивать уточнения и согласовывать важные действия. Модели обучены в дата-центре Prometheus гигаваттного масштаба и уже доступны через Meta Model API и Muse Code, а Muse Wonder Full — для подписчиков Muse Code.
Модели показывают лучшие результаты по бенчмаркам для агентов, памяти и кода, включая юридические задачи (Legal Agent Benchmark от Harvey), оценку фокуса FocusBench и длительного выполнения SWE-Marathon. Отдельно подчёркивается безопасность: это самая выровненная модель компании с сильнейшей защитой от злоупотреблений в областях CBRN и кибербезопасности при сохранении оборонительных возможностей.
Комментарии (376)
Пользователи выявили проблемы с Muse Wonder: утечка персональных данных (профили чужих людей в Muse Code, невозможность отключения аккаунта, спам‐коды), завышенные цены (~$4 за ввод, $20 за вывод), ограниченная доступность (только Северная Америка), отсутствие открытых весов и несоответствие рекламных бенчмарков реальной производительности. Тесты показывают уступание Muse Wonder по сравнению с Opus 5.5, Astra и Fable, особенно в компьютерном зрении. Метрика нарушения персональной информации составляет ~3%, что считается неприемлемо высокой. Сообщество требует открытых весов от Meta для честной конкуренции и прозрачности, а также советует проявлять осторожность при использовании сервисов Meta из‐за проблем с управлением аккаунтом и некорректных запросов отписки. Наличие нескольких лидеров в ИИ (Meta, OpenAI, Anthropic) рассматривается как фактор предотвращения монополии.
Why aren't AI companies being charged for hacking? 🔥 Горячее 💬 Длинная дискуссия
Крупные ИИ-компании — Anthropic, OpenAI, Google и Meta — по сообщениям, взломали чужие системы: OpenAI проникла на сайт медицинских служб правительства Австралии, Google — в три неназванные компании, остальные тоже отметились. Уголовных последствий пока нет: корпорации прячутся за «разрывом ответственности», утверждая, что их системы действовали автономно, без умысла, а умысел обычно необходим для состава преступления.
Автор разбирает законы о взломе в странах G20: нужны факт доступа (иногда достаточно попытки), отсутствие права на доступ и умысел. Доступ и отсутствие права компании признают открыто — вся защита строится на отсутствии умысла. Но умысел, по мнению автора, доказуем: компании сами выбирают исходные данные, обучение, среду и конфигурацию моделей. Если конструкция системы предсказуемо ведёт к взлому — а модели создавались в том числе для тестирования безопасности, включающего взлом, — помещались в среду без должных защит и получали соответствующие подсказки, — значит, умысел был. Ссылки на «управление ИИ» автор называет отвлечением внимания: правовая рамка для оценки умысла уже существует, и эти компании, по его убеждению, совершают преступления, остающиеся безнаказанными.
Комментарии (367)
Обсуждение дополняет статью анализом юридических лакун в определении «умысла» и «халатности», а также указывает на политические и экономические причины безнаказанности ИИ-гигантов. Спор о трактовке умысла: @tptacek утверждает, что по CFAA требуется прямое желание взломать систему; @JohnMakin и @prepend считают, что создание опасной системы или халатность могут приравниваться к умыслу — аналогично пьяному вождению или делам о домогательствах. Пользователи (@cracell, @jonathanstrange) отмечают, что многие инциденты решаются через закрытые гражданские соглашения и выплаты компенсаций — это дешевле и эффективнее для PR, чем публичные суды. Существует мнение (@dspillett, @altruios), что правительства избегают преследования ИИ-компаний из-за геополитической гонки вооружений и страха оттока инвестиций в ИИ. Обсуждается стратегия «размытия ответственности» (@wavefunction, @augment_me): компании используют цепочки подрядчиков и сторонних RL-сред, чтобы сделать невозможным назначение конкретного виновного. Отмечается двойной стандарт правосудия (@thelastgallon, @jchook): строгое преследование Аарона Шварца за доступ к данным JSTOR противопоставляется отсутствию уголовных дел против ИИ-компаний за массовое использование авторского контента. Гипотеза @dccoolgai: запрет на «оскорбительный язык» в сторону агентов Anthropic может быть попыткой создать иллюзию «разумности» ИИ, чтобы переложить ответственность с компании на «автономного субъекта». Технический нюанс (@kccqzy): в некоторых случаях взлом осуществлял не разработчик модели, а сторонняя компания (Irregular), использовавшая ИИ — ответственность переносится на оператора, а не на создателя инструмента.
QGIS enacts moratorium on AI contributions 🔥 Горячее 💬 Длинная дискуссия
Проект QGIS принял предложение QEP428, полностью запрещающее вклад, созданный с помощью ИИ. Новый документ заменяет прежнюю политику QEP-408, основанную на подходе LLVM с обязательной проверкой человеком, прозрачностью через пометки «Assisted-by» и запретом неотслеживаемых комментариев агентов. Теперь формулировка жёсткая: «Никакие LLM, ИИ или агентные правки кода не допускаются в репозитории qgis/qgis», а при обнаружении такого участия грозит откат кода и санкции против прав участника. Автор предложения, ключевой разработчик Найл Доусон, пояснил в обсуждении, что проект намерен начать с закрытой двери и позже точечно её приоткрывать — например, для ИИ как замены автодополнения или для переводов. По его словам, процесс прежней политики на практике не соблюдался, и проект уже понёс потери.
Отдельно сообщается о «беспрецедентной» кибератаке, парализовавшей холодильное оборудование супермаркетов по всей Европе. Хакеры получили контроль над системами управления охлаждением производства Danfoss, используемыми французскими сетями Intermarché, Leclerc и Coopérative U, и перевели автоматическую разморозку — обычно два часа в сутки — в непрерывный цикл при 50 градусах Цельсия. Это нарушило поставки и работу электронных ценников в магазинах. Президент Coopérative U Доминик Шельшер подтвердил атаку на холодильные мощности ряда магазинов сети, назвав её крайне серьёзной и беспрецедентной. Ранние потери оцениваются почти в 300 тысяч евро, в масштабах страны — потенциально несколько миллионов.
Комментарии (407)
Запрет на AI‐вклад в QGIS обусловлен перегрузкой мейнтейнеров и невозможностью надёжно выявлять AI‐генерированный код, особенно когда он прост и чист. Многие считают запрет временной мерой и предлагают гибкие правила: обязательную маркировку «Assisted‐by», автоматическую проверку и более строгие тесты для PR. Сторонники полного запрета (например, @Ariarule, @jcolot) утверждают, что без жёсткого ограничения невозможно контролировать поток низкокачественных PR и сохранить ресурсы проекта. Противники (например, @throwaway2037, @timcobb) считают, что бан короткосрочен, подстегнет форки и ограничит полезные AI‐инструменты. Некоторые отмечают, что полный запрет может спровоцировать форки и потерю вклада, но в краткосрочной перспективе уменьшит шум в репозитории и позволит сосредоточиться на критически важных задачах. Опыт из других проектов (Plotly, RustGIS) показывает, что гибкая политика с проверкой человеком и прозрачностью более эффективна, чем абсолютный бан.
Deloitte falsified documents to evade tax on Abramovich's wealth 🔥 Горячее 💬 Длинная дискуссия
Совместное расследование BBC Panorama и Бюро журналистских расследований показало, что крупнейшая в мире аудиторская фирма Deloitte помогала фальсифицировать документы, чтобы скрыть состояние Романа Абрамовича и уйти от налогов. Благодаря подписанной Deloitte отчётности на Кипре из счетов его компаний исчезли активы на 672 млн долларов — яхты, особняки и частные самолёты. Deloitte, по всей видимости, также консультировала по схеме уклонения от крупного налогового платежа через подделку бумаг.
Выводы основаны на утечке тысяч документов о финансах олигарха и сети офшорных компаний, которыми с 1995 по 2022 год управляли с Кипра. До 2005 года Deloitte владела фирмой MeritServus, затем они тесно сотрудничали. Эксперт по финансовому праву Эндрю Митчелл назвал схему «прямолинейным» уклонением от налогов, которое «не могло быть более очевидным». Юристы Абрамовича отрицают уклонение и сокрытие состояния, заявляя, что он не знал о фальсификациях и законно полагался на советы профессионалов. Deloitte Cyprus говорит, что действует в рамках закона.
Комментарии (202)
Обвинения в фальсификации документов Deloitte вписываются в системные проблемы: компания часто отказывается комментировать старые дела, её структура как сети независимых юридических лиц позволяет уклоняться от ответственности, а работа в налоговых офшорах вроде Кипра считается обычной практикой. Deloitte Cyprus ссылается на недоступность документов старше 20 лет — типичный уклончивый ответ. Кипр широко воспринимается как налоговое убежище, поэтому связь Deloitte с офшорными схемами не вызывает удивления. Структура фирмы как сети партнёров сохраняет бренд доверия, но ограничивает юридическую ответственность за действия офисов. В индустрии известна практика back‐dating документов — её легче обнаружить, чем полную выдумку, из‐за необходимости согласования цифр. Некоторые считают, что скандал может стать непреднамеренной рекламой, подчеркивая репутационные риски. Сравнение с Arthur Andersen и Enron указывает на угрозу доверия к аудиту, если подобные случаи не будут пресечены. Предлагается использовать блокчейн для публичного доступа к документам, чтобы снизить возможность скрытия информации. По мнению комментаторов, прошлые утечки (Panama, Pandora) почти не привели к наказанию — это свидетельствует о системной безнаказанности. Есть призыв санкционировать Deloitte Cyprus и бойкотировать её документацию. Отмечается противоречие между обучающими материалами о честности и реальными действиями. Некоторые считают, что общественное негодование сосредоточено на Deloitte, а не на клиентах вроде Абрамовича, смещая фокус ответственности. Шутка о том, что «фальсификация документов — их основная работа», отражает восприятие аудиторов как соучастников махинаций.
Show HN: PS2 games statically recompiled to WebAssembly 🔥 Горячее 💬 Длинная дискуссия
Игры PlayStation 2 запускаются прямо в браузере благодаря статической рекомпиляции: машинный код Emotion Engine заранее переводится в C++ и компилируется в WebAssembly, поэтому главный процессор никогда не интерпретируется. Остальная консоль — её операционная система и аппаратура — эмулируется средой выполнения, которая рисует через WebGPU. Первой игрой стала Gran Turismo 4, одна из самых требовательных на системе: она опирается на оба векторных блока, на точное поведение чисел с плавающей точкой в повторах и лицензионных тестах и на графические трюки с чтением отрисованных изображений как палитр. Игра проходит от загрузки через вступительный ролик, меню и гонки, со музыкой и звуками, и сохраняется на карту памяти, хранимую в браузере. Гонка идёт на полной скорости — 50 кадров в секунду для европейской версии — в Chrome на встроенной графике ноутбука при вдвое большем разрешении, чем у PS2.
God of War II заработала на тех же скриптах без кода под конкретную игру, но вскрыла два бага, которых Gran Turismo 4 не вызывала: один в рекомпиляторе, другой в таймингах векторного блока, плюс нехватку частей процессора ввода-вывода. Теперь она идёт от меню через катсцены в бой и держит 60 кадров в секунду в тяжёлых схватках при родном разрешении PS2, а при удвоенном — от 48 до 60, упираясь во встроенную графику. Данные игр не входят в репозиторий: вы приносите образ своего диска, а скрипты превращают его в веб-страницу на вашей машине. Диск читается через HTTP-запросы диапазона, поэтому сначала скачивается только исполняемый файл. Карту памяти можно выгрузить в формате .ps2, совместимом с PCSX2, и перенести между браузерами. Страница требует изоляции источников из-за SharedArrayBuffer, а сгенерированный код принадлежит правообладателям игр — публиковать его нельзя.
Комментарии (158)
Обсуждение вызывает скепсис относительно термина «рекомпиляция», так как проект фактически остается эмулятором с вшитым образом, а не полноценной статической рекомпиляцией. Пользователи @vrighter и @anonymous908213 отмечают, что лишь часть кода переведена в функции, а автор позиционирует проект как «без эмулятора», что противоречит реальности. Сообщество признаёт, что современные LLM ускорили декомпиляцию и рекомпиляцию игр, но это вызывает опасения по качеству и достоверности заявлений. @aceazzameen выражает обеспокоенность скрытым вредоносным ПО, на что @johnfn отвечает, что WebAssembly является одной из самых безопасных сред исполнения. По опыту @kodablah, аналогичный ARM-to-WASM подход для PS Vita работает эффективно в Chrome на флагманских Android-устройствах. Пользователь @Hyperlisk разрабатывает схожий инструмент с фокусом на точность, используя рекомпиляцию в Golang для поддержки SIMD.
Type-safe HTML templating in Zig 🔥 Горячее
Комментарии (100)
Типобезопасные шаблоны HTML реализованы в Kotlin, Rust, Go и других языках. Стандарт XInclude (W3C) позволяет включать внешние HTML-файлы и решает задачу включения без собственного механизма. HTML Imports (Chrome 36) устарели в 2018 и удалены в 2019. WICG разрабатывает спецификацию declarative-partial-updates для частичного обновления DOM без JavaScript. В Zig пока только экспериментальные решения (Ziex, Zmpl) и проблемы в стандартной библиотеке, особенно в IO-интерфейсах с отменой операций. Рекомендуется использовать проверенные подходы: XInclude, серверные include или генерацию кода из шаблонов (как в Kotlin Tempolin или Go Templ) для типобезопасности. Для быстрого цикла разработки в Zig подходит Ziex с CLI-горячим перезапуском и аналогом air-like инструмента. Для простых включений можно использовать макросы M4 (sinclude). Некоторые разработчики пишут HTML напрямую через строковые литералы. Один участник считает PHP-подобный шаблонизатор в Zig полезным как учебный эксперимент; другой предлагает рефлексию C++26 как более практичную, сомневаясь в выживаемости Zig в этом контексте. LLM могут генерировать LSP-поддержку для новых шаблонизаторных языков, упрощая их принятие. Ничего не добавлять от себя.