Hacker News Digest

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

Проект демонстрирует, что современные модели, такие как GPT-4, справляются лишь с частью заданий, подчёркивая пробелы в понимании контекста и планировании действий. Это указывает на необходимость дальнейшего улучшения агентов для автономной работы над сложными проектами. Практический вывод: хотя ИИ уже полезен в рутине, до полной автономии в разработке ещё далеко.

• Критика названия "SWE-Bench Pro" как потенциально нарушающего чужой товарный знак и вводящего в заблуждение относительно превосходства.
• Сомнения в эффективности защиты тестового набора копилфт-лицензией для предотвращения обучения на нём ИИ-моделей, учитывая игнорирование лицензий в индустрии.
• Вопросы к репрезентативности бенчмарка: отсутствие в тестировании самых современных и крупных моделей, доверие к приватному датасету и проблема "загрязнения" публичного.
• Обсуждение ключевых проблем бенчмарков для ИИ-кодеров: сложность создания "чистых" задач, которые модель не видела ранее, и уязвимость к "читтингу" через анализ скрытых частей репозитория.
• Замечание о стиле README репозитория (обилие эмодзи) как возможном признаке генерации LLM, что подрывает доверие.

Исследование опровергает массовый исход миллионеров, о котором активно сообщали СМИ в 2024 году. Более 10 900 публикаций основывались на отчёте компании Henley & Partners, которая продаёт «золотые паспорта» и консультирует правительства по таким схемам, недавно признанным Европейским судом незаконными.

Анализ Tax Justice Network показывает, что данные Henley & Partners не подтверждаются: реального массового переезда богачей не произошло. Это ставит под сомнение обоснованность смягчения налоговых реформ, принятых под влиянием этих сообщений.

• Сомнения в реальности массового исхода миллионеров из-за налогов, так как данные Henley & Partners считаются преувеличенными и маркетинговым ходом.
• Подчеркивается, что переезд в другую страну для избежания налогов — сложный и редкий шаг, который большинство не готово предпринять, несмотря на угрозы.
• Указывается на методологическую слабость исходного отчета, включая узкое определение «миллионера» и игнорирование долгосрочных тенденций и инвестиционного климата.
• Отмечается, что даже небольшой отток состоятельных людей на маргинальном уровне может иметь cumulative эффект на экономику, аналогично упадку промышленных центров.
• Обсуждается, что нарратив об «исходе» часто используется в политических и медийных целях для влияния на налоговую политику в интересах богатых.

За последние 15 лет интернет стал значительно безопаснее: доля зашифрованного трафика выросла с менее чем 10% до более 95%, во многом благодаря усилиям Cloudflare. Однако некоторые области, например внедрение IPv6, прогрессируют медленно, что увеличивает стоимость сетевой инфраструктуры и ограничивает новых участников.

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

• Обсуждается предложение Cloudflare о создании новой бизнес-модели, где AI-компании платят за скрейпинг контента, а часть средств получают создатели.
• Высказываются опасения, что это приведет к появлению нового посредника (Cloudflare) и монополизации, что может убить открытый интернет и затруднить вход на рынок новым игрокам.
• Участники сомневаются в эффективности модели и справедливом распределении доходов, проводя параллели с проблемами существующих систем (например, App Store, AdSense).
• Поднимается вопрос о том, что считать контентом, достойным оплаты, и как быть с синтетическими данными, созданными AI на основе первоисточников.
• Обсуждается ностальгия по старой, более децентрализованной модели интернета и скептицизм по поводу возможности вернуться к ней или создать справедливую новую.

PlanetScale запустил общедоступную версию своей управляемой базы данных для Postgres, завершив этап приватного тестирования. Сервис предлагает миграцию с других провайдеров Postgres через гайды и поддержку sales-команды для сложных случаев. Компания уже пять лет развивает Vitess для MySQL, а теперь переносит этот опыт на Postgres, объединяя производительность своей платформы Metal с гибкостью Postgres.

Сотни компаний, включая Convex и Supermemory, уже используют PlanetScale для Postgres в продакшене, отмечая улучшение скорости и масштабируемости. Анонсирован также будущий инструмент Neki — решение для шардинга Postgres, построенное на принципах Vitess, но спроектированное с нуля для специфики Postgres; его открытую версию планируют выпустить позже.

• Успешная миграция на PlanetScale Postgres с улучшением производительности запросов и оперативной поддержкой команды, включая помощь в решении возникших проблем.
• Критика недостаточной ясности описания продукта и цен на сайте для новых пользователей, а также отсутствия бесплатного тарифа для тестирования.
• Вопросы о технических деталях: масштабировании записи (горизонтальное шардирование через Neki), использовании эфемерных дисков NVMe в GCP, поддержке расширений Postgres и сравнении с конкурентами (Aurora, Supabase).
• Положительные отзывы от пользователей бета-тестирования о высокой производительности и надежности продукта в production-среде.
• Объяснения от команды PlanetScale о архитектуре (репликация для надежности вместо сетевых дисков) и планах по развитию (горизонтальное масштабирование через Neki).

Математики опровергли простой метод измерения сложности узлов, предложенный ещё в 1876 году Питером Тейтом. Он предполагал, что «заузленность» можно измерить минимальным числом пересечений, которые нужно перевернуть, чтобы развязать узел. Этот параметр, известный как unknotting number, долгое время считался интуитивно понятным инструментом для классификации узлов.

Однако недавно было доказано, что эта мера не работает так, как ожидалось: оказалось, что для некоторых узлов требуется больше переворотов, чем предсказывает теория, а сама операция может быть крайне неочевидной. Это открытие усложняет задачу различения узлов и показывает, что их математическая структура гораздо тоньше, чем кажется на первый взгляд.

• Обсуждается нетипичное поведение узлов, в частности, невозможность простого сложения их "чисел развязывания" при комбинировании.
• Высказывается гипотеза о существовании "отрицательного" числа развязывания для некоторых узлов, чтобы объяснить расхождения в расчетах.
• Уточняется, что проблема возникает из-за непредсказуемости изменения пересечений при соединении узлов.
• Отмечается, что для торических узлов все пересечения можно изобразить как положительные или отрицательные, что усложняет теорию.
• Обсуждается возможная связь концепции с другими математическими областями, такими как мнимые или сюрреальные числа.

GitHub Actions добавили поддержку YAML-якорей, что автор считает серьёзной ошибкой. Якоря избыточны: ту же функциональность можно реализовать через встроенные механизмы вроде workflow-level env, которые прозрачнее и логичнее в архитектуре. Они вводят ненужную сложность, нарушая локальность — теперь элементы могут зависеть от частей конфигурации в совершенно другом месте файла, что усложняет чтение и анализ.

Кроме того, якоря усугубляют проблемы безопасности: инструментам сложнее анализировать workflows, так как нарушается соответствие между исходным YAML и объектной моделью. Это мешает точно отслеживать уязвимости, например утечки секретов. GitHub не реализовал ключи слияния (merge keys), единственный сценарий, где якоря могли бы быть оправданы, что делает их поддержку бессмысленной и вредной.

• Внедрение YAML-якорей в GitHub Actions оценивается положительно для устранения дублирования в конфигурациях, но критикуется за использование нестандартного синтаксиса, усложняющего анализ.
• Высказываются предложения заменить YAML на полноценный язык программирования для определения пайплайнов, чтобы улучшить тестируемость, локальную разработку и избежать сложностей шаблонизации.
• Поднимаются проблемы безопасности из-за неявного распространения переменных окружения (включая секреты) при использовании якорей и слияния объектов, что противоречит принципу минимальных привилегий.
• Отмечается, что текущие ограничения GitHub Actions (например, отсутствие фильтрации путей для workflow_call) вынуждают пользователей создавать костыльные решения или полагаться на сторонние инструменты.
• Обсуждаются компромиссы между декларативным и императивным подходами: одни предпочитают чистый YAML для читаемости, другие генерируют его из кода для удобства поддержки сложных логик.

Книга Эбби Коверт предлагает системный подход к работе со сложными информационными системами. Она объясняет, что беспорядок состоит из информации и людей, и подчеркивает важность архитектуры информации, которая окружает нас повсюду. Автор утверждает, что понимание сложности пользователей, заинтересованных сторон и знаний — ключ к наведению порядка.

Метод включает три этапа: определение проблемы, формулирование цели и анализ реальности. Коверт рекомендует начинать с «почему», затем переходить к «что» и только потом к «как», используя язык как инструмент для выражения намерений. Практические инструменты, такие как диаграммы и карты, помогают визуализировать и структурировать информацию, делая сложные системы управляемыми.

• Обсуждение подчеркивает важность инструментов визуализации, таких как диаграммы критического пути и графы зависимостей, для анализа сложных систем и процессов.
• Участники отмечают, что хаос и сложность часто возникают из-за плохой документации, низкого качества данных и взаимосвязанных проблем в системах.
• Многие комментарии критикуют дизайн сайта автора, называя его запутанным и трудным для восприятия, что отвлекает от содержания.
• Обсуждаются стратегии работы со сложностью: улучшение сигнал/шум, заимствование методик из других областей (авиация, OODA-петли) и принятие неизбежных "помоек".
• Модератор напоминает сообществу о правилах, призывая избегать непродуктивных жалоб на второстепенные раздражители, такие как формат сайтов.

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

Именно этим объясняется «алгебраичность» Algebraic Effects: набор эффектов и обработчиков строится как свободная алгебра с заданной сигнатурой операций, а значит любая программа сводится к выражению, подчиняющемуся строгим законам переписывания. Практический выигрыш — возможность комбинировать и вложенно перехватывать эффекты без «callback-ада», потому что поведение заранее ограничено алгебраическими законами.

• Обсуждается различие между "алгебраическими" в контексте типов данных и эффектов, подчеркивая, что последние связаны с алгеброй монад, а не просто наличием уравнений.
• Участники предлагают ресурсы для изучения темы (статья "What is algebraic about algebraic effects and handlers?") и проводят аналогии с булевой алгеброй для лучшего понимания.
• Отмечается сложность терминологии и необходимость перевода абстрактных математических концепций (операции над типами/эффектами) в более доступные для программистов термины.
• Поднимается вопрос о синтаксическом представлении алгебраических типов (сумм и произведений) в разных языках программирования (OCaml, Lean).
• Обсуждается практическое применение алгебраических операторов на примере пакета Algebra of Graphics для Julia.

• CRDTs предлагаются как техническое решение для бесконфликтной синхронизации данных, но их реализация сложна и требует глубоких знаний.
• Основными барьерами для популярности local-first приложений называются экономические причины: SaaS-модели более прибыльны, а монетизация офлайн-приложений затруднена.
• Многие пользователи не видят ценности в офлайн-работе из-за повсеместного доступа к интернету, что снижает мотивацию разработчиков.
• Синхронизация и совместная работа требуют серверной инфраструктуры, что противоречит идее локальности и усложняет архитектуру.
• Разработчики сталкиваются с техническими сложностями, отсутствием готовых библиотек и необходимостью решать проблемы конфликтов данных.

Cap'n Web — это новая система RPC для браузеров и веб-серверов, созданная Cloudflare на чистом TypeScript. Она наследует философию объектно-ориентированных возможностей (object-capability) от Cap'n Proto, но оптимизирована для веб-стека: использует JSON для сериализации, работает поверх HTTP, WebSocket и postMessage(), весит менее 10 КБ и не требует схем или шаблонного кода. Поддерживает двусторонние вызовы, передачу функций и объектов по ссылке, а также конвейеризацию промисов для сокращения задержек.

Настройка занимает буквально несколько строк: клиент подключается через WebSocket, а сервер реализуется как класс с методами, которые автоматически становятся удалёнными процедурами. Например, метод hello(name) на сервере можно вызвать из браузера как api.hello("World"). Система интегрируется с TypeScript для типобезопасности и работает в Cloudflare Workers, Node.js и современных браузерах. Это делает распределённое программирование почти неотличимым от локального, с учётом сетевых реалий.

• Обсуждение Cap'n Web как упрощённой, schemaless версии Cap'n Proto RPC для TypeScript/JavaScript с поддержкой передачи функций и двусторонних вызовов.
• Сравнение с другими технологиями: проводятся параллели с GraphQL (решение проблемы N+1, но без DataLoader), tRPC/ORPC (схемы vs schemaless), gRPC-web (сложность) и старыми системами вроде Java RMI или .NET Remoting.
• Подняты вопросы о безопасности (риски из-за отсутствия схем и передачи произвольных колбэков), состоянии сервера (статусность vs статусность) и проблемах отладки (сложность отслеживания сетевых запросов).
• Обсуждаются технические детали: пайплайнинг промисов для уменьшения RTT, выполнение .map() на сервере через DSL, управление памятью и сборкой мусора для долгоживущих соединений.
• Запросы на расширение: поддержка других языков (Rust, Elixir), стриминг, генераторы, версионирование API и бинарная совместимость с Cap'n Proto.