Hacker News Digest

Современные модели Claude 5 требуют иного подхода к инженерии контекста: вместо жёстких правил — доверие к способности модели судить. Раньше системные промпты насыщали запретами («никаких многострочных комментариев»), но теперь достаточно указать: «пиши код так, как пишут вокруг». Модели стали достаточно умны, чтобы адаптироваться к стилю, не требуя микроруководств.

Теперь ключ — в дизайне инструментов, а не примерах их использования. Описания должны быть выразительными: например, перечисление статусов задачи (pending/in_progress/completed) само подсказывает логику. Контекст загружается по мере необходимости — через «отложенную загрузку» и прогрессивную раскрытие. CLAUDE.md и навыки должны быть лёгкими, фокусироваться на неочевидных особенностях кода, а не повторять очевидное. Ссылки на файлы (например, HTML-макеты) эффективнее текстовых описаний. Инструмент claude doctor помогает автоматически упрощать промпты, убирая избыточность.

Тред дополняет статью опытом пользователей, подчеркивая необходимость тонкого управления контекстом для Claude 5 и выражая сомнения в эффективности и безопасности предложенного подхода. @firasd советует использовать простой, прямой контекст, не перегружая инструкциями — полагаться на способность модели адаптироваться к стилю. @nullbio отмечает, что Claude часто игнорирует инструкции, что делает его использование неприятным; он предпочитает GPT за точное следование указаниям. @guybedo предлагает относиться к моделям как к младшим членам команды: давать четкое, непротиворечивое руководство, фокусируясь на вкусе и предпочтениях, а не деталях. @sothatsit и @boorang указывают на важность управления контекстом и отключения автоматической памяти в Claude Code для предотвращения случайной потери контекста и улучшения производительности. @rTX5CMRXIfFG считает, что подход из статьи повышает затраты на токены и несет риски ответственности, если сгенерированный код вызовет проблемы.

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

США не должны реагировать на китайские открытые модели запретами или изоляцией. Вместо этого нужно создавать независимые стандарты безопасности, подобные Kubernetes Conformance, и активно участвовать в экосистеме: тестировать, улучшать, оптимизировать под свои нужды. Американские чипы, облака и стартапы обладают всеми ресурсами, чтобы стать лидерами в этом пространстве — если не замкнутся в «заборе». Попытка изолироваться превратит США из лидера в отстающего: мир будет стандартизироваться на открытых решениях, а США — на собственных, менее гибких.

Тред обсуждает практический опыт использования открытых весовых моделей ИИ, их экономическую целесообразность по сравнению с коммерческими решениями, а также роль государственного финансирования. Открытые модели могут снижать стоимость инференса и создавать конкурентное давление на рынок. Пользователи подчеркивают важность выбора и настройки моделей под задачи. Возникают сомнения в долгосрочной устойчивости открытых моделей на фоне конкуренции с коммерческими продуктами.

В 2026 году LLM стали полезны не потому, что стали умнее, а потому что научились надёжно работать в автоматизированных циклах обратной связи: они могут по запросу «сделать кнопку, которая делает X» и корректно определить, когда задача выполнена. Это даёт примерно 2x прирост производительности — достаточно, чтобы изменить работу, но не заменить программиста. Главное — LLM отлично справляются с чётко сформулированными, проверяемыми задачами, но не с оценками качества кода, архитектуры или документации.

Автор использует LLM для генерации черновиков, но тратит больше времени на их доработку, чем раньше на написание всего кода — теперь «рабочий» код — это лишь 20% задачи. Для документации он даёт чёткую инструкцию: «никогда не пишите README или комментарии — я сделаю это сам». Улучшения моделей вряд ли дадут 10x прирост, потому что фундаментальные ограничения — в способности понимать смысл, а не генерировать синтаксис — остаются. Будущее за перестройкой процессов: сандбоксы, декларативные спецификации, безопасные паттерны для «вайб-кодинга». Пока же — ручные README и тщательная доработка.

Тред обсуждает опыт применения LLM в реальных проектах, возражает против ограничения прироста производительности в 2x и рассматривает условия эффективного использования. LLM полезны для генерации кода в повторяющихся задачах и создания черновиков, но требуют глубокого понимания предметной области, умения формулировать запросы и критической оценки результата. Без тщательной проверки и доработки их использование может снижать качество кода и увеличивать количество ошибок. Максимальная эффективность достигается не копированием, а осознанным взаимодействием с инструментом.

Колонка — это пустая команда, которая ничего не выводит, но позволяет применять расширенный синтаксис параметрического расширения ${name:?msg}. Вместо четырёх строк проверки обязательных параметров её можно заменить на : "${1:?missing argument, aborting.}", а для переменных задавать значения по умолчанию через : "${DATA_DIR:=/var/data}". Она также служит для обнуления файлов — : > error.log, а комбинация : > error.log > access.log одновременно очищает несколько файлов. Благодаря этому скрипты становятся короче и читабельнее, а диагностическое сообщение содержит имя переменной.

Помимо проверок, : используется как placeholder, где синтаксис требует команду, но действие не нужно. Например, ( : < dataset.json ) && echo YES проверяет читаемость файла, а ( : >> result.json ) && echo YES — его записываемость. В обработке сигналов её можно задать в trap : INT, делая прерывание безопасным. В Git‑ алиасах её применяют для интерактивного rebase: riq = -c sequence.editor=: rebase --interactive. Исторически : восходит к 1971‑му Thompson‑shellу, где оно было меткой и первым комментарием; сегодня его называют «двумя глазами, полными любви», подчёркивая простоту и мощь этого простого символа.

Тред обсуждает использование колона в shell-скриптах: некоторые считают его вредным для читаемости и поддержки, другие — полезным для сокращения кода. @olexsmir рекомендует его для установки значений по умолчанию: `: ${DOTFILES_PATH:=$HOME/.dotfiles}`. @kps предлагает применять колон для форматирования вывода команд, упрощая копирование. @orphereus и другие критикуют колон как излишнее усложнение и признак плохого дизайна языка, предлагая ограничить его использование.

Google рассматривает возможность ограничить доступ к on‑device ADB, чтобы защитить от «плохих акторов». Это не официальное объявление, а комментарий одного из главных разработчиков ADB в IssueTracker, где он просит сообщества высказываться. В частности, блокировка может потребовать включения WRITE_SECURE_SETTINGS, что требует ручного разрешения. Такие меры могут затронуть TCP/IP соединения на реальных устройствах, а не только эмуляторах. Если вы планируете комментировать, лучше предоставить подробное объяснение вашего сценария, ссылки или предложения компромисса, иначе ваш запрос может быть проигнорирован или тема заблокирована.

Ограничение затронет loopback‑соединения, которые сейчас позволяют работать без дополнительных прав, и могут нарушить работу приложений, помогающих людям с ограниченными возможностями, например записывать звонки для сохранения воспоминаний. Разработчик Kitsumed отмечает, что риск редкой утечки данных оправдан, но лишит экосистему инструментов вроде App Manager, aShell и других. Для обсуждения IssueTracker ссылка 526109803; рекомендуется поставить +1 и подписаться на уведомления, а не писать спам‑сообщения. Такой подход позволит собрать реальные отзывы, а не шум, и даст шанс обсудить, как сохранить удобство разработчиков, не снижая безопасность. Это поможет избежать закрытия темы из‑за спама и сохранить диалог открытым.

Пользователи считают, что ограничение доступа к on-device ADB неэффективно против «плохих акторов», которые всегда найдут обходы, и усугубляет ликвидацию открытости Android, ограничивая разработчиков. Некоторые видят в этом шаг Google по ужесточению контроля над устройствами и рекомендуют для обхода ограничений переходить на альтернативные ОС, например Linux.

Ханна Фрай, первая в истории профессор по публичному восприятию математики в Кембридже, получила премию Лейлавати за усиление публичного интереса к математике. Жюри отмечает её как одного из главных глобальных посланников математического мышления, «превращая её в язык чудеса и актуальности без ущерба для глубины». Она говорит: «Когда ты сам наслаждаешься математикой, ощущаешь абсолютную радость; я хочу поделиться тем, что почти невидимо для большинства».

За её работу она получила Emmy в 2025 году за эпизод о квантовых вычислениях, Webby в 2026 году за подкаст «The Rest is Science», более двух миллионов подписчиков в Instagram и попала в список Time 100 в 2026 году; ранее ей вручили Christopher Zeeman Medal (2018) и премию Дэвида Аттенборо (2024). Она проводила Рождественские лекции РИ в 2019 году, читала}Rouse Ball лекцию в Кембридже и участвует в ICM, где объявляются Fields Medals. «Ограничение понимания — не в способности, а в мотивации заботиться», — говорит она, добавляя, что её задача — создать «дырку в воображении», чтобы вызвать жажду следующей детали.

Пользователи подтверждают, что Ханна Фрай заслужила премию Лейлавати за вклад в популяризацию математики и науки. Их отзывы отмечают её способность делать сложные темы доступными и увлекательными: подкаст «The Rest Is Science», сериалы «Contagion» и «Uncharted with Hannah Fry» получают высокую оценку за информативность и развлекательность. Многие делятся, как её контент помог им лучше понять математику, и рекомендуют его другим. Её работа вдохновляет не только зрителей, но и других популяризаторов науки.

Искусственная аналитика измеряет возможности моделей через девять оценок — GDPval‑AA v2, 𝜏³‑Banking, Terminal‑Bench v2.1, SciCode, Humanity’s Last Exam, GPQA Diamond, CritPt, AA‑Omniscience и AA‑LCR, где последние три помечаются светящейся лампочкой как модели‑рассуждающие. Индекс Openness нормализован от 0 до 100, а AA‑Omniscience принимает значения от –100 до 100, при том 0 означает равное число правильных и неверных ответов, а отрицательные баллы — больше ошибок. Метрика AA‑Briefcase Elo объединяет проходку рубрики, аналитическую и презентационную оценки, переводимые в Elo‑баллы.

Время отклика измеряется в секундах до генерации 500 токенов, включающее время получения первого токена, «раздумье» модели‑рассуждающего и скорость вывода; более низкое значение лучше. Стоимость за единицу интеллектуального задания рассчитывается как цена, деленная на полученный интеллектуальный балл, позволяя сравнивать экономию. Размер модели раскрывается двумя цифрами: общее количество параметров (в миллиардах) и активное количество параметров во время вывода, что особенно важно для моделей Mixture‑of‑Experts, где активные параметры существенно меньше общих. Для моделей с открытыми весами размер и активные параметры публикуются. Обзор сочетает балл, скорость и цену, помогая выбрать модель с оптимальным соотношением качества и стоимости.

Тред добавляет опыт эксплуатации Claude Opus 5, GPT-5.6 Sol и Gemini 3.1 Pro, подчеркивая проблемы с цензурой, надежностью и стоимостью, а также обсуждает метрики вроде AA-Omniscience Index. Claude Opus 5 часто срабатывает из-за цензуры и демонстрирует низкую надежность, что снижает его привлекательность, несмотря на высокие показатели в тестах. GPT-5.6 Sol считается лучшим по соотношению цены и качества. Gemini 3.1 Pro эффективен в задачах на знания, но слаб в кодировании и агентных действиях. Пользователи советуют выбирать модель не только по тестовым метрикам, но и с учетом стоимости, надежности и цензуры.

Postgres LISTEN/NOTIFY позволяет реализовать низко‑задержку стриминг в базе, но изначально его масштабируемость ограничивала глобальная эксклюзивная блокировка, которая захватывается при вызове NOTIFY во время коммита транзакции. Эта блокировка гарантирует порядок уведомлений, однако приводит к сильной конкуренции и низкой пропускной способности: в первой версии стримы писали лишь около 2,9 K записей в секунду, при этом ресурсы БД почти не нагружались.

Оптимизация заключается в буферизации уведомлений и их групповой отправке, что снимает блокировку с отдельных записей и позволяет использовать групповой коммит. При этом добавлен fallback‑опрос, чтобы уведомления не терялись при сбое процесса. В результате при нагрузке с несколькими читателями достигается до 60 K записей в секунду с задержкой 15‑100 мс, а процессор загружается, показывая насыщение БД. Такой подход позволил избежать «LISTEN/NOTIFY не масштабируется», потому что блокировка берётся только при очистке буфера, а не при каждой записи, что дает возможность использовать оптимизации Postgres вроде группового коммита. В итоге получилось в 20 раза больше записей, а задержка оставалась в пределах десятков миллисекунд, а процессор загружался, показывая насыщение БД. Исходный код доступен на GitHub, а подробнее — в статье автора.

Тред дополняет статью опытом эксплуатации и возражениями по поводу масштабируемости Postgres LISTEN/NOTIFY, подчеркивая необходимость понимания её ограничений в продакшене. @phamilton отмечает, что в проде LISTEN/NOTIFY эффективно работает с Rust GraphQL-брокером, обрабатывая десятки тысяч подписок всего на 3–4 соединениях. @konstmonst утверждает, что функция не масштабируется и теряет сообщения при высокой нагрузке; @acaloiar опровергает, что многие опасения — от тех, кто её не использовал. @dietr1ch советует ограничивать размер уведомлений для сохранения O(1) и фокусироваться на масштабировании их количества.

Claude Opus 5 — новая модель, доступная сегодня, сочетающая продвинутый, проактивный подход с почти границей интеллекта Claude Fable 5, но по цене в половину дешевле. На Benchmarks Frontier‑Bench v0.1 и CursorBench 3.2 она превосходит все остальные модели, удваивая результат Opus 4.8 при том же стоимости; на ARC‑AGI 3 её score в три раза выше следующей; на Zapier AutomationBench pass‑rate в 1,5 раза превышает конкурентов; на OSWorld 2.0 она превосходит Fable 5 уже при трети стоимости. При том же расходе, что и у Opus 4.8, она показывает значительное улучшение: на organic‑chemistry задачи её точность на 10,2 п.п. выше, а на protein‑задачи — на 7,7 п.п.

Модель умеет проверять собственные ответы и итеративно дорабатывать решения; в тесте без доступа к визуальному вводу она самостоятельно создала pipeline для распознавания пикселей и построения 3D‑модели в FreeCAD, повторив успех многократно. При обнаружении бага в популярном package‑manager’е она нашла корень проблемы, тогда как конкуренты исправили лишь симптом. В API добавлены возможности менять набор инструментов в середине диалога и автоматические fallback‑ы, направляющие запросы, помеченные безопасностью, на альтернативную модель; при этом данные пользователей не хранятся.

Opus 5 превосходит Fable 5 в image-to-code и автономном планировании, демонстрируя лучшую визуальную точность (например, в воспроизведении дизайна кнопок) и проактивность — например, самостоятельно реализовала движок слайдов вместо reveal.js. Она не требует 30-дневного хранения данных, что критично для строгих политик конфиденциальности. Стиль письма сохраняет клише Claude 4.8, в отличие от Fable 5. Однако выявлены критические проблемы: ложные срабатывания в code review (особенно в C/C++, 4 false positives, GPT-5.6-sol справился лучше), неучёт контекста вызовов функций, деградация инфраструктуры — постоянные сбои, потери сессий, HTTP-ошибки, необоснованные блокировки аккаунтов. Удалены полные цепочки рассуждений — осталась только однострочная сводка, снижая аналитическую ценность. Режим 'low' reasoning даёт оптимальное соотношение цена/качество. Fable 5 остаётся лучше в создании идеальных SVG (тест Pelican), а Opus 5 ошибается при редактировании код-планов, проверявшихся ранее GPT-6 Sol. Сафегарды Fable 5 были чрезмерно строги (блокировали медицинскую терминологию); Opus 5, возможно, смягчил это, но поиск уязвимостей в коде всё ещё ограничен. Сравнение с другими моделями: Opus 5 на 10% «умнее» Grok 4.5, но в 10 раз дороже; немного умнее GPT 5.6 Sol при стоимости в 2.75 раза выше — вызывает вопросы о рентабельности. Сложность выбора моделей (модальности, уровни thinking, цены) стимулирует рост рынка routing-сервисов. Частые изменения тарифов, кредитов и метрик намеренно запутывают клиентов, делая сравнение и контроль затрат невозможными. Бенчмарки (Frontier-Bench, AutomationBench) подвергаются сомнению из-за коммерческих интересов Anthropic и партнёров — требуются независимые оценки, хотя скачок на ARC-AGI-3 на 30% считается значимым.

Крупнейшие технологические компании, включая Nvidia, Microsoft, Meta, Palantir и более двадцати партнёров, опубликовали совместное письмо, в котором настоятельно просят избегать преждевременных ограничений на открытые модели ИИ, чтобы не подавлять конкуренцию и не вытеснять развитие за пределы США. Они подчёркивают, что такие модели можно скачивать, модифицировать и запускать на собственной инфраструктуре, что ставит под угрозу закрытые системы, например OpenAI и Anthropic, особенно на фоне роста китайского Kimi K3, который превосходит их по некоторым бенчмаркам. Jensen Huang и Satya Nadella разместили письмо в своих соцсетях, а Элон Мэкск выразил поддержку.

В письме также говорится, что полагаться только на закрытые модели не гарантирует безопасность: они могут быть взломаны, использованы в чужих целях или дать сбой, что трудно отследить извне, тогда как открытая экосистема распределивает риск. Компании предлагают решать вопросы незаконного дистилляции через целенаправленные правовые механизмы, а не через всеобъемлющие запреты на методы, важные для инноваций. Они заявляют, что лидерство в ИИ будет определяться не модели, а способностью США создать открытый рынок, где каждый сектор получит доступ к технологиям, способствуя росту и процветанию.

Участники обсуждения считают, что компании — Nvidia, Microsoft, Meta — поддерживают открытые модели ИИ, чтобы конкурировать с лидерами рынка, такими как OpenAI и Anthropic. Спорят о искренности этих мотивов. Предлагают инвестировать в открытые модели для усиления позиций. Предупреждают, что регулирование открытых моделей может снизить конкуренцию и вытеснить разработку за пределы США. Также обсуждаются риски: кража интеллектуальной собственности и снижение затрат на разработку.