Hacker News Digest

Экспериментальный пакет golang.org/x/exp/simd предоставляет платформенно-независимый доступ к SIMD-инструкциям в Go, позволяя писать высокопроизводительный код для обработки массивов данных без привязки к конкретной архитектуре. Он абстрагирует низкоуровневые инструкции (такие как SSE, AVX, NEON) через универсальный API, где разработчик описывает операции над векторами, а компилятор и рантайм подбирают оптимальную реализацию под текущее оборудование. Это упрощает написание кода, который одновременно работает эффективно на x86, ARM и других платформах, избегая необходимости вручную писать ветвления по наборам инструкций или использовать cgo/ассемблер.

Пакет поддерживает типизированные векторные типы (например, v128 для 128-битных регистров) и операции над ними: загрузка/сохранение из памяти, арифметика, логические операции, перестановки и редукции. Особое внимание уделено безопасности и предсказуемости: все операции имеют чётко определённое поведение, включая обработку случаев, когда запрашиваемая ширина вектора недоступна на текущей платформе (в этом случае происходит паника или fallback на скалярный код, в зависимости от режима). В экспериментальном режиме пакет позволяет включать автовекторизацию через флаги компилятора, а также предоставляет инструменты для benchmarking и проверки генерации кода. Хотя пакет всё ещё находится в exp и может меняться, он демонстрирует путь к тому, чтобы SIMD стал доступной частью стандартного Go-стека для задач вроде обработки изображений, сигналов, криптографии и научных вычислений.

Экспериментальный пакет simd в Go дает прирост производительности от 30% до 5x по сравнению со скалярным кодом, при этом имея лишь небольшой оверхед относительно платформенно-специфичных реализаций. Это подтверждают тесты @ImJasonH, задачи по обработке видео и аудио (speech-to-text/text-to-speech). SIMD устраняет необходимость в CGO для векторизации, упрощая сборку и убирая зависимости от C/C++. Это делает Go привлекательнее для системных задач, включая разработку баз данных (например, streambed). Технические особенности: — Поддержка архитектур с переменной длиной вектора (SVE, RVV) обеспечивает будущестойкость. — Генерация специализированных версий функций при компиляции исключает runtime-накладные расходы. — Автоматическая векторизация в компиляторе Go (CL 791740) уже в разработке и показывает хорошую эффективность. Рекомендации и альтернативы: — Для максимальной скорости стоит использовать платформенно-специфичный код, оставив портативную реализацию как запасной вариант. — Чтобы сохранить портативность, длину вектора следует ограничивать минимально поддерживаемым размером целевых платформ. — В качестве альтернативы CGO можно использовать Go-ассемблер и пакет unsafe (как в go-pherence). — Предложено создать линтер для автоматической замены числовых циклов на SIMD-операции. Дискуссии: — Некоторые критикуют Go за игнорирование долгосрочных запросов (например, 13-летнее ожидание generics) при внедрении SIMD без явного спроса. — Возник спор о влиянии SIMD на проблему накладных расходов CGO: часть пользователей считает, что SIMD полностью устраняет необходимость в CGO.

Git-bug — это распределённый трекер ошибок, полностью интегрированный в Git: он хранит данные внутри репозитория, не добавляя файлов в проект, и позволяет работать офлайн, синхронно с кодом через обычные команды git bug push и git bug pull. Благодаря этому ваш трекер ошибок всегда доступен, даже без интернета или при недоступности внешних сервисов, и не привязывает вас к конкретному провайдеру — вы получаете полную резервную копию вместе с кодом.

Инструмент поддерживает несколько workflow: нативный (синхронизация через Git remotes), bridge-режим (импорт/экспорт с другими трекерами вроде Jira или GitHub Issues) и экспериментальный веб-интерфейс. Управление происходит через CLI: создание багов (git bug add), фильтрация по запросам (git bug ls "status:open"), интерактивный терминальный UI (git bug termui) и GraphQL API для интеграции с внешними инструментами. Все операции быстрые, не загрязняют рабочее дерево и сохраняют полную историю изменений вместе с коммитами. Лицензия — GPLv3.

Git-bug изолирует трекер ошибок от кода, но требует упрощения интерфейса для нетехнических пользователей и решения конфликтов идентичностей при офлайн-синхронизации. Для монетизации нужно снизить барьер входа, так как Git-интеграция уменьшает доступность по сравнению с GitHub или Jira. Рекомендуется интегрировать ForgeFed или IndieAuth для децентрализованной аутентификации, избегая привязки к централизованным провайдерам. Использование DID:PLC (как в Bluesky) упростит перенос идентификаторов между репозиториями — критично для распределённой модели. Некоторые считают, что трекер ошибок не должен быть частью репозитория: достаточно хранить баги в отдельной ветке или в SQLite (как @0xbadcafebee). Git-bug эффективен для маленьких команд, где минимизация переключения контекста между кодом и трекером повышает продуктивность (по @michaelastreiko). Проблема дублирования багов при офлайн-работе требует механизма слияния, аналогичного git-слиянию — это не решено в текущей реализации (по @promptsphereeee). Имя 'git-bug' ограничивает применение для отслеживания фич — возможно, стоит переименовать или расширить функционал (по @bflesch). Для привлечения пользователей важно поддерживать WebUI с OAuth, но также обеспечить работу без веб-интерфейса (как b4 и cgit на kernel.org, по @Aissen). Git-bug — часть тренда локально-первичных инструментов (как Fossil, ticgit, git-issue), но его успех зависит от устранения барьеров ввода и синхронизации (по @Izkata и @khimaros). Разделение трекера и кода через отдельную ветку (например, issues-branch) даёт гибкость и изолирует изменения (по @0xbadcafebee), что проще для масштабирования. Некоторые сомневаются в необходимости Git-bug, так как GitHub Issues уже интегрирован с Git и работает для большинства команд (по @Alex131313 и @zeroq). Использование git-refs для хранения багов (как в gitseq от @inguz) позволяет сохранять подпись и последовательность — потенциально более надёжно, чем текущий подход git-bug.

PipePipe — это независимо развивается как форк NewPipe, начатый в начале 2022 года. Проект не синхронизируется с оригиналом: не получает его обновления и не вносит изменения в него, что позволяет быстро исправлять ошибки и часто добавлять новые функции. В отличие от таких форков, как Tubular, PipePipe идёт своим путём, что делает его более гибким и независимым.

Приложение расширяет возможности NewPipe: интегрирует SponsorBlock для пропуска рекламы, восстанавливает дизлайки через ReturnYouTubeDislike, показывает оригинальные нелокализованные названия видео и поддерживает вход в аккаунт для доступа к премиум-контенту. Добавлены danmaku-наложения для live-чатов, поддержка AV1 и VP9 кодеков, режим музыкального плеера с фоновым воспроизведением, продвинутые фильтры поиска и блокировка шортс и платных видео. Управление улучшено жестами свайп-для-перемотки, долгим нажатием для ускорения и таймером сна. Плейлисты можно скачивать целиком, искать и сортировать локально. Доступно в F-Droid и IzzyOnDroid, развитие поддерживается через Ko-Fi и Liberapay. Wiki и благодарности сообществу указаны в репозитории.

Пользователи подтверждают, что PipePipe успешно заменяет NewPipe с поддержкой SponsorBlock, но возникают вопросы по надежности, конфиденциальности и альтернативам на других платформах. PipePipe эффективно решает проблему пропущенных спонсорских блоков, отсутствовавших в NewPipe, и обеспечивает стабильную работу после обновлений YouTube. Разработчик PipePipe активно поддерживает проект, быстро реагируя на изменения YouTube, что делает его надежнее других форков. Спор: Некоторые пользователи отключают SponsorBlock из-за чрезмерного пропускания контента (например, в видео Tony Iommi), считая его раздражающим; другие ценят эту функцию как ключевое преимущество. Спор: Возникает вопрос о конфиденциальности: Return YouTube Dislike в PipePipe отправляет данные о просматриваемых видео третьей стороне без анонимизации, в отличие от SponsorBlock, и опция отключения не работает. Совет: Пользователи рекомендуют Materialious для самостоятельного хостинга — сохраняет историю просмотров и работает на всех устройствах через браузер без установки приложений. Совет: Для iOS предложены альтернативы вроде KiraTuno и Morphe, но они не решают проблему отсутствия полноценного клиента, как PipePipe на Android. Совет: Для Apple TV надежного решения нет: SponsorBlock в контейнере только глушит рекламу, но не пропускает её, снижая удобство. Morphe и ReVanced — популярные альтернативы: Morphe использует yt-dlp, как и PipePipe; ReVanced сохраняет рекомендации и Shorts, что важно для некоторых пользователей. Спор: Некоторые пользователи сталкиваются с блокировкой IP YouTube в PipePipe и NewPipe, возможно, из-за CGNAT, тогда как официальное приложение YouTube работает без проблем с тем же IP. Функция таймера сна для прослушивания перед сном считается ключевым преимуществом PipePipe, отсутствующим в большинстве других клиентов. Совет: Для десктопа пользователи ищут аналоги SponsorBlock в браузерах, но прямых решений, сопоставимых с PipePipe, в обсуждении не представлено. Спор: Есть этическое возражение: один пользователь считает, что использование SponsorBlock — это кража у создателей контента; другие видят в нём инструмент улучшения опыта без прямого ущерба.

DAWO.community — это открытое сообщество, объединяющее правительство, бизнес и общество Нидерландов для создания цифровой автономии в государственном секторе. Цель проекта — построить рабочее место для нидерландского правительства, основанное на открытых, проверяемых и взаимозаменяемых технологических компонентах, чтобы усилить цифровой суверенитет страны, улучшить сотрудничество между госорганами и обществом, обеспечить безопасность и защиту данных, стимулировать инновации и сделать государственные ИТ-системы прозрачными и аудитируемыми.

Технологическая основа DAWO строится по принципу «заменяемых строительных блоков»: вместо единой монолитной системы предлагается набор открытых компонентов — ИИ, операционная система (DAWO-NixOS), облачная инфраструктура и инструменты для совместной работы — все они доступны в публичных репозиториях (code.overheid.nl, Codeberg) и могут быть независимо проверены, обновлены или заменены. Участие в сообществе открыто всем: через код, документацию, пилотные проекты, обсуждения на форуме и события, анонсируемые в публичном членском портале. DAWO подчеркивает, что разработка ведётся не «для» сообщества, а «с» сообществом — государственные и частные структуры совместно формируют один общий чертеж цифрового будущего для нидерландского госуправления.

NixOS обеспечивает неизменяемость и централизованное управление через read-only хранилища, что важно для государственных систем. Код проекта DAWO‐NixOS доступен на Codeberg и code.overheid.nl. Французское правительство использует NixOS‐базированные системы securix и bureautix, подтверждая применимость на государственном уровне. Аналогичные инициативы — openDesk (Германия) и La Suite (Франция) — демонстрируют практическую реализуемость. Однако остаются проблемы: офисные пакеты (LibreOffice/Collabora) не полностью заменяют Microsoft 365 без потери функциональности; в Nixpkgs наблюдаются задержки в слиянии патчей CVE, замедляя реакцию на уязвимости. Рекомендуется: внести пакеты DAWO в официальный Nixpkgs для расширения экосистемы; изучать Rust‐основанные альтернативы Nix (Lix, Snix); проводить сканирование безопасности модулей провайдеров и исследовать генерацию конфигураций из естественного языка; упростить координацию, так как проект разбит по нескольким репозиториям и организациям, что замедляет развитие.

Mac Mini M6 демонстрирует выдающиеся результаты в эмуляции старых ПК через 86Box, где ключевым фактором является однопоточная производительность хоста. Благодаря высокой частоте и стабильной работе ядер Apple Silicon, M6 способно удерживать эмуляцию на уровне 100% для процессора до 600 МГц (Pentium II), тогда как базовый M4 ограничивается 500 МГц из-за более низкой частоты ядер (~3,7 ГГц против ~4,7 ГГц у M6). Эмуляция включает точную воссоздание chipset, шины ISA/PCI, звука и графики (включая Voodoo 3 через ARM64 JIT), что делает нагрузку почти полностью однопоточной — работа сосредоточена на двух «супер» ядрах (cpu6, cpu7), загруженных на 45–49% при 600 МГц эмуляции, при общей загрузке пакета менее 26%. Это подтверждается тестами: Cinebench 2000 и 3DMark 2000 SE работают без просадок звука и при полной скорости эмуляции. Автор отмечает, что такая производительность ставит виртуальную систему в диапазон Pentium III, а тихий, компактный форм-фактор Mac Mini за ~1600 евро делает его исключительно удачным решением для ретро-эмуляции. Упоминаются планы попробовать эмуляцию Windows XP в будущем.

Эмуляция Pentium II с Voodoo 3 на M6 Mac Mini через 86Box обеспечивает цикл-точную точность и воссоздаёт уникальный эмоциональный опыт перехода от софтверного к аппаратному рендерингу, недоступный на современных гипервизорах. 86Box корректно запускает игры с Glide-рендерингом, в отличие от стандартных гипервизоров, которые не эмулируют ISA-карты, Glide и точные тайминги старых GPU. Однопоточная производительность Apple Silicon критична: M6 (до 4.5 ГГц) поддерживает 600 МГц Pentium II на 100%, M4 (3.7 ГГц) — только до 500 МГц. Для полной производительности в 86Box необходимо включить dynarec; иначе производительность падает в разы (как в Unreal на M2). Эмуляция Voodoo 3 воспроизводит оригинальный Glide-рендеринг, невозможный в VM с виртуальными GPU из-за несовместимости драйверов Windows 98 с современными API. Пользователи отмечают, что Voodoo 3 на PCI (например, Voodoo 3-2000) были хуже AGP-версий, но революционны для своего времени. Эмуляция на M6 позволяет разрабатывать и тестировать ОС для Pentium II без физического оборудования — ценно для энтузиастов и историков ПК. Она воссоздаёт атмосферу эпохи: звуки дисковода, шум вентиляторов, визуальные артефакты Voodoo, уникальную цветовую палитру Glide в Quake и Unreal, которые софтверный рендеринг передавал лучше. Сравнение с QEMU + softgpu показывает превосходство 86Box в точности эмуляции Voodoo и ISA-устройств. Предупреждение: эмуляция может нагревать Mac до 90+°C — требуется мониторинг температуры (например, через MacThrottle). Спор о целесообразности эмуляции вместо запуска Windows 98 на гипервизоре не отменяет факта: только цикл-точная эмуляция сохраняет оригинальный опыт.

Я ухожу из Google, потому что считаю, что ускорение развития ИИ в текущих условиях опасно для людей. Моя команда работает над снижением стоимости и задержки ИИ, что ускоряет его распространение и мощность, а я верю, что прогресс ИИ сейчас слишком быстр и его последствия непредсказуемы. Перейти в другой проект в Google, не связанный с ускорением ИИ, невозможно — особенно из-за моих связей с Новой Зеландией, где инженерные команды отсутствуют.

Я не отрицаю ценности своей работы в Google: люблю коллег, среду и интересные задачи. Но моя христианская этика не позволяет мне игнорировать потенциальный вред — от когнитивной сдачи и психоза до концентрации власти и экономического хаоса. Хотя моё влияние мало, я верю, что мои редкие навыки могут принести больше добра вне компании. Продолжу поддерживать Pernosco и rr, исследуя, как инструменты отладки могут помочь ИИ-агентам, и буду искать способы применять таланты во благо человека, оставаясь в Новой Зеландии.

Обсуждение подтверждает опасения автора о слишком быстром развитии ИИ, добавляя практические детали: реальные оттоки сотрудников через VEP, эффективность внутреннего сопротивления, различие между «doomers» по уровню тревоги, уход от проблем атрибуции, а также религиозные и экономические аргументы, показывающие многогранность вопроса. Развитие ИИ опережает социальные планировочные горизонты, делая устоявшиеся сроки, например четырёхлетнее образование, неадекватными для будущего. Оставаться в компании и формировать внутреннее движение считается более эффективным, чем массовый уход, поскольку трудовые ресурсы — единственная рычаговая сила для корпораций. Серия уходов из OpenAI, Anthropic и Google, а также открытое письмо более чем 1000 экспертов, усиливают восприятие риска ускорения ИИ. Некоторые комментаторы считают, что демократизация ИИ (снижение стоимости и задержки) менее опасна, чем другие моральные вопросы, связанные с компанией. Проблема атрибуции в LLM остаётся актуальной, но часто игнорируется в публичных дебатах. Программа VEP привела к массовому уходу сотрудников, подтверждая тенденцию оттока. Выделяют два типа «doomers»: те, кто боятся реальных возможностей ИИ, и те, кто считает ИИ переоценённым и «хайповым». Религиозные мотивы автора вызывают полярные реакции: одни считают их оправданными, другие — отталкивающими и несерьёзными. Автор и некоторые комментаторы выражают тревогу по поводу «cognitive surrender», психоза и одиночества, вызванных зависимостью от ИИ. Есть мнение, что страхи перед ИИ преувеличены; некоторые ищут способы уйти из технологической отрасли, не считая ИИ угрозой. Критика компаний за инвестиции триллионов в машины, которые могут заменить людей, рассматривается как противоречие человеческой ценности. Ускорение ИИ может привести к экономическому дисбалансу, концентрации власти и проблемам кибербезопасности.

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

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

План-режим не умер, а трансформировался: его функции перешли в итеративные диалоги, документированные артефакты и строгие ограничения на действия агентов, сохраняя контроль над архитектурой и понимание системы. Изначально Plan mode в Claude Code был просто промптом, а не функцией инструментов. Его отмена произошла потому, что модели стали самостоятельно понимать необходимость планирования без явного включения режима. Спор: Некоторые разработчики (@jonathanlydall, @Marha01) утверждают, что план всё ещё необходим для ясности целей и понимания архитектурных решений, иначе AI может строить код на неверных предположениях, даже если он «суперинтеллектуален». Противники (@bcherny, @tcdent) считают, что современные модели достаточно точно следуют инструкциям вроде «не пиши код пока не скажу», делая формальный режим избыточным. Сторонники (@stephen_cagle, @pioneerjeff) видят в нём инструмент контроля и согласования. Планирование не исчезло — оно стало интерактивным: разработчики теперь просят AI сначала объяснить подход, обсудить компромиссы, задать вопросы, а затем утверждать план, прежде чем перейти к реализации (@valzam, @blensor). План-режим помогает ограничивать действия AI, особенно при работе с несколькими файлами, предотвращая неожиданные изменения и обеспечивая прозрачность — это критично для тех, кто не готов доверять коду без просмотра (@altern8, @dsign). Многие используют альтернативы: создание документации как артефакта, который затем используется агентами в процессе реализации, что обеспечивает устойчивость контекста и согласованность между разными сессиями и моделями (@jfaat, @pcblues). Ограничение инструментов AI (например, запрет на запись вне папки /agile) и использование readonly-режимов стали заменой план-режиму, позволяя сохранить контроль без формального режима (@digitaltrees, @coolgoose). Планирование стало частью OODA-цикла: действовать → инспектировать → уточнять → корректировать → действовать снова, где понимание системы развивается через итерации, а не через одноразовый план (@Eupolemos). Совет: Для сложных задач полезно заставлять AI задавать 10+ уточняющих вопросов перед реализацией — это резко повышает качество и уверенность в решении, как показал опыт @valzam. Совет: Использование rules.md с явными инструкциями (например, «не начинай писать код, пока я не скажу codenow») и автоматическое создание бэкапов файлов помогает сохранить контроль и откатываемость при работе с AI (@dbojan). План-режим не умер, потому что он решал проблему не только планирования, а — контроля контекста: без него AI часто пишет код, не прочитав достаточную часть кодовой базы, что приводит к ошибкам (@loveparade). Современные инструменты (например, Antigravity CLI, Astra) показывают, что планирование эффективно, если оно отделено от реализации и требует явного утверждения — это снижает токен-стоимость и повышает качество (@parasti, @robertlagrant). Самый ценный вклад план-режима — это сохранение ментальной модели системы разработчиком, а не просто формальное согласование шагов: без этого кодовые базы становятся непонятными и неподдерживаемыми (@taurath, @dsign). Совет: Для больших изменений полезно разделять сессии: одна для теоретического анализа проблемы, другая — для реализации исправлений на основе конкретных данных, что снижает риск сбоя в процессе (@cronin101).

Дэвид Хайнемайер Ханссон объявил, что отошёл от профессионального программирования и теперь позиционирует себя как «мейкер», веря, что английский язык стал лучшим языком программирования благодаря LLM, а чтение сгенерированного кода больше не требуется. Он утверждает, что ручное написание кода перестало быть экономически продуктивным для большинства программистов, и что 37signals переписывают Hey на нативные приложения с использованием Rust на серверной стороне — языка, который он считает «ужасным» для людей, но идеальным для LLM, поскольку он не читает код anyway. За август он насгенерировал 150 тыс. строк кода (в основном «словного» Rust), тогда как раньше писал около 30 тыс. в год, и доля Ruby в его работе упала с 50% до 3%. Его видение: к концу года LLMs будут доминировать во всех сферах, а люди будут читать код лишь исключительно, как ошибку в Sentry. Он также хочет, чтобы у каждого сервиса был CLI для взаимодействия через агентов. На Rails World 2026 он использовал ключевую речь, чтобы объявить, что флагманское Rails-приложение Hey покидает фреймворк, хотя и отметил, что Rails остаётся хорошим для веб-приложений и разработки с ИИ. Однако его аргументы сводились к тому, что Rails был лишь временным обходным манёвром, а теперь его роль сведена к «веб-приложениям по необходимости», а «конвенция над конфигурацией» переосмыслена как «эффективность токенов». Критик отмечает отсутствие чёткой стратегии для Rails, заменённую оптимизмом без фактической основы, и выражает разочарование тем, что вместо обсуждения будущего Rails DHH предложил лишь веру в ИИ и отверг скептицизм как «чёрную таблетку для неудачников».

Rails не умирает из-за технологий, а из-за ухода DHH. Многие разработчики продолжают использовать его для CRUD- и LoB-приложений в 2026 году благодаря сильным конвенциям, упрощающим поддержку, даже если LLM генерирует большую часть кода. LLM-генерация делает производительность Ruby менее критичной, так как разработчики фокусируются на проверке и доработке сгенерированного кода. Один разработчик отмечает, что 90% его 25k строк продакшн-кода и тестов генерируются LLM — код надежен, легко расширяем и требует меньшего ручного вмешательства. SRE предупреждают, что если LLM генерирует код быстрее, чем человек его читает, чтение становится необязательным, что ставит под вопрос понимание системы на уровне инженеров. Производительность Rails (80–100 мс на запрос) остаётся приемлемой для большинства бизнес-приложений, и миграция не мотивирована скоростью, а удобством разработки. Компании не переходят на другие стеки из-за производительности, а из-за усталости от устаревших инструментов и отсутствия развития экосистемы без DHH. Критики утверждают, что DHH, как BDFL, не передал управление, что привело к фрагментации сообщества и необходимости форка — это системная проблема, а не техническая. Некоторые считают, что переход на нативные приложения или CLI-агенты — ответ на ограничения веб-фиделити, а не на устаревание Rails. LLM не генерируют код в WASM или нативной сборке, а используют высокоуровневые языки, значит, они ускоряют разработку фреймворков, а не заменяют их. Исторически Rails решал проблему медленной разработки в 2000-х — теперь эта проблема решена LLM, и фреймворки перестают быть конкурентным преимуществом, а становятся инструментом. Разработчики, ушедшие от Ruby, рекомендуют Kotlin+http4k как альтернативу: он сохраняет стиль Ruby с типизацией, поддерживает функциональный подход и лучше интегрируется с агентными системами.

Когда ИИ стал способен выполнять все домашние задания в моём курсе, я перестал проверять понимание через работу вне аудитории. Раньше я использовал GPT-3 для тестов ещё в 2021 году и видел, как он выдаёт убедительные ответы без чтения материала, но тогда ничего не менял. К 2026 году ситуация изменилась: агенты ИИ могли делать любые задания, и я перестроил оценку, сделав акцент на взаимодействии с ассистентами, экзаменах и видео-демонстрациях, даже если это противоречит некоторым педагогическимベスト-практикам.

Курс Machine Learning in Production остался верен своим целям — обучению инженерным компромиссам, управлению рисками и командной работе, а не написанию кода или использованию конкретных инструментов. Мы разрешили студентам использовать ИИ везде, кроме письменных и устных экзаменов, считая, что запрет бесполезен, а умение работать с ИИ — часть профессиональной подготовки. Основная идея: если ИИ может сделать домашнее задание, то проверять нужно то, что он не может — живое мышление и диалог.

Традиционные домашние задания утратили смысл из-за ИИ, так как студенты легко генерируют ответы, не понимая материала. Преподаватели переходят к аудиторным формам проверки — устным экзаменам, интервью, проектам с защитой — как единственному надежному способу оценить реальное понимание. Ограниченные по времени письменные задания без интернета также считаются разумным способом сохранить контроль. ИИ не заменяет цели обучения, а лишь подменяет доказательства их достижения — то, как мы измеряем знания, а не что мы учим. Переход к высокоставочным экзаменам вынужден, так как низкоставочные частые оценки (например, ДЗ) обходятся ИИ. Некоторые видят в ИИ персонального репетитора и винят неправильное использование студентами, но другие считают, что это не решает проблему отсутствия самостоятельного обучения. Запрет устройств в аудитории предлагается как решение, но считается нереалистичным из-за масштабов и стоимости. Рекомендуется сочетать практические проекты с устной защитой для проверки понимания в реальном времени. Предложения обучать студентов ответственному использованию ИИ или использовать ИИ для создания самопроверяющихся заданий признаны неработающими. Домашние задания всегда были ineffective из-за списывания — ИИ лишь ускорил этот процесс. Переход к персонализированному, практичному обучению желателен, но требует системных изменений, которых пока нет. Использование ИИ для обратной связи преподавателями (например, боты в Slack) допустимо, но не для студентов — иначе возникает обвинение в лицемерии. Преподаватели, которые никогда не задавали ДЗ и фокусировались на лекциях и экзаменах, считают, что система была сломана давно — ИИ лишь обнажил проблему.

Калифорния планирует ввести одноразовый налог на миллиардеров в размере 5%, растянутый на пять лет, чтобы собрать около 20 млрд долларов в год на здравоохранение, продовольственную помощь и школы после федеральных сокращений. Однако авторы статьи из Центра земельной экономики утверждают, что такой налог провалится, потому что миллиардеры, в отличие от земли, могут уехать — у них есть «ноги». Они подсчитали, что общая стоимость земли в Калифорнии составляет около 8,14 трлн долларов, что в восемь раз превышает реалистичную налоговую базу миллиардеров. Например, земля Лос-Анджелесского округа стоит больше, чем всё состояние целевой группы миллиардеров, а Бая область отстаёт незначительно.

Земля — идеальная налоговая база: она не может уехать, её стоимость определяется общим развитием региона, и налог на неё падает преимущественно на богатых владельцев prime-недвижимости на побережье и в центре городов, почти не затрагивая скромные дома в Центральной долине. В то же время текущая система налогообложения земли в Калифорнии разрушена с 1978 года из-за Proposition 13, которая заморозила оценочную стоимость недвижимости до момента продажи. В результате государство оценивает недвижимость лишь в 44–60% от её реальной стоимости, теряя до половины потенциальных доходов. Это вынуждает штат компенсировать дефицит высокими налогами на доход — самыми высокими в стране — которые, однако, также утекают вместе с мобильными богатыми резидентами. Вместо того чтобы чинить сломанную базу, Калифорния предлагает новый налог на мобильное богатство, обречённый на провал из-за оттока капитала. Авторы призывают обратить внимание на налог на стоимости земли — стабильный, огромный и неподвижный источник дохода, который уже лежит под ногами.

Обсуждение показывает, что однократный налог на миллиардеров в Калифорнии вызывает сомнения: богачи вряд ли уедут из‐за налогов, а угрозы отъезда считаются пустыми. Более эффективным может быть земельный налог и реформа Prop 13, учитывая переизбыток текущих налогов и плохое управление бюджетом. Передача налога на стоимость земли арендаторам вызывает спор: одни считают это невозможным, другие полагают, что арендодатели просто повысят арендную плату. Предлагается изменить Prop 13 так, чтобы он распространялся только на основные резиденции, исключив вторичные дома, инвестиционную и коммерческую недвижимость — это, по мнению автора, решит большую часть бюджетного дефицита. Некоторые отмечают, что Калифорния уже собирает слишком много налогов и страдает от плохой бюджетной дисциплины, вместо поиска новых источников дохода. Есть разногласия по поводу выбора между однократным налогом на богатство и реформой земельного налога: одни считают, что налог на богатство провалится, другие видят в нём эксперимент. Автор предлагает рассматривать налог на миллиардеров как эксперимент: измерять отток богатых семей и корректировать порог налога для баланса между доходами и оттоком. Ссылка на Генри Джорджа: налог на землю без налога на постройки стимулирует эффективное использование земли и инвестиции в жильё. Оценка стоимости земли в округе Санта‐Клара часто неверна; рекомендуется улучшить методику разделения стоимости земли и построек для справедливого налогообложения. Спор о возможности уклонения: одни утверждают, что налог на богатство можно избежать, уехав из штата; другие считают, что земельный налог невозможно уклониться, так как земля привязана к месту. Несколько участников подчёркивают, что повышение налога на имущество ограничено Prop 13, и без его отмены попытки увеличить доходы через земельный налог будут безрезультатны.